41–50 of 116 posts
Serving different content for the same URI based upon various metadata fields in the request goes completely against the spirit of a URI.
Earlier quoted context omitted.
Yes, I wish they would engage with how this fits into the rest of the Privacy Sandbox proposal ( https://www.chromium.org/Home/chromium-privacy/privacy-sandb... ). My understanding is it's: 1. Move entropy from "you get it by default" to "you have to ask for it". 2. Add new APIs that allow you to do things that previously exposed a lot of entropy in a more private way. 3. Add a budget for the total amount of entropy…
I think pretty much all browsers and a lot of web platforms made it clear in their response to FLoC that everyone except Google (and Twitter, I guess?) considers Privacy Sandbox to be harmful as a whole.
Serving different content for the same URI based upon various metadata fields in the request goes completely against the spirit of a URI.
This is unfortunately the world of web apps, where a URI just gets you to the app, and the content within is dynamic.
Serving a slightly different web app from the same URI based upon other random metadata on the other hand. Makes caching all the more complicated.
Earlier quoted context omitted.
I think pretty much all browsers and a lot of web platforms made it clear in their response to FLoC that everyone except Google (and Twitter, I guess?) considers Privacy Sandbox to be harmful as a whole.
Objections to FLoC are basically about what should be included in #2. I don't understand why people would be opposed to #1 or #3 though?
Google's position is that it's okay for a website to know X amount of data about a user, you know, as long as it doesn't, in total, cross the creepy line.
Everyone else's position is that if the data isn't required to operate, you don't need it. If we accept that the User Agent, as it is going to be frozen, is going to be served anyways to avoid breaking the legacy web, very little of this proposal adds value, and much of it adds harm. It isn't practical to move to not serving the User Agent, so any replacement for the data in it is pointless at it's very best. The frozen UA provides enough to determine if someone is mobile, the only real need for UA strings. And when most browsers are looking at reducing the tools for websites to fingerprint, Google is introducing new ones.
So Firefox's position on Privacy Sandbox as a whole is pretty logical: If it's optional enough to be requested, why offer it at all? The entire premise of Privacy Sandbox is that it wants sites to have access to some amount of information about the user, and the position of every non-Google-browser is that they want to give sites as close to no data at all as possible.
This is the core of the problem with a single company being legally permitted to operate a web browser and an ad company. Every single browser developer that doesn't own an Ads and Analytics suite is opposed to Privacy Sandbox.
Earlier quoted context omitted.
This is unfortunately the world of web apps, where a URI just gets you to the app, and the content within is dynamic.
Even with web apps, you can serve the same app from the same URI. URI doesn't imply static content. Serving a slightly different web app from the same URI based upon other random metadata on the other hand. Makes caching all the more complicated.
I mostly think the replacement for user agent should be a boolean of mobile or not mobile. And everything else should be dynamically handled by the client.
I'm late to the ballgame, but what does "Sec-" mean as a HTTP header prefix anyway? I am failing at googling.
It means the browser is in control of the header, and not some script. From https://datatracker.ietf.org/doc/html/rfc8942 : Authors of new Client Hints are advised to carefully consider whether they need to be able to be added by client-side content (e.g., scripts) or whether the Client Hints need to be exclusively set by the user agent. In the latter case, the Sec- prefix on the header field name has the effect of p…
> Moving stuff around (from User-Agent to Sec-CH-UA-*) doesn't really solve much. That is, having to request this information before getting it doesn't help if sites routinely request all of it. I think this is sort of ignoring the whole point of the proposal. By making sites request this information rather than simply always sending it like the User-Agent header currently does, browsers gain the ability to deny exce…
Having to request it is a terrible idea to begin with. If I want to use different templates for mobile vs desktop, I need to know, on the backend, whether the device is a mobile device, and I need it on the very first request. Having to request these headers explicitly is an unnecessary complication that would slow down the first load. However it is nice that there's now a separate header that gives a yes or no answe…
Serving different content for the same URI based upon various metadata fields in the request goes completely against the spirit of a URI.
https://mozilla.github.io/standards-positions/#ua-client-hin...
Earlier quoted context omitted.
> Set-Cookie was supposed to have the browser ask the user to confirm whether they wanted to set a cookie. Not many clients doing that today. No worries, that's why we have laws to make the website do in the content what the browser no longer wants to do in the viewer. ;D
Having the browser explicitly prompt for cookies is neither necessary nor sufficient to do what strong, consistently-enforced privacy laws can do, because the browser can't tell a tracking cookie (which needs a prompt) apart from a settings cookie (which does not).
It's not tightly bound to cookies in any way.
And vastly misunderstood.
There was a predecessor which was somehow tied to cookies but even then you didn't need to ask for setting purely functional cookies.
But somehow everyone ended up interpreting it as such.
Maybe because most sites don't have many purely functional cookies or fingerprinting, as they always track you for other purposes, too.