Yes, just like the do-not-track bit. That could change if courts start treating these bits as a "no, I do not consent to any tracking" statement. What if it was illegal to track users with this bit set?

"Tracking" becomes a little more subtle for websites that try to maintain some per-visitor state in order to function. But if it were well defined legally, it could probably be a really nice move for the sake of peoples' privacy.

Of course, that only helps with agents subject to the relevant laws.

Which, one would hope, Google is.

There's a reason big tech companies have entire PR departments with "We can do better™" statements ready to go.

Sometimes I wonder if there are cynical teams in Google or Facebook who implement features and also write public apologies for those features ahead of time.

Maybe the really advanced ones have PR statements that say "Oh, this feature sounds bad but it only really does this thing which is mostly okay" and then another one for "okay yeah you caught us it doesn't just do that okay thing but all the other not okay stuff you worried it did ahead of time".

I'm sure there are entire machine learning teams working out the best way to word these non-apologies and the best schedule for releasing them to best soften the impact of getting caught with their hands in the (literal or figurative) cookie jar.

I think the reality is much simpler. There's nobody in Google writing public apologies in parallel to implementing features. Through the magic of free market economy, they can just outsource it. Some court frowns at what they're doing? A quick call to a reputation management company (which they probably have on a retainer, or at least on speed dial), and they get all the press releases and training they need to manage the crisis. Why do it in house, if you can have experts do it for you?

Much like testing what would happen if a migration script dropped a column, features need to be tested against the possible outcomes in the court of opinion. I expect a well-organized corporate to have Product Owners who design the packaging of the feature and have it reviewed by the higher-ups when it’s a user-facing feature, or to design the apology letter and have it reviewed by the higher-ups when it’s an advertiser-facing feature.

But it’s our role as a society to not be gullible, and eventually organize against such behaviors, which this judge is doing.

If it just sets the "do not track" header, you don't necessarily know whether the user is in private browsing or just always has that enabled. I think adding the extra identifying bit to the sea of identifying information would be worth it if we had regulation (with teeth!) around what sites were/were not allowed to do with "do not track" on.

The header takes the values DNT=null (user didn’t specify), DNT=0 (can track), or DNT=1. We could have DNT=2 (really do not track?). Why not DNT=3 (“please disregard my login even if I attempt to”?).

Why would incognito mode be any more detectable? If it's a question of not giving access to certain data that could be used for fingerprinting (e.g. user agent, screen resolution, storage API, statistics of accelerometer noise, gyroscope drift rate), the browser should respond with fake data instead of no data.

There's a lot of data that doesn't need to be present, or presented, without user approval. The info at https://browserleaks.com/ is just... ridiculously detailed.

I don't see why a website should be able to get information about my WebGL capabilities without me being asked first if I want to let them display content, or why they can get a list of audio and video input devices without asking to use them first.

Even on Firefox, which I think is generally doing a much better job about this stuff, there's so amazingly much data that shouldn't be shared without asking first.

> why they can get a list of audio and video input devices without asking to use them first

I don't think they can do this without audio/video permissions (?)

The problem is that you cannot just add a new permission and expect things to not break. The flow for requesting permissions is different and would break pretty much every website that uses these APIs.