53 karma · joined September 22, 2010
https://fmarier.org
[ my public key: https://keybase.io/fmarier; my proof: https://keybase.io/fmarier/sigs/DgmaM0qamFAjS0VuAdpoGMTDMb9JMVMh76QT7KOYjs8 ]
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...
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.
In this particular example, all of the information is on the wiki page I maintain (https://wiki.mozilla.org/Security/Tracking_protection) but it felt like a more accessible description of the overall system would also be useful. I put it on my blog because it seemed too detailed/technical for my team's blog (https://blog.mozilla.org/security/) or Hacks (https://hacks.mozilla.org/).
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).
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!
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 :)
1. JavaScript shim 2. include.js 3. Centralized verifier 4. Fallback identity provider
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.
That list you see in Chromium (which is now also shared with Firefox) is the list of sites that come with HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Stric...) turned ON.
Of course, if you find anything we've missed, please file a bug :)
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.
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.
Getting UX right is a priority for Persona.
I've pasted your comments into a bug report: https://github.com/mozilla/browserid/issues/2539
Feel free to jump in if you have ideas on how we can phrase this better.
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.
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.
The video should be available from http://www.innovation.org.nz at some point.