SocialAPIMultiProvider
Please use "Edit with form" above to edit this page.
Item Reviewed
| Social API Multiple Providers | |
| Target | https://mana.mozilla.org/wiki/display/SECURITY/Social+API+multi-providers+Security+Review
this should have been public :) Prev review info: https://mana.mozilla.org/wiki/display/SECURITY/Social+API+Security+Review |
{{#set:SecReview name=Social API Multiple Providers |SecReview target=https://mana.mozilla.org/wiki/display/SECURITY/Social+API+multi-providers+Security+Review this should have been public :) Prev review info: https://mana.mozilla.org/wiki/display/SECURITY/Social+API+Security+Review }}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- install process for additional social providers
- (for Facebook) user goes to page, "turn on" button, starts social API, also has an undo panel
- For Firefox 22 only social providers included on our whitelist can be installed, these are restricted to organisations with whom we have working relationships or partnerships with.
- In Firefox 23 we will allow any social provider to be installed. (can be listed on AMO or marketplace)
- additional panel for non-whitelisted provers, panel has a notice and enable button and undo panel
- implementation taken from light weight themes process (DOM event)
- manifest data recieved from target element, validated, then presented with enable panel
- manifest stored into prefs
UI :
- sidebar and content
- sidebar from us
- content page on the site
- buttons in chrome UI
- can be defined from provider and bound by sameorigin
What solutions/approaches were considered other than the proposed solution?
- use add-ons, did not want installation of additional items (e.g. features--addons can do anything)
- JSON file from provider, seperatly loaded - unneccessary given it can come from page
Why was this solution chosen?
- most direct pathway with least friction
Any security threats already considered in the design and why?
- same origin required for additional pages to page requesting installation
- images can come from an alternate domain
- backend also supports blocklisting (hard and soft via AMO)
Threat Brainstorming
- UI redressing attack on the "Enable Services" doorhanger
- Is there a delay before a user can click, similar to the addons dialog
- diff between disable and remove?
- disable only turns it off, removes from list
- remove takes it out
- provider loaded, sidebar hidden
- frame worker loaded (as workers can not currently support sockets)
- supported schemes for iconURLs
- created as image tags
- mobile may handle differently but SOP protects <img> data
- directory provided manifests?
{{#set: SecReview feature goal=* install process for additional social providers
- (for Facebook) user goes to page, "turn on" button, starts social API, also has an undo panel
- For Firefox 22 only social providers included on our whitelist can be installed, these are restricted to organisations with whom we have working relationships or partnerships with.
- In Firefox 23 we will allow any social provider to be installed. (can be listed on AMO or marketplace)
- additional panel for non-whitelisted provers, panel has a notice and enable button and undo panel
- implementation taken from light weight themes process (DOM event)
- manifest data recieved from target element, validated, then presented with enable panel
- manifest stored into prefs
UI :
- sidebar and content
- sidebar from us
- content page on the site
- buttons in chrome UI
- can be defined from provider and bound by sameorigin
|SecReview alt solutions=* use add-ons, did not want installation of additional items (e.g. features--addons can do anything)
- JSON file from provider, seperatly loaded - unneccessary given it can come from page
|SecReview solution chosen=* most direct pathway with least friction |SecReview threats considered=* same origin required for additional pages to page requesting installation
- images can come from an alternate domain
- backend also supports blocklisting (hard and soft via AMO)
|SecReview threat brainstorming=* UI redressing attack on the "Enable Services" doorhanger
- Is there a delay before a user can click, similar to the addons dialog
- diff between disable and remove?
- disable only turns it off, removes from list
- remove takes it out
- provider loaded, sidebar hidden
- frame worker loaded (as workers can not currently support sockets)
- supported schemes for iconURLs
- created as image tags
- mobile may handle differently but SOP protects <img> data
- directory provided manifests?
}}
Action Items
| Action Item Status | In Progress |
| Release Target | ` |
| Action Items | |
* [dchan] - Follow up with clouserw on origin verification process for AMO / marketplace directory provided manifests - I dont think that he has even begun thinking about social support at all yet
|
|
{{#set:|SecReview action item status=In Progress
|Feature version=` |SecReview action items=* [dchan] - Follow up with clouserw on origin verification process for AMO / marketplace directory provided manifests - I dont think that he has even begun thinking about social support at all yet
- [dchan] - Look into about:socialerror chrome privileges and file bug if needed
- [psiinon] Test to make sure only script accessible cookies will be available to providers
- [psinnon] http/https discussion
- [psiinon] Investigate collecting FHR metrics inc http/https
}}