1220844 - Embedded video on SmartOn Tracking sending pings to non Mozilla GA account

Status: RESOLVED FIXED

(www.mozilla.org :: Pages & Content, defect)

Description

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Attachment: Non Mozilla GA pings

This bug is to call out that the site we are getting the embedded video from is sending pings to a Non Mozilla GA account. This was brought to my attention by garethc.

Just want to make sure we are aware of the risk of talking about DNT, and sending pings to a non Mozilla GA account.

A secondary item to note is that in bug 1217896, we enclosed our GA in a DNT wrapper. The site we are hotlinking to does not do the same.

Is there a reason we aren't hosting this video ourselves?

Comment 1

[Alex Gibson [:agibson]]

To be clear, this is not a video. What we're doing is loading a third party website into an iframe on a mozorg page. We have zero control over that content. 

I did query this during review and noted that it wasn't very good for performance. The embedded site clocks in at around 100MB, and makes nearly as many HTTP requests. The fact is also uses GA under the hood is probably another reason why we should not be embedding it (this I did miss). IMO, we should just link to the site instead (opening the page in a new tab if folks are worried about people dropping off our site).

Comment 2

[Jennifer Bertsch [:jbertsch]]

(In reply to Cory Price [:ckprice] from comment #0)
> Created attachment 8682160 [details]
> Non Mozilla GA pings
> 
> This bug is to call out that the site we are getting the embedded video from
> is sending pings to a Non Mozilla GA account. This was brought to my
> attention by garethc.
> 
> Just want to make sure we are aware of the risk of talking about DNT, and
> sending pings to a non Mozilla GA account.
> 
> A secondary item to note is that in bug 1217896, we enclosed our GA in a DNT
> wrapper. The site we are hotlinking to does not do the same.
> 
> Is there a reason we aren't hosting this video ourselves?

Could you please review for compliance, Stacy?

Comment 3

[Jennifer Bertsch [:jbertsch]]

Adding Gregory.  He is the content stakeholder.

I'm OK if we need to just link to the website for performance and privacy reasons.

Comment 4

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

NI Greg - okay to just link off to this person's website instead of introducing a 3rd party iFrame?

Comment 5

[Craig Cook (:craigcook)]

Attachment: Github pull request https://github.com/mozilla/bedrock/pull/3500

Comment 6

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

In the interest of making our deadline for tomorrow with the least amount of risk, we are going to comment out the interactive iFrame, and replace it with a link.

Comment 7

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/843a731ea1beecf42b9c57909bf862854ac1b44f
Bug 1220844 - Remove the interactive embed from SmartOn Tracking

Fall back to a plain link, opens in a new tab.

https://github.com/mozilla/bedrock/commit/23ec09e7d212101d14c5f64f63569055dc1b953e
Merge pull request #3500 from mozilla/bug-1220844-smarton-remove-donottrack-embed

Bug 1220844 - Remove the interactive embed from SmartOn Tracking

Comment 8

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Spoke briefly with Greg. We're going to production with the iFrame commented out, but will reconsider based on Stacy's recommendation.

Three primary concerns from the webprod team are:

1. iFrame means we are at the will of the content the 3rd party puts up (and is able to keep up facing traffic)
2. sending pings to a non Mozilla GA account
3. the 3rd party site is adding ~100MB to the size, and makes a excessive amount of HTTP requests

Comment 9

[Gregory Jost]

I am ok with opening a new tab as backup solution. Will defer to Stacy on whether that's necessary from a privacy standpoint.

For the record, I have a strong preference for keeping this content as part of the experience if we can. 

- Privacy: the documentary has links (incl. in the iframe) to their privacy policy and from the context I think it is pretty clear that users are viewing third-party content. Question becomes is this a violation of our privacy policy?

- Performance: we recently placed the iframe in a modal window partly to minimize load issues (only gets triggered when modal opened).

- We have been very intentional about wanting to makes this part of the experience, incl. via an iframe embed. So I am pretty surprised that we're catching this so late in the process. What is the appropriate process to avoid those types of blind spots in the future?

Comment 10

[stacy]

Hi all,

The applicable privacy notice is: https://www.mozilla.org/en-US/privacy/websites/

One pretty standard approach is to post a "you are leaving the Mozilla site" type notice.  Is that a possibility here? (Is that the new tab solution?) Could we make it very transparent before they click that if they click on the video, they are going to a separate website and that site's privacy policy applies?

Many of the Webmaker teaching kits include embedded videos. Ex: Net Neutrality Teaching Kit John Oliver clip. https://keyboardkat.makes.org/thimble/LTQzNjIwNzM2MA==/net-neutrality-teaching-kit

Comment 11

[u554402]

^^ could Stacey's proposal to add transparent language be used to keep this as a modal dialogue that is embedded?  The series was created with "tracking" as part of its conceit, so letting users know that this is happening is within keeping of the series goals of transparency.  We could additionally warn that it loads many images and is not recommend for folks on mobile connections.

fwiw the concern over the 3rd party being able to add additional content shouldn't be much of a concern - I'm the creator of the series and also a Mozilla employee, and there are no plans (or money) from the production company to add any additional content.

Comment 12

[stacy]

Hi all,

Summarizing from a conversation with Shane Caraveo to get a more technical perspective.  We used Comment #8 as a good summary of the issue.  Within Comment #8,  the primary issue is having an embedded frame with 3rd party GA tracking - since users may not realize that the embedded iframe is 3rd party, not mozilla - and would only get the 3rd party privacy policy after the content is loaded and GA has been pinged.  It still appears to us that the best way to mitigate these issues is with a notice - either some kind of pop up - or a notice right below the iframe - to alert the user that the iframe goes to a 3rd party site and the 3rd party privacy notice will apply.  It would really help to give them a way to read the 3rd party privacy notice before they click. I like Brett's idea of including in the notice that tracking is part of its concept. If you go with the new tab approach, would it be possible to add a "leaving Mozilla" interstitial with a link to the new site's privacy notice so a user can read the privacy notice before they land on the page?  It comes down to whether users understand that a) it is 3rd party content, b) under a different privacy notice, c) they don’t mind or understand the logic behind tracking happening on a video about DNT d) they understand the logic behind why there is 3rd party tracking in link on a Mozilla page about DNT. We think clear notices is the best way to do all of this, so that users can make an informed choice before they click.

Comment 13

[Alex Gibson [:agibson]]

If the ultimate resolution for this bug is to add some text, could we also provide a notice to users that it requires a substantial amount of data in order to view the embedded site? Just as with any privacy implication, a user currently has no way to tell how much data will be used before they click the link. 

I think most users would appreciate a notice like this as much (if not more) than a privacy statement. Especially for those on a mobile data connection, where this could easily eat up a substantial amount of someone's monthly allowance.

Comment 14

[Gregory Jost]

Hi all,
Wanted to follow-up with a few suggestions based on Stacy's comment 12. Let me know if any of these would work:

> Option 1 - pre-modal thumbnail caption:
- We keep the modal option where users click on a thumbnail to open the iframe in a modal dialogue. See screenshot: https://www.dropbox.com/s/1oq2ts9dpo20ym3/Screen%20Shot%202015-11-03%20at%2012.32.35.png?dl=0
- We update the current caption that comes with thumbnail to say: "To get a good look at how tracking works, be sure to check out the first episode of Brett Gaylor’s documentary series, Do Not Track. *Note: you will be leaving Mozilla and the Do Not Track privacy policy will apply.*"


> Option 2 - pre-modal thumbnail overlay:
- As users hover over the thumbnail a notice gets displayed saying: "tracking is part of Do Not Track's experience, by clicking you will be leaving Mozilla and our privacy policy will no longer apply"
- Clicking opens the modal dialogue with iframe embed

> Option 3 - modal pre-load notice:
- Users click on thumbnail which opens modal dialogue
- A notice similar to option 2 is displayed.
- User clicks ok which triggers the iframe to load.


Stacy, let me know if any of these options would address the concern. Please also advise on the exact language that would work. Strong bias towards something light and friendly!

Brett: let us know if this kind of language would work from your perspective and represents DNT fairly.

Comment 15

[stacy]

Hi Greg,

How about something like this:  

To get a good look at how tracking works, be sure to check out the first episode of Brett Gaylor’s documentary series, Do Not Track. Note that by design, the documentary tracks you while you watch it to help you understand how your personal information can be seen by others. You can read their cookie and privacy notice here[https://donottrack-doc.com/en/cgu/]. Also note that embedded sites use large amounts of data.

Comment 16

[stacy]

Hi again,

Here's a shorter suggestion:

To get a good look at how tracking works, be sure to check out the first episode of a documentary 
series from Brett Gaylor that tracks you while you watch it. Here's their privacy notice. 
Note that embedded sites use large amounts of data.

Comment 17

[u554402]

+1

Also, the link we have given in the interim doesn't actually do what the user would expect.  We suggest they will be linking to the first episode, but instead we've sent them to our home page/landing page, which is several clicks away from that first episode.  I think that will lead to more users bouncing if it hasn't met their expectations, and since the series deals with many subjects, it may not accomplish the goals of why it was embedded.  If it takes some time to go with the approach Stacy is suggestiing, I'd at least recommend sending users here:

https://episode1.donottrack-doc.com/

Comment 18

[u554402]

And your suggestions seems smart, Greg! No problems with the language.

Comment 19

[Gregory Jost]

Thanks Stacy.

Here's what I suggest with the following redirects:

To get a good look at how tracking works, be sure to check out the first episode of *Do Not Track* [www.donottrack-doc.com], a documentary series from Brett Gaylor that *tracks you while you watch it* [https://donottrack-doc.com/en/your-datas/].

I would only add the the notice about large amounts of data on mobile (where DNT is not currently featured by the way).

Would this work?

Comment 20

[Alex Gibson [:agibson]]

(In reply to Gregory Jost from comment #19)
> I would only add the the notice about large amounts of data on mobile (where
> DNT is not currently featured by the way).


The type of device a user is on does not necessarily reflect their network connection type or bandwidth. Many tablet users also use roaming data connections for example. Desktop users in areas of poor connectivity would also find this information useful. I would say it's not only applicable to mobile users.

Comment 21

[Gregory Jost]

I talked to Stacy. Let's re-establish the modal dialogue and update the thumbnail caption using the following copy:

To get a good look at how tracking works, be sure to check out *Do Not Track* [https://donottrack-doc.com/], the first episode of a documentary series from Brett Gaylor that tracks you while you watch it. Here's their *privacy notice* [https://donottrack-doc.com/en/your-datas/]. Note that embedded sites use large amounts of data.

Can we do the switch for English and request a string update from l10n whenever possible?

Comment 22

[Mike Alexis [:malexis]]

Craig, will you be able to add these new strings before PTO?

Comment 23

[Alex Gibson [:agibson]]

> "Note that embedded sites use large amounts of data."

This is kind of an over-generalization. Just because a site is embedded does not mean it uses a large amount of data necessarily. I would suggest something more explicit, like:

"Note that the experience might take a while to load, and could use up a considerable amount of data."

Comment 24

[Gregory Jost]

Mike, Craig, what's the status on this new string? I haven't seen any update since comment 22.

If the string hasn't been extracted yet, let's address Alex's comment by replacing
"Note that embedded sites use large amounts of data."
with
"Note that this embedded site could use up a large amount of data."

That's a bit shorter than your recommendation Alex ;)

When can we expect to have the change made? We need to take advantage of the traffic we're receiving now and the current new tab redirect to DNT isn't even linking to the right page (http://donottrack-doc.com/ instead of http://episode1.donottrack-doc.com)

Comment 25

[Gregory Jost]

Ping. It's been two weeks! Can we change the link?

Comment 26

[Craig Cook (:craigcook)]

Attachment: Github pull request https://github.com/mozilla/bedrock/pull/3583

This PR cleans up the embed code, updates the link to point directly to Episode 1, and also adds an opaque page image for sharing.

Comment 27

[Gregory Jost]

Thanks!

Comment 28

[Gregory Jost]

Any luck pushing this?

Comment 29

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/d7141b35bfa4c66b801f907e84ccc62c8d06df18
Fix bug 1220844 - remove site embed from SmartOn Tracking

* Update the Do Not Track link to go directly to Episode 1
* Add an opaque page image for sharing

https://github.com/mozilla/bedrock/commit/a56879ae8794017b4f2f73f7a30074378daab896
Merge pull request #3583 from craigcook/bug-1220844-donottrack-website-link

Fix bug 1220844 - remove site embed from SmartOn Tracking

Comment 30

[Gregory Jost]

The image shared is still on transparent background: https://twitter.com/gregoryjost/status/669593445820796929

Comment 31

[Craig Cook (:craigcook)]

(In reply to Gregory Jost from comment #30)
> The image shared is still on transparent background:
> https://twitter.com/gregoryjost/status/669593445820796929

Hm looks like Twitter has cached the old image, I'm not sure if we can make them re-fetch the metadata.

Ah, looks like running it through the validator at https://cards-dev.twitter.com/validator does make them re-fetch and update their cache. I'm seeing the white image on Twitter now.

Comment 32

[Mike Alexis [:malexis]]

Clearing NI