CII Best Practices badge application not affected by EU GDPR "like" button issues

David A. Wheeler

The Court of Justice of the European Union (ECJ) has ruled that online websites that embed a Facebook "Like" button are responsible for the data they send to Facebook and are liable for the same penalties under EU data protection laws. There are many reports about this, e.g.:

While it's true that the CII Best Practices badge application has "share" buttons (e.g., see the bottom of ), to my knowledge the CII badge website is *not* affected by this ruling. I explain why (in detail) below. Basically, instead of using the dangerous "Like" buttons, we use "Responsible Social Share Links" ... that means that users can see our web pages (even the ones with share buttons) without having that fact automatically reported to some social media site. Social media sites only receive information when the user specifically chooses to do this. We also don't send our information on "who accessed what" to anyone or accept payment to act on that information.

If there's an error or any other kind of security/privacy issue, please let us know so we can fix it. We've made serious attempts to counter exactly these kinds of problems, but we're human and it's possible we've missed something. We want our site to be secure & to respect the privacy of others.


--- David A. Wheeler

=== DETAILS ===

The "like" button that Facebook recommends that people use transfers personal data automatically when a non-Facebook page loads. That approach means that a user's visiting of that non-Facebook page is immediately revealed to Facebook without the user's knowledge or consent.

However, the "share" button we implemented in the CII Best Practices badge site has *never* worked that way. One of our requirements ( ) is to "Protect users and their privacy. In particular, we MUST comply with the EU General Data Protection Regulation (GDPR). Don't expose user email addresses, and don't expose user activities to unrelated sites (including social media sites) without that user's consent." As a result, we *never* accepted privacy-destroying constructs such as pages that transclude third party artifacts. We explain how we do this in . In particular, here's how we handle this:

"We do have links to social media sites (e.g., from the home page), but we do this in a privacy-respecting manner. It would be easy to use techniques like embedding images from external (third party) social media sites, but we intentionally do not do that, because that would expose to an external unrelated site what our users are doing without their knowledge. We instead use the approach described in "Responsible Social Share Links" by Jonathan Suh (March 26, 2015) , specifically using share URLs. In this approach, if a user does not press the link, the social media site never receives any information. Instead, a social media site only receives information when the user takes a direct action to request it (e.g., a click), and that site only receives information from the specific user who requested it."

This is part of a more general approach to supporting privacy. That same security section also notes that, "We directly serve all our assets ourselves, including JavaScipt, images, and fonts. Since we serve them ourselves, and never serve information via external third parties, external sites never receive any request from a user that might impact that user's privacy. This is enforced by our CSP policy.... We do not use any web analytics service that uses tracking codes or external assets. We log and store logs using only services we control or have a direct partnership with." Our page (which provides instructions on contributions) says, "Avoid mechanisms that could be used for tracking where possible (we do need to verify people are logged in for some operations), and ensure that third parties can't use interactions for tracking."

We also ensure that the site's main functionality (displaying and editing project & user data) works even when JavaScript is disabled. From a security and privacy point-of-view, automatically running arbitrary code provided by all sites is more dangerous (due to malicious code, fingerprinting, and so on). Our site works better with JavaScript, but we ensure (and test) that the main parts work without JavaScript so that users can choose to enhance their security and privacy (by disabling JavaScript) if they desire to do so. This isn't possible to do for all web applications, but it's certainly possible for many web applications including ours.

If you see a remaining security / privacy issue, please let us know. For details on vulnerability reporting, please see: