SPspiffytech·Mar 10, 2022
I've seen this consent manager recommended: https://github.com/kiprotect/klaro
In Consent-O-Matic: Automatic handling of GDPR consent formskiprotect
klaro
JavaScript2020–2022
kiprotect / klaro
klaro
Klaro Privacy Manager. An open-source, privacy-friendly & compliant consent manager for your website.
2Distinct people
16Mentions
0Explicit recommenders
1.5KGitHub stars
What to know before exploring
What it is
Klaro Privacy Manager. An open-source, privacy-friendly & compliant consent manager for your website.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month16 dated mentions
Observed mentions: 2020-05-08 13:50:06 UTC to 2022-03-10 13:57:36 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| May 2020 | 2020-05-01 00:00:00 UTC | 2020-06-01 00:00:00 UTC | 1 | 0 | 1 |
| Jun 2020 | 2020-06-01 00:00:00 UTC | 2020-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2020 | 2020-07-01 00:00:00 UTC | 2020-08-01 00:00:00 UTC | 3 | 0 | 3 |
| Aug 2020 | 2020-08-01 00:00:00 UTC | 2020-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2020 | 2020-09-01 00:00:00 UTC | 2020-10-01 00:00:00 UTC | 1 | 0 | 1 |
| Oct 2020 | 2020-10-01 00:00:00 UTC | 2020-11-01 00:00:00 UTC | 3 | 0 | 3 |
| Nov 2020 | 2020-11-01 00:00:00 UTC | 2020-12-01 00:00:00 UTC | 1 | 0 | 1 |
| Dec 2020 | 2020-12-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2021 | 2021-01-01 00:00:00 UTC | 2021-02-01 00:00:00 UTC | 2 | 0 | 2 |
| Feb 2021 | 2021-02-01 00:00:00 UTC | 2021-03-01 00:00:00 UTC | 1 | 0 | 1 |
| Mar 2021 | 2021-03-01 00:00:00 UTC | 2021-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2021 | 2021-04-01 00:00:00 UTC | 2021-05-01 00:00:00 UTC | 1 | 0 | 1 |
| May 2021 | 2021-05-01 00:00:00 UTC | 2021-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2021 | 2021-06-01 00:00:00 UTC | 2021-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2021 | 2021-07-01 00:00:00 UTC | 2021-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2021 | 2021-08-01 00:00:00 UTC | 2021-09-01 00:00:00 UTC | 1 | 0 | 1 |
| Sep 2021 | 2021-09-01 00:00:00 UTC | 2021-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2021 | 2021-10-01 00:00:00 UTC | 2021-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2021 | 2021-11-01 00:00:00 UTC | 2021-12-01 00:00:00 UTC | 1 | 0 | 1 |
| Dec 2021 | 2021-12-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2022 | 2022-01-01 00:00:00 UTC | 2022-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2022 | 2022-02-01 00:00:00 UTC | 2022-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2022 | 2022-03-01 00:00:00 UTC | 2022-04-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
16 sourcesIn 2018 I built a privacy-friendly open-source consent manager (https://github.com/kiprotect/klaro) which is used on many websites across Europe. From the beginning I never liked the IAB, didn't implement it and told people that I regard it as unlawful since e.g. a user cannot possibly make an informed decision that involves thousands of third-parties. Still many of our users kept asking me about it since it was "the way" to become compliant.
So I finally asked the IAB how one could potentially implement their framework as an open-source framework. Their answer was basically that it's not possible. You have to register as a CMP provider and ensure that your users are using your software in their compliant (ha ha) way, which is of course impossible to enforce with an open-source software that everyone can self-host. In general, in my opini
Read the rest
on the IAB is mostly a framework to shift liability from the advertisers who steal the users' data to the publishers and CMP providers. Therefore I'm quite happy we never got around to implement this "feature" in our CMP, and I hope the IAB will quickly die and takes all those alibi CMP providers down with them.
Having designed several sites and products without frameworks (e.g. https://github.com/kiprotect/klaro/tree/master/src/scss) I think it's way more concise and easy than relying on a framework.
In Ten Years of BootstrapMaybe Klaro? https://github.com/kiprotect/klaro
It's FOSS, BSD-3 licensed. It has been in development for three years now, just today I made a new release to improve contextual consent functionality (e.g. for Youtube videos).
In Ask HN: The best Cookie Warning popup you've seen recently?What the author discovered here is the full list of publishers as given by the IAB consent framework [1], which is an attempt at self-regulation by the ad industry and website publishers.
Presenting the user with the full list of advertisers is indeed silly and not compliant IMHO. We also offer an open-source privacy & security tool for websites (Klaro! - https://github.com/kiprotect/klaro) and we have decided against implementing the IAB framework as it's clear that it does not conform to the intent of the GDPR. We also opted against using dark-patterns and making declining more difficult than accepting. Overall this results in slightly less opt-ins (around 50-70 % for most websites) but in any case those dark patterns will have to go sooner or later.
[1] https://iabeurope.eu/transparency-consent-framework/
In What Do You Agree to When You Accept All CookiesThe ePrivacy regulation is being negotiated right now, your best bet is to join the lobbying. It's for certain that there will be some amendments to the GDPR and ePrivacy directive regarding the way cookies and tracking are handled for websites. In Germany the Bitkom is a good place to start if you want to make your voice heard, they have a working group on data protection that comments on the EU legislation process (you'll be a bit late to the party regarding the ePrivacy regulation though, not sure if there's still much room for change).
I don't think a citizen initiative will be likely to succeed as the regulation has been in the works for a long time and will probably be passed in one form or another, and I really doubt the EU would want to amend the handling of cookies a third time.
BTW I develop an open-source CMP (https://github.co
Read the rest
m/kiprotect/klaro) and the problem is a bit more complex than honoring the DNT header, as the user needs to grant or decline his/her informed consent for all non-essential third-party services. In the long run I think this functionality should be implemented directly in the browser, but again this will require more than a single header IMHO.
Sounds great, I'll start:
We're building Klaro (https://github.com/kiprotect/klaro), a tool that helps website owners respect and protect the privacy of their users. Right now you could mostly describe it as a consent management platform but we have much bigger plans and we think there's a way to operate websites with modern tools and services without selling out your visitors / users, and that's the vision we want to fulfill with Klaro.
We already have thousands of open-source users and also launched a commercial service a few months ago, which is already growing nicely. We want to hire our first open-source developer soon, starting with a part-time engagement while we're increasing our revenue.
Anyone interested should be knowledgeable in JS and React.js and know a good deal about browser internals (e.g. how cookies, localStorage etc. w
Read the rest
ork and which security & privacy features and restrictions apply).
The work would be fully remote and fully on open-source software (we also have physical offices in Berlin though that you could work from if you happen to live there). We're quite early in the process of hiring someone and we don't even have a job description, if you're interested to chat please just drop me an e-mail to klaro@kiprotect.com. Thanks!
Well, cookies are not per se evil and you can use them in a privacy-friendly way. You should ask for consent for non-functional cookies (for the Cloudflare cookie you probably wouldn't need to ask for consent, for example) and make sure your consent workflow is compliant with the GDPR. The European Data Protection Board just published guidelines on this btw (in May): https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_gui...
We e.g. offer an open-source consent management solution that is compliant with GDPR (as much as you can say that with confidence) and which you can self host: https://github.com/kiprotect/klaro
Building sites without cookies is possible but it's a bit extreme IMHO. Properly scoped and limited first-party cookies do not pose a large privacy risk to indivuals and can make certain legitimate use cases like analytic
Read the rest
s much easier (or even possible, in some cases).
That will still break your site if the CDN updates the file because it won't load anymore. The point the author made was that people use libraries distributed by CDNs to get auto-updates and fixes, sadly that won't work in combination with CSP as you'll still have to update the integrity tag manually.
We deliver integrity tags for our CDN files as well btw (https://github.com/kiprotect/klaro/blob/master/releases.yml), that doesn't solve the auto-updating problem though.
In Please stop using CDNs for external JavaScript libraries> Latest software versions automatically when the CDN updates.
I'd also be very careful including a JS library from a CDN that gets auto-updated to the latest version, this might break your site without you noticing.
We did this with our own JS library (Klaro - https://github.com/kiprotect/klaro), for which we offered a CDN version hosted at https://cdn.kiprotect/klaro/latest/klaro.js. We stopped doing that with version 0.7 as we realized we could not introduce any breaking changes without risking to break the websites of all users that were using the "latest" version. So what we do know is that we only automatically update minor releases, i.e. we have a "0.7" tag in the CDN that will receive patch releases (0.7.1, 0.7.2 , ...) and which users can safely embed in their websites.
That said we always recommend users to self-host their scrip
Read the rest
ts as well and to use integrity tags whenever possible, it's usually better from a security and privacy perspective as well.
Like most JS libraries Klaro is quite small (45 kB compressed), so the loading time is dominated by the connection roundtrip time, which again is dominated by the TLS handshake time. For our main servers in Germany we have a roundtrip ping of around 20 ms (for most connections from Germany), and with the TLS negotiation it takes about 60-100 ms to serve the script file from our server. If the server connection is already open that time reduces to 20-40 ms. So the benefit of hosting small scripts with your main website content is that your browser doesn't have to do another TLS handshake with the CDN, which for small scripts can dominate the transfer time. If you then use modern HTTP & TLS versions you can reduce the transfer time quite a bit.
Interesting post. We're also building a business based on open-source / open-core software and have managed to build an active Github community around our first product (Klaro - https://github.com/kiprotect/klaro). It's a pretty simple tool that helps organizations to manage consent and protect their user's privacy on their website. We have other, more complex products in the making as well (e.g. https://github.com/kiprotect/kodex - a privacy engineering toolkit). What we found during the development of Klaro is that even a very simple product can require a tremendous amount of work to turn into a functioning product. I think we're almost there now but it took several months of building and refining.
For me, the main benefit of developing in the open is the great feedback and contributions we get from our community. A lot of people have r
Read the rest
eached out to us based on our open-source work, I don't think this would've happened if we had developed a closed-source tool.
We're building open-source privacy solutions for websites and we also regularly scan the web for tracking technologies, as the article says Google Analytics is by far the most popular technology we find, followed by Facebook tracking pixels, Adobe Tag Manager and other analytics services. That said the amount of tracking on a site depends greatly on how it is funded. Websites that generate their revenue from advertisements tend to have 5-10 times more trackers installed than e.g. e-commerce websites.
So right now it's pretty much a "Win-Lose" situation as website publishers try to force privacy-invading trackers on users, which clearly have no interest in being tracked. Current consent management solutions are (IMHO) not a great solution for this problem, as consent managers that use dark patterns (e.g. each tracker needs to be disabled b
Read the rest
y hand, decline buttons are hidden two or three layers deep, ...) are not compliant and consent managers that give users a free choice have bad opt-in rates (which is not surprising). On our own site for example, about 50 % of users decline consent (live stats here: https://kiprotect.com/klaro/demo), based on consent requested via our own, user-friendly consent manager (it's open-source btw: https://github.com/kiprotect/klaro).
Another dilemma is that most publishers don't want to force invasive tracking on users, but they don't have much choice as the tracking/analytics market is highly concentrated and there aren't many privacy-friendly options that can deliver the required functionality and visibility.
Most of the time your users will become your contributors. That's mostly true for libraries targeted at developers, but even if you build software for non-technical users some of them will be developers and will eventually contribute.
Don't expect your community to build large features for you, even though that happens from time to time my experience is more that most people contribute small patches and improvements. That's great too because the small things can be quite time-consuming, so if your community has your back on things like documentation or translations it can help a lot.
One of our latest open-source projects is Klaro (https://github.com/kiprotect/klaro), an open-source consent manager for websites. We already got some really great contributions from our community, most people that contributed did so to solve a problem they h
Read the rest
ad with the software (e.g. missing translations) or to build something they wanted for themselves. We don't accept all PRs but if they are in line with our development goals we're happy to merge them.
We're in the process of monetizing an open-source project as well (Klaro - https://github.com/kiprotect/klaro). The project started as a "weekend hack" for our own website and became quite popular over time, to the points that it's used on thousands of websites already. We plan to keep the client software (i.e. the part that runs in the browser) open-source and feature-complete. We want to charge for backend services (managing consent data, scanning websites) and comfort features like a graphical configuration editor. That way we hope to enable users to still get great free value from the open-source version while allowing us to raise money for the development.
Contrary to some other voices here we had great community contributions to our project right from the start: For example, almost all translations are contributed by the community
Read the rest
and even some of the non-trivial features have been built by community contributors. That said it's a rather simple Javascript project and we try to keep it as accessible as possible. We have another open-source project (KIProtect - https://github.com/kiprotect/kiprotect - just open-sourced it last week actually) which is way more complex and that we also want to monetize, we'll see how many contributions we'll get for that.
Small changes in UI can have a significant effect on acceptance rate. I'm developing an open-source consent tool (Klaro - https://klaro.kiprotect.com, Github: https://github.com/kiprotect/klaro) and where to put the different buttons, which colors to give to them and how easy to make opt-out is a large debate in our community. By default we favor a very user-friendly approach but we give our users (i.e. the website owners) different ways to ask for consent: A mandatory modal, a consent flow that accepts all cookies/apps (or customize) and a consent flow that accepts only a pre-selection of cookies/apps by default. In every flow there's a "Decline" button that visitors can use, so declining consent is just as easy as giving it. Most website publishers prefer the "Accept all" flow as they usually have a good reason for including a given app
Read the rest
/tracker on their website, so only choosing a subset doesn't make much sense. A few sites also implement the mandatory flow, where the visitor won't be able to see the website content until he/she has chosen to either give or decline consent (and again, both options are equally simple to reach).
From a GDPR and ePrivacy perspective it's clear that opting out needs to be just as easy as opting in. Most websites violate this principle as opting in is in fact way easier, and often the UI is designed to be deliberately confusing to the user.
IMHO the consent problem one of the central unsolved issues in privacy though, as most people would not opt-in to tracking if they were given a real choice.
Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.