No personal information is shared.

While I do not aggree with pervasive age restrictions, this is a nice technical solution to privacy preserving age verification

The correct flow for preserving anonymity is: the requesting party issues a challenge token to the user -- the token header describes the type of request (>=18yo?) and the token body is completely random(). The user then takes this token and has the challenge verified (signed) on their side, the signed token is then returned to the requester.

This way the state never knows the identity of the challenge issuer.

() Note that this scheme requires good faith on the part of the challenge issuer that the token body is actually random, although it would seem that a simple DH-key mechanism would patch this vulnerability.

You'd know the state they're a legal resident of as they use state-specific keys used for signatures.

If the request allows checking arbitrary ages like Apple's, then you can get their age with a handful of requests. If one has to verify every visit, then you can get exact birthdate eventually.

If the one verifying has to pass data to the verifier site or the request to the verifier has any site/app/company-specific IDs (again, Apple), then you're leaking what you're visiting to the verifier.

And not to beat a dead horse, but as long as there are jurisdictions that don't require age verification in the world, children can easily use a free VPN or proxy to avoid checks altogether at which point, one has to ask, why do it at all?

If you assume a sensible rate limit, that entering the check is voluntary (and unlikely to fail), and that people age monotonically, then it's going to require a lot of cooperation from the victim to get more than a couple of bits of entropy.

I wouldn't trust Apple here regardless, since they are not the state and have their own separate interests.

It seems like this line of thinking would lead you to ask the same question of literally any law, wouldn't it?

Laws often don't rely on being 100%. Even though there is a law saying people need to wear a seat belt, they can just not wear it! So what's the point, &c, &c?

If you use a VPN to visit a porn site to bypass age verification, you haven't broken the law as it applies to sites, not users. There will be no measurable impact on underage people visiting since the barriers to VPNs/proxies are almost nil while still costing money to enforce on non-tech savvy adults - an overall detriment to society.

Laws that are unenforceable and don't benefit society are bad laws.

They won't be able to visit porn sites in their own jurisdiction -- let us call it jurisdiction J -- because those sites have to perform age verification, but they will be able to visit porn sites in other jurisdictions, since they can send traffic that appears to originate in those jurisdictions. Those porn sites are not in J and so don't have to enforce J's rules.

When I think about this situation, though, it just seems like it would lead lawmakers to require VPN sites to perform age verification.

There’s a video halfway down this page showing the process in Apple Wallet: https://learn.wallet.apple/id/ (notice “Age Over 21”)

https://apnews.com/article/utah-app-store-age-verification-7...

https://le.utah.gov/~2025/bills/static/SB0142.html

With an eID card, if it's just saying "yes, this person is old enough" then any teen can swipe a device with an eID card and start using it.

In practice, as it relates to enums, I don't usually see 'no value provided' as a frequently used case - it's more likely that 'no value provided' maps to a more informative 'enum' value

Like - what basic functionality? Does not sound like "browsing" is that functionality and I am not interested in any other functionality. I do not want you (Mozilla organization) to use any of that information.

Moreover, what if I do not have the right to sublicense the content I enter to FF? Am I legally not allowed to use Firefox?

But I agree with you that this should not require specific legal language. However, I point out that most other browsers have already added that same language, or something similar, to their own ToS. As have programs such as Microsoft Office. If you cannot use Firefox then you cannot use any of them either.

Why does Mozilla need to be granted a license to my IP to submit form fields, but curl doesn't? These are just tools, used by me personally. I'm not hiring Mozilla. Mozilla is not a party to my use of their tool.

There's a lot more in there than phishing protection.

* https://en.wikipedia.org/wiki/Bic_(company)

Mozilla has "larger organizational exposure" precisely because they're tracking users and packaging up that data for sale.

Yes. Well, that, and Firefox talks to backend services (updates, safe browsing, etc) to do its job for the user, whereas cURL doesn't.

> Do you actually find it hard to believe that the legal terms attached to cURL are entirely sufficient an that Mozilla is using different terms because Mozilla is planning to take meaningfully different actions with respect to user data?

I've known a lot of Mozilla folks for a long time, so, yes.

Except when you actually read the ToU the controversial, unnecessary license doesn't even talk about Mozilla's services at all.

"It also includes a nonexclusive, royalty-free, worldwide license for the purpose of doing as you request with the content you input in Firefox."

Sorry, this is BS. Nobody was going to win shit from Mozilla for typing a URL into their browser that runs locally on their machine. Where they might have gotten in trouble is with their telemetry (e.g. Pocket), but that’s sort of screaming to the problem that they’re pivoting to spyware.

If anyone claims they need to "store and process" this data, it is explicitly and solely so they can spy on you.

There is absolutely zero requirement of any kind for anyone other than the website to even know you're entering text. There is no reason or excuse for Mozilla to claim otherwise. If Mozilla claims they require a license for text you type into a website, they're lying so they can sell the data you're entering on third party websites.

This is extremely cut and dry. What Mozilla is implying is not how browsers work. This is not how websites work. Mozilla is trying to spy on users and there is no other technically valid explanation.

But I agree that it’s stupid that Mozilla now feels you need to give it explicit permission to do this rather than implicit permission. But since only you own the copyright to the comments you write, maybe I can see the point.

You don't have to give Mozilla permission to store and reproduce what you type into a textarea on a non-Mozilla web site.

If you legally need some license to type into a program on your computer (I don't think so, but let's say you do solely for the sake of imaginary argument) you can just give the license to yourself, no need to involve any third parties at any point here.

If Mozilla says they need a license so you can fill a form in Firefox, then they must've literally forgotten what Free Software even means. I hope this is not true, but merely a misunderstanding of some sort.

Note that the MPL grants you the user many permissions, but does not grant Mozilla any. If Mozilla feels that they need to be explicitly granted more permissions then they have to add that somewhere else. They cannot easily change the text of the MPL.

I think it is dumb that they want _explicit_ permission to do this, when we grant _implicit_ permission to all kinds of programs day in and day out to do the same thing. `less` doesn’t ask for permission when I tell it to display a file to me, it just does it. `curl` doesn’t ask for permission when I tell it to upload the file to a server. Etc, etc.

But check out the ToS for other web browsers, for desktop publishing programs, office suites, email clients, etc, etc. Many of them have similar language. Not all of them, but many.

> But I agree with you that this should not require specific legal language. However, I point out that most other browsers have already added that same language, or something similar, to their own ToS.

Not so you can submit forms to websites (again, this is absurd) but so they can spy on you and do whatever they want with the data they collect, same as what Firefox is trying to gain the legal cover to do (whether they use that cover or not).

Why was the previous state of affairs not sufficient? Hasn’t Firefox been letting me type data into a form for nearly 20 years now, _without_ this language?

If so, Tsst. Bad Mozzila! No!

Seriously though, that would be a huge mistake for a supposedly free software company. Especially when people are realizing the "meh" of the value added with most applications of LLMs.

HashiCorp rug pull level mistake.

This is a silly argument.

If they mean that they should say that.

But also it doesn't seem like they would need permission to store data locally, on your own computer. If it's a matter of using Mozilla Sync, then the TOS would apply to Sync and having a Mozilla account, not for using the browser.

It says “By using Chrome or ChromeOS, you agree to the Google Terms of Service located at https://policies.google.com/terms […]”. The Google Terms of Service at https://policies.google.com/terms?hl=en-US#scope is what you are looking for.

I don’t have the others in front of me.

Plus:

> Some of our services are designed to let you upload, submit, store, send, receive, or share your content. You have no obligation to provide any content to our services and you’re free to choose the content that you want to provide.

In my opinion, it is the result of following qualities:

1. The language direcly supports concepts needed for live WYSIWYG editing (i.e. properties and events) while other languages only simulate it by convention (i.e. Java Bean specification)

2. The language syntax is simple enough for the IDE to understand and modify programatically, but powerful. The properties files that define the forms are even simpler, support crucial features (i.e. references and hierarchy) but do not bring unecessary complexity as general-purpose formats do (XML files or JSON)

3. Batteries included - you can do very powerful stuff with the included components (gui, i/o, ipc, sql, tcp/ip, graphics - all the practical stuff) without hunting for libraries

4. Discoverability - the visual component paradigm with Property editor lets you see all your possibilities without reading the documentation.

5. Extensibility - you can build your own components that fully integrate with the IDE. This is my litmus test for low-code and RAD tools: For any built-in feature, can I recreate the same using the provided tools? Many tools fail this, and the built-in components can do things that are inaccessible to user-defined components.

6. Speed - both compilation and runtime, thanks to one-pass compilation and native code. Leads to fast iteration times.

7. The VCL component architecture is a piece of art. The base classes implement all the common functionality: They automatically manage memory, can store and load persistent state, have properties for visual placement (position, size) etc. The language features really help here (I remebmer something about interface delegation) but there is no magical runtime that does this from the outside, it's an actual implementation of the component that can be extended or overriden.

But of couse there are the ugly things as well: alien syntax, forward declarations, strict compiler blocking the Form Designer on any error preventing you to fix the very error and most of all: while there is very good abstraction for the components, there is none for data and state. There is no good tooling for data modelling and working with the data models. That leads to poor practices as having state in the visual components or in global variables.

> Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses. Packets are routed before the firewall rules can be applied, effectively ignoring your firewall configuration.

So docker is "effectively" ignoring your firewall in the case of ufw. I don't see how it can be considered to not ignoring your firewall when it ignores the rules you've setup.

Does Docker violate the principle of least surprise? Yes. Was I bitten by this behavior? Definitely. Does it bypass the firewall? No.

To be frank, it kind of feels like the kind of technical nitpick argument I'd read from a Docker Inc employee trying to somehow defend ignoring the user's firewall.

The end result is that you setup rules in UFW, and Docker ignores them.

It's not. This technique is more about getting text on the screen in the easiest way possible for debugging. You just add some data to your shader and poof, you get text.

The converse is, you write code to generate a font atlas (so more work), or go find and existing one and need to load it (so need to write loading code so more work). And/Or draw a full message into a texture (more work) and you'll need to cache that result until the message changes (more work)

On top of all of that, you need to manage resources and bind them into the system where as here no resources are needed.

but again, it's a technique for getting "debugging text" on the screen. It is not a solution for text in general.

Note that drawing text to textures is how most browsers and OSes work. They draw fonts into texture atlases dynamically (since a atlas for all of Unicode per font per size would take too much time and memory). They then use the texture atlas glyphs to make more textures of portions of the app's window. In the browser you can turn on show texture edges to see all textures. Rendering->Layer borders will outline each texture in cyan

Drawing using a glyph atlas is still a way better use of resources. Modern text rendering pipelines will also often use either SDF or encoded bezier curves to improve glyph legibility when scaling which is also a great way of saving more memory.

Regarding the upload part: at the end of the day, you have X bytes of glyphs and they need to get into GPU memory somehow. Whether you get them there as textures, as uniform data or as shader constants doesn't really matter performance-wise. If anything, doing it through shader constants as described in TFA is more expensive on the CPU side, since all those constant declarations need to be processed by the shader compiler.

What does matter on the GPU side is which memory hierarchy you hit when reading glyph data (texture fetches have a dedicated L1 cache on most GPUs, larger than the "normal" L1 cache I think) and what order the data is in (textures are usually stored in some version of Morton order to avoid cache misses when you're shading blocks of pixels). For a production atlas-based text renderer you probably want to use textures.

Edit: I misread the question; you were asking about drawing individual glyphs on the GPU vs. drawing an entire block of text on the CPU, right? This is a speed/space tradeoff, the answer is going to depend on how much memory you want to blow on text, whether your text changes, whether it needs to have per-character effects applied, and so on.

FWIW, this method is also a texture despite being called “texture-less”; the texture is just stored in a different format and a different place. True textureless font rendering evaluates the vector curves on the fly.