Hacker News Reader

I like that your solution actually handles loading the third-party libraries and only does so after consent has been given, so that if a user opts out absolutely no data (not even a DNS lookup) is sent to the third-party.

A lot of consent management solutions appear to load the third-party scripts regardless and only focus on cookies, even though the real danger is IP-based tracking and browser fingerprinting which doesn't depend on cookies or any persistent data being stored (they've adapted as modern browsers heavily restrict cookies).

The IAB is the fox guarding the henhouse. It always was a paper thin figleaf and you're a hero for doing your part to expose that.

Ugh, finally a consent manager with an "I decline" button. I can't believe how rare they are.

I am a user of klaro.js and just wanted to express my thanks for the work you do.

One question, that arose though is how one would fulfill the requirements of GDPR regarding the logging of consent as a kind of 'paper trail'. As I understand the requirements one would need to store some Form of identification (like an arbitrary ID, the time and scope of consent and also store this for the user or on their machine). I understand how this could work for email opt ins. But consent on a web page?

I always wonder.

Thanks! So documenting consent can happen directly in the users' browser, this is also GDPR & ePrivacy compliant. Those legislations don't require server-side storage of consents, it's another myth propagated by CMP providers to sell subscriptions.

Storing consent server-side only makes sense for identified users (e.g. those that are logged in on your site) as there you actually have something that you can link the consent to. For an anonymous user that e.g. has a Google Analytics ID stored in the browser you'd have to store a link to that ID on the server-side as well in order to link it to the consent, and that is not privacy-friendly. Storing IP addresses also isn't a good idea as you're again creating more privacy risks for the user than necessary.

Is this really the case.

The key is that the data controller be able to demonstrate AND RECORD that consent was received. If I clear my cookies, how does data controller prove consent?

“keep a record of consent statements received, so [the controller] can show how consent was obtained, when consent was obtained and the information provided to the data subject at the time ... [and] also be able to show that the data subject was informed and the controller’s workflow met all relevant criteria for a valid consent.”

With that guidance in mind, and from a practical standpoint, consider keeping records of the following:

The name or other identifier of the data subject that consented; The dated document, a timestamp, or note of when an oral consent was made; The version of the consent request and privacy policy existing at the time of the consent; and, The document or data capture form by which the data subject submitted his or her data."

Just seems like some huge liability here if you didn't record the required elements in a manner that allowed you to produce them. Does GDPR allow me to requisition my users devices if I'm investigated?

Of course, we are told GDPR is "easy".

but it is. either stay under the radar or just stop gathering data that you dont need.

The consent and the data collected via the consent need to be linkable. That's why it makes sense to store consent records for identified users on the server-side, because you "know" the user in that case.

For pseudonymous users, e.g. those you track via a Google Analytics cookie you don't know who the user is and you (hopefully) can't reidentify them without the Google Analytics cookie. Since the cookie is stored in the users' browser it makes sense to also store the consent record there. If you would store that consent record on the server-side you'd still need a cookie in the users' browser to link the consent record to them.

> The consent and the data collected via the consent need to be linkable. That's why it makes sense to store consent records for identified users on the server-side, because you "know" the user in that case.

Yup, this is why a lot of websites try to lure you into logging in to the website to enjoy the full content (they won't tell you this is the reason, of course).

Thanks for the answer. Not sure if I misunderstood the GDPR but I thought it had the requirement to be able to provide the consent documentation for any identifiers used (like Google Analytics ID or Matomo ID).

The user has the consent documentation on their device. But I can't provide the documentation myself.

I actually don't think the risk is very high. And I agree that storing this information on my side is additional data privacy risk.

But I don't feel GDPR is easy here.

Exactly. If you read the cases, a fair number of them are gotcha type things. For example, ask yourself, if google tried to say they couldn't provide consent records (despite CLEAR language in GDPR) because they are only stored on devices - I have a feeling a MAJOR fine would be inbound.

But we get expert advice here that it is fine.

One of the claims I saw was that google hadn't said something about information being used to advertise - but when I read the related disclosure (they have all the versions) it seemed clear enough to me. I'm not saying ruling was wrong, but they in some cases hinge on issues just like this.

And we are just scratching the surface of things here.

If you clear site data for a site tracking anonymous consent, you've cleared your consent. No records necessary unless you are linking consent to user accounts stored on your backend.

As an EU citizen, what is the point of the consent forms? Are there really that many people who click accept?

Yes, years of computer use have conditioned users to just click the box to make the dialog go away. Add to that the minimising language and "make our products better" language the form's presentation is couched in and the dark patterns to make opting out hard, I think most users accept.

Yeah ... dark patterns - its always blue what you should click

Apart from everyone being trained to accept everything, some people genuinely enjoy the "share this" buttons and so on.

When presented in a clear manner with Accept/Decline, the absolute vast majority of users will click decline.

So the leeches at IAB, OneTrust and everyone else employ a variety of dark patterns to make the user just click "Accept".

Your site "you currently cannot scan arbitrary URLs."

So, how can we use the scanner?

could you point to an example of your actual consent form? i could not find any.

You can just follow the link to our website (https://heyklaro.com), we use the CMP there as well.

This looks _really_ good.

Looks great design wise, but I still see some dark patterns like making the accept button green, and decline grey

It's still preying on the psychology of users that have been taught for years that green = good, accept, happy path, things will work

If you look at something like Apple's consent which as "Ask app not to track" and "Allow tracking" (can't remember exact phrasing), the binary choice is presented in a fair and equal way which makes you actually think about what you're pressing, because there's no clear "right" choice they want to you to press unconsciously

Edit: I understand though, you have a paid product, you boast about your acceptance rates as part of your marketing strategy, and no company is going to pay for something that decreases their ability to track users.

I've been in the same position as a developer where I'm asked to implement the maximum amount of obtrusiveness to coerce people to accept tracking, like overlays with the famous 'body { overflow: hidden }', because our marketing departments start to go ballistic when they can't track every single users every move. It just makes me sad sometimes that this is what we're dedicating our time to.

> Looks great design wise, but I still see some dark patterns like making the accept button green, and decline grey

Since all the other consent forms are like this it makes sense to not change the established standard. I would for sure misclick, since I've by now gotten this dark pattern ingrained (I automatically go for the grey button).

We don't boast about acceptance rates anywhere on our website, or claim that we optimize them in any way (which we don't). In my opinion having differently colored buttons makes declining easier for users as they have more visual clues to distinguish the choices. Most users are accustomed to a green "yes" button and a grey "cancel" button from system dialogs (though there are many variants these days), so they don't have any trouble finding the "cancel" button. Acceptance rate for Klaro on our website is around 50 % (33 % when it's on HN :D), which is much lower than what other solutions claim to achieve using dark patterns.

Personally I often click on the wrong choice when e.g. asked about giving a website access to my location on iOS, as there's no color difference between them and the texts are quite similar as well.

BTW Klaro is full customizable so users can change the styling, and some users choose to display the buttons in the same size and style, though I don't think this influences acceptance rates too much.