If they're not using their normal browser, they don't have any cert data stored, so they have to 'log in' the traditional way to Mozilla Persona, which then gives the browser the cert data. The whole thing hinges on caching login credentials.
The simplest way to support this without depending on a 3rd party (Mozilla) would be to use an e-mail reset to send you a temporary credential to log in from an "unsafe" computer. There would need to be lots of restrictions on its use of course.
Persona doesn't involve any hard dependency on Mozilla. The user can use another ID provider (or even run their own) and the site can verify the credentials without using Mozilla's webservice. Both are currently unlikely, but it's easy to imagine GMail being an ID provider in the future.
can i supply more than one so sites could check if one of the providers has been compromised or something similar? does it make sense to have more than one?
As I understand it, it checks with the domain from the 'email address' to verify you. (air quotes because it needn't be possible to send email to the identifier). So it wouldn't make sense to have more than one way to verify one ID. If the site you're signing into is particularly sensitive, it could require a separate check - perhaps even a second BrowserID login from a different domain.
E-mailing temporary credentials still effectively relies on an ID provider: your mail server, which must ensure that no-one else can read e-mail sent to your address. You can run both that and a BrowserID provider yourself if you don't trust someone else to do it.
BrowserID is much easier for the web developer to set up and for the user to log in with: no switching between tabs to copy and paste passwords from your e-mail.
