Photo by Charles Deluvio on Unsplash.
With GDPR and similar legislation in other countries—like the LGPD here in Brazil—picking up I've started to get asked about privacy-focused issues on my clients' websites.
One such case got me working on a Cookie Consent pop-up. Yea I hate those too but as others have mentioned it's mostly because they're being used wrong.
The first thing I did was to look up what's been done before in this front. But as I did my research I began to realize my options were plugins for WordPress for non-developers, bloated suites that do too much—often overlapping with existing components in my website—or basically adware that tries to reel me into their paid services.
Two of the popular ones are Osano's cookieconsent and OIL.js.
As a fan of small, focused libraries that do one thing and do it well I was left hanging. So I did as any sane developer would do and set out to create my own.
My aim was:
- Smaller scope. Fix the issue at hand and don't touch the rest.
- Simple API that gives full control to the developer.
- Don't touch the user interface.
The issue at hand, in this case, was to manage user consent for cookies, tracking and some other stuff and get out of the way. I already have the interface done, using my own styles and markup all accessible and whatnot.
That's how Consentman came to be.
import {
addConsentSubject,
getConsent,
changeConsent,
enforceConsent
} from "consentman";
addConsentSubject("default", state => {
switch (state) {
case "allowed":
console.log("Consent has been granted. Installing trackers.");
break;
case "blocked":
console.log("Consent has been revoked. Removing trackers.");
break;
default:
console.log("User needs to consent first.");
break;
}
});
if ("indeterminate" === getConsent("default").consent) {
if (confirm("Would you like to consent?")) {
changeConsent("default", "granted");
} else {
changeConsent("default", "revoked");
}
}
enforceConsent();
In the example above, when the user first visit the website the consent named default
will be indeterminate
, so a confirmation will be shown asking the user for consent.
If the user clicks Yes
consent will be granted and any subjects will have their state changed to allowed
.
If the user clicks No
consent will be revoked and any subjects will have their state changed to skipped
.
Subsequent visits by the user will not trigger the confirmation since consent is remembered across visits—via local storage.
By then, if at any time default
consent is revoked and re-enforced, any subjects will have their state changed to blocked
.
Notice that there are two possible states resulting from the consent being revoked. This way you can handle a subject being skipped over and being blocked separately.
You can also have additional consents with different names, e.g. one for trackers, one for advertising, etc.
Head over to the repository and checkout the code! Also, don't be a stranger, all feedback is welcome. 😊️
Thank you for your time and have a good one.
Top comments (0)