Can i use it in europe – GDPR?

Yes, there is a problem. It’s the fact that there’s no option to load the icons locally. The plugin makes use of a 3rd party CDN exclusively, which is difficult to justify under GDPR.

Hi there,

Great question. Alas, I’m not familiar with the GDPR’s implications re: the use of CDN. Can you explicate a bit more?

I find it hard to believe that the GDPR would preempt the usage of assets hosted on CDN/3rd-parties given that 99% of the web does this. For example, wouldn’t this also mean that you can’t load Google’s CDN version of jQuery?

Definitely let me know if I’m missing something. Much appreciation for bringing this issue to light!

Yeah –?this seems to be a problem. Maybe you can implement a function to refer to another URL of FontAwesome so that we can place it on our own server.

Otherwise I have to deactivate the plugin May the 25th. ??

Indeed, CDN’s are a problem under GDPR because you’d need a data processing agreement with them to form a legal basis for collecting and storing private data.

Under GDPR, an IP address is considered private data so we all have to go through this whole contract/agreement Spiel to make it feasible.

Thanks so much to all for researching this. I’ve done a bit of research as well and concur with what you’ve all suggested, though I’m not 100% clear on the details. Are there certain CDN’s that are compliant, or are all CDN’s out of the picture?

In the meantime, you do have a method for bypassing any CDN usage via the bfa_force_fallback filter. You can see documentation here: https://github.com/MickeyKay/better-font-awesome-library#bfa_force_fallback

I think this is your best bet to resolve this issue prior to the 25th, as I can’t commit to implementing a solution by then. In a perfect world, I’m imagining that BFA would give you the option to download and then locally serve any version of Font Awesome, however I won’t be able to ship this by the 25th. If, on the other hand, there is another reliable CDN that somehow complies with GDPR, then perhaps I can ship a minor release that implements this change.

Let me know what you think, and thanks again!

Adding jsdelivr’s thread on GDPR: https://github.com/jsdelivr/jsdelivr/issues/18067. Curious if this has any bearing on your concerns.

Another update. MaxCDN appears to have addressed GDPR more directly: https://www.keycdn.com/gdpr. I’m not qualified to interpret this, but this info does suggest that MaxCDN might be more, if not fully, compliant. Can you please review this link and let me know what you think?

Both possible but only with a data processing agreement in place before enabling it.

Hey guys,

is there news about this? Are we forced to locally serve it, or will a paragraph in the privacy policy suffice? GDPR is such a clusterfck…

@mcguive7 can you elaborate which kind of data is transmitted? Only IP? Is there a way for you to implement a checkbox that masks IP’s maybe?

I will be using your new FA plugin as well, as soon as its production ready, so this will affect that too.

Thanks for you help in advance!

Tim

• This reply was modified 6 years, 5 months ago by farbenfeuer.

Hi all,

These are all great questions that I am unfortunately not qualified to answer. I’d be happy to make any reasonable changes required top make BFA compliant. What I need from y’all is a clear list of what the known and potential problem areas are.

It’s hard for me to imagine this is being handled widely on the plugin side, since it would require literally thousands of plugin authors to update their plugins, and I strongly doubt this is happening.

Now, if BFA is the only issue for some of you, and the fix is relatively innocuous, I’d be happy to make some updates.

@farbenfeuer per the latest beta – have you giving it a spin yet? I’m just holding off on getting more testing feedback.

Hi Mickey,

maybe it’s an option to you to add the latest version of FA files to the plugin an give an option to load them instead of any other version / latest version via the cdn.

Greets,
Marciel

Hi @cyberian90,

While I understand the reasoning behind your suggestion, at this point BFA just becomes an icon picker. You can achieve this yourself very simply by writing a tiny bit of code to dequeue the CDN version of CSS and enqueue the latest on your own. The whole purpose of this plugin is that it dynamically pulls in the latest version of FA for you.

That said, the real bottom line here is that I’d still like someone to clearly articulate to me what the specific nature of the problem is. Most likely your hosting providers are all logging IPs as well – how is this different from one of the most trusted CDNs out there handling data?

Again, I’m happy to make changes but I need to better understand the issue at hand first. Can anyone enlighten me?

Hi @mickey Kay,

I try to explain the legal problem. The new regulation obliges website operators within the EU to apply different principles. Including data economy and transparency. Another principle is the so-called permission reservation. This means that, in principle, the user must give his consent for data processing and / or data transfer before it takes place.

Some of the most sensitive data include IP addresses, if they are timestamped and thus attributable to a specific person.

When external CDN is called, the IP address and time stamp are transmitted. I therefore need the permission of the user beforehand. A tacit agreement is not enough.

If the data are transmitted to servers outside the EU and thus to the scope of the GDPR, even stricter rules apply. Here I would have to conclude as an operator a contract for data processing, data storage, protection against disclosure by unauthorized third parties and the like with the CDN operator and also seek the consent of the user.

Also the own hoster collects this data when calling my page. That’s right. Here, however, as operator of the site, I have concluded such a contract (which is now offered by all hosters). The regulation grants a legal exception here, since the user’s consent is considered given when he calls the page. The legislator assumes that the user knows about the circumstance of the data transfer to the server of the site when he calls it. However, he does not necessarily know that data is being transferred to other servers, so he must be informed in advance and asked for permission.

I hope that the problem has now become more understandable.

• This reply was modified 6 years, 5 months ago by BartzikWebdesign.

@cyberian90 – well explained – I learned something – thanks ??

@mcguive7 – I realize this would be a big undertaking and so I will totally understand if you are not up to it, but I would like to ask you to consider writing the plugin so that Font Awesome icons are loaded once from Font Awesome to the local server, and then your plugin pulls them from the local server instead of externally.

The same GDPR issue lies with Google Fonts and a developer has made a plugin that download Google fonts once and then loads from the local server – Self-Hosted Google Fonts – https://www.ads-software.com/plugins/selfhost-google-fonts/