101–110 of 116 posts
I would rather have all this information (along with whatever is being inferred from them) be exposed through a Javascript API instead of having browsers indiscriminately flood global networks with potential PII. Chrome came up with this? Figures. Stay evil, Google.
> "User Agents MUST return the empty string for model if mobileness is false. User Agents MUST return the empty string for model even if mobileness is true, except on platforms where the model is typically exposed." (quoted from https://wicg.github.io/ua-client-hints/#user-agent-model ) Honestly now - who drafts and approves these specs? Not only does it make no sense whatsoever to encode such information this way -…
Why/how does this waste bandwidth? These are opt-in, so they are only sent if requested. I mean sure http being plaintext is silly but that's not down to the authors of this particular rfc.
Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints? If they're going to (which is more than likely, let's not kid ourselves) - I don't see how your point holds?
> "Why/how does this waste bandwidth?"
Based on the current proposal - non-mobile browsers or browsers that simply do not wish to expose the specific model are somehow required to return the following header in response:
Sec-CH-UA-Model: ""
Earlier quoted context omitted.
That's private browsing currently. Why not use a private window?
Because i might want cookies on this page, gmail and reddit, and nowhere else. This would mean me starting a private window, googling something, finding a link on reddit, opening it, either logging in again, or copying the link to a non-private window, commenting, closing that window, and back to search results.
Earlier quoted context omitted.
There were people promising to implement it. That's a lot better than nothing.
Is it? The whole point to this thread is that none of the big players stood by their "promises" for longer than a few months. Especially Google's hypocrisy of promoting DNT in Chrome and knowing full well their adtech teams would ignore it as soon as they had an excuse. (Microsoft and Mozilla enabling it by default sure was a "good" excuse, despite that obviously being the best interest of the users.)
Earlier quoted context omitted.
Is it? The whole point to this thread is that none of the big players stood by their "promises" for longer than a few months. Especially Google's hypocrisy of promoting DNT in Chrome and knowing full well their adtech teams would ignore it as soon as they had an excuse. (Microsoft and Mozilla enabling it by default sure was a "good" excuse, despite that obviously being the best interest of the users.)
It's possible they were looking for an excuse and lying. But enabling it by default definitely seemed to defeat the entire point of the fragile agreement. It doesn't matter to them whether it's better for users.
Earlier quoted context omitted.
Why/how does this waste bandwidth? These are opt-in, so they are only sent if requested. I mean sure http being plaintext is silly but that's not down to the authors of this particular rfc.
> "These are opt-in, so they are only sent if requested." Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints? If they're going to (which is more than likely, let's not kid ourselves) - I don't see how your point holds? > "Why/how does this waste bandwidth?" Based on the current proposal - non-mobile browsers or browsers that simply do not wish to…
Possibly, but they only need them on initial request I think.
> It would convey the exact same information to the server ("my Sec-CH-UA-Model is empty"), without the overhead of sending additional data.
It doesn't commit the exact same info though. This says "the client is aware of this scheme and doesn't reply, vs the client is unaware of the rfc. It's the true/false/none issue.
In a sane world, there would be auch shorter way to encode that, but http is a bad protocol so you can't nest/namespace things or whatever.
Earlier quoted context omitted.
> "These are opt-in, so they are only sent if requested." Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints? If they're going to (which is more than likely, let's not kid ourselves) - I don't see how your point holds? > "Why/how does this waste bandwidth?" Based on the current proposal - non-mobile browsers or browsers that simply do not wish to…
> Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints? Possibly, but they only need them on initial request I think. > It would convey the exact same information to the server ("my Sec-CH-UA-Model is empty"), without the overhead of sending additional data. It doesn't commit the exact same info though. This says "the client is aware of this scheme…
I don't see how this is going work.
If this is data the backend needs the client is either going to have to send it out on every request (like it does today with the User-Agent header) - or the client will only send it out once, and the response would be cached by the backend somehow. The requirement to cache this data on the backend is non-trivial to implement and is a huge paradigm shift. That's actually another pitfall with the RFC in a sense.
> It doesn't commit the exact same info though. This says "the client is aware of this scheme and doesn't reply, vs the client is unaware of the rfc. It's the true/false/none issue."
This doesn't make any sense to me whatsoever.
The "scheme" is what we make it out to be. If the scheme would allow for omitting headers (as it should have) - then the client would be in compliance with the scheme, wouldn't it?
By designing an RFC which allows for omitting headers we actually resolve the ambiguity between "false" and "none": the data is either explicitly there, or it's not.
I'm simply claiming that the scheme as currently proposed is nonsensical and negligent. At Chrome's scale - I expect each proposal to introduce more headers and data to every request to be very carefully weighed against impact on global bandwidth consumption and resource utilization (and energy use). I don't feel like any of that is reflected in this RFC, which is an absolute shame and a big part of the problem: we keep piling up more crap thinking "it doesn't really make a difference". I think it reflects poorly on the people involved with designing and building this.
Perhaps we should mandate providing these numbers explicitly with every RFC so that we can know how much the implementation actually "costs" in terms of bandwidth, memory, etc at the web's scale. This should help identify RFCs like this one which are seriously off on the engineering side of things.
Earlier quoted context omitted.
> Are google.com, youtube.com, netflix.com, facebook.com, amazon.com and reddit.com going to ask for User Agent Client Hints? Possibly, but they only need them on initial request I think. > It would convey the exact same information to the server ("my Sec-CH-UA-Model is empty"), without the overhead of sending additional data. It doesn't commit the exact same info though. This says "the client is aware of this scheme…
> "Possibly, but they only need them on initial request I think." I don't see how this is going work. If this is data the backend needs the client is either going to have to send it out on every request (like it does today with the User-Agent header) - or the client will only send it out once, and the response would be cached by the backend somehow. The requirement to cache this data on the backend is non-trivial to…
The point is that a server may care about the difference between "I am explicitly opting out of giving you this information" and "What are you talking about".
Also keep in mind that Chrome, when communicating with Amazon, Google, or Netflix probably uses HTTP/2 or HTTP/3, which would compress the headers, making much of your complaint moot. I'd expect `Sec-CH-UA-{foo}: ""` to compress very well.
Earlier quoted context omitted.
It's possible they were looking for an excuse and lying. But enabling it by default definitely seemed to defeat the entire point of the fragile agreement. It doesn't matter to them whether it's better for users.
My entire point is that if it was a "fragile agreement" it wasn't in good faith and it was lying and waiting for any excuse to break it, by definition. It doesn't matter what excuse broke it. It was always a bad faith attempt to score some regulatory points and it was never about actually doing good for users. They never should have offered a "standard" for such a "fragile agreement" they didn't really believe in, an…
I haven't seen any particularly compelling evidence it wasn't in good faith.
It was an "attempt to score some regulatory points and it was never about actually doing good for users". But that was always obvious because it was companies doing it.
It still would have done good if it was implemented.
Earlier quoted context omitted.
My entire point is that if it was a "fragile agreement" it wasn't in good faith and it was lying and waiting for any excuse to break it, by definition. It doesn't matter what excuse broke it. It was always a bad faith attempt to score some regulatory points and it was never about actually doing good for users. They never should have offered a "standard" for such a "fragile agreement" they didn't really believe in, an…
I meant a fragile good faith agreement. I haven't seen any particularly compelling evidence it wasn't in good faith. It was an "attempt to score some regulatory points and it was never about actually doing good for users". But that was always obvious because it was companies doing it. It still would have done good if it was implemented.
It's not a good faith agreement if "we agree to do this only so long as the setting to enable it is in the sub-sub-basement of the browser locked in a closet marked 'Beware of Leopard'". If it wasn't "oh no a browser enabled it by default" it would have been "oh no a tutorial went viral on social media telling people how there isn't really a leopard and that everyone should just open that closet and click the button", because again the excuse doesn't matter why they stopped supporting it they never planned to support it for more than the theory of it. There's always some other excuse. It was only ever a "heisenberg feature": it can either not be used or it could just not exist. I'm saying it's not possible at all to design a "heisenberg feature" like that in any possible definition of "good faith". If it wasn't designed to be used by even a paltry 5% of users at the time they balked and stopped supporting it, it wasn't designed in good faith. There's no way to look at that and think they meant anything about any of their promises when they said they'd support it.