Hacker News new | ask | show | jobs
by tzs 111 days ago
This law doesn't do anything that prevents non-anonymous access. Here's how you would access things anonymously if you bought a new computer that implemented this.

1. When you set up your account and it asks for your birthdate, make up any date you want that is at least far enough in the past to indicate an age older that what any site you might use that checks age requires.

2. Access things the way you've always done. All that has changed is that things that care about age checks find out you claim to be old enough.

The only people it actually materially affects on your new computer are people who cannot set up their own accounts, such as children if you have set up permissions so they have to get you to make their accounts.

Then if you want you can enter a birthdate that gives an age that says non-adult, so sites that check age will block them.

From a privacy and anonymity perspective this is essentially equivalent to sites that ask "Are you 18+?" and let you in if you click "yes" and block you if you click "no". It is just doing the asking locally and caching the result.

3 comments

As with all age verification bills, the fact that developers are opened up to liability if children access content they're not "supposed to" means that facial scans and ID checks will be implemented as they currently are everywhere.

From the bill:

> (3) (A) Except as provided in subparagraph (B), a developer shall treat a signal received pursuant to this title as the primary indicator of a user’s age range for purposes of determining the user’s age.

> (B) If a developer has internal clear and convincing information that a user’s age is different than the age indicated by a signal received pursuant to this title, the developer shall use that information as the primary indicator of the user’s age.

It's not enough to just accept the age signal, you can still be liable if you have reason to believe someone is underage based on other information.

The cheapest and easiest way to minimize that liability is with face scans and ID checks. That way you, as a developer, know that your users won't bankrupt you.

Sounds like if the OS doesn't track anything else about the user, then it won't receive any other signals and will just use whatever was typed in at account creation.

If websites accept this as age verification it could provide a very easy way to bypass it.

In fact, looking at it again, point B specifically says if the "developer" has information rather than the "system" has information. So really sounds like if the developer isn't collecting logs that they can access themselves this wouldn't apply to them.

The cheapest and easiest way to minimize liability is not to collect any information not needed to actually provide the service you are providing.
I agree. I feel the flow of having browsers send some flag to sites is the most privacy-preserving approach to this whole topic. The system owner creates a “child” account that has the flag set by the OS and prevents the execution of unsanctioned software.

This puts the responsibility back on parents to do the bare minimum required in moderating their child’s activities.

What would be even more privacy preserving would be to mandate sites to send age appropriateness headers (mainstream porn sites already do this voluntarily).

Possibly it could be further mandated that the OS collect relevant rating information for each account and provide APIs with which browsers and other software could implement filtering.

And possibly it could be further mandated that web browsers adopt support for this filtering standard.

And if you want a really crazy idea you could pass a law mandating that parents configure parental controls on devices of children under (say) 12 and attach civil penalties for repeated failure to do so.

There's never any need for information about the user to be sent off to third parties, nor should we adopt schemes that will inevitably provide ammo for those advocating attested digital platforms.

I think you would find widespread support from the various websites out there for this. Most porn websites today voluntarily implement some type of mechanism that advertises them as not for children.
The issue is how does the browser know the age bracket of the user in question so it knows to not load content with those headers? The API this bill mandates is the missing half to make those headers actually useful without specialized browsers/3rd party plugins.
So does Google send a header for each search result when you look up "Ron Jeremy" so that some results get hidden, or does the browser just block the whole page?

Sending all the "bad" data to the client and hoping the client does the right thing outs a lot of complexity on the client. A lot easier to know things are working if the bad data doesn't ever get sent to the client - it can't display what it didn't get.

Google would send a header that it is appropriate for all ages (I'm not sure how the safe search toggle would interact with this, the idea is just a rough sketch after all).

When you click on a search result, you load a new page on a different website. The new page would once again come with a header indicating the content rating. This header would be attached to all pages by law. It would be sent every time you load any page.

Assuming that the actual problem here is the difficulty of implementing reliable content filtering (ala parental controls) then the minimally invasive solution is to institute an open standard that enables any piece of software to easily implement the desired functionality. You can then further pass legislation requiring (for example) that certain classes of website (ex social media) include an indication of this as part of the header.

Concretely, an example header might look like "X-Content-Filter: 13,social-media". If it were legally mandated that all websites send such it would become trivially easy to implement filtering on device since you could simply block any site that failed to send it.

> A lot easier to know things are working if ...

Which is followed by wanting an attested OS (to make sure the value is reliably reported), followed by a process for a third party to verify a government issued ID (since the user might have lied), followed by ...

It's entirely the wrong mentality. It isn't necessary for solving the actual problem, it mandates the leaking of personal data, and it opens an entire can of worms regarding verification of reported fact.

Yes this is a really simple fix. The first line if your post says it all. If they really wanted to protect children, you would put the responsibility on the services on the other end. This is about mass surveillance or disadvantaging open source solutions
If browsers are going to send flags, they should only send a flag if its a minor. Otherwise is another point of tracking data that can be used for fingerprinting.
If you send a flag ever, then absence of a flag is also fingerprinting surface.

If you imagine a world where you have a header, Accepts-Adult-Content, which takes a boolean value: you essentially have three possibilities: ?0, ?1, and absent.

How useful of a tracking signal those three options provide depends on what else is being sent —

For example, if someone is stuffing a huge amount of fingerprinting data into the User-Agent string, then this header probably doesn’t actually change anything of the posture.

As another example, if you’re in a regular browser with much of the UA string frozen, and ignoring all other headers for now, then it depends on how likely the users with that UA string to have each option: if all users of that browser always send ?0 (if they indicate themselves to be a minor) or ?1 (if they indicate themselves to be an adult or decline to indicate anything), then a request with that UA and it absent is significantly more noteworthy — because the browser wouldn’t send it — and more likely to be meaningful fingerprinting surface.

That said, adding any of this as passive fingerprinting surface seems like an idea unlikely to be worthwhile.

If you want even a weak signal, it would be much better to require user interaction for it.

I'm not sure it's worth entertaining these hypotheticals. Just another absurd CA law that's impossible to comply with. "When you set up your account and it asks for your birthdate." What does this mean? "Setup" what account? "It" what? Some graphical installer? What if I don't want to use one? How would this protocol be implemented in such a way where it's not trivially easy for the user to alter the "age signal" before sending a request? The "signal" is signed with some secret that you attest to but can't write? So it's in some enclave? What if my smart toaster doesn't have an enclave? Does my toaster now have to implement software enclave? I'm not aware of a standard, or industry standards body, or standard specification, or implementation of a specification, around this "age signal" thing. Is this some proprietary technology that some company has a patent on, and they've been lobbying for their patent to be legally mandated? If so that's very concerning and probably has antitrust implications (it is ironic that ever-tightening surveillance of people is a downstream consequence of all this deregulation of corporate persons; fine for me but not for thee I guess). I would love to know the full story here, since this is being shopped around in several states, but I haven't seen any sort of investigative journalism about this which is disappointing. This whole thing is really curious.
Most of these questions are actually answered in the law itself. You could be your own investigator in seconds.

https://leginfo.legislature.ca.gov/faces/billTextClient.xhtm...

Your toaster is not impacted. You’re turning a law that, yes, has some open questions around implementation, into a way bigger scare and conspiracy.

> operating system provider, as defined, to provide an accessible interface at account setup that requires an account holder, as defined, to indicate the birth date, age, or both, of the user of that device for the purpose of providing a signal regarding the user’s age bracket to applications available in a covered application store and to provide a developer, as defined, who has requested a signal with respect to a particular user with a digital signal via a reasonably consistent real-time application programming interface regarding whether a user is in any of several age brackets, as prescribed. The bill would require a developer to request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.

Let’s be honest here. 99% of general purpose computing devices targeted at consumers make an “account” when you setup for the first time. Even Linux if just to name a home directory. It’s pretty obvious what an account is. Especially when it only applies to bundled app stores. What App Store has no account anyways?

It allows the operating system to define the interface. No patent or proprietary system. No surveillance. The law says user interface. Not graphical interface. Do with that as you will. A OS producer who has an App Store probably has a graphical interface, but if not they surely figured out how to interface with users already.

It actually requires operating systems and developers to not abuse this data or use it for anticompetitive purposes.

There is no attestation. It’s entirely self reported and unverified.

You should follow your own advice.

Their definition of "app store" is a mile wide: "(e) (1) “Covered application store” means a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications from third-party developers to users of a computer, a mobile device, or any other general purpose computing that can access a covered application store or can download an application."

Grats, github is an appstore. apt-get is an app store. You posting software on your own website is an app store.

GitHub isn’t an app stores associated with an operating system though. Your personal website is most likely not in scope. You have to put all the pieces together.

Apt… yes is an App Store run by an operating system organization (Debian org). That feels pretty unsurprising. Debian’s parent organization (headquartered in the US) probably needs to comply with this.

> Apt… yes is an App Store run by an operating system organization (Debian org). That feels pretty unsurprising. Debian’s parent organization (headquartered in the US) probably needs to comply with this.

And that right there is exactly the fucking problem. A zero profit collective “store” that publishes zero profit hobbyist “apps” is now going to have to invest in some kind of harebrained compliance scheme that will only grow from here.

In a couple of years is my “app” in Debian’s store going to require some goddamn TPS report and certification to tell California that everything is above board? It’s incredibly likely! By itself this law does nothing but lay the groundwork for regulation of “apps”, which by itself might be acceptable, but including FOSS distribution channels and hobby apps in the scope of this law is nothing short of evil. It’s laying the groundwork for a frontal assault on FOSS, and if you don’t see that then I don’t know what to tell you.

My guess is that Linux wasn’t extensively considered in the writing of this law, but when the next stage comes along and people start complaining, legislators will shrug and say “oh well, they need to comply”—and lobbyists for the big 3 proprietary software firms will back that position up. This is setting up a killshot for consumer Linux.

Where in that definition does it say the app store must be associated with an OS?