
Improving privacy and security on the web - migueldemoura
https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
======
tptacek
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, those requests will no longer carry
cookies.

To get the cookies to work from EVIL.COM, VICTIM.COM's developers will have to
explicitly set SameSite=None on their session cookies. Which nobody will do,
because nobody sets SameSite at all today.

Better still: 99 out of 100 CSRF exploits (maybe 999 out of 1000) target
endpoints for which SameSite=None isn't needed; they're cookies nobody ever
uses cross-site to begin with. There are only limited cases where anyone needs
the behavior to change, and those cases don't track the most sensitive
cookies.

As a vulnerability researcher for whom exploitable bugs mostly exist to spark
joy: good riddance to CSRF. It was a dumb bug class, and never, ever fun to
exploit.

~~~
Lx1oG-AWb6h_ZG0
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](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](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.

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

------
niftich
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...](https://www.microsoft.com/en-
us/research/publication/atlantis-robust-extensible-execution-environments-for-
web-applications/) [2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=795346](https://bugzilla.mozilla.org/show_bug.cgi?id=795346)
[3] [https://github.com/mozmark/SameDomain-
cookies/blob/master/sa...](https://github.com/mozmark/SameDomain-
cookies/blob/master/samedomain.txt) [4]
[http://homakov.blogspot.com/2013/02/rethinking-cookies-
origi...](http://homakov.blogspot.com/2013/02/rethinking-cookies-
originonly.html) [5] [https://tools.ietf.org/html/draft-west-first-party-
cookies-0...](https://tools.ietf.org/html/draft-west-first-party-cookies-07)
[6]
[https://news.ycombinator.com/item?id=13689697#13691022](https://news.ycombinator.com/item?id=13689697#13691022)

------
akersten
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.

~~~
Ajedi32
The reason this is related to browser fingerprinting is that cross-site
cookies aren't _just_ used for CSRF, they're also a way to track users across
sites.

With this change, developers will have to _explicitly_ declare when they're
using cookies for that purpose (by setting SameSite=none) which makes it
easier for browsers to identify cookies used for tracking and give users
control over them.

------
Ajedi32
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?

~~~
mikewest
We're proposing treating cookies as `SameSite=Lax` by default
([https://tools.ietf.org/html/draft-ietf-httpbis-
rfc6265bis-03...](https://tools.ietf.org/html/draft-ietf-httpbis-
rfc6265bis-03#section-4.1.2.7)). 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-
incrementalism](https://tools.ietf.org/html/draft-west-cookie-incrementalism)
spells out the proposal in a bit more detail.

~~~
Boulth
This is exactly the information I was looking for when I opened chromium blog
post. Technical and to the point. Is there a reason why this couldn't be
appended to the blog post?

~~~
tptacek
Because you aren't really the audience for that post, and they can safely
assume you'll dig deeper anyways?

~~~
tedivm
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.

~~~
tptacek
I'm just guessing. Something else that sparks joy for me: the fact that Google
will never give any of their announcements the titles they're justifying,
like, "OMG, WE KILLED CSRF!", and that I'll have to dig in a bit to see how
big a deal what they just did is. It's like every "Improving privacy and
security on the web" is a little gift I get to unwrap. It's like Justin Schuh
and Mike West's version of "one more thing".

------
driverdan
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.

~~~
om2
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.

~~~
user17843
Let me guess: Google will tie the new proposal to a new Chrome setting which
effectively identifies tracking cookies according to this new identifier, and
will regularly purge them.

------
34r45sdg
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.

~~~
incompatible
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.

~~~
jedimastert
Isn't that exactly what Incognito mode does?

------
fenwick67
Why do cross-domain requests need cookies at all? Honest question, why
couldn't we just stop sending them ever?

~~~
actimia
At my company for example we run services on multiple domains that are all
authenticated by a single backend. Could probably be solved by some re-
architecturing, but changing cookie behaviour would definitly break existing
sites.

------
sempron64
Is there a timeline for this change?

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

~~~
tptacek
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.

~~~
techntoke
It's actually pretty easy overall... just don't use JavaScript and don't send
user-agent string that shows browser/OS information.

~~~
incompatible
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"

~~~
cpv
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.

~~~
olliej
Back in the day, safari 2.0.4 encountered a large amount of site breakage
because sites were using useragent.indexof(“4”)!=-1 as the test for “are you
Netscape 4”, and if you were then they’d use netscape’s layer apis (netscape’s
alternative to css). Any changes to the user agent are very scary - that’s
kind of how they ended being as terrible as they are.

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.

------
zzzzzzqzzzzzz
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?

~~~
techntoke
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.

~~~
zzzzzzqzzzzzz
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

~~~
dredmorbius
Surf / Suckless: [https://surf.suckless.org](https://surf.suckless.org)

