Live data from Hacker News

Improving privacy and security on the web

blog.chromium.org

21–30 of 64 posts

Re: Improving privacy and security on the web

#21
post #10

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.

No web browser is going to disable JavaScript by default and Google is one of the worst offenders when it comes to User-Agent sniffing (you can experiment with this on your own by setting a custom User-Agent and attempting to use various Google websites).

And even then that's far from enough to stop fingerprinting. Ordering of http headers has been used to fingerprint browsers. The element can be used to leak browser screen size. CSS can leak information in @media and @support queries by requesting specific images. It's even possible to create "DNS cookies".

More: http/2 passive fingerprinting: https://www.akamai.com/us/en/multimedia/documents/white-pape... Fingerprinting servers based on header order: http://www.net-square.com/httprint_paper.html#httpheader List of CSS Media queries, including vendor specific ones: https://browserleaks.com/css DNS Cookies Demonstration: http://dnscookie.com/

Re: Improving privacy and security on the web

#22

Not that any step towards additional privacy protections isn't a good thing, same for security. But Google has got to be one of the major contributors to the erosion of privacy. How about chrome nagging to have you sign in? How about their very own ad networks?

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

Re: Improving privacy and security on the web

#23

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.

No web browser is going to disable JavaScript by default and Google is one of the worst offenders when it comes to User-Agent sniffing (you can experiment with this on your own by setting a custom User-Agent and attempting to use various Google websites). And even then that's far from enough to stop fingerprinting. Ordering of http headers has been used to fingerprint browsers. The element can be used to leak browser…

DNS cookies, by the way, are awesome.

Re: Improving privacy and security on the web

#24
post #5

Is this another way for Google to prevent you from clearing their cookies via the 'Clear Cookies' option? Its a step in the right direction with enforcing SameSite cookie scoping, but we must be cautious that Google doesn't use this to force you to always be logged in. Google has a long way to go to rebuild trust after that last browser login debacle. I don't trust em.

Does Chrome support automatically clearing cookies at shutdown yet? I seem to remember it didn't but I haven't used it recently.

Edit: I searched for it, and it seems they have added the feature, but maybe not the related feature of clearing browsing history at shutdown.

Re: Improving privacy and security on the web

#25
This is great - the `SameSite=lax` attribute is arguably how cookies should have worked in the first place, and I'm quite pleased that it's an existing RFC and not a proprietary change being done just in Chrome. Hopefully other browsers follow suit.

What worries me is the vague commitment to stop browser fingerprinting - not a lot of detail there and I'm fearful that useful features might be getting crippled. I don't think I'm as convinced that browser fingerprinting is as big of an issue as CSRF (prevented by the cookie changes here). Time will tell I suppose.

Re: Improving privacy and security on the web

#26
post #10

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.

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"

Re: Improving privacy and security on the web

#27
post #11

Wow, if this works, this is basically the end of CSRF. Essentially: CSRF relies on an HTTP POST to VICTIM.COM triggered by HTML on EVIL.COM, and that request carrying cookies. Today, even though SameSite exists, the default --- SameSite=None --- maintains that longstanding status quo. But after the change, the Chrome default will be SameSite=Lax, and while EVIL.COM will still be able to trigger POSTs to VICTIM.COM, t…

Before you start emitting samesite=lax, be warned that webkit/safari iOS12 has a weird implementation: if you set the cookie in a POST method and redirect to a GET (like most default oauth explicit grant login flows), the cookie will not be sent: they consider POST pages as "unsafe". See https://bugs.webkit.org/show_bug.cgi?id=188165#c12 for more details.

Edit: it looks like people have found other issues since I last looked at this bug:

> It's a serious issue affecting many common user flows, including the flow of visiting a website coming from a GMail link. If the user comes from GMail, it reaches the destination website without any cookies, thereby breaking functionalities that depend on session/login cookie and CSRF cookie. Only fix for now seems to be removing the Lax flag from cookies. (https://bugs.webkit.org/show_bug.cgi?id=188165#c47)

At this point, it looks like the safest approach is to only emit sameSite if the browser isn't safari.

Re: Improving privacy and security on the web

#28
post #20

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.

You will be part of the rare minority that uses that configuration which by itself is a fingerprint.

The point probably was to make that configuration default

Re: Improving privacy and security on the web

#29
This is a continuation of a long arc of convergent work [1][2][3][4][5] by various people over several years; I've been following along [6].

The innovation of this proposal is to work towards the crossdomain cookie transmission being less insecure-by-default, by eventually making the current, limitless behavior opt-in.

This shifts the incentive of developers: presumably those whose sites require crossdomain acceptance of cookies will modify their sites accordingly, while those whose sites don't, or those who haven't thought about the issue will see fewer incidences of the most egregious POST-based CSRF.

[1] https://www.microsoft.com/en-us/research/publication/atlanti... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=795346 [3] https://github.com/mozmark/SameDomain-cookies/blob/master/sa... [4] http://homakov.blogspot.com/2013/02/rethinking-cookies-origi... [5] https://tools.ietf.org/html/draft-west-first-party-cookies-0... [6] https://news.ycombinator.com/item?id=13689697#13691022

Post reply on HN