41–50 of 64 posts
Earlier quoted context omitted.
The point probably was to make that configuration default
That configuration will not be the default. You might just as productively argue that the best way to defeat fingerprinting would be to default to Gopher.
And for what you can't, a banner asking for permission to run Javascript, like we have/had for Java/Flash/ActiveX
Interesting. So apparently Chrome is going to stop sending cookies in cross-site requests unless they're created with `CrossOrigin=None` and the page is loaded over HTTPS?
We're proposing treating cookies as `SameSite=Lax` by default ( https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03... ). Developers would be able to opt-into the status quo by explicitly asserting `SameSite=None`, but to do so, they'll also need to ensure that their cookies won't be delivered over non-secure transport by asserting the `Secure` attribute as well. https://tools.ietf.org/html/draft-west-cookie…
I would even go so far to substitute "should" with "must". But it is a first step.
The easiest way to improve cookie privacy is to block 3rd party cookies by default. Adding new polices is not the right solution. 3rd party cookies are completely unnecessary.
Earlier quoted context omitted.
Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.
It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.
Earlier quoted context omitted.
It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.
User-agent strings should have been abolished long ago. It may not do much against sniffing, but it would spare us monstrosities like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134"
The easiest way to improve cookie privacy is to block 3rd party cookies by default. Adding new polices is not the right solution. 3rd party cookies are completely unnecessary.
Safari's Intelligent Tracking Prevention effectively blocks third-party cookies, at least for resources that are used in a third-party context on multiple sites. This google Chrome proposal also does it, but provides a dead simple workaround for trackers by sending SameSite=None and Secure with the cookie.
The easiest way to improve cookie privacy is to block 3rd party cookies by default. Adding new polices is not the right solution. 3rd party cookies are completely unnecessary.
Chrome mobile, for example, can support add-ons and privacy features, but the risk to ad revenue is preventing them from making it available. Chrome being the default browser for Android means most people won't switch and they have >~80% marketshare.
Why do cross-domain requests need cookies at all? Honest question, why couldn't we just stop sending them ever?
Earlier quoted context omitted.
User-agent strings should have been abolished long ago. It may not do much against sniffing, but it would spare us monstrosities like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134"
I was surprised to see how many popular websites rely on things like user agent or referer header to deliver functionality. As soon as you start tinkering with them, they stop working, or say you use an older browser, etc.
Yet still sites continue to use the user agent to gate access. The same sites also like to complain about how bizarre UA strings are.
Earlier quoted context omitted.
That configuration will not be the default. You might just as productively argue that the best way to defeat fingerprinting would be to default to Gopher.
You can do a lot of things with just HTML and CSS, more than what Gopher allows. And for what you can't, a banner asking for permission to run Javascript, like we have/had for Java/Flash/ActiveX
The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”.
I get that you don’t like it, but the reality is that the web is a platform that includes JS as a core technology. The reason for limiting java and activex was because they had catastrophically terrible security properties more or less by design.
Even flash had problems, but was sensible enough to correct many deficiencies and defer to the browser for interaction with anything outside of its view. Which is why you weren't asked about running flash on every website you went to. JS and the various web/html/dom APIs all have much much stricter constraints than anything flash had - they are designed to be safe in spite of all content being untrusted.
More over dialogs like that are largely recognized among browser developers as being a form of blame shifting - a regular user has no reasonable way to determine whether or not saying “yes” is safe. The purpose of asking them, is so that if something does go wrong you can say “they shouldn’t have clicked yes”.