Consider making pingback and remote fonts configurable

[jbg]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

giphy-js makes analytics pingbacks and loads fonts from a remote server, and these behaviours are not configurable.

Expected behavior 🤔

These behaviours should be configurable (and ideally should be opt-in).

Steps to reproduce 🕹

Steps:

1. Use giphy-js in a project.
2. Observe connections to remote servers for analytics and loading of remote fonts.

Screenshots or Videos 📹

No response

Platform 🌍

All

GIPHY-JS SDK version

All

TypeScript version

All

Additional context 🔦

The lack of configurability of this functionality forces projects which care about their users privacy to apply patches, e.g. https://github.com/jitsi/jitsi-meet/pull/11457/files

[LBBO]

I'm interested in creating a PR for the second part of this, i.e. disabling the pingbacks. Since I find the environment variable overly cumbersome, I'd like to implement a prop that can be passed to the individual components in order to control the pingbacks. I could also add a corresponding property for the fonts.

Furthermore, in the interest of Privacy by Design, I would like to make this an opt-in setting. Please let me know if you have any objections.

[pshoniuk]

@jbg Thanks for your feedback. Pingbacks are invaluable to maintaining and improving GIPHY products, so we don’t have plans to accommodate this request

[jbg]

At the very least, disclosing this behaviour clearly in the README would allow developers who use this library to comply with the requirement to get informed consent from their users, as required by myriad privacy laws these days. At the moment it's just a hidden unpleasant surprise that this library sends analytics data.

[LBBO]

Despite not being a lawyer, I would like to add some context from the GDPR that I find relevant here. In Recital 47, which expands on the concept of "legitimate interests" that may justify collection of data without user's constent it says:

[3] At any rate the existence of a legitimate interest would need careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place. 
[4] The interests and fundamental rights of the data subject could in particular override the interest of the data controller where personal data are processed in circumstances where data subjects do not reasonably expect further processing.

I would argue that these components may be used in contexts where the collection of this data is not reasonably expectable*. Therefore, to comply with the GDPR, developers would have to be able to block these requests (or at least allow their users to disable them), which your decision makes impossible. I could see this forcing projects to re-implement these components on their own, which costs them time, will pobssibly result in a worse product and that might come back to damage your brand, e.g. if users see its name associated with a bad UI.

Again, I want to emphasize that I am not a lawyer. But neither are most developers and I can imagine that many of them, just like me, would rather be on the safe side and not risk violating the GDPR. This decision just forces them to not use this library.

More importantly though, I would agree with @jbg that the collection of data should be prominently disclosed in the README, as the current version might lead developers to accidentally and unknowingly violate the GDPR.

---

* Personally, I would even argue that it is never reasonably expectable that an app may collect data about me hovering over an HTML item, combined with a presumably unique user ID. ESPECIALLY if this data is being collected just for a 3rd party.