51–60 of 64 posts
Earlier quoted context omitted.
You mean like Firefox sync and Pocket? The so called founder of JavaScript was the CEO of Mozilla, and that is the biggest cause of erosion of privacy on the web.
Absolutely. I should have the option to use a browser, be it Firefox or Chrome, without unwanted integrations or 'features'. I'd like a browser that just browses the internet and respects my privacy. But apparently that's too much to ask
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"
Unfortunately websites break if you stop sending it or dramatically change it. Most browsers can't afford the risk of a dramatic change here.
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
yes, @media queries for example that trivially let the site fingerprint you again.
Earlier quoted context omitted.
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
Can a user meaningfully determine the correct answer to that question? 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…
> The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”.
I agree; but the extra click may be an insentive for web developpers to try not to use JS.
> Which is why you weren't asked about running flash on every website you went to.
Firefox did ask about running Flash, because "attackers can also use the security flaws in Flash": https://support.mozilla.org/en-US/kb/set-adobe-flash-click-p...
> they are designed to be safe in spite of all content being untrusted
But they have flaws, like Flash.
Earlier quoted context omitted.
Because you aren't really the audience for that post, and they can safely assume you'll dig deeper anyways?
If we're not the audience then who is? This was made to the Chromium open source blog, which is typically a developer heavy blog (with previous topics like "Hint for low latency canvas contexts"). Throwing a few reference links at the bottom shouldn't harm their message with the less technically savvy.
" rel="nofollow">https://web.dev/samesite-cookies-explained/>
which does go into a good deal of technical detail. A challenge is that even experienced web developers didn't know much about SameSite prior to this announcement.
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.
Really disappointed in you Google for not addressing fingerprinting much sooner.
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.
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.
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.
Is it? As I understand it, fingerprinting relies on properties and headers, both of which could be altered (eg adding headers for software that doesn't exist, and only sometimes, change the order, etc). You probably can't make them do it so that websites can't see the browser type, and you might not want to.