[ndriscoll]

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.

[dcow]

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.

[ndriscoll]

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

[const_cast]

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

[dcow]

We’re talking about a language preference cookie. How is that a privacy concern?

[zzo38computer]

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

[vanschelven]

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