Add opt-in telemetry for Gfycat

[jewel-andraia]

Per #4430, Gfycat has requested that clients send impressions for Gfycat's analytics.

This implementation should satisfy certain constraints:

• Request user consent
  • Store consent in settings
    • Add boolean option to Gfycat media host for gfycatPhoneHome: Consent to send analytics telemetry to media host
    • When module settings are saved, if gfycatPhoneHome is changed, then store the datetime (unix milliseconds) in a hidden (enabled: () => false) text option.
    • OR MAYBE store the event in RES storage? like RES.events.append({ type: 'options', payload: { moduleID: 'gfycat', optionId: 'gfycatPhoneHome', value: true|false, oldValue: true|false }, timestamp: Date.now() }
• Add button (link) option to Gfycat privacy policy (same as in https://github.com/honestbleeps/Reddit-Enhancement-Suite/issues/4981)
• Notify user confirmation of telemetry/consent
  • MAYBE show notification (sticky?) when saving to enable consent, "hey you did the thing, click this button if you want to go turn it off"
  • Evangelize consent opt-in / opt-out
    • Show notification on first time user opens Gfycat expando (i.e. cooldown of forever) that Gfycat has requested analytics telemetry and would they pretty please opt in by clicking this button to visit the settings console and enable it
    • MAYBE Periodically notify user that telemetry is being sent and they can disable it by clicking button through to this option? (e.g. when expando is opened, show a notification linking to the option with a cooldown period of 6 weeks)
    • MAYBE Periodically notify user that telemtry is being not sent every 6-8 weeks and ask permission again?
• Gfycat implementation requests:
  • Include a client ID (RES will need to register one. I could take care of it.)
  • Send impression pixel for single or batch ("view all images" pageload)
  • Send impression pixel on "user returned to page" (page is visible again) while video is playing

I think this pixel must be sent from the background page due to extension security constraints on foreground pages. I believe this is handled invisibly by RES's ajax helper.

[jewel-andraia]

What opinions do folks have? I'm open to thoughts on implementation details so that we do right by both RES's users and the platforms which RES relies on.

The RES team has hesitated to implement analytics telemetry of its own for a few reasons:

• Yes Means Yes: ask consent before collecting data, and provide enough information to earn a reasonably-informed yes.
• Data stewardship: collecting and storing user data brings a lot of legal liability, such as GDPR.
• cost: APIs, databases, and analytics packages aren't free: you're either paying in money or data rights.
• security: data in transit and data in storage are subject to theft or manipulation. It's a pain to deal with.
• community blowback: many RES users are very protective of their privacy and security. See also: Yes Means Yes.

When it comes to providing client analytics to other platforms, the RES team is not responsible for stewardship or cost. However, RES should request consent from users to collect data and provide notice to users when it is aware data is being collected. Additionally, that data should be transmitted reasonably securely. The implementation details for requesting consent which RES uses should be satisfactory to most everybody, which means being a little obnoxious to be informative and do right by the platforms, but also being mindful of not irritating users with asking/notifying for consent too often.

[benmcgarry]

I do not feel comfortable right now with allowing telemetry for a third party service within the extension.

RES has always prided itself in being very user focused and we have a good track record with not messing around with users privacy. Allowing a single media host telemetry data would set a bad precedence as others may come along asking for the same thing which puts us in a sticky position.

Not to mention the pain this will cause with getting the extension approved on the browser extension marketplaces. Review processed would become a lot more strict if we are sending data out to third party endpoints. I can't imagine Mozilla would be too happy with it being very user security and privacy focused.

We need to tread very carefully because even if we do implement it, if there is a slight security/privacy issue on our end, it will blow up in our faces.

[honestbleeps]

I'm also not very comfortable with this. If it's the price way have to pay for support, I'd consider dropping support as the preferred option right now.

I don't see why we'd be responsible for providing telemetry that a host can already track on its own via API hits (why do they not track that?), unless they're also wanting us to provide stop/play/pause/repeat events etc - which is a big ask, and in that case an SDK should be provided even if I were OK with providing such events.

basically, while I may not fully understand the reasons we're being asked for telemetry, I'm also not sure that any reasons justify it in my mind.

it is absolutely right, of course, to put this up here as an issue for the community and core developers to discuss, and I laud @andytuba for doing that, to be clear. My tone is a dismissal of the API requirement, not of andytuba rightly putting the new requirement up here for discussion!

[Ajedi32]

I'd like to point out that any expandos that use an iframe likely already send analytics data to the embedees, so this isn't exactly unprecedented. In fact, we have a lot more control over the data sent in this case, so it's actually strictly better from a privacy perspective than other expando implementations.

As for implementation, rather than an annoying pop-up or notification I strongly recommend embedding any consent requests within the expando itself. (Probably as a simple one-line explanation with yes/no buttons, with a link to more information on exactly what information is included in the analytics data.) This would be much more user-friendly, and makes the association between expanded content and request for consent more clear.

Whatever button the user clicks, change the relevant setting don't bother them again. This isn't important enough to be worth asking more than once. Maybe add a gear icon at the bottom of the expando linking to the relevant settings page (maybe for all expandos, as I think that's just good UX in general).

Also, we need to make sure we respect incognito mode and avoid sending analytics data or prompting the user when that mode is active.

If, in the future, we end up implementing this for other expandos, there should also be a global setting to toggle everything on or off (and maybe an additional button for the consent requests to easily access that setting).

[benmcgarry]

I'd like to point out that any expandos that use an iframe likely already send analytics data to the embedees, so this isn't exactly unprecedented. In fact, we have a lot more control over the data sent in this case, so it's actually strictly better from a privacy perspective than other expando implementations.

While this is true yes, we are talking about actually going out of our way for a media host to gather telemetry unique to RES apposed to it being universial for all API hits. We suddenly become responsible for how we manage it from our end as apposed to it being baked into their own APIs and it being their responsibility.

[benmcgarry]

Upon further thought on this, i would feel a lot more comfortable if we could reach out to the Gfycat team to see what information they actually gather against their supplied docs. Then we can make an informed decision and see what the impact to the end user would be.

[Brcrwilliams]

I see no reason to do this. They are asking that we send them the user's tracking cookies, since the cookies aren't necessarily sent when API calls are being made. I dislike these analytics methods, I block them on all sites that I visit, and I would not like for them to be implemented into any software I use. Full stop.

So, my mind is already made up at that point. Then you add on the legal conundrums and the amount of work that this would cost us and it solidifies into a hard no. I agree with @honestbleeps: If this is really a requirement for Gyfcat, then I would rather drop Gyfcat support than implement these analytics.