51–60 of 116 posts
Earlier quoted context omitted.
Unless a big vendor (coff Microsoft coff) decides to enable it by default, them it becomes meaningless.
It was meaningless from the beginning: DNT was always nothing but an Evil Bit. You’re getting mad at Microsoft for pointing out that the emperor had no clothes.
Earlier quoted context omitted.
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…
Does it stand for something? Why the letters 'Sec'?
But that's 100% a guess on my part.
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?
The only IMHO reasonable technical solution is to reduce entropy as much as possible, even below any arbitrary set entropy limit.
Through in the end I think the right way is a outright (law based) ban of micro targeting and collecting of anything but strongly, transparently and decentralized anonymized metrics.
Also I don't seen Google fully pulling through, e.g. one area where chrome is massively worse then Firefox wrt. entropy is the canvas (at least last time I checked). It's an area where there are known reliable ways to strongly hinder fingerprinting of the canvas. But I don't see Google using them as it would be in conflict with Flutter Web rendering animations in the canvas (which inherently has problems and is technically sub-par compared to how the browser could render web animations (and does in case of Firefox)).
Earlier quoted context omitted.
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?
It's a fundamental disagreement on the very idea: 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 we…
I don't think this categorization is accurate. For example, Apple built https://webkit.org/blog/8943/privacy-preserving-ad-click-att...
> if the data isn't required to operate, you don't need it
This is simple, but it's also wrong. Some counterexamples:
* Learning from implicit feedback: dictation software can operate without learning what corrections people make, or a search engine can operate without learning what links people click on, but the overall quality will be lower. Each individual piece of information isn't required, but the feedback loop allows building a substantially better product.
* Risk-based authentication: you have various ways to identify a user, some of which are more hassle for them than others. A login cookie is lowest friction, asking for a password adds more friction, email / SMS / OTP verification add even more. You don't want to ask all users to go through the highest-friction approach on every pageview, but you also don't want to let a fraudster who gets access to someone's cookiejar/leaked password/old device/etc impersonate the user. If you have a small amount of information about the current user's browsing environment, in a way that's hard for a fraudster to imitate, you can offer much lower friction for a given level of security.
* Incremental rollouts: when you make changes to software that operates in complex environments it can be very difficult to ensure that it operates correctly through testing alone. Incremental rollouts, with telemetry to verify that there are no regressions or that relevant bugs have been fixed, produces better software. You're writing as if your position is Firefox's but even they collect telemetry by default: https://support.mozilla.org/en-US/kb/telemetry-clientid
> the position of every non-Google-browser is that they want to give sites as close to no data at all as possible ... Every single browser developer that doesn't own an Ads and Analytics suite is opposed to Privacy Sandbox.
I cited Apple's conversion tracking API above, but another example of this general approach is Microsoft's https://github.com/WICG/privacy-preserving-ads/blob/main/Par... I don't know where you're getting that they're trying for "close to no data at all", as opposed to improving privacy and preventing cross-site tracking?
(Still speaking only for myself)
Earlier quoted context omitted.
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…
Why would you need different templates for mobile/desktop? CSS is quite capable responding to any screen orientation.
- The Mobile vs Desktop design differences are too great.
- The site was originally created without considering mobile, and retrofitting mobile support is unfeasible.
Earlier quoted context omitted.
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?
IMHO #3 is fundamentally flawed as I just can't imagine browsers improving to a point where you couldn't cross reference such "fixed" entropy budges to clearly identify the user. The only IMHO reasonable technical solution is to reduce entropy as much as possible, even below any arbitrary set entropy limit. Through in the end I think the right way is a outright (law based) ban of micro targeting and collecting of any…
A. Browsers successfully reduce available entropy to where users cannot reliably be tracked across sites.
B. Browsers fail at this, and widely available JavaScript libraries allow cross-site tracking. If it's possible to extract enough bits, they will be extracted.
The thing is, if you can't get all the way to (A) then in removing bits you're just removing useful functionality and adding work for browser developers and web developers. Fighting fingerprinting is only worth it if you have a serious chance of getting to (A).
If you think (A) is off the table then I agree a regulatory solution is the best option. Even then, #1, as exemplified by UACH, is still helpful because it makes tracking more visible. If every piece of information you collect requires active work, instead of just receiving lots of bits by default, then it's much easier for external organizations to identify excessive collection.
(Still speaking only for myself)
Earlier quoted context omitted.
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).
And the law also only requires you to ask the user if they want to be spied on. 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 fingerpri…
Earlier quoted context omitted.
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 get that. I do think by and large, the user's agent (the browser) should be making display and format decisions based on itself, rather than the server serving different content. Though I think the exception is mobile, where we probably shouldn't serve the client endless garbage it doesn't need. I mostly think the replacement for user agent should be a boolean of mobile or not mobile. And everything else should be…
The "garbage" we don't want to serve mobile, is often also garbage for desktop, autoplay videos, too many tracking scripts, etc. If we force people to optimize their site for mobile and desktop then maybe we'll actually get good desktop sites.
Earlier quoted context omitted.
Does it stand for something? Why the letters 'Sec'?
I don't think I've ever seen it called out, but I always assumed it's "Secure" in the sense it hasn't been modified by a script. But that's 100% a guess on my part.
Earlier quoted context omitted.
Why would you need different templates for mobile/desktop? CSS is quite capable responding to any screen orientation.
You're not wrong. However, there are times when CSS isn't enough. For example: - The Mobile vs Desktop design differences are too great. - The site was originally created without considering mobile, and retrofitting mobile support is unfeasible.