Item Reviewed

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

Taken from: https://developer.mozilla.org/en-US/docs/Social_API/Share

A service provider may choose to provide a Share panel that users can use to share content from the current browser tab with their friends. The Share panel is slightly different from other Social UI in the browser. The Share panel itself contains a list of providers that support the share functionality. When a user shares a page, they can choose which provider they want to share with. Each provider may have differing functionality, such as simply providing a comment box to extensive functionlality allowing for image selection and more.

Share is initiated by the user either through the share button in the toolbar or a context menu. The user can select an image or text in a page to be shared, or share the page itself. Links within a page may also be shared without visiting the link.

A provider implementing support for share may choose to use a URL template that is compatible with OExchange, however the browser also sends a DOM event to the page after load containing details of the share. In some circumstances, such as sharing a link on the page, the browser will not have detailed information. Using the DOM event allows the provider to display information about the page being shared without needing to fetch it themselves and parse the page for information. The browser includes certain META tags, including OpenGraph tags in the event data.

What solutions/approaches were considered other than the proposed solution?

Share evolved out of F1 then later reworking into a client side only solution (using client side oauth) and eventually into a web activities based share (using web pages rather than oauth based APIs). Share in SocialAPI is based on the concepts developed in the last iteration based on web activities, and will later be hooked into the current web activities api when that is available on desktop. As you can see we've implemented various approaches finally resting on a mechanism that simply relies on web pages delivered from the share "provider".

Why was this solution chosen?

This is the simplest approach and avoids issues around using APIs provided by the target share services (e.g. managing oauth keys, login etc), as well as reducing engineering effort in maintaining API based approaches, and allowing share services to implement features we may not have thought to support.

Any security threats already considered in the design and why?

Security implications are the same as loading the share url into a regular browser tab, likewise, essentially the same as other web content panels used in socialapi. The share service manages whatever authentication they use, typically relying on cookies, etc., all outside the purview of Firefox.

Threat Brainstorming

'

Action Items

2013.08.15

Items to be reviewed: https://bugzilla.mozilla.org/show_bug.cgi?id=862628 https://wiki.mozilla.org/Security/Reviews/SocialShare

Introduce Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

A replacement for the nascar mess of buttons for sharing info

What solutions/approaches were considered other than the proposed solution?

There was F1 then...

Why was this solution chosen?

Any security threats already considered in the design and why?

We rely on the security mechanisms already present int he browser (using an iFrame) - no chrome privs, etc. We rely on the existing sec. model

- We use the opengraph tags (a standard for markup of share) - we scan fr those tags (and other meta tags, e.g. title) and create a json object that we send via a DOM event to the share page. Suggested picture, description, etc. - allows the provider to rely on FX without having to have backend infra to facilitate that.
Provider content loaded in iframe without chrome priv

DOM event has url, title, .. Only fired by FX not by the page, when user has clicked on the button - so shoulndt be possible for docs to fire this directly Do we strip information from https pages? (e.g. when relying on referer, providers wouldn't have had this - but with script they would) Remove user password from the URI, but thats it

Threat Brainstorming

Sharing urls with session tokens

Conclusions / Action Items

• Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug)

http://mixedpuppy.github.io/socialapi-demo https://mozsocial.cliqz.com/ https://www.facebook.com/about/messenger-for-firefox