Hacker News Reader

Comment by jefftk | Hacker News Reader

> You don't need a cookie banner to be allowed to create Cookies. You only need them if you're using them for something like tracking.

That is a common misunderstanding of the ePrivacy Directive [1][2]. It applies to all cookies (and "similar devices") that are not "strictly necessary in order to provide an information society service explicitly requested by the subscriber or user". And "strictly necessary" is quite a high bar.

(not a lawyer)

[1] https://en.wikipedia.org/wiki/Privacy_and_Electronic_Communi...

[2] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL... See especially (25).

View on HN

It’s not that high. Here’s an official opinion on some usecases that meet the bar and some that don’t: https://ec.europa.eu/justice/article-29/documentation/opinio...

Generally, it matches my expectations. Shopping carts, sessions, and even most user preferences are fine and don’t need a banner. Worst case a small “uses cookies” text next to a language change button is enough.

It is still very strict. For example, here is what the document you link has to say about cookie lifetimes for shopping carts:

"A cookie that is exempted from consent should have a lifespan that is in direct relation to the purpose it is used for, and must be set to expire once it is not needed, taking into account the reasonable expectations of the average user or subscriber. This suggests that cookies that match CRITERION A and B will likely be cookies that are set to expire when the browser session ends or even earlier. However, this is not always the case. For example, in the shopping basket scenario presented in the following section, a merchant could set the cookie either to persist past the end of the browser session or for a couple of hours in the future to take into account the fact that the user may accidentally close his browser and could have a reasonable expectation to recover the contents of his shopping basket when he returns to the merchant’s website in the following minutes."

So? That's totally what I'd expect from a shopping cart cookie. I don't expect something I put in a cart to be there the next day (I will have bought it somewhere else).

I was using the website for a Dutch big box hardware store (Gamma) today, and it had a door stopper I was looking to purchase half a year ago in my shopping cart. I never finished that transaction. That kind of retention is just pointless.

While I do agree keeping items in the cart for a year is not what users expect, if someone puts something in their cart, closes the browser, and then comes back the next day, I think most e-commerce sites would still list the item. And I think that's generally something users want.

It’s worth noting that you do not need cookies to store shopping cart details if you have a user account system. You can store their cart in a database and associate it with a user account.

A session based cookie can then be used to store your identity in a short term session, and the server can easily gather long-term storage on its own.

I think it’s a fair compromise to say “if you want to save this cart, please log in”, which satisfies opt-in data tracking in a user friendly way. You aren’t mandating a user account, but if you opt in you get something potentially useful.

My principle complaint about most of the discourse on this topic is that it is superficial. There are reasonable workarounds for most user-friendly tracking that allow for tacit opt-in via responsible and clear UX. The “hard parts” seem to generally concern the type of tracking that isn’t so clearly user-friendly, such as behavior tracking and PII collection, which is a conversation we should be having anyways without obfuscating the issue by pretending it’s about the easy stuff.

I think just about the only "essential" cookies to ensure functionality would be session cookies. But I would be surprised to learn that the point is to eliminate useful cookies. Shopping cart cookies, when designed so they are not shared with 3rd parties, are benign and should not require an opt-in. That's my opinion on most cookie-based functionality, really. Client-side state is useful for a lot of user-friendly functionality.

For example, remembering things like Dark Mode, pop-up re-sizing, slider locations (volume for example) are all legitimate use cases that I would prefer as a user to be isolated per client.

I think that works if the site clearly says that your preference will be stored. On the other hand, if it's just a "dark mode" checkbox or something, my reading of the directive is that isn't enough?

I don't want to have to make accounts on websites just for them to remember what is in my cart for my next visit. I don't like having more accounts, especially if I'm not yet sure if I'm going to buy from them.

Since the site does not know you are leaving, it doesn't have any opportunity to prompt you and ask whether you would like to save your cart (and if it did I would find it pretty annoying)

If I go to an e-commerce website and I am not signed in to, add a bunch of stuff to my cart and leave, I have absolutely no expectation the cart will persist until the next day, and I really don’t think you should either. Not only is it in an unreasonable expectation as an end user, but also it sounds like an absolute nightmare for businesses (Do you hold physical inventory for things in the cart? What about price changes or products are discontinued? Etc).

In practice, sellers do deal with this. The most common approach is that putting something in the cart does not reserve it or maintain a fixed price. Then if availability or pricing changes, they flag that to the user when viewing the cart.

Also, you initially asserted that the regulations were strict for any and all cookie usage. The person replying to you provided plenty of evidence to the contrary, and now you’re bringing up incredibly niche edge cases, to what end I’m not sure. I think it would be more productive to just concede that the regulations aren’t as strict as you stated.

Most companies will not be compliant unless they do one of (a) get consent from users or (b) hire a lawyer to review each of the things they do in the context of ePrivacy, and make corresponding changes to keep everything within the bounds of "strictly necessary". I'm bringing up these 'edge cases' as part of showing that most sites would have changes they would need to make if they wanted to stop asking for consent from users, and that these changes are not obvious and go beyond removing tracking.

> I don't expect something I put in a cart to be there the next day

I do. I use the shopping cart as a staging area sometimes when deciding what to buy. In fact, I don't really see a good reason for a shopping cart ever lose items I put in it until I explicitly remove them or they stop being available, since the whole point of a cart is to express intent to buy.

The whole point of a shopping cart is for items that you are going to buy--not for things you may (or may not) buy tomorrow. It's a shopping cart. Not a bookmarking service. You don't go into a physical grocery store, put things in your shopping basket, leave, and expect them to be there when you walk in the next day.

The metaphor is imperfect. It is a staging area for orders in practice, and people like to be able to use it that way. I often build up a shopping cart on several sites while trying to figure out where is the best place to buy from (especially in cases with a shipping is a large proportion of the overall price) and sometimes this takes me several days.

That is your interpretation of shopping carts in web stores. Other people add things to their cart as they need to replace eg: items in the stationery cupboard, then checkout once a week. Some people use the cart as a form of Wishlist, or a picking list while evaluating similar products.

At the very least if a site doesn’t offer Wishlist, shipping list or other bookmarking facilities I would expect the shipping cart to give me a cookie that lasts at least three days to cover the weekend or the option to create an account to save that shopping list/cart to come back to later.

Often you need only the session cookie. Everything else can go into the database indexed by that cookie. This is especially safe if the user has an account and won't lose the data if the cookie is lost.

I think I would understand was is meant by an "information service", but what exactly is an "information society service"? Such odd wording -- does it have a specific meaning?

It's a legal term the EU came up with to cover things like websites and apps in a technology-agnostic manner.

Surely if someone has instructed the website to remember a setting, then that cookie was explicitly requested by the user?

Storing something in response to an explicit user request seems fine without additional consent, though you still need to explain to users how the cookies are used to fulfill their request. [1]

On the other hand, there are many things that sites do that are not fully explicit. For example, shopping sites often show you items you have recently viewed to facilitate comparisons, or a news site showing ads might want to make sure they don't show you the same one over and over. That doesn't sound to me like it is strictly necessary for the functioning of the site?

[1] "users are provided with clear and precise information in accordance with Directive 95/46/EC about the purposes of cookies or similar devices so as to ensure that users are made aware of information being placed on the terminal equipment they are using"

Couldn't sites wait to ask for cookie permission until the actually user tries to do something that may benefit from a cookie? Like put text and a link with an explanation next to buttons to change the theme or regions which may contain recently viewed items.

Yes.

Preferably this would use a browser cookie setting. I know you use cookies to store my settings, I don't need you to ask. Please stop asking.

I've been wondering about that. I have a simple web app and I'd like to gather some basic statistics about what users do, which pages they visit... Not to spy on people, not to share with anyone else, just to have some insight on how to make the app better. The app is just a toy program people use for fun, you couldn't possibly argue that any stats I'd be collecting could be used maliciously. It seems to be difficult to do that while respecting the GDPR and without some annoying pop-up though?

Do you really need cookies for this or could you also use your server logs for this?

Per default you could not gather statistics but ask inside you app if people are willing to participate in making the app better and if they would agree to accept some cookies for this reason.

I don't need cookies for this. However, AFAIK the GDPR doesn't just apply to cookies, it applies to any data retention, or at least anything that could be tied to an IP address or a certain user.

Maybe the key is to have stats that are purely anonymous, eg, how many people visited this page.

Right, I focused on cookies here. Yes you could just cut the IP out of the logs and check the visited sites and requested resources.

If you're using server logs, without any cookies or other client-side storage, then the ePrivacy Directive is not relevant and you're thinking about the GDPR. Unlike ePrivacy, the GDPR is specifically concerned with personal data, so if you are careful in how you set up your logs you can generally still collect good analytics on how people use your site without accidentally collecting data on how a specific person uses your site.

(still not a lawyer)

Cookie banners predate the GDPR: they were initially for the (much older) ePrivacy Directive, though many sites now have combination consent gathering flows for ePrivacy+GFPR.

For your specific question, I think the Planet49 ruling gets pretty close. "It does not matter whether the cookies constitute personal data or not - Article 5(3) of the e-Privacy Directive (i.e. the cookie consent rule) applies to any information installed or accessed from an individual's device." [1]

(still not a lawyer)

[1] https://www.twobirds.com/en/news/articles/2019/global/planet...

Just do it server side, with a unique session token.

How do you assign individual web requests to a session without cookies?

Add a session id to the URL and all generated links, I'd guess. Still probably not any more legit than a cookie, though.

I wouldn't be surprised if that fell under "similar devices", just like localStorage.

generate a random ID in js when your page starts, set it in the context and send it as a header on every request

While might not be caught easily, you‘r still not compliant with GDPR by doing it all on the server without consent.

GDPR only applies to PII. If you're just collecting anonymous session tokens you're fine (it's what comes "out of the box" if you host your webapp on AWS for example, you'll see an AWS correlator ID in the request headers)

Technical answer: You can use Differential Privacy[1] to collect such data (“what percentage of users used this feature?”, “What is the distribution of time between visits?”, etc) without collecting any data about individuals. Some projects already do this and there are open source libraries that do the math for you.

However, I don’t think the regulations have an explicit safe harbor along the lines of “You’re fine as long as the math checks out”. Perhaps if it did, we wouldn’t be in such a mess.

(A passive observer that sees a JSON POST wouldn’t know that you’re using differential privacy. It would look like typical telemetry. They’d have to read your code or look at multiple samples and notice that the data looks random)

https://en.m.wikipedia.org/wiki/Differential_privacy

plausible analytics claims to not need consent as it does not do user level tracking or issue clienside state.

https://plausible.io/

Do you really need to know which pages a particular user visits, or just which pages are visited frequently.

The latter is easily gathered from web server logs, the former sounds like a case of "I want to do this bad thing (spying on users) for good reasons", and the law only cares that it's a bad thing, not about your reasons (or arguably it does care slightly about your reasons, but not in enough detail to accommodate your use case). Laws being rather blunt tools and reasons being rather hard to divine.

You might want to know, in aggregate, which paths users take through your site so you can make it better. This requires cookies, and the cookies are not, in my reading, essential for the site to function.

Yes... Agreed on both points.

You can get a bit of that via referrers, but not as much as you would like.

Yeah, item 25 is interesting, but the way I read this it's more about the informative links instead of the click-to-allow ones

> strictly necessary in order to provide an information society service explicitly requested by the subscriber or user".

Sounds to me then that login/customizations are allowed

I was under the impression that for something like a session token stored in a first-party cookie you don't need consent. The second paragraph refers to both GDPR and ePrivacy directive.

> 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. While it is not required to obtain consent for these cookies, what they do and why they are necessary should be explained to the user. [1]

> Receive users’ consent before you use any cookies except strictly necessary cookies. [1]

[1] https://gdpr.eu/cookies/

It depends on what you're doing with the session cookie. If it is just for holding shopping cart items or tracking whether you are logged in, I agree with you. But there are many first-party things sites want to do which are probably not "strictly necessary".

Reply on news.ycombinator.com