Polyfill-service: Ghostery blocks downloads from polyfill.io

[murdoch]

Appologies if this is not the place to report polyfill.io issues.

Ghostery (browser anti-tracker plugin) does not appear to like polyfill.io, screenshot attached

As you can see the console error:

failed to load resource: net::ERR_BLOCKED_BY_CLIENT

Which occasionally becomes:
GET https://cdn.polyfill.io/v2/polyfill.min.js net::ERR_BLOCKED_BY_CLIENT

Is polyfill.io tracking visitors?
If so, is there a way to ask it not to?
Is there a way round this which doesn't involve removing polyfill.io? Do I need to manually install the service, without using the CDN?

Why does polyfill.io track users?

[JakeChampion]

Hi @murdoch, we have a privacy policy which should explain everything you are wanting to know -- https://polyfill.io/docs/privacy-policy#what-information-do-we-collect-from-the-service

I'm not sure how Ghostery decides what to block and not block. If you know a good next step to take to get polyfill.io unblocked that would be useful :-)

[murdoch]

Thanks @JakeChampion - I'll email ghostery and ask them :+1:

[alonnberg]

What did Ghostery say?

[murdoch]

Hi @alonnberg here is their response:

Hi Stephen, thanks for reaching out.  We've had a few developers contact us about Polyfill.io in the past as well. What we did then was move Polyfill to our Essential category, which is our admittedly imperfect way of telling users that this is a script required by the website.  Additionally, we introduced a Smart Blocking feature in Ghostery v8 intended for "set-and-forget" users, a feature of which keeps trackers in the Essential category unblocked.  However, our "power users" are more likely to forgo that setting and block everything, including Essentials.  

Unfortunately, Polyfill.io is a third-party script collecting user data, including IP information.  Ghostery gives our users the choice as to whether they would like that information to be shared.  Many of them would rather see a broken page then have their data sent to a third party. 

I wish I had a better solution for you in this case.  Have you considered switching to a transpiler like Babel, instead of polyfills? 

I understand (and agree with) ghostery's point on this matter.

I imagine polyfill.io probably needs to stop logging people's IP addresses to get this reversed.

FWIW, the privacy policy for polyfill.io states:

The information we retain cannot identify you.

They obviously weren't expecting any developers to read it!

[JakeChampion]

I'm not sure what you meant by:

They obviously weren't expecting any developers to read it!

The information we log with regards to IP address is the country code associated with the IP range:
https://github.com/Financial-Times/polyfill-service/blob/master/vcl/main.vcl#L175

We also record a salted and hashed extract of 16 bits with a 16 bit offset, which is the first 16 bits of an IPv4 address and bits 96-114 of an IPv6 address. The code which extracts the IP bits is located in the file linked below:
https://github.com/Financial-Times/polyfill-service/blob/master/vcl/main.vcl#L170

[alonnberg]

@JakeChampion: What!?
The policy you referred too says that the IP is not logged.

We then retain only the following information: the domain of the web page which has made the request to the Service; the user agent string for your browser; the set of polyfills that were requested by the web page.

And now you say you log the country of the IP. It do sound like Ghosterys choice of blocking you is even more correct when your privacy policy apparently only tells part of the truth...

[JakeChampion]

@alonnberg I agree, you are absolutely correct. The code I have linked to is what is expected to go out in the next release however, noticing that it would violate our privacy policy I have put a hold on making the release.

[JakeChampion]

To update this issue. We are going ahead with the release but have disabled the logging backends which means we would not be recording any data which would be in violation of our current privacy policy, the code is still in the repository but it does not do anything on our servers.

The reason to start recording this information is to enable the polyfill service to be able to decide based on the data it has collected, which polyfills should be served to which browsers. Currently that is a manual process and something which takes a long time to roll out. Making it an automatic process based on real world data means we could serve the correct polyfill combination to many different browsers that we currently do not support E.G. UCBrowser, OviBrowser, DolphinBrowser etc.

We will be updating the privacy policy before we implement this feature and definitely before we start recording this data.

I will also be contacting Ghostery at some point to see what we can do to help get polyfill.io off of their blocklist.

[triblondon]

It seems incorrect to say that Ghostery has a policy of blocking polyfill.io. They don't, they have a policy of indexing all services that are used by websites as third party scripts, which is the way polyfill.io is designed to be used. So it seems unlikely that Ghostery will remove us. As they said, they've put us in the essentials category, and I just validated that:

It's unclear why we're in there because right now, in accordance with the privacy policy, polyfill.io does not log any IP-derived information. It used to, and when our first privacy policy was published, we stopped doing that because it seemed unnecessary. Now, we would like to enable logging of an anonymised, aggregated, IP-derived hash, in order to identify patterns of usage and abuse of the service. This violates the privacy policy, which is why the FT is working on a new one.

If logging a hash of 16 bits of the IP using code that is publicly inspectable, and only on websites that have opted in, is not acceptable to Ghostery to remove us entirely from their database then I think it's likely we will remain on their list albeit in the Essentials category.

There's a world of difference between Polyfill.io's behaviour and that of an behavioural ad tracking network, or even an analytics provider like Google Analytics, which logs many orders of magnitude more information that we do. In fact, if possible, we hope to make the information we're logged completely public, because if we're confident that it doesn't infringe privacy, then there should be no reason to keep it confidential.

[triblondon]

Some misunderstanding here might result from the fact that Ghostery refers to all third party scripts as 'trackers', regardless of whether or not they do any tracking (which, right now, polyfill.io does not).

[oyeanuj]

@JakeChampion @triblondon thank you for the updates, appreciate that! please do keep us posted as you contact Ghostery!