The problem with this specific design is that it reveals your identity to the site, which is obviously undesirable from a privacy perspective.
For those who are interested one of my recent newsletter posts goes into a fair amount of detail about the various technical options here for using digital IDs in this context: https://educatedguesswork.org/posts/age-verification-id/
In this case the ZKPs are tied to a private key stored in a secure element in the phone, so effectively they are tied to control of the device where the original credential was enrolled.
That's nice and all for the cryptography but now think about what's needed to associate it with the physical attribute (such as the age) of the user of the device which may or may not change hands over time.
The Google system is tied to a mobile driver's license, and there is an identity check at enrollment that is intended to tie the credential to the device. It's true that if you give someone access to your phone without erasing it, then they can potentially use this mechanism to circumvent age assurance. This is true for a number of other age assurance mechanisms (e.g., credit card-based validation).
In any case, I'm not really interested in getting into an argument with you about the level of assurance provided by this system and whether it's "trivial to abuse" or not. I was merely describing the way the system worked in case people were interested.
The suitability of the remedy (ZKP) for the purpose of age assurance is the entire problem. The non-cryptographic aspects cannot be handwaved away as something not worth discussing when they're the primary area of concern here.
You're arguing with something I'm not saying. I didn't handwave anything away or say it wasn't worth discussing. I simply described how the system was designed.
But they must allow some kind of proxy signing so that you can sign in from other devices besides the phone. So how do you protect against misuse of that feature without logging any identifiers?
Running improvement isn't actually like this, except for beginners.
First, you actually do quite a bit of periodization at the season level, so you might have a long base block, followed by a more stamina/quality oriented block, then race specific sharpening, followed by taper and an A race, and then rest. Improvement is distinctly non-linear across these phases, and you'll actually start each season fairly far behind where you were at your peak.
There are also plateau effects, where you've basically adapted as much as you can to an existing stimulus and you need to find new ways of triggering adaptation.
Right. Basically, beginners in any sport are naive to effectively all training stimuli, and so they will respond to a wide variety of inputs.
Once you get adapted it gets harder and harder to find new stimuli that will trigger new adaptation without breaking you down too much. If you're interested in running, Steve Magness and Jonathan Marcus talk about this quite a bit in the On Coaching podcast (https://www.scienceofrunning.com/podcast-2?v=47e5dceea252).
This is actually true for many forms of physical training, including not just strength training but also endurance training (running, etc.) Plateaus and injuries aside, the basic principle of training is overload followed by recovery, and it's not uncommon during the overload phase to have high levels of fatigue and minimal improvement if not regression.
This is something a lot of casual athletes don't notice because there is a very steep development curve for the untrained, so you just getting better very quickly. Once you have been training for years, gains come much slower.
For example, I recently attended the IETF meeting in Montreal--practically the epicenter of v6 thinking--which offers a by default v6-only network. My Mac worked fine, but my son's school-issued Chromebook had glitchy behavior until I switched to the network that provided v4.
For example, I recently attended the IETF meeting in Montreal, which offers a by default v6-only network. My Mac worked fine, but my son's school-issued Chromebook had glitchy behavior until I switched to the network that provided v4.
Sounds like exactly the sort of thing the IETF's IPv6-only network is trying to shake out.
I went to IETF a few years ago and ran into issues on their IPv6 only network because I host some stuff from home, and my residential ISP doesn't support IPv6 at all. It made me really want to get all that fixed.
> Why should I be required to download and ignore your translation feature, when I could just as easily not have it included in the first place?
This seems like special pleading. The browser (and any software package) is full of features that some people use and others don't. Just off the top of my head, these include: the password manager, PDF viewer, dev tools, and the extensions store. Each new SKU that the vendor has to provide is additional effort to build and test, and the result is that it's more expensive to produce the product. Moreover, it makes it harder for users to discover new features what they might want (oh, you wanted view source, you needed Firefox developer edition).
On the specific case of translation, I don't really see much of a distinction between "I need to browse" and "I want to read content that is not in a language that the content provider has supported for me". In both cases, I want to get the content on the site and I'd like the browser to help me do it.
> I don't mind being the minority, I just don't think it's inappropriate to ask for only what I need instead of "all the bullshit you want to force me to have".
And you can have that by building it yourself. It's open source software. What you're really asking for is for Mozilla to build a version of the software that has only the features you personally want.
lol. I didn't ask for SKUs, I asked for plugins. I wouldn't mind the dev tools, and PDF viewer being plugins too. Again, include those plugins in the default download, just let me have a download that doesn't include them. Modularity to the bone, packaging for the masses. It really is that easy.
But, sure, I need to go build it myself because I had the gall to ask "can't I just have the parts I need?"
> lol. I didn't ask for SKUs, I asked for plugins. I wouldn't mind the dev tools, and PDF viewer being plugins too. Again, include those plugins in the default download, just let me have a download that doesn't include them. Modularity to the bone, packaging for the masses.
This is in fact you asking for two SKUs, one with all the plugins (what you call the "default download") and one without ("let me have a download that doesn't include them.")
As for "really is that easy", as usual, it's easy in some cases and not others. To the extent to which things are already modular and developed separately, then yes, it probably is easy. To the extent that things are not currently modular, then it's separate engineering effort to make them so. In some cases that effort might be small (e.g., the new module is all in HTML/JS) and in some cases that effort might be large (e.g., there is extensive C/C++ code that needs to interface with the browser core). I don't know how much about Firefox's AI features to know which category they fall into. But it's almost certainly not zero effort in any case.
For those who are interested one of my recent newsletter posts goes into a fair amount of detail about the various technical options here for using digital IDs in this context: https://educatedguesswork.org/posts/age-verification-id/
reply