Support/Goals/BrowserID Failure Plan

BrowserID as a new feature promoted by Mozilla is fully supported by SUMO. This document intents to cover the scenarios where BrowserID can disrupt the normal operations of SUMO because of a particularly high increase of the traffic.

They are three main cogs that drive the experience of a user around BrowserID:

• The email provider and eventually identity provider.
• Mozilla as responsible of the BrowserID UI and integration with the chrome of the browser. In the meantime, it also serves as secondary identity provider.
• Site where BrowserID is used as a login method.

At the moment SUMO is present in the UI as a contextual help for any use who has problems log in into their favorite service. In the following sections we will explore how different events will affect SUMO.

Identity Providers

Big player adopts BrowserID and offers primary identity validation

In the case that Google or Yahoo add this feature to their email service we will suddenly have more than 650 million (http://news.cnet.com/8301-13772_3-20114975-52/microsoft-aiming-to-clean-up-hotmail-users-inboxes/ and http://thenextweb.com/google/2012/01/19/gmail-closes-in-on-hotmail-with-350-mm-active-users/) users that could use BrowserID with a primary validation. The only difference for these users is that they will not require any validation of their email as soon as they try to log in into their favorite website. They will not recognize any difference in their account or their email. They are still potential BrowserID users.

Identity provider goes down

If this is the case, users will not be able to log in into their favorite service using BrowserID. We should work around the messaging in the BrowserID UI to make sure that it’s clear who to contact. In this case the user will need to contact their identity provider and we should make that path simple.

Bug to track the case: https://github.com/mozilla/browserid/issues/1140

Mozilla

There are three different pieces that can go down and cause some type of usage disruption:

The UI for the authentication process and the client logic could go down

This will leave every user trying to use the method to log in into the favorite site unable of doing so.

Users facing this issue will not see the BrowserID UI so unless they know that they were using BrowserID to log in into that site and they know that Mozilla is behind BrowserID is unlikely that they will end up in SUMO massively to ask why they can’t log in into their favorite site.

Instead, they will be more likely to contact the webmaster of the site and webmasters will act as liaison between the users and Mozilla.

The service that provides the client certificates for email addresses goes down

Even with a multiple 9 approach there will be times where Mozilla systems go down and users can not be authorized to log in into their favorite site.

That said, if the user has used BrowserID in the last hours/day using the same email, they will have a certificate stored locally that they can use to sign in so they will not notice the outage. The portion of user who haven’t used recently will need assistance. Some of them will reach out SUMO while a big percentage of the users will contact the support team of the specific site they are trying to access.

The verification service goes down

In this particular case users will not be able to log in to the site if the site is using Mozilla’s verification service (they can run their own one).

In this scenario some users will reach out to SUMO (as the linked “Help” in the BrowserID UI) while we expect the majority of users to identify the issue as a problem with the site they are trying to log in into.

We expect site owners to act as a liaison of their users and Mozilla to make the communication more efficient. We should also work in a messaging to modify the UI so users understand what’s happening.

Sites

BrowserID is adopted by a major publisher/service

In the case that a major site like The New York Times start to use BrowserID the service will be exposed to millions of users. If nothing goes wrong (i.e. if nothing fails as describe in the previous section) their login experience should be seamless and BrowserID shouldn’t represent a complication where they need help. We could see some traffic coming to SUMO but is unclear why anyone will need additional help that is not covered in the Help Article.

That said, this adoption increase combined with the issues explained in the previous section will represent a significant user facing issue. While this is true, we don’t expect this to be happening in the short term (i.e. before Q3 2012).