Skip to content

Navigation Menu

Toggle navigation

Sign in

Appearance settings

Platform

AI CODE CREATION

GitHub CopilotWrite better code with AI

GitHub SparkBuild and deploy intelligent apps

GitHub ModelsManage and compare prompts

MCP RegistryNewIntegrate external tools

DEVELOPER WORKFLOWS

ActionsAutomate any workflow

CodespacesInstant dev environments

IssuesPlan and track work

Code ReviewManage code changes

APPLICATION SECURITY

GitHub Advanced SecurityFind and fix vulnerabilities

Code securitySecure your code as you build

Secret protectionStop leaks before they start

EXPLORE

Why GitHub

Documentation

Blog

Changelog

Marketplace

View all features

Solutions

BY COMPANY SIZE

Enterprises

Small and medium teams

Startups

Nonprofits

BY USE CASE

App Modernization

DevSecOps

DevOps

CI/CD

View all use cases

BY INDUSTRY

Healthcare

Financial services

Manufacturing

Government

View all industries

View all solutions

Resources

EXPLORE BY TOPIC

AI

Software Development

DevOps

Security

View all topics

EXPLORE BY TYPE

Customer stories

Events & webinars

Ebooks & reports

Business insights

GitHub Skills

SUPPORT & SERVICES

Documentation

Customer support

Community forum

Trust center

Partners

View all resources

Open Source

COMMUNITY

GitHub SponsorsFund open source developers

PROGRAMS

Security Lab

Maintainer Community

Accelerator

GitHub Stars

Archive Program

REPOSITORIES

Topics

Trending

Collections

Enterprise

ENTERPRISE SOLUTIONS

Enterprise platformAI-powered developer platform

AVAILABLE ADD-ONS

GitHub Advanced SecurityEnterprise-grade security features

Copilot for BusinessEnterprise-grade AI features

Premium SupportEnterprise-grade 24/7 support

Pricing

Search or jump to...

Search code, repositories, users, issues, pull requests...

Search

Clear

Search syntax tips

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

Sign in

Sign up

Appearance settings

Resetting focus

You signed in with another tab or window. Reload to refresh your session.
You signed out in another tab or window. Reload to refresh your session.
You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

flatpak

/

xdg-desktop-portal

Public

Notifications
You must be signed in to change notification settings

Fork
242

Star
789

Code

Issues
173

Pull requests
42

Discussions

Actions

Projects

Wiki

Security and quality
0

Insights

Additional navigation options

Code

Issues

Pull requests

Discussions

Actions

Projects

Wiki

Security and quality

Insights

Draft: Add parental controls to the Accounts portal#1922

Open

davidedmundson wants to merge 1 commit intoflatpak:mainflatpak/xdg-desktop-portal:mainfrom
davidedmundson:work/d_ed/user_agedavidedmundson/xdg-desktop-portal:work/d_ed/user_ageCopy head branch name to clipboard

+535Lines changed: 535 additions & 0 deletions

Conversation82 (82)Commits1 (1)Checks5 (5)Files changed12 (12)

Open

Draft: Add parental controls to the Accounts portal#1922
davidedmundson wants to merge 1 commit intoflatpak:mainflatpak/xdg-desktop-portal:mainfrom
davidedmundson:work/d_ed/user_agedavidedmundson/xdg-desktop-portal:work/d_ed/user_ageCopy head branch name to clipboard

Conversation

Copy link

Copy Markdown

Contributor

davidedmundson

commented

Mar 2, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Applications need to filter content to match the age rating of the user.

The rating restrictions tend to be location and domain specific without

a common ground for where these groupings should be. Instead

applications provide a range of gates and the implementation returns

which group they are between.

This change is somewhat influenced by the new California law to make public API available but it's something we want to be pushing for anyway to allow applications to perform relevant filtering.

Draft as I haven't tested the complete stack. Implementation is mostly a copy/paste of GetUserDetails.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

1
PlasmaPower reacted with thumbs up emoji

57
mkljczk, Daxorinator, nnnn20430, YarosMallorca, sewnie, localspook, pedropaulosuzuki, TobiKuik, xerydian, Person-Who-Exists, and 47 more reacted with thumbs down emoji

All reactions

1 reaction

57 reactions

Copy link

Copy Markdown

Contributor

Author

davidedmundson

commented

Mar 2, 2026

Someone on a mailing list linked something clever:

https://developer.apple.com/documentation/declaredagerange/

It seems that what they do is that apps will send an array containing 3 age gates and their API responds with two ints, a lower bound and upper bound. The values of the lower and upper bounds will be either -1 or the value of one of the gates you sent. Lower is the lowest age gate they exceed and upper is the highest age gate they are below. For example:

Quoting Danielle:

I send the api an array of [9, 13, 16].

If the API responds [9, 16], the child is older than 9 but under 16.
If the API responds [-1, 16], the child is under 9
If the API responds [16, -1], the child is over 16.

it's not super intuitive, but pretty clever. I can pivot to that.

2
mcrampon and uwuclara reacted with thumbs down emoji

7
danirabbit, zspencer, CarlSchwan, ArrayBolt3, dylanmtaylor, xerydian, and jthoward64-lexcelon reacted with heart emoji

All reactions

2 reactions

7 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

danirabbit

mentioned this pull request

Mar 2, 2026

Comply with California Age Verification law
elementary/settings-useraccounts#260

Open

2 tasks

Copy link

Copy Markdown

EtchedPixels

commented

Mar 2, 2026

Asking the users age outside of California and handing it out to arbitrary applications may violate the law in other jurisdictions so your implementation needs to ensure they are in California

5
swedneck, isage, uwuclara, DSKVL, and janderssonse reacted with thumbs up emoji

All reactions

5 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

davidedmundson

force-pushed
the

work/d_ed/user_age

branch
from
4bd4327 to
bd1eda3
Compare

March 2, 2026 19:32

Copy link

Copy Markdown

Contributor

Author

davidedmundson

commented

Mar 2, 2026

Asking the users age outside of California and handing it out to arbitrary applications may violate the law in other jurisdictions so your implementation needs to ensure they are in California

Parental controls exist in almost all countries and something we definitely want available everywhere.

Whether that should be available for every app without prompts is potentially up for debate, but I don't see how it affects this PR, that can be an implementation detail for the backend.

4
danirabbit, kurisubrooks, mansaliacom, and dylanmtaylor reacted with thumbs up emoji

14
vinajuliette, jelemux, Bryntet, swedneck, peazip, mcrampon, isage, Encore6122, dae550, sersonz, and 4 more reacted with thumbs down emoji

All reactions

4 reactions

14 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

Author

davidedmundson

commented

Mar 2, 2026

One TODO is that the point of Apple's 3 arg API (rather than 2 args N times) is presumably to rate limit it so that can't just bisect an exact value. That's probably the job of this portal?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

swick

commented

Mar 3, 2026

/cc @pwithnall @ignapk

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

swick

commented

Mar 3, 2026

but I don't see how it affects this PR, that can be an implementation detail for the backend.

Let's not make things behave completely different for no reason.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

swick

commented

Mar 3, 2026

Another thing: we're trying to move towards static permissions to use a portal. In this case, there should be a permission in the app manifest, where without it, the call always fails.

2
davidedmundson and pedropaulosuzuki reacted with thumbs up emoji

All reactions

2 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

EtchedPixels

commented

Mar 3, 2026

Even a daily rate limit on the query means an app will discover child dates of birth on the day they transition between age classes. That means it does disclose date of birth exactly (and I think unfixably while in compliance with California as it stands). That means things like GDPR apply in Europe, and as it may be data from a minor must also be handled in accordance with other (eg US state) laws on processing data for children under 13.

I'm not saying it's a bad idea to have parental control - but that you have compliance and regulatory issues to deal with that are rather more complicated than just "it's an API" and the API has to be able to deal with those compliance issues (eg returning a "not permitted" status). The Apple approach doesn't appear to fix the problem.

The API also needs geolocation or some kind of regulatory locale information in order to figure out what answer ranges are permitted. California for example requires

"Send only the minimum amount of information necessary to comply with this title and shall not share the digital signal information with a third party for a purpose not required by this title."

So sending age information outside of the four categories in 1798.501 (a)(2) appears tbe be a violation of 1798.501 (a)(3) because the law was rather badly drafted.

5
schrmh, ninakali, Bryntet, swedneck, and janderssonse reacted with thumbs up emoji

All reactions

5 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

Author

davidedmundson

commented

Mar 3, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Another thing: we're trying to move towards static permissions to use a portal. In this case, there should be a permission in the app manifest, where without it, the call always fails.

Done.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

davidedmundson

force-pushed
the

work/d_ed/user_age

branch
from
bd1eda3 to
b646cf8
Compare

March 3, 2026 13:14

Copy link

Copy Markdown

Collaborator

swick

commented

Mar 3, 2026

Sorry, should have been more specific. We want the flatpak manifest to statically define that it should have access to use the portal. This means specifically that an app must have a key based on Policy https://docs.flatpak.org/en/latest/flatpak-command-reference.html#policy-metadata in its manifest, and the XdpAppInfo needs a method to query if the key is set, and deny the request otherwise.

1
davidedmundson reacted with thumbs up emoji

All reactions

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

pwithnall

commented

Mar 3, 2026

I haven’t read the law, am not a lawyer, and do not reside in California, but one approach to not giving out the user’s date of birth might be to bias the DoB returned to the app with a unique random offset (which differs per app, but is deterministic). The offset would be within a range big enough to make the date of birth useless for the app if it’s trying to impersonate the user, but small enough to not meaningfully affect age restrictions on app content. If it’s needed to comply with age restriction laws, then the offset could always be positive (i.e. always makes the user appear a bit younger than they actually are) rather than evenly distributed around zero.

I haven’t checked if this would comply with the law, but it might be worth considering for whoever is thinking about this.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

AdrianVovk

commented

Mar 3, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

We gotta be careful with fudging the users age. I don't think it's a good idea to fudge it into the "younger than they really are" direction is because apps will unfairly lock people out of content they otherwise should be able to access.

Let's say John is a 15 year old kid. His parents promised him that they'll get him the hot new FPS game, ForkKnife, for his 16th birthday. ForkKnife is age rated to 16+, and so by law it's required to use age verification to check that the user is 16+. On John's 16th birthday his parents buy him ForkKnife and the game is installed. He wants to play it with his friends that evening. But alas: due to our privacy measure, John has to wait some unknown number of days before ForkKnife is told that he's over 16 and he's allowed to play the game

5
davidedmundson, Adowrath, dylanmtaylor, DEiselt, and swedneck reacted with thumbs up emoji

All reactions

5 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

AdrianVovk

commented

Mar 3, 2026

Note that the Apple API has the following note:

When geo-specific ranges are required, the returned age range reflects regulatory requirements rather than the bounds of your age gates.

So... really the ranges you pass into the app don't matter very much? They will be ignored anyway, and the API will just return what it's legally required to return

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

Author

davidedmundson

commented

Mar 3, 2026

So... really the ranges you pass into the app don't matter very much? They will be ignored anyway, and the API will just return what it's legally required to return

They've definitely approached this in a way to allows them flexibility if they ever need it.

I struggle to believe that comment gets applied in most countries.

In the UK:

video games are PEGI rated which is 3,7,12,16,18

films have a 12, 15 and 18 rating

social media platforms that have rules at 13+

I'm pretty close to all the numbers in the teens at this point and individual apps/services could have their own policy different from the minimum.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Conan-Kudo

commented

Mar 3, 2026

Mississippi has a similar law for online services to denote them 18+ AFAIK

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

AdrianVovk

commented

Mar 3, 2026

Hmm. Well it probably doesn't hurt to put in the ability to give ranges and then choose to ignore it later. Hell, we could probably make it optional - if an app doesn't specify a range we give the legally required range and be done

Then we should let apps give more than three ages in the range. I can totally imagine a state having a law that requires ranges like this: [13, 15, 17, 18, 21] (under 13, 13-15, 15-17, 17-18, 18-21, 21+)

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

AdrianVovk

reviewed

Mar 3, 2026

View reviewed changes

data/org.freedesktop.impl.portal.Account.xml

Outdated

The following results get returned via the @results vardict:

* ``low`` (``i``) and ``high`` (``i``)

Copy link

Copy Markdown

Collaborator

AdrianVovk

Mar 3, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Hmm, should the portal backend just return the real age? And then the frontend can handle all the range calculation?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Copy link

Copy Markdown

ArrayBolt3

Mar 4, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

The real age might not be known by any application on the system, frontend, backend, or otherwise. Some portal implementations will want to (need to) store only just enough information for age bracket signals to work legally while not storing any information that could be used to fingerprint the user if the device becomes infected by malware. (Whonix is the primary system that will need this functionality, and it is essential enough that we will potentially have to make our own custom implementation if a standard implementation does not take this into account.)

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

1
schrmh reacted with heart emoji

1
davidedmundson reacted with rocket emoji

All reactions

1 reaction

1 reaction

Copy link

Copy Markdown

Collaborator

AdrianVovk

Mar 4, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Hmm fair enough. But then the age gates requested by the frontend should be passed into the backend as well, and the backend should be totally responsible for implementing all of the logic here. This weird hybrid situation where the backend returns a range and then the portal tries to mangle it into another range won't actually work.

Like if the backend says "the user is between 15 and 17". Then the app tries to query with gates of (13, 16, 18). What should the portal do? The user might be 15, and the portal should return (13,16). Or the user might be almost 17, and then the portal should return (16,18).

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Copy link

Copy Markdown

Collaborator

AdrianVovk

Mar 4, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Alternatively, we just drop the ability for the app to provide gates that it's looking for, as I suggested before. They seem to complicate the design here, and I don't think there's actually a good idea of how they'd be used?

It's just an opportunity for apps to be abusive. Like: we need to consider an app that would also send gates [13, 14, 15, 16, 17, 18] to just get the user's exact age and use that for whatever illicit purpose. How would we deal with that? How would we even detect it?

So if we ultimately must ignore the app's age gates, then I don't really see a reason to include them in the spec. After all: unlike Apple here, our API takes an a{sv} so we can add arbitrary arguments to the function call later, if we decide that it's necessary

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Copy link

Copy Markdown

Collaborator

AdrianVovk

Mar 5, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Also: the backend might only know an age range, but it could just return the bottom of that range to the frontend when asked. If your distro only knows that the user is between 16-18, then you can just safely tell the frontend that the user is 16 (you know that they are at least 16, so you won't ever over-report their age).

Basically I think it might be useful to centralize the actual compliance bits (the map of location -> mandated age gates) in the frontend, so that desktops don't have to worry about getting it right individually. This means that the backend giving the frontend a range will have the same issues as I described above: what if the range spans multiple legally-required ranges?

If you report a single age that's the bottom age of your range, then you'll always fall into a range that's the age of your user, or younger. Which is the only thing you can do given the lack of information.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Copy link

Copy Markdown

ArrayBolt3

Mar 5, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Valid point. The backend probably has to be responsible for doing all of it then. If we did stick with the "turn one range into another range", the only legally safe thing to do would be to stick with the lower bound and treat that as a canonical age value. That's not great for the reasons you pointed out above (unfair restriction of some app features), but for some distros that's an acceptable compromise because of the importance of other goals.

Edit: This was originally in reply to #1922 (comment)

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Copy link

Copy Markdown

ArrayBolt3

Mar 5, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Alternatively, we just drop the ability for the app to provide gates that it's looking for, as I suggested before. They seem to complicate the design here, and I don't think there's actually a good idea of how they'd be used?

That sort of removes the "parental controls" aspect from this and leaves it as little more than a compliance mechanism. It leaves the age brackets entirely up to the desktop, and while some desktops may want to specify the age brackets exactly, that might not make sense in every scenario.

If it was to be nothing but a compliance mechanism, it might be good to pair it with a standardized way of tracking what age brackets are required by each jurisdiction. I have a concept for that, but I think it's orthogonal to the portal implementation and probably not something go into here. That would be more suited for a tzdata-like project.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Copy link

Copy Markdown

ArrayBolt3

Mar 5, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Heh, I read further and see you thought of a centralized database already. I have a non-xdg-desktop-portal implementation spec draft I was going to send to the XDG mailing list before I ran into this. Maybe it's worth posting anyway in case some of the ideas are useful here?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

1
AdrianVovk reacted with thumbs up emoji

All reactions

1 reaction

Copy link

Copy Markdown

Conan-Kudo

commented

Mar 3, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

In the US, TV has parental guidelines, films have MPA ratings, and games have ESRB ratings.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

pwithnall

commented

Mar 3, 2026

The other way to approach this would be to turn it on its head, and instead of having a portal which tells apps what age the user is, instead have a portal which apps can query to tell them whether content which has a certain rating should be shown to the user.

gnome-software, AppStream and malcontent use the OARS ratings system for tagging content with what might be age-restricted about it. This has a mapping to a CSM age (which is international), and that has mappings to most countries’ national ratings systems, and is designed for web content as well as games and films.

That would avoid directly revealing the user’s age (problems would still exist on the transition between two age categories), but would perhaps map better to the implied use case here, which is filtering content in apps?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

AdrianVovk

commented

Mar 3, 2026

The other way to approach this would be to turn it on its head, and instead of having a portal which tells apps what age the user is, instead have a portal which apps can query to tell them whether content which has a certain rating should be shown to the user.

This would be non-compliant with the law. The law specifically talks about age ranges

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

pwithnall

commented

Mar 3, 2026

Perhaps an approach would be to design the portal API based on the use cases we think are useful for apps to use wrt parental controls and content filtering, and then bolt on something to make the legislature of California happy afterwards? Designing a stable portal API purely to satisfy a law from one state of one country, which people here seems to think is not well drafted, is probably not maintainable.

2
warriordog and Red-Teapot reacted with thumbs up emoji

All reactions

2 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

Author

davidedmundson

commented

Mar 3, 2026

Perhaps an approach would be to design the portal API based on the use cases we think are useful for apps to use wrt parental controls [...]

Agreed.

What we want for generic parental controls a way for apps/services to query if the current user is within arbitrary age ranges.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

danirabbit

commented

Mar 3, 2026

The other way to approach this would be to turn it on its head, and instead of having a portal which tells apps what age the user is, instead have a portal which apps can query to tell them whether content which has a certain rating should be shown to the user.

@pwithnall thats what this does. The app sends up to 3 age gates and then the portal responds. You can send just one gate :)

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

Author

davidedmundson

commented

Mar 3, 2026

he app sends up to 3 age gates and then the portal responds. You can send just one gate :)

That's what this should do :) I currently have 3 gates mandatory. I either need to allow -1's or do an array.

2
AdrianVovk and danirabbit reacted with thumbs up emoji

All reactions

2 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor

pwithnall

commented

Mar 3, 2026

What we want for generic parental controls a way for apps/services to query if the current user is within arbitrary age ranges.

Sorry, but that’s not a use case, that’s an API specification.

I’m guessing (based on having spent several years working on parental controls and content filtering) that the use cases here (for ‘parental controls’ as a portal) would be more like the following, but you may have other specific and unstated use cases in mind which motivated this PR in the first place:

“Sandboxed game library app needs to be able to hide games based on national age certification metadata (e.g. PEGI game rating) associated with the app”

“Sandboxed wiki browser app needs to be able to filter wiki pages based on content tags (e.g. OARS attributes) to hide ones which cover age-inappropriate themes”

“Parent wants to preserve the privacy of their child by not exposing their child’s personal data to untrusted apps or the internet”

“Sandboxed app needs to be able to determine whether to show gambling-related content (OARS tag money-gambling) to the user, but not show it to them if they’re too young or are a recovering gambling addict” (there is crossover here, as in many places, with more general wellbeing controls)

“State requires that apps are clearly made aware of when a user is under a certain age of consent”

“Parent wants to apply parental controls to their child’s use of the computer, but wants to be able to override some filtering in specific sandboxed apps as they disagree with that filtering, or know their child is mature enough to handle that specific content”

“Parent wants to broadly know what kinds of content might be shown to their child by a given sandboxed app before letting their child access it”

“Parent wants to broadly know what kinds of content their child has been accessing through a given sandboxed app, to keep an eye on their computer usage and adjust parental controls settings accordingly”

“Sandboxed app needs to be able to determine whether to allow chat with unknown people on the internet (OARS tags social-*)”

“Sandboxed app needs to be able to determine whether to submit user’s social media handles when sharing content with a website, as a child might have an Instagram account from age 13, but their parents might not want apps sharing that handle when sharing content elsewhere”

Many of these will not be relevant to most apps. The kinds of apps where they might be relevant are ones which expose libraries of online content or user-generated content, ones which wrap websites, and ones which allow chat with other people. I strongly encourage anyone thinking about designing a portal like this to play around with the OARS generator to see the kinds of attributes which are considered relevant.

Or, to state things from a different angle: if app developers have to map every decision into a “what age range is this appropriate for”, then (a) that means the policy for “what content is acceptable” is determined inside each app, and there is potentially no consistency between them, and (b) you’ll rapidly run into conflicts where some content will be rated for one age range in one country, but a slightly different age range in another, with no way to reconcile that.

The solution is to filter content based on its OARS attributes (basically, a list of the things which might make it filterable in different countries, and their intensity), and leave the policy of how that maps to different age ranges in different countries up to the portal implementation rather than the apps.

You may morally disagree with some of the use cases above, but they all come from conversations with parents and previous work on parental controls. Some of them may end up being out of scope here, but I think it’s worth considering them as a bigger picture if someone’s going to design a ‘parental controls’ portal, otherwise we’ll end up implementing something which satisfies lawmakers in California and nobody else.

The other way to approach this would be to turn it on its head, and instead of having a portal which tells apps what age the user is, instead have a portal which apps can query to tell them whether content which has a certain rating should be shown to the user.

@pwithnall thats what this does. The app sends up to 3 age gates and then the portal responds. You can send just one gate :)

Maybe I should have been clearer: by ‘content rating’ I was thinking of OARS attributes, not age ratings.

1
schrmh reacted with thumbs up emoji

All reactions

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

AdrianVovk

commented

Mar 3, 2026

Designing a stable portal API purely to satisfy a law from one state of one country, which people here seems to think is not well drafted, is probably not maintainable.

It's not just one state. Colorodo has a nearly identical law. The EU is working towards an OS age verification framework as well, as far as I understand.

If these laws get overturned, then the API could start to tell apps that the age range is [-1, -1). It might do that in regions where there is no legal requirement for OS-level age verification anyways.

Note that there's a cost to making this API overly restrictive. Apps, to comply with the laws, will turn to significantly more privacy invasive solutions like asking users directly, in the app, to scan their face or upload their ID. They might also start asking for the user's location, just to know what laws they need to comply with. This is something to consider. I trust the OS much more than every individual app. Especially on our platform

That's what this should do :) I currently have 3 gates mandatory. I either need to allow -1's or do an array.

An array seems most flexible, as I've pointed out above. Different states may have a different number of gates to check.

you may have other specific and unstated use cases in mind which motivated this PR in the first place:

In my opinion, the legal compliance side of things and the "ideal API we want" are two separate issues. What Philip is saying totally applies, I agree with it, and we should have that in a "Parental Controls" portal.

But we also, for legal reasons, need to have an "Age Verification" feature in our portals. This is distinct from the parental controls case. I think to avoid confusion we should not call what we have here parental controls, and call it age verification. Especially because future legislation may require more from the OS vendor. For instance: if the EU sets up some anonymous government service that checks your ID and spits out some one-time signed token an app can use to verify that the user is, indeed over a certain range, then an "age verification" portal would need to talk to this API while a parental controls portal wouldn't

3
danirabbit, pwithnall, and dylanmtaylor reacted with thumbs up emoji

3
nnnn20430, peazip, and sersonz reacted with thumbs down emoji

All reactions

3 reactions

3 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

danirabbit

commented

Mar 3, 2026

I think to avoid confusion we should not call what we have here parental controls, and call it age verification

I agree with this 100%. We should have better content-based parental controls as a separate API because that's probably the right thing to do for parents, but we must have a declared age range API because that's what lawmakers are demanding we do.

For instance: if the EU sets up some anonymous government service that checks your ID

The apple implementation also returns an enum that describes the age set method. I'm not sure if we want to jump ahead to including this information in v1 https://developer.apple.com/documentation/declaredagerange/agerangeservice/agerangedeclaration

1
pwithnall reacted with thumbs up emoji

4
nnnn20430, sersonz, nguyendoan15082006, and silverhadch reacted with thumbs down emoji

All reactions

1 reaction

4 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

42 hidden items

Load more…

Copy link

Copy Markdown

nnnn20430

commented

Mar 6, 2026

Designing a stable portal API purely to satisfy a law from one state of one country, which people here seems to think is not well drafted, is probably not maintainable.

It's not just one state. Colorodo has a nearly identical law. The EU is working towards an OS age verification framework as well, as far as I understand.

If these laws get overturned, then the API could start to tell apps that the age range is [-1, -1). It might do that in regions where there is no legal requirement for OS-level age verification anyways.

Note that there's a cost to making this API overly restrictive. Apps, to comply with the laws, will turn to significantly more privacy invasive solutions like asking users directly, in the app, to scan their face or upload their ID. They might also start asking for the user's location, just to know what laws they need to comply with. This is something to consider. I trust the OS much more than every individual app. Especially on our platform

That's what this should do :) I currently have 3 gates mandatory. I either need to allow -1's or do an array.

An array seems most flexible, as I've pointed out above. Different states may have a different number of gates to check.

you may have other specific and unstated use cases in mind which motivated this PR in the first place:

In my opinion, the legal compliance side of things and the "ideal API we want" are two separate issues. What Philip is saying totally applies, I agree with it, and we should have that in a "Parental Controls" portal.

But we also, for legal reasons, need to have an "Age Verification" feature in our portals. This is distinct from the parental controls case. I think to avoid confusion we should not call what we have here parental controls, and call it age verification. Especially because future legislation may require more from the OS vendor. For instance: if the EU sets up some anonymous government service that checks your ID and spits out some one-time signed token an app can use to verify that the user is, indeed over a certain range, then an "age verification" portal would need to talk to this API while a parental controls portal wouldn't

I think it is much better to ban such privacy violating app from any free software distribution, than to placate and hope that if you give it enough user data in a controlled way the developers will be nice enough not to violate the users privacy or freedom any further.

11
silverhadch, AutumnRivers, warriordog, ggemre, jelemux, Bryntet, swedneck, Red-Teapot, sersonz, AidasLit, and veneficium42 reacted with thumbs up emoji

1
swedneck reacted with rocket emoji

All reactions

11 reactions

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

dylanmtaylor

mentioned this pull request

Mar 6, 2026

Age group as an optional alternative to birthdate for age verification (userdb: add ageGroup field to JSON user records)
systemd/systemd#40974

Closed

Add parental controls to the Accounts portal

…

Loading

Loading status checks…

Uh oh!

There was an error while loading. Please reload this page.

c750405

Applications need to filter content to match the age of the user.

The rating restrictions tend to be location and domain specific without
a common ground for where these groupings should be. Instead
applications provide a range of gates and the implementation returns
which group they are between.

This change is somewhat influenced by the new California law to make
public API available but it's something we want to be pushing for anyway
to allow applications to perform relevant filtering.

davidedmundson

force-pushed
the

work/d_ed/user_age

branch
from
b646cf8 to
c750405
Compare

March 6, 2026 16:51

danirabbit

reviewed

Mar 6, 2026

View reviewed changes

data/org.freedesktop.impl.portal.ParentalControls.xml

org.freedesktop.impl.portal.ParentalControls:

@short_description: Backend for the ParentalControls portal

-->

<interface name="org.freedesktop.impl.portal.ParentalControls">

Copy link

Copy Markdown

danirabbit

Mar 6, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Just wanted to note here that there was some discussion that seemed to indicate a consensus around not calling this ParentalControls and instead using specifically AgeVerification since we might want a more content-focused parental controls API and there's hope of age verification maybe being deprecated someday

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

1
dylanmtaylor reacted with thumbs up emoji

All reactions

1 reaction

Copy link

Copy Markdown

Contributor

Author

davidedmundson

Mar 6, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

There's a few too many discussions!

I know there was consensus to split from Accounts which I've done and I know there was consensus that OARS permissions is something we want to forward and should be a separate method.

I'm not sure what we gain from effectively going for one method per portal. They can still have separate permissions and I can't think of a non ParentalControl reason to be interested in age.

It's not a hill I'll fight over if there is consensus from others.

One key point I would push against is we should steer clear of the word "verification" given we don't really promise that.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

1
danirabbit reacted with heart emoji

All reactions

1 reaction

Copy link

Copy Markdown

Collaborator

AdrianVovk

Mar 6, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

I'm not sure what we gain from effectively going for one method per portal. They can still have separate permissions and I can't think of a non ParentalControl reason to be interested in age.

I'd put it in its own portal, distinct from parental controls, because if the laws go away we can deprecate the API and the portal entirely. Also, we don't know what kind of laws will exist in the future, and we may want to add additional functionality to the portal that's only really usable for age verification.

For instance: Apple has APIs to present a confirmation dialog. This dialog would explain some sort of major changes that happened to an app, and would require a parent to confirm that the app should still be allowed to run for their child. If we need to implement an API like this, that'd be another method to add to the age verification portal.

Also, IMO, if you're interested in parental controls you're not actually interested in age. If you're interested in parental controls, you want to know what kind of content restrictions the parent has set up for their child. Or the user has set for themself. Neither has to do with age. Really the only reason you'd be interested in age is to comply with these laws.

One key point I would push against is we should steer clear of the word "verification" given we don't really promise that

We can call it AgeRange or AgeSignals? Apple calls it the "Declared Age Range API". Google's API is called "Play Age Signals API". Windows calls it the "Age Consent API"

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

3
pwithnall, danirabbit, and dylanmtaylor reacted with thumbs up emoji

All reactions

3 reactions

Copy link

Copy Markdown

pedropaulosuzuki

Mar 6, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

Agreed, there is no point in calling this "Parental control" if there is no control and only age is being passed, instead of flags for what should or not be allowed for that account. Parents should be able to disable contents based on flags, like "Violence", "Online chat", "Gambling", and so on.

While age-range makes sense, maybe we should call this what it really is: age-telemetry/age-surveillance.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Copy link

Copy Markdown

Contributor

Author

davidedmundson

Mar 6, 2026

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

I'll move it so we have the most flexibility moving forwards.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

dylanmtaylor

mentioned this pull request

Mar 6, 2026

identity: add birthDate field to user provisioning [DRAFT]
canonical/ubuntu-desktop-provision#1338

Closed

AdrianVovk

mentioned this pull request

Mar 6, 2026

user: add required birth date field to non-root user creation
archlinux/archinstall#4290

Draft

dylanmtaylor

mentioned this pull request

Mar 6, 2026

postinst: write BirthDate to target AccountsService keyfile
canonical/ubuntu-desktop-provision#1339

Closed

This comment was marked as off-topic.

Sign in to view

Copy link

Copy Markdown

Bryntet

commented

Mar 10, 2026

commercially reasonable age assurance

For an open source project, there is no commercially reasonable age assurance, open source is not commerce.

1
swedneck reacted with thumbs up emoji

All reactions

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

HaplessIdiot

commented

Mar 10, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

The framing of this as a privacy-preserving mechanism deserves scrutiny.

In practice, to get home internet service you sign a contract with your ISP so your identity is already on file. To get a mobile plan, a carrier verified your ID at activation. The device this portal runs on is, in most jurisdictions and most real-world use cases, already tethered to a verified identity long before any app calls GetParentalControls or GetAgeVerification

What this API actually does is normalize the OS as a trusted intermediary for identity attestation a role that, once baked into a D-Bus interface under the org.freedesktop namespace, will not be walked back. Legislators in California, Colorado, Brazil, and New York are already citing each other's laws. The [-1, -1] fallback that's supposed to protect users in non-mandating jurisdictions will last exactly until the next legislative session.

The argument that "if we don't do this, apps will do something worse" is worth acknowledging, but it's also the exact argument used to justify every expansion of surveillance infrastructure. The ISP knows who you are. The carrier knows who you are. The app store account knows who you are. Adding an OS-level age signal as a standard freedesktop API doesn't improve privacy; it adds a new, standardized, queryable surface to an identity graph that already exists.

If the goal is genuine parental controls, a parent configuring content restrictions on their child's account, that's a local user-controlled setting that needs no identity attestation at all. Malcontent does this without involving government-mandated age ranges or cross-app queryable signals.

This PR conflates two distinct things: parental controls (a privacy-preserving, locally scoped feature) and age verification compliance (a government mandate to expose user age to third-party apps). They should not share an interface, and the latter should not be dressed up as the former.

9
Bryntet, xronin01, sersonz, swedneck, Red-Teapot, mcrampon, isage, AidasLit, and gkatev reacted with thumbs up emoji

All reactions

9 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

sersonz

commented

Mar 10, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

The framing of this as a privacy-preserving mechanism deserves scrutiny.

In practice, to get home internet service you sign a contract with your ISP so your identity is already on file. To get a mobile plan, a carrier verified your ID at activation. The device this portal runs on is, in most jurisdictions and most real-world use cases, already tethered to a verified identity long before any app calls GetParentalControls or GetAgeVerification

What this API actually does is normalize the OS as a trusted intermediary for identity attestation a role that, once baked into a D-Bus interface under the org.freedesktop namespace, will not be walked back. Legislators in California, Colorado, Brazil, and New York are already citing each other's laws. The [-1, -1] fallback that's supposed to protect users in non-mandating jurisdictions will last exactly until the next legislative session.

The argument that "if we don't do this, apps will do something worse" is worth acknowledging, but it's also the exact argument used to justify every expansion of surveillance infrastructure. The ISP knows who you are. The carrier knows who you are. The app store account knows who you are. Adding an OS-level age signal as a standard freedesktop API doesn't improve privacy; it adds a new, standardized, queryable surface to an identity graph that already exists.

If the goal is genuine parental controls, a parent configuring content restrictions on their child's account, that's a local user-controlled setting that needs no identity attestation at all. Malcontent does this without involving government-mandated age ranges or cross-app queryable signals.

This PR conflates two distinct things: parental controls (a privacy-preserving, locally scoped feature) and age verification compliance (a government mandate to expose user age to third-party apps). They should not share an interface, and the latter should not be dressed up as the former.

Completely agree. It's disappointing to see so many people who really should know better complying in advance with legislation that (at least in the US) will trivially be held to be unconstitutional. (NB: I would be fine with malicious compliance that consists of intercepting all program executions and forcing the user to manually input their age, but that's definitely out of scope of XDG and probably technically malware.)

3
Bryntet, xronin01, and HaplessIdiot reacted with thumbs up emoji

1
HaplessIdiot reacted with hooray emoji

1
HaplessIdiot reacted with heart emoji

1
HaplessIdiot reacted with rocket emoji

All reactions

3 reactions

1 reaction

1 reaction

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

jackpot51

suggested changes

Mar 10, 2026

View reviewed changes

Copy link

Copy Markdown

jackpot51

left a comment

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason

Spam
Abuse
Off Topic
Outdated
Duplicate
Resolved
Low Quality

Hide comment

On behalf of System76, Pop!_OS, and COSMIC I would urge you to avoid over-eager implementation of these laws. They are still being discussed and have the potential for amendments that could significantly reduce requirements on open source operating systems.

For example: https://fosstodon.org/@carlrichell/116201429639953387

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

3
HaplessIdiot, Bryntet, and sersonz reacted with thumbs up emoji

2
HaplessIdiot and sersonz reacted with hooray emoji

3
Bryntet, xronin01, and HaplessIdiot reacted with heart emoji

1
HaplessIdiot reacted with rocket emoji

All reactions

3 reactions

2 reactions

3 reactions

1 reaction

Copy link

Copy Markdown

qwertviop

commented

Mar 10, 2026

@HaplessIdiot Can you stop making posts on Reddit calling for people to go to linked PRs (here or on the FDO GitLab) and spam the comments? This is really not helping anyone (but that is rather the point I suspect).

7
sersonz, Bryntet, HaplessIdiot, isage, mcrampon, uwuclara, and skylt reacted with thumbs down emoji

2
Bryntet and HaplessIdiot reacted with confused emoji

All reactions

7 reactions

2 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

sersonz

commented

Mar 10, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

@HaplessIdiot Can you stop making posts on Reddit calling for people to go to linked PRs (here or on the FDO GitLab) and spam the comments? This is really not helping anyone (but that is rather the point I suspect).

I think it's actually entirely reasonable to suggest that people use their voice to oppose load-bearing parts of the ecosystem complying in advance with bad law.

4
Bryntet, xronin01, HaplessIdiot, and mcrampon reacted with thumbs up emoji

1
HaplessIdiot reacted with heart emoji

All reactions

4 reactions

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Bryntet

commented

Mar 10, 2026

•

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

@HaplessIdiot Can you stop making posts on Reddit calling for people to go to linked PRs (here or on the FDO GitLab) and spam the comments? This is really not helping anyone (but that is rather the point I suspect).

Letting things like this through without scrutiny won't help anyone either.

1
HaplessIdiot reacted with thumbs up emoji

1
HaplessIdiot reacted with hooray emoji

1
HaplessIdiot reacted with heart emoji

1
HaplessIdiot reacted with rocket emoji

All reactions

1 reaction

1 reaction

1 reaction

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

This comment was marked as off-topic.

Sign in to view

Copy link

Copy Markdown

qwertviop

commented

Mar 10, 2026

@sersonz If it's constructive, yes. But you don't achieve that by asking people on social media to go into the comment section on GitHub

1
davidedmundson reacted with thumbs up emoji

4
sersonz, HaplessIdiot, isage, and mcrampon reacted with thumbs down emoji

1
Bryntet reacted with confused emoji

All reactions

1 reaction

4 reactions

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Bryntet

commented

Mar 10, 2026

@sersonz If it's constructive, yes. But you don't achieve that by asking people on social media to go into the comment section on GitHub

How do you achieve constructive discussion around this then? Would you prefer to converse via email? I am open to any medium.

1
HaplessIdiot reacted with thumbs up emoji

1
HaplessIdiot reacted with hooray emoji

1
HaplessIdiot reacted with heart emoji

1
HaplessIdiot reacted with rocket emoji

All reactions

1 reaction

1 reaction

1 reaction

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

This comment was marked as off-topic.

Sign in to view

Copy link

Copy Markdown

danirabbit

commented

Mar 10, 2026

I keep seeing people saying things like "complying in advance" or "over-eager implementation". If you just heard about this and have little experience trying to contribute to freedesktop I can understand this perspective. But keep in mind that for some of us it's been 5 months already of waiting and seeing (the california law passed in October of last year) and it can take a very long time to get things merged into freedesktop. My last contribution took about a year to get merged.

Plus we have to think about LTS distros which will be expected to comply, this is something that's already been brought up if you've been following the conversation but I'll repeat it. We don't need to just have something ready by January, we need to have something ready in time for LTS release windows

If we do nothing right now, we will certainly miss the Jan 1 deadline and that will mean the end of many projects—selfishly like mine—who don't have the legal resources of a large company like system76. I'd like to continue being able to pay my rent personally. It's much easier to patch something out in the event the law changes and imo much more foolish to do nothing at all when the laws already exist and the consequences of not following them are existential

2
mcrampon and sersonz reacted with thumbs down emoji

All reactions

2 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

qwertviop

commented

Mar 10, 2026

If it was a sane PR it wouldn't need to be hidden from the public eye now would it?

It's not "hidden from the public eye". It's a public PR in a public repository. What it needs is people arguing about the issue in good faith, not with the intention of harassing devs or derailing discussions.

How do you achieve constructive discussion around this then? Would you prefer to converse via email? I am open to any medium.

I'm not arguing against discussing issues in comments to a PR (although I do think policy discussions are better done over mailing lists), I'm arguing against asking laypeople on social media to go flame others on Github.

1
sersonz reacted with thumbs down emoji

All reactions

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

sersonz

commented

Mar 10, 2026

If it was a sane PR it wouldn't need to be hidden from the public eye now would it?

It's not "hidden from the public eye". It's a public PR in a public repository. What it needs is people arguing about the issue in good faith, not with the intention of harassing devs or derailing discussions.

Nobody here is harassing devs or derailing. I certainly think that there's a significant moral hazard that attaches to devs for complying, but that doesn't mean I'm harassing devs.

How do you achieve constructive discussion around this then? Would you prefer to converse via email? I am open to any medium.

I'm not arguing against discussing issues in comments to a PR (although I do think policy discussions are better done over mailing lists), I'm arguing against asking laypeople on social media to go flame others on Github.

Good thing HaplessIdiot didn't "ask laypeople on social media to go flame others on Github", then.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

This comment was marked as off-topic.

Sign in to view

Copy link

Copy Markdown

HaplessIdiot

commented

Mar 10, 2026

I keep seeing people saying things like "complying in advance" or "over-eager implementation". If you just heard about this and have little experience trying to contribute to freedesktop I can understand this perspective. But keep in mind that for some of us it's been 5 months already of waiting and seeing (the california law passed in October of last year) and it can take a very long time to get things merged into freedesktop. My last contribution took about a year to get merged.

Plus we have to think about LTS distros which will be expected to comply, this is something that's already been brought up if you've been following the conversation but I'll repeat it. We don't need to just have something ready by January, we need to have something ready in time for LTS release windows

If we do nothing right now, we will certainly miss the Jan 1 deadline and that will mean the end of many projects—selfishly like mine—who don't have the legal resources of a large company like system76. I'd like to continue being able to pay my rent personally. It's much easier to patch something out in the event the law changes and imo much more foolish to do nothing at all when the laws already exist and the consequences of not following them are existential

The urgency argument cuts both ways. Yes, freedesktop moves slowly. However, that is precisely why rushing a spec under deadline pressure is dangerous. A half-baked interface merged in haste becomes the de facto standard everyone lives with for a decade. The LTS argument supports doing something right, not just doing something fast.

On legal reality: California's DAAA primarily targets platforms and app stores, not desktop infrastructure. The existential liability you're describing almost certainly doesn't flow from whether this D-Bus interface exists by January. A spec that hasn't been through proper security review could expand your exposure, not reduce it.

There's also a simpler path worth considering: freedesktop.org is a nonprofit, and nonprofit incorporation jurisdiction is easier to change than most people realize, often three pages of paperwork available online. Hosting the project under a legal framework in a jurisdiction whose laws are more constitutional and humane is a legitimate option that sidesteps the compliance question entirely rather than baking surveillance infrastructure into the Linux desktop to satisfy one state's overreaching mandate.

"Easier to patch out later" undersells how sticky adopted infrastructure becomes. Distros ship it, apps depend on it, and suddenly removal is a multi-year migration. We've seen this before.

4
sersonz, mcrampon, gkatev, and Bryntet reacted with thumbs up emoji

All reactions

4 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

This comment was marked as off-topic.

Sign in to view

This comment was marked as off-topic.

Sign in to view

Copy link

Copy Markdown

Member

GeorgesStavracas

commented

Mar 10, 2026

This is very unfortunate and I'm sorry about it, but to avoid the influx of comments from non-contributors coming here from an uncalled for call to action in social media, I'll lock this thread for a few days.

2
Bryntet and sersonz reacted with thumbs down emoji

1
sersonz reacted with laugh emoji

All reactions

2 reactions

1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

This comment was marked as off-topic.

Sign in to view

flatpak

locked as too heated and limited conversation to collaborators

Mar 10, 2026

Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.

Reviewers

AdrianVovk

AdrianVovk left review comments

+5 more reviewers

dylanmtaylor

dylanmtaylor left review comments

danirabbit

danirabbit left review comments

pedropaulosuzuki

pedropaulosuzuki left review comments

ArrayBolt3

ArrayBolt3 left review comments

jackpot51

jackpot51 requested changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

None yet

20 participants

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Footer

© 2026 GitHub, Inc.

Footer navigation

Terms

Privacy

Security

Status

Community

Docs

Contact

Manage cookies

Do not share my personal information

You can’t perform that action at this time.