[cge]

My understanding is that the preferences should not be an opt-out of a default setting per the GPDR, they should be preferences that requested and then saved. So surely the opt-in setting would take just as long as the opt-out setting, wouldn't it?

[ratww]

The opt-in should technically take more time, since you shouldn't be sending PII data before the consent.

In the case of opt-out the only single thing that has to happen is setting a local cookie and closing the modal window, which are things that also happen when you accept.

[the_gipsy]

You are right that technically opt-in should always take longer. No cookies should have been set until the user accepts.

But opt-out should not set anything. I don't know what you mean by "local cookie", a cookie is always sent over the wire by HTTP. If you mean saving to LocalStorage, then I don't think that's allowed either.

[ratww]

> But opt-out should not set anything. I don't know what you mean by "local cookie", a cookie is always sent over the wire by HTTP. If you mean saving to LocalStorage, then I don't think that's allowed either.

It is allowed for this case.

You must save a cookie (or a localStorage value) with the user preferences to avoid showing the cookie banner again. Simplifying: cookies are fine under GDPR as long as they don't carry PII (Personal Identifiable Information). You don't have to ask for consent to store those. They're called "Strictly necessary cookies" in GDPR lingo. (And, of course you can't use any of those to track, though. Intent matters.)

And you can save cookies using a Javascript API. That doesn't involve HTTP requests. The cookie will be sent to the server in future requests, though.

[the_gipsy]

Thank you, I didn't know that you can set a cookie if it's deanonymized. It does make a lot of sense.

[d1sxeyes]

> You are right that technically opt-in should always take longer.

Hm... I suppose so, but negligibly. Setting cookies takes milliseconds, so there shouldn't be a significant difference from a user's perspective.

> No cookies should have been set until the user accepts.

That's not accurate. A number of different types of cookies can be set without consent, generally described as 'strictly necessary' cookies - these include cookies that are required for core functionality of the site, or those required to perform a service expressly requested by the user.

> But opt-out should not set anything.

It's a good practice to record the opt-out (or, that user has not opted in). This can be done as a cookie or using Local Storage. This allows you to do things such as only load third party embeds if the user has opted in, giving the 'opted out' user the option to conditionally opt-in for specific embeds without inconveniencing the 'opted in' user. As far as I understand, current thinking is that this type of preference being recorded falls within the scope of 'strictly necessary'.

> I don't know what you mean by "local cookie", a cookie is always sent over the wire by HTTP.

That's not necessarily true. It is possible to use JavaScript to set and read cookies as a sort of local storage. It's definitely not what cookies were invented for, but technically it can be done.

> If you mean saving to LocalStorage, then I don't think that's allowed either.

GDPR does not care about the method of storage, so if you're allowed to store a cookie, you're allowed to set something in Local Storage (and vice versa).

[ratww]

> Hm... I suppose so, but negligibly. Setting cookies takes milliseconds, so there shouldn't be a significant difference from a user's perspective.

When you accept third-party cookies in a website, additional scripts can be loaded and additional data can be sent to their backends. In the case of providers like TrustArc, etc, consent data is often sent to those third-party after consent is given.

It is of course possible to defer this in the name of user friendliness, which is what TrustArc, etc, tend to do, but only when there is consent.