Comment by dcow
1 month ago
It would be nice if you could argue, “well, just be a good site and don’t use marketing cookies”, but the ePrivacy Directive requires consent for performance and preference cookies too. Perhaps a liberal reading arguably allows classification of certain statistics and preferences functions to be strictly necessary, like “I wouldn’t provide this service without crash reporting because I’d go insane so it’s strictly necessary”, but most lawyers would be ill before advising as much.
There’s still the question of what law mandates that they are annoying pop-ups? They could be preferences in a menu, for example.
What happened is website operators started to feel entitled to doing whatever they want with cookies on users’ machines and eventually decided to act like petulant children when the rules changed.
If cookies are only used for preferences functions, then I should expect that it should only require to mention the cookies in the preferences menu (I hope)? If they have a document to explain each cookie by name, then it would also be helpful, that you can enable/disable them individiaully (or make them read-only) by the browser settings. However, for some things such as languages there are other ways to do without using cookies, such as Accept-Language header for languages, although cookies could be used to override the Accept-Language header in case both are present in the request.
Yes that's the point. You don't need those things. The idea that a news article or blog post or e-commerce page could "crash" is ridiculous, and the law shouldn't humor that excuse. There's been standard ways to declaratively define such pages since before scripting frameworks gained popularity. Use those standard ways. If you're really building an app and need to performance test, buy some hardware in your target range. Privacy aware users block things like Sentry.
You don’t need a shopping cart either. Just make the user write down the skus from your online catalog and send you a purchase order. Products exist on spectrum and the ones that win are typically easier and more convenient to use. If your business is developing the best product it can, it absolutely needs the ability to be convenient and useful.
Adding a language select option on a multinational site seems pretty table stakes in my experience. Plenty often the user does not wish to use the same language as their system/browser. Switching your system’s default language just for one site is a huge hassle.
Re crash reporting: I’m talking about tools like Sentry. I have never once worked on a product of any scale that didn’t need to collect diagnostic reports from the field in order to address code level errors that happen as users are using the product. In house or 3rd party it doesn't matter, and client state has always been involved. A product that doesn’t function is broken. It needs to be fixed.
There is no privacy concession in any of these cases. The EPD simply over-regulates cookies.
I mean maybe we should just reimplement all this crap using indexdb. That’s not a cookie, legally.
The EPD fights symptoms not causes and the internet is worse for it.
Language selection seems easy enough: when the user clicks your flag button, show a toggle switch for "Allow a cookie for language preference". When the user toggles it on, present the language options. If they toggle it off, delete the cookie (in a better world, the server could just send a standard language options header and let the browser show a dropdown for per-site language selection, but oh well).
For crash reporting: pop up a dialog asking if they'd like to submit a report (as software used to do). Don't just submit info from their computer without asking.
If literally any physical product breaks, I don't expect the manufacturer to receive telemetry so they can fix it. If I want them to fix it, I'll bring it back to them. I expect that if I don't go out of my way to tell them something, after I buy the thing, we go our separate ways, and they have no idea about anything I do. If their thing breaks, I also have the option of just not telling them and instead telling everyone else that they're crap. They don't need to spy on me for any reason.
I'm really not seeing the issue with asking consent to do things as they're actually needed. You don't need an "I CONSENT TO EVERYTHING" banner, and most of the stuff you want isn't necessary anyway.
Like I said, privacy conscious users block tools like Sentry. It's a perfect example of "no, you don't actually need to spy on me."
> You don’t need a shopping cart either.
Pretty sure this exact example is explicitly carved out as a-okay.
I think what we're dealing with here is not websites trying to do basic things. Rather, it's every website and their mom thinking they need elaborate analytics to sell plastic garbage.
Yes, that elaborate analytics you spread to 20 third parties IS a privacy concern. We should be looking at that.
1 reply →
> You don’t need a shopping cart either. Just make the user write down the skus from your online catalog and send you a purchase order.
I think this is a way to do it, I had thought also of such a thing before. You can send a "computer payment file" which includes the product ID numbers (and parameters if applicable), the total price that the customer expects to pay, a signature, and encrypted data for use with the bank or credit card company (or some specification of store credit, if you are using that instead).
The existing use of "shopping cart" cookie can still be available as an alternative as well though, in case you do not want to use (or cannot use) the "computer payment file"; then it can provide its UI but you can also use your own if you have your own implementation.
> Adding a language select option on a multinational site seems pretty table stakes in my experience. Plenty often the user does not wish to use the same language as their system/browser. Switching your system’s default language just for one site is a huge hassle.
This is true. However, it would also be helpful to be able to change the settings (including languages, and HTTP request headers) per URL prefix, which would also be another way. This does not mean that the setting cannot also be available as a cookie, which will override the Accept-Language header if both are present in the request.
There is also user authentication; cookies are not really the best way to do that either. I think X.509 client certificates are a better way. However, other methods can still be provided for compatibility for users who do want to use it.
And then, there is more other stuff too, they can also be done in other ways.
Note that all of the above stuff means that many things can work with JavaScripts and cookies disabled (or unavailable), but enabling them will provide a way of working that does not require these other things too.
> In house or 3rd party it doesn't matter
It does matter from the perspective of privacy, because in one case your vistors deal with one party (you) and in the other case another party (Sentry) is also involved.
The GDPR standard of "consent" (as I suspect you know, but as context for my opinion) is applied to the ePrivacy Directive and relates to any cookies that are not strictly necessary.
I do not like using the legal basis of "consent" for processing personal data, and I would much prefer not to need to use consent for placing cookies. As it is, in my personal capacity I can get away without placing cookies at all .
If we had access to other lawful bases for placing cookies, I'd like to think we could work out way towards phasing out any blanket consent. I'm sure "legitimate interests" would be abused and over-relied-on. But it already is, and if we're not arguing with people about whether the "consent" they rely on is legitimate then maybe we'll have more time to worry about whether companies are using other bases appropriately.