Security/Reviews/F1 (round 2)

Items Reviewed

F1 :: retooled version of the link sharing service we looked at in May (https://wiki.mozilla.org/Security/Reviews/F1)

• https://wiki.mozilla.org/Labs/F1
• https://wiki.mozilla.org/Labs/F1/Roadmap
• https://wiki.mozilla.org/Services/F1/Design
• https://wiki.mozilla.org/Privacy/Reviews/F1
• https://wiki.mozilla.org/Security/Reviews/F1
• example https://github.com/mozilla/fx-share-addon/blob/develop/extra/share.html
  • this is partly old code that is being moved to activities

Introduce Feature (5-10 minutes)

• Initial release will be "Firefox Share (alpha)
  • F1 team is considering this as a labs alpha release
• method for allowing users to share content on their social networks & later email
  • Twitter, Facebook and GMail will be in the initial release
    • Twitter uses oauth1, secret will be in the addon
    • Facebook uses oauth2, requires no secret
    • GMail uses oauth1, but we're using the "anonymous" secret
      • UX is not great with the anonymous secret
    • GMail uses smtp with xauth (oauth token in place of password)
      • smtp is provided in chrome code, an injected api provides access
• F1 is now a mediator for the "share" activity
  • installs specialized webapps for facebook, twitter and gmail to bootstrap sharing

Differs from OWA (Open Web Applicaiton) because:

• mediator for F1 is more elaborate than default for OWA
• provides OAuth as an authentication api
  • pops up a login dialog
• we would prefer to not use OAuth where possible (depends on service providers)
  • it is not possible at this time to get away from oauth, it is still a goal over time
  • Yes, just "native" OWA if possible.

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

• Attempting to make the sharing of web data easier for users
  • remove the NASCAR effect of sharing buttons on an item (longer term goal)

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

• Client-Server arch of previous has been abandoned for a browser only solution using OWA
• possibly build F1 into OWA directly to avoid cross application issues
  • F1 currently includes OWA and oauthorizer addons, both jetpack based

Why was this solution chosen?

• better privacy protection for users
• does not put Mozilla in a postition to hold possibly private data / auth secrets for the user
  • this data is currently stored in localstorage of each app (for alpha release)
  • data to be stored chrome-side in future releases

Any security threats already considered in the design and why?

• ^^ see previous discussion & OWA items

Threat Brainstorming (30-40 minutes)

• Screenshot image leakage (potentially sensitive data shows up in screenshots that are shared)
  • only works for email which is not in current implementation, might be dropped due to privacy concerns
  • Shane says probably it will just be pulled out.
• Can arbitrary content invoke the OAuth flow/dialog ?
  • as of right now yes, this is a property of the injector that needs to be fixed
  • by design no, this is due to reuse of injector code
    • good thing to test during implementation review/penetration testing
• potential clickjacking due to dialog being displayed over content, possibly phishing also by mimicing the experience (particularly in full screen mode)
  • potential mitigation - exit fullscreen mode when dialog is shown
• Starting Share/F1 (or any activity) could be the "new window.open()"
  • jstenback is the person to talk to about trusted events being required for startActivity

Conclusions / Action Items (10-20 minutes)

• [scaraveo]Need to figure out if the temporary part for Twitter OAuth will end up in the product, or if we can cut it out before the first release.
• [scaraveo]Final decision on screenshot thumbnail sharing
  • This decision will need to be communicated back to secteam
• [scaraveo] bug to track fixing the of OAuth flow/dialog/injector