From MozillaWiki
Jump to: navigation, search

Items to be reviewed: Thunderbird Account Provisioner - Agenda:

Introduce Feature

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

  • Started with a survey of users, where 2/3 thought Mozilla was going to give them an email account when they installed
    • To help users setup email accounts better this feature was created
    • Goal is to help them get an email account
  • Working with already established providers (5 at the moment) to help users get accounts (i.e. Hover), some are pay for some are ad-supported
    • 1 focused to German Market, 1 Focused to Russian Market, all others North America focused (for now)
    • criteria for who is in there now?
      • No, other than providers that protect users privacy
    • Asking the email offer'ers to give secure IMAP/SMTP and for the most part they are offering this

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

  • None
  • Directory of providers is helpful if you have an account, but not if you need one

Why was this solution chosen?

  • Had considered sending users to providers
    • Wanted something more integrated that could help users
  • Not sure if users are more interested in the domain/email name
    • With this soln we can check if a given email prefix name is available from multiple sources

Any security threats already considered in the design and why?

  • List of providers come from a mozilla server that discriminates by local
    • could be customized for order
  • What information is sent to providers when querying for account info
    • First & Last Name (any 2 words the user types in, entered by user)
      • We use these as default values in the provisioning form.

Threat Brainstorming

  • Do we worry about the providers being hacked, and returning bad data to the Mozilla Messaging server?
    • Possible but a threat that is not being handled now
  • Is this the first time TB will open untrusted code from web?
    • no RSS feeds, and other add-ons do this today
    • Do we need to lock down the browser (e.g. disable plugins, disable WebGL, etc.)? Could we put the browser in private browsing mode?
  • Sanity check the info returned from the provider for setting up with the account (e.g. domain of email address, security configuration is IMAPS + SMTPS).
  • Do we need to delete cookies generated during the browsing when signing up for an account?
    • Should we use private browsing mode, so that stuff gets removed when we're done?

Conclusions / Action Items

  • [bwinton +done] Document the assumption that all communication between all parties in this feature is done over secure channels (HTTPS/IMAPS/SMTPS), as the security review has assumed this.
  • [_infrasec_] Infrasec review of server side ? (custom communication for each provider)
  • [dchan] implementation review of patch
  • [testing]
    • JSON formats - done
    • URLs handling and input (kickout to default browser for most of them but should still be tested) - done
    • error handling - done
  • [sid] privacy review