1. 47
  1. 35

    Cookies Are On Their Way Out

    No, not really.

    It’s true many front end devs are relying more and more on JWTs, Paseto, etc, but cookies are in many cases the best option.

    If you use these options when creating the cookie you will prevent most security problems:

    • secure: the cookie will only be sent via https
    • sameSite: the cookie will only be sent to the domain that created it. This prevents all cross site attacks.
    • httpOnly: the cookie will not be available to JS. No more XSS stealing JWTs attacks.

    Also, if you read the EU GDPR documentation on cookies, you do not need to show the “accept cookies” button on authentication cookies:

    Strictly necessary cookies — These cookies are essential for you to browse the website and use its features, such as accessing secure areas of the site. Cookies that allow web shops to hold your items in your cart while you are shopping online are an example of strictly necessary cookies. These cookies will generally be first-party session cookies.

    And later on:

    To comply with the regulations governing cookies under the GDPR and the ePrivacy Directive you must: Receive users’ consent before you use any cookies except strictly necessary cookies.

    1. 55

      Also privacy laws are about data collection and data processing in general. They don’t care which HTTP header you use and how cleverly you obtain the data.

      If you’re collecting non-essential information, you need consent, whether that’s cookie consent, etag-tracking consent, or consent to be followed by an RFC 1149 homing pigeon.

      1. 21

        One of the great successes of the advertising and privacy invasion industry is convincing people that the EU cookie law is ridiculous and forces every website to present annoying pop-ups. The same has been tried (though less successfully in my experience) with the GDPR and its annoying pop-ups.

        More people need to know that actually, no website has to show GDPR or cookie banners. Websites only have to show those banners and pop-ups when they actually violate your privacy in really creepy ways.

        1. 9

          many front end devs are relying more and more on JWTs, Paseto, etc

          That’s very apples to oranges. JWT is how you generate a token, cookies is how you store/transfer a token — you could put a JWT into a cookie. It’s kinda annoying when people say “JWTs etc” to really mean “localStorage”..

          1. 3

            And a cookie, with the flags mentioned in the root comment (secure, httpOnly, sameSite), is the best way to store a JWT in the browser. localStorage is insecure and should be avoided; it’s like using cookies without those options:

            https://snyk.io/blog/is-localstorage-safe-to-use/

            1. 1

              You’re absolutely right, but I think we can at least agree storing JWTs in localStorage and sending those as an auth header is by far the most popular way of using JWTs.

            2. 7

              Also, if you read the EU GDPR documentation on cookies, you do not need to show the “accept cookies” button on authentication cookies:

              I always supposed it was the case, so I’m glad it’s actually in the official language, thanks for quoting it here!

              It almost looks like commercial companies are deliberately hiding behind a neutral technological term “cookies” to not scare off customers by calling them “personal tracking markers from surveillance 3rd parties”.

              1. 2

                This is great info, thanks for sharing!

              2. 24

                Lobsters needs a whole “I didn’t read and misunderstood GDPR” tag. There’s just every week another article like this. People thinking they can be clever and circumvent laws with technology, just like some of the bitcoin fans believing they can avoid taxation.

                kornel already said everything that’s to be said on this topic.

                1. 9

                  This is also an issue with some people insisting you need to ask consent for any and all data you collect, which isn’t actually the case; the GDPR is more nuanced than that and has a list of items under which it considers data processing to be lawful, consent being just one of them. @kornel’s comment (“If you’re collecting non-essential information, you need consent”) is somewhat lacking in nuance in that regard.

                  Whether that’s a good or bad thing is up for grabs, but it’s certainly not as simple as often claimed.

                  1. 6

                    Wat? Did you read the article? Your fears are addressed in the 3rd paragraph. It’s even above the fold.

                    A few quick opening remarks: The whole point of this piece is to spark discussion and awareness in the industry and among users. Personally, I would never advocate for employing these tracking practices and I am glad to be working for an analytics vendor, that has always put privacy, transparency, and integrity first. Besides, from a legal perspective, this technique does not circumvent the GDPR or similar privacy laws. Just because ETags are technically not cookies, does not mean they are not covered within such guidelines and require no user consent.

                    Emphasis, mine.

                    1. 9

                      I am pretty sure that sentence wasn’t there when I read that article.

                      1. 1

                        Correct. You can see an older version in Google’s cache: https://webcache.googleusercontent.com/search?q=cache:https%3A%2F%2Flevelup.gitconnected.com%2Fno-cookies-no-problem-using-etags-for-user-tracking-3e745544176b

                        The third para was simply:

                        One quick opening remark: The whole point of this piece is to spark discussion and awareness in the industry and among users. Personally, I would never advocate for employing these tracking practices and I am glad to be working for an analytics vendor, that has always put privacy, transparency, and integrity first.

                  2. 2

                    It strikes me that this is a variant of the general class of cache side-channel attacks made famous by Spectre and Meltdown. This isn’t a timing side-channel (though those are possible on the web too) but still a side-channel due to performance optimizations.

                    Just like in CPUs, if caches were completely disabled the side-channels would go, but so would the performance we’ve come to know and love.

                    1. 2

                      However, there are a few options for users to protect themselves from ETag tracking:

                      • Disable cache in the browser settings […]
                      • Modify headers with a browser add-on […]

                      Or the simplest of them all, refresh the page while holding down [Shift].

                      1. 1

                        That protects from one isolated tracking incident. If you want to generally be protected from this kind of tracking, you should find some way to automate refreshing/loading without cache.

                      2. 2

                        Meta: paywall.

                        1. 2

                          What caching mechanism do people recommend?

                          • An expiry time seems bad because if the content changes sooner than expected, the client won’t know.
                          • ETags are bad because they can be abused for tracking.
                          • If-Modified-Since could also be abused:
                            • If the client sends “If-Modified-Since: ”, that timestamp could identify the user.
                            • If the client sends “If-Modified-Since: ”, the server can send me a unique last-modified value; effectively an ETag.

                          Maybe something like ETags is possible, but with less room for abuse:

                          1. The server sends an ETag header with every response.
                          2. The client remembers the ETags, but never sends them.
                          3. If the client suspects it can avoid a GET, it does a HEAD to see if the ETag has changed.
                            • If it changed, you’ve wasted a HEAD request.
                            • If it didn’t change, you’ve avoiding retransmitting the large response body.
                          1. 2

                            For static assets, Cache-Control: max-age: 31536000, immutable + cache busting (e.g. /style.css?rev=<hash-of-the-content>).

                            For pages… don’t?

                          2. 1

                            Buried in the medium comments, but I thought it was also interesting this was tried many years back and ended up in a lawsuit: https://www.research-live.com/article/news/kissmetrics-settles-etag-tracking-lawsuit/id/4008518

                            1. 1

                              I suppose browsers could make this kind of tracking more difficult by ignoring the ETag header completely unless it was verifiably just a hash of the payload. For example, if the browser saw the header

                              ETag: "sha256:2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"
                              

                              then it would compute the SHA-256 digest of the page. If they matched then it would use that ETag for future requests; if the ETag was not in the blessed “sha256:” format (or if the digest didn’t match) then it would assume that the ETag was being used for tracking and it would not include it on future requests.

                              Disadvantages of this approach: (1) The server could counter it by generating a slightly different page for each consumer and then just tracking ETags like before. (2) It might add a lot of per-request CPU overhead for the server. Most of the ETags I’ve seen are much shorter—and presumably much easier to compute—than the output of a modern cryptographic hash function.

                              1. 6

                                That wouldn’t prevent tracking, because the browser still sends If-None-Match: "sha256:2cf24etc" to the server. It doesn’t matter what’s in the file — it could be a garbage file with random content. The tracking ability comes from each user remembering an etag sent by the server, and then disclosing that saved state.

                                Browsers already prevent etag from being used for tracking across unrelated websites by having a separate disk cache for every top-level domain. That means that shared JS and font CDNs lost all bandwidth savings advantage they could have, but sites can’t see what other sites have cached.

                                1. 1

                                  Right. I was thinking that making the ETag value a well-known function of the file contents would at least push the tracking identifier into the file itself, which might increase the effort enough that some site operators would no longer bother. But I guess if you’re willing to do this in the first place, that’s not much of a technical or ethical barrier.

                                2. 1

                                  I suppose browsers could make this kind of tracking more difficult by ignoring the ETag header completely unless it was verifiably just a hash of the payload.

                                  How would that make prevent this type of tracking? The server could just include the tracking number in the payload and the browser would dutifully send a hash of it back in the cache control headers. SHA-256 is pretty efficient these days, and with an appropriately constructed payload, a server could use the length extension trick with the M-D construct such that it wouldn’t really be more expensive. Mapping the hash to the tracking number isn’t a lot to ask of the tracking server, either.

                                  I guess it’d cause more cache misses than proper use of ETag but no worse than what’s described in the OP link.