They are cleared the same way as normal cookies: they are visible in the cookie manager where they can be manually deleted, and they are generally included in all of the other cookie-clearing mechanisms.
> did you evaluate various information sources (Ghostery, etc.) before settling on Disconnect?
Monica Chew, the engineer who did the bulk of the work on this feature, did consider a number of available lists before settling on this one. The Disconnect list was the best freely-licensed (GPL) one at the time. Also, they now have a web form to let users suggest new trackers to block (https://disconnect.me/trackerprotection) so it should get even better.
> Does anyone understand why Mozilla publishes valuable information like this over random personal blogs, rather than a central place like a knowledge base (e.g., a wiki)?
It's pretty tricky to share information in the "right place" because of the amount of information produced by everyone at Mozilla. Someone's preferred channel is often another person's blind spot.
Yes, your best protection is a short-lived signature on the user's public key. That's up to the identity provider to decide.
On our internal Persona IdP (for mozilla.com and mozillafoundation.org email addresses), the signature is short-lived (a few minutes I think). The browser will therefore need to request a new signature very often. This can happen transparently as long as you still have a session with the IdP and that session can be invalidated server-side in case of a compromise (or a password change).
One thing to note as well is that if a virus steals your email password, then you're a bit screwed too because that can, in most cases, be used to reset your password on other sites.
As we've seen with a bunch of high-profile compromises, the email account is already an extremely valuable target for attackers. Another good reason to enable 2-factor auth there!
I think you might be confused with how Persona works, it's not quite like OAuth. There is no "token" in Persona, we have keys and assertions.
The first step is for your browser to generate a public and secret keypair. Then you send the public key over to the identity provider to get it signed.
Once it's signed, you use your secret key (which never leaves your browser) to sign an assertion. The assertion contains your signed public key and an expiration, but it's also tied to an audience (i.e. the URL of the site you're logging into). That's what you send to the site you're trying to log into.
So if that site tries to impersonate you on a different website using the assertion you just gave it, it won't work because it can't change the audience that's inside the assertion (that would break the signature on the assertion). If the audience doesn't match, no other site will accept it.
Of course if a site steals your secret key from localStorage, then it's game over. However if you find a way to do this, then you've got yourself a browser 0-day :)
However, we've designed the protocol so that all of these pieces (necessary to bootstrap the system) will go away over time.
#1 will go away once we have native support in the browser (some of our developers have starting working on this). #2 will go away once we make include.js self-hostable, which we are definitely planning to do. #3 will no longer be needed once sites can use local verification libraries, which we have started writing. #4 can already be avoided if you put up your own identity provider (several people have done so).
Right now, our fallback identity provider (for email providers without native support) requires that people set a password to avoid having to confirm their email every time. However, we're currently exploring the idea of making the password optional and letting users click an email link at every login, just like the author of that article suggests.
I don't think it works for everyone, for example some people read their email on a different device, but it would certainly work for those who always keep their webmail open in a tab.
The fallback identity provider (at login.persona.org) does use email for password resets, but other identity providers will likely use other mechanisms.
Logging into a different device is not a problem, you just get a different certificate in that device's browser and it allows you to login in the same way.
When you use a computer that's not your own, Persona keeps the session time very small. Of course, when you're done using that computer, you should ideally clear cookies, just like you would if you used OpenID or Facebook on a shared computer.
One of the reasons why we couldn't just "fix" OpenID is that we wanted a scheme that would be privacy-sensitive.
With OpenID, the result of the site redirecting you to the IdP (and then the IdP redirecting you back to the site) is that the IdP can get a trail of every website you're trying to log into. That's pretty fundamental to the way OpenID is designed.
When you click the "Sign in with Persona" button on a website, the dialog that pops up has a "This is not me" button which logs out the current user and allows you to login with a different email.
> 3.it prompts for your password - gmail password or yahoo password
Yes. In this case the "it" that prompts for your password will be an iframe served from gmail/yahoo. Once they support Persona natively, login.persona.org is no longer in the loop and your gmail/yahoo password goes directly to gmail/yahoo.
In the case of the Javascript shim, the certificates are stored in the browser's local storage. In Firefox (and I believe in most other browsers), this gets deleted when you clear cookies.
So you can do that before you leave that public computer, or you can use private browsing / incognito mode so that cookies and local storage stay in RAM and disappear when you exit.
They are cleared the same way as normal cookies: they are visible in the cookie manager where they can be manually deleted, and they are generally included in all of the other cookie-clearing mechanisms.
You can find out more about the ways to control cookies in Firefox here: https://feeding.cloud.geek.nz/posts/tweaking-cookies-for-pri...