Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving privacy and security on the web

blog.chromium.org

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Improving privacy and security on the web

#31

Post by simonebrunozzi »

tptacek wrote: 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…

I read half of your comment, and thought: wow, this guy really explains things very well. Incredibly well. It's that simplicity and clearness that you only find in great teachers with very deep technical skills.

And then I saw your username... Ah, of course! :)

Re: Improving privacy and security on the web

#32

Post by tptacek »

anonymfus wrote: post #28
ayrx wrote: post #20

Earlier quoted context omitted.

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

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.

Re: Improving privacy and security on the web

#33

Post by mikewest »

Lx1oG-AWb6h_ZG0 wrote: post #27
tptacek wrote: 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 las…

We did just clarify this in the spec: https://github.com/httpwg/http-extensions/commit/49bcb4fddb8.... Hopefully that, plus the tests we'll add in https://bugs.chromium.org/p/chromium/issues/detail?id=960375 will help other vendors align their behavior with developer expectations.

Re: Improving privacy and security on the web

#34

Post by olliej »

zzzzzzqzzzzzz wrote: post #22
techntoke wrote: post #17

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

You mean like Safari? ;D

Re: Improving privacy and security on the web

#35

Post by [deleted] »

tptacek wrote: post #10
techntoke wrote: post #9

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.

[deleted]

Re: Improving privacy and security on the web

#36

Post by olliej »

techntoke wrote: post #9

Really disappointed in you Google for not addressing fingerprinting much sooner.

This is a completely unrelated aspect of the modern web. Fingerprinting is a giant mess of edgecases to manage. For all my feelings on Chrome’s privacy track record, this is an incredibly big improvement to security across the web. More specifically this change to cookie policy is a “fix an entire class of security bugs” change vs piecemeal fixes to individual instance of a bug class.

Re: Improving privacy and security on the web

#37

Post by cpv »

incompatible wrote: post #26
techntoke wrote: post #16

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"

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.

Re: Improving privacy and security on the web

#38

Post by olliej »

techntoke wrote: post #16
tptacek wrote: 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.

Browser and OS information is not the biggest info leak, it really isn’t.

Compared to cookies in the request.

Time stamps in the request and the tls header.

IP address, etc etc

People vastly overestimate the value of those data in the UA

Re: Improving privacy and security on the web

#39

Post by vatueil »

tedivm wrote: post #13
tptacek wrote: post #12

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.

A few more reference links might not hurt, true.

As for who the audience is, perhaps people who were alarmed by the WSJ's scaremongering: https://www.wsj.com/articles/googles-new-privacy-tools-to-ma...

Someone leaked the news to the WSJ, which tried to spin this as an anti-competitive move.

Post reply on HN