One percent? Make it something significant like 50%. Better yet, figure out how much money they made with their surveillance capitalism, including any investments and profits derived from such capital. Fine them exactly that and then some for good measure.
Why? They’re literally adding friction to their purchasing process. Nothing they sell is critical. Nobody’s privacy is being violated. They aren’t lying. They’re just being annoying.
This is the most trivial non-issue one could possibly get hysterical over.
Does that mean the law doesn't apply to them? You do business in Europe, you follow European laws + the laws of the specific country you're doing business with, doesn't matter what the type of business is.
The ePD is notoriously ignored and unenforced [1]. It is also not clear what part of the law a simple delay would violate. (Most of the sparing enforcement has been around dropping cookies after someone opts out.)
No no no it's blatantly and obviously in breach as it adds friction to the opt-out that doesn't exist for opt in while the letter of the regulation says it must be as easy to opt out.
It doesn't get much clearer than that.
Of course it doesn't matter if the friction is 1.5 seconds artificial delay or if the friction is because you are forced to send an opt out in two copies via fax.
The only argument to why it wouldn't be in violation would be "it's too trivial" - but I don't think that's a very good argument.
It's a decent attempt at an argument, but far from convincing. One could argue it's to dissuade opting out. One could also argue it's being presented to show the opt out has teeth. (Non-technical people ascribe meaning to fantasy progress meters. A number of UI studies have shown that.)
As for opt out needing to be instant in comparison to opt in, the argument holds no water. If a legacy system were patched for GDPR, it's reasonable for the opt-out to involve more code, not less, as an extra routine undoes the defaults. That or making a record of the opt out is done tediously. (In this case, the argument is moot since the delay is fake.)
The toughest argument one could make from the ICO checklist [1] is that a one and a half second spinner delay constitutes a material "detriment" or penalization of withdrawal of consent. Those are technically true to a trivial degree, but immaterial. Far from meriting a 1% fine per the original comment.
These kinds of arguments hurt everyone working for privacy by trivializing it to a sympathetically mockable degree.
> One could also argue it's being presented to show the opt out has teeth. (Non-technical people ascribe meaning to fantasy progress meters. A number of UI studies have shown that.)
In this case, why isn't the same applied to the opt-in?
> If a legacy system were patched for GDPR, it's reasonable for the opt-out to involve more code, not less, as an extra routine undoes the defaults.
The GDPR mandates that no non-essential data processing should happen unless the user opts-in. Even if there was more code involved in making a legacy system GDPR-compliant, said code would need to be ran first (essentially applying the delay to the initial page load). Otherwise, since this consent form is overlaid on top of the existing webpage (as opposed to being on its own page with none of the trackers being loaded) this essentially means that data is being processed until the slow opt-out process completed, thus being in breach of the GDPR. In short, GDPR-compliant systems should work on the basis of "opt-in", not "opt-out". Having the delay on the opt-out proves that the system assumes the user has opted in (and thus immediately processes data that the user may not be willing to share) until told otherwise.
Also, regardless of the delay, the simple fact that the flow has a big prominent "agree and proceed" button which takes one click and then a less prominent "manage settings" which takes multiple clicks is enough for this to be in breach, at least according to the ICO's guidelines.
wait, what? are you saying that a change in the way the site functions is not a change in functionality?
Seems your argument is that the change is trivial, thus safe to ignore; that there is some threshold below which changes to functionality don't matter. Do I read you right? i.e. "Important functionality is not changed one iota"
