701759 - Solve Facebook/Twitter share buttons privacy issues

Status: RESOLVED FIXED

(mozilla.org :: Security Assurance: Applications, task)

Description

[Yvan Boily [:ygjb][:yvan]]

We have an occasionally recurring issue with using social media links on our pages where the developer will reference code hosted by a 3rd party.  Since this is a violation of our privacy policy it results in bugs being filed.  We need to put together some drop-in code and graphics resources that will allow our developers and anyone in the community to have these icons present on their page, but only make the call to the third party when they are selected.

See bug 638535 comment 6 for more info on the type of bug we are trying to address and the issues our developers have.

Comment 1

[Yvan Boily [:ygjb][:yvan]]

Added a bunch of people who will probably need to weigh in on the priority or work that is needed, or are working on related functionality.

Comment 2

[Sid Stamm [:geekboy or :sstamm]]

Makes sense to do this work once to make it easier on devs who do future work.  At the very least, it makes sense to write a how-to that explains how and why to embed links properly.

Comment 3

[Yvan Boily [:ygjb][:yvan]]

Although Twitter and FB are the initial targets, we should build something that could be reasonably extended for other services that a particular group might want to use.

I think that the easiest way to do this would be to have the image and script assets loaded from the same site, and then when a user clicks on the image(or whatever action is required), load and invoke the 3rd party script.

This is probably an overly simplistic view, and is the opposite end of the spectrum to oztens approach with his Repo The Web project https://github.com/mozilla/repotheweb

Comment 4

[Austin King [:ozten]]

It might be good to list why Engagement includes these widgets on campaigns.

Engagement Use Cases:

1) Show how populate a page is

FB and Twitter badges display how often a url has been mentioned.

2) Allow easy sharing of a page

FB and Twitter badges offer one click sharing into that social network

Others?

Comment 5

[Austin King [:ozten]]

> 2) Allow easy sharing of a page

Firefox Share (F1) does a great job of providing this in-client.

Doing this in content runs into the NASCAR problem, which is why I mentioned repotheweb, which is probably out of scope for 1.0

Comment 6

[Yvan Boily [:ygjb][:yvan]]

I included davida and mixedpuppy because they have done a bunch of work in this space.  The goal with this work is to provide something that is functional, meets our typical use cases, and can be consumed with minimal effort by the community as well.
  
There has been alot written recently on this issue (although it is not new!), and it is an opportunity for us to show the community the right way to do this without compromising on the functionality the 3rd parties offer.

I think it is also the case that we want to publish code for others to re-use, but we shouldn't be asking them to link to scripts or content hosted by us since in that case we would just be a 'man in the middle' that could be doing additional tracking.

Comment 7

[Shane Caraveo (:mixedpuppy)]

I think there are 2 approaches that need to be taken, basically at the same time.

One, fix it right now.  This is important for our own privacy policies, and we can demonstrate to others how to do this as well.  Whether we want to take on legal issues is another story (see the story below).

The second is the longer term solution.  I feel this is web activities (or intents) based with potentially further smarts in the UA.  The share addon takes that approach, but we need a pure-web fallback for web activities.  The longer term solution can also address the nascar issue.



Here is a solution that can be used today.  There is a 2-click jquery plugin that handles the details.

http://www.zdnet.com/blog/facebook/german-website-creates-two-click-like-button-facebook-not-amused/3247

http://www.heise.de/extras/socialshareprivacy/

A third item is user education around tracking beacons like the like button. We could modify that slightly to include some link to an education page, provide some pointers for users to avoid the tracking (e.g. using adblock, using the share addon, etc.)

The UX around this is admittedly less than pleasing, certainly not as nice as a single click like.

Later, we could additionally modify the jquery plugin to recognize if web activities is available, and use that in place of the individual buttons.

Comment 8

[Austin King [:ozten]]

From an email thread with williamr in engagement:

> The main reason is to allow easy sharing of a page and amplify who sees our campaigns.
...
> In a brand campaign like Firefox Live, the main call to action for the user is to share the page with friends
...

Comment 9

[Austin King [:ozten]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #7)
> I feel this is web activities (or intents) based with potentially further smarts in the UA.

+1

> http://www.heise.de/extras/socialshareprivacy/
+1

The other question I have is on the efficacy of FB and Twitter badges for meeting Engagement's goals. 

If they don't provide significant benefit (engagement KPI or user enjoyment), then removing FB/Twitter share buttons from our properties and doing a campaign around highlighting the dangers of these badges would be a good strategy.

Comment 10

[Ben Adida [:benadida]]

That jQuery plugin looks perfect. Before I knew about it, I was going to suggest that we provide that kind of service right away for other sites. Instead, we should be advertising that system.

Comment 11

[Shane Caraveo (:mixedpuppy)]

I was also thinking, a simple jetpack that page-mods all sites to replace the buttons with the 2 click might be a nice idea.  however, adblock + share addons is probably a better solution.

Comment 12

[Ben Adida [:benadida]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #11)
> I was also thinking, a simple jetpack that page-mods all sites

Disconnect does that. Maybe we need to have a HOWTO on how to browse the web and protect your privacy that lists these 3rd-party tools, as a start?

Comment 13

[Yvan Boily [:ygjb][:yvan]]

For the socialshareprivacy one, can we engage some localization resources and reach out to the developers of the jquery plugin?  Providing documentation in other languages and additional guidance may be helpful.

Comment 14

[Yvan Boily [:ygjb][:yvan]]

Recommendation: A model based off of the example at https://developer.mozilla.org/en-US/demos/detail/globetweeter

One area engagement was concerned with was the ability to demonstrate the number of likes / retweets /etc that a particular campaign is getting.  To work around this a service could be implemented to proxy calls to the appropriate APIs to allow the site to load in those values; done through an AJAX call it should have a limited impact on page performance while allowing this functionality to meet our privacy requirements.

This will need further investigation and dev work by people more familiar with the API than I am!

Comment 15

[David Ascher (:davida)]

I'll have to ask paul rouget for the source to that app, but I'm not sure I understand the suggestion: that every web property that has a share button does a proxy call via a mozilla server?

The share buttons (esp. facebook's) are designed to leverage accounts, to show which of one's friends have liked a page.  Proxying any of that data through a mozilla server would centralize a lot of data which we probably don't want to.

I agree w/ most of the comments above: shane's pointer to the two-click jquery plugin likely deals with the pragmatic effect of privacy by default for non-sharers + sharing-is-easy for people who "do that sort of thing".

Comment 16

[mcbmoz]

Update: compiled all ideas and met with Michael, Yvan, jbalogh, Mike Alexis, and William R yesterday. Came up with two solutions, namely creating a solution and dispatching via an iframe and the other creating a small library. Both protect privacy and require minimal effort to build. jbalogh can comment more on both.

Assigning over to Mike Alexis to assign to webdev, excited to get this in place in a few weeks for all teams and community members to use!

Comment 17

[Yvan Boily [:ygjb][:yvan]]

The code for the share stuff off the demo site that I mention in comment 14 is at https://github.com/mozilla/kuma/blob/master/apps/demos/templates/demos/launch.html#L54

The idea for the proxy was just to pull the total number of likes/shares/retweets/ whatever other name for the metric is on social media sites.  It was a suggestion to bridge the gap between the Demo Studio style site and the counter style buttons hosted by 3rd party sites.  Not every site would have them, and ideally such a proxy service would be either a built-in component of playdoh or a shared service that we have vetted that our developers/contractors can consume without fear of privacy issues.

Comment 18

[William Reynolds [:williamr]]

(In reply to Yvan Boily [:ygjb][:yvan] from comment #17)
> The idea for the proxy was just to pull the total number of
> likes/shares/retweets/ whatever other name for the metric is on social media
> sites.

To give some more context from an Engagement perspective, we sometimes want to show the total number of likes/shares/retweets next to the share button. We believe that helps increase conversion, although more testing is needed to make that conclusion. Nonetheless, we will definitely want to show the total number of shares on some sites. For example, the total number of tweets was key to the Firefox 4 Twitter Party.

Thanks for pulling this all together. Very happy we're making this easy to drop into projects.

Comment 19

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to William Reynolds [:williamr] from comment #18)
> (In reply to Yvan Boily [:ygjb][:yvan] from comment #17)
> > The idea for the proxy was just to pull the total number of
> > likes/shares/retweets/ whatever other name for the metric is on social media
> > sites.
> 
> To give some more context from an Engagement perspective, we sometimes want
> to show the total number of likes/shares/retweets next to the share button.
> We believe that helps increase conversion, although more testing is needed
> to make that conclusion. Nonetheless, we will definitely want to show the
> total number of shares on some sites. For example, the total number of
> tweets was key to the Firefox 4 Twitter Party.

To clarify, would the total number of shares be visible BEFORE user interaction with the share button or AFTER they click on the initial share?

If it is BEFORE then we'll have to investigate some sort of proxy approach (e.g. slightly more complicated). Because there is no way to share the number of shares directly in a privacy respecting way.

Comment 20

[William Reynolds [:williamr]]

(In reply to Michael Coates [:mcoates] from comment #19)
> To clarify, would the total number of shares be visible BEFORE user
> interaction with the share button or AFTER they click on the initial share?
> 
> If it is BEFORE then we'll have to investigate some sort of proxy approach
> (e.g. slightly more complicated). Because there is no way to share the
> number of shares directly in a privacy respecting way.

For some campaigns we will want to show the number of shares BEFORE the user clicks. That's when we'll need to use the proxy approach.

For most campaigns though, we can show the number of shares AFTER they click on a button.

Comment 21

[Jeff Balogh (:jbalogh)]

To show the counts before interaction we'd probably want a backend proxy app that can get share counts, store the numbers in cache for a little while, and serve that up to our js lib. However, there don't appear to be public APIs to get the numbers.

There's an unadvertised API to get the share count for twitter: 

$ curl -s 'http://cdn.api.twitter.com/1/urls/count.json?url=http://www.mozilla.org/en-US/firefoxlive/'
{"count":370,"url":"http://www.mozilla.org/en-US/firefoxlive/"}

The like counts for facebook are embedded in an HTML response:

$ curl -s -H'User-Agent: Firefox' 'http://www.facebook.com/plugins/like.php?href=http%3A%2F%2Fmozilla.org' | perl -ne '/(<[^>]+>\d+ likes.{10})/ && print $1'
<span class="connect_widget_not_connected_text">3833 likes. <a href=

Comment 22

[David Ascher (:davida)]

Unadvertised APIs tend to change, so we should probably setup automated scripts to detect if they change.  Also, we should probably be careful to avoid hitting them too often.

If we want to ask Facebook or Twitter about their willingness to support these APIs, let me know.  (There may be ToS that we need to worry about).

(I like the fact that as long as we're dealing w/ a finite set of URLs, we can do this w/o leaking any user data that the user doesn't intentionally leak through sharing).

Comment 23

[Fred Wenzel [:wenzel]]

So, to summarize (please correct me if I am wrong) it looks like we're looking for a library combining backend/frontend issues here as follows:

1) on the backend provides a way to retrieve the FB/Twitter share counts without leaking the user's identity.
2) one the frontend, we'd use Heise's dual click implementation as to not hit FB/Twitter servers without user interaction.

Correct?

I suppose neither of this would go into playdoh by default, but 1) would need to be a django plugin to be written by us that can and should be used across Mozilla properties where share counts are desired. 2) looks like it's done, minus missing localization, it's all German as far as I can tell.

Comment 24

[Jeff Balogh (:jbalogh)]

I think #1 would be better as a standalone service that everyone uses. That way it gets built once and everyone benefits from the proxy.

#2 could be a small js library that people add to their project, which could optionally talk to #1 if the site wants count info.

Comment 25

[mcbmoz]

Mike A & Fred, do you have enough information to move to a developer to build? If not, what else can we provide you with?

Comment 26

[Chris More [:cmore]]

Here is a ultra simplified proof-of-content I made (hacky code) to illustrate how the default Facebook/Twitter widgets can be used without exposing user data until a user has decided to "share" this page/site in question.

http://people.mozilla.org/~cmore/share-example.html

Has anyone found documentation or reached out to FB or Twitter to determine if anything like this or a proxy would be against their TOS?

Comment 27

[mcbmoz]

Updating with some RASCI roles, so we can carry this over the finish line:


Responsible, owner of the problem/project
--Mike Alexis, WebDev/Prod

Accountable, "R" is Accountable and is the authority who approves to sign off on work before it is effective
--Yvan Bolly, Security
--Stacy Martin, Privacy

Supportive: that is a person who provides resources or plays a supporting role in implementation
--Fred Wenzel

Consulted: that is a person who provides information and/or expertise necessary to complete the project
--CMore, WilliamR, Cbrodigan

Informed: that is a person who needs to be notified of results but need not necessarily be consulted
--DAscher, Ben A., JSlater, JFinnette, any other site owners who will implement

Mike Alexis will send out a meeting invite, so we can have a final huddle on privacy and then move to Fred for webdev implementation.

Comment 28

[Chris More [:cmore]]

From this page:

https://developers.facebook.com/policy/#policies

Section IV. Application Integration Points, part 4d: "You must not obscure or cover elements of our social plugins, such as the Like button or Like box plugin."

We need more definition around what obscure or cover the social plugins means because the JavaScript example is doing just that. They still exist in the page, but they do not execute or are visible until a user clicks. The definition doesn't say permanently obscure or cover.

Comment 29

[Chris More [:cmore]]

Clarification: In my share example (http://people.mozilla.org/~cmore/share-example.html), the FB buttons are not being hidden. The FB code creates an iframe that displays the like button and found. In my example, the FB JavaScript code is not executed until the user clicks and at that time the iframe is loaded and Like button appears. The button is not being obscured, but instead just not executed until a user action takes place. The normal user action is page load and instead the example switches it to a click event.

The appropriate place to ask this question seems to be:

http://facebook.stackoverflow.com/

Comment 30

[Fred Wenzel [:wenzel]]

(In reply to Chris More [:cmore] from comment #29)
> Clarification: In my share example
> (http://people.mozilla.org/~cmore/share-example.html), the FB buttons are
> not being hidden.

Then we are good -- no one can force us to *add* a certain DOM node to our documents at load time.

Comment 31

[Chris More [:cmore]]

Another clarification: This proposed JavaScript solution will not be locally displaying the Facebook or Twitter icon linked to a different button. There will be a generic "Share" icon or something along those lines that when clicked will display the out-of-the-box and standard Facebook plugin or Twitter button. There will be no local storage of the button or modifications to original Facebook code. No where in the FB policies does it state that their code HAS to be executed onLoad vs onClick.

Comment 32

[William Reynolds [:williamr]]

Thanks Chris and Fred. This approach sounds good to me and would work well for our sites and campaigns.

Comment 33

[Chris More [:cmore]]

My script scanned over 190 production Mozilla websites and I found the following websites using few variations of social sharing:

https://etherpad.mozilla.org/websites-existing-social-sharing

After we have a working example and code, we will need to reach out to the owners of these sites.

Action item complete!

Comment 34

[mcbmoz]

(In reply to Chris More [:cmore] from comment #33)
> My script scanned over 190 production Mozilla websites and I found the
> following websites using few variations of social sharing:
> 
> https://etherpad.mozilla.org/websites-existing-social-sharing


Chris, do you think it would also be useful to scan for the @mozilla and @mozlabs Twitter and FB implementations as well. Or is this unnecessary scope creep? I'm not sure that these sites hit our Security team's workflow.

Examples include:

http://mozillapopcorn.org/popcornjs/
http://betafarm.mozillalabs.com/

> After we have a working example and code, we will need to reach out to the
> owners of these sites.
> 
> Action item complete!

Comment 35

[Chris More [:cmore]]

 
> Chris, do you think it would also be useful to scan for the @mozilla and
> @mozlabs Twitter and FB implementations as well. Or is this unnecessary
> scope creep? I'm not sure that these sites hit our Security team's workflow.
> 
> Examples include:
> 
> http://mozillapopcorn.org/popcornjs/
> http://betafarm.mozillalabs.com/
> 

I purposely excluded regular links to FB/TW links because links to "follow us" is different than sharing abilities. When we finish the development on the creation of a "safe" way to socially share, it still won't affect how people link to official social media accounts on their site.

I could scan for official twitter links on sites, but the reason and usefulness of that would be different than this bug. If there is a need for that in the future, I can do it.

Thanks!

Comment 36

[Bram Pitoyo [:bram]]

Attachment: Share UX

What’s notable about this UX is the fact that an arrow indicator appears when your mouse hover over the share link or button. The arrow will form part of the popover dialog.

The dialog is non-modal, so we don’t interfere with the page layout (ie. shift the page down) or how the user navigates.

To close the popover dialog, the user can click on any part of the page outside of the button or dialog.

Comment 37

[William Reynolds [:williamr]]

Adding a wiki page that has draft requirements, usage scenarios and implementation options that have been discussed:
https://wiki.mozilla.org/Social_Sharing

Comment 38

[mcbmoz]

Tackling our first pass at design over on Bug 725759 - will report back with a final comp shortly.

Thanks for all your ideas here!

Comment 39

[Bram Pitoyo [:bram]]

I’ve mocked up the wireframes for new contributor registration UX:
1. https://bugzilla.mozilla.org/attachment.cgi?id=596580
2. https://bugzilla.mozilla.org/attachment.cgi?id=596600
3. https://bugzilla.mozilla.org/attachment.cgi?id=596583
3a. https://bugzilla.mozilla.org/attachment.cgi?id=596584
4. https://bugzilla.mozilla.org/attachment.cgi?id=596585

We’re ready to go with designing higher res mockups and writing copy for these steps.

Comment 40

[Bram Pitoyo [:bram]]

Please disregard the last message. It was for the wrong bug. Sorry!

Comment 41

[mcbmoz]

Cmore: PSDS

https://bugzilla.mozilla.org/show_bug.cgi?id=725759#c5

Comment 42

[Chris More [:cmore]]

(In reply to mcbmoz from comment #41)
> Cmore: PSDS
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=725759#c5

Thanks!

Comment 43

[mcbmoz]

Second version for campaigns not on mozilla.org (e.g. Flicks, etc.)

Working on documentation regarding both, but in this version the visual distinction to convey what this widget can look like on different pages. That way webdev will know to give each element its own CSS class making it easy to change

https://bugzilla.mozilla.org/attachment.cgi?id=600488&action=edit
Moz.org

Comment 44

[Chris More [:cmore]]

Hello everyone! The social sharing library is code complete for the 1.0 version and it is currently in a security review. I will update this bug when we have more information about it.

Comment 45

[Mike Alexis [:malexis]]

This is live. For any future iterations we can open new bug.