Comment by tzs

1 day 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.

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.

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.

    • 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

    • 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.

      1 reply →

    • 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.

      1 reply →

  • 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.

      2 replies →