fmarier

And how are these cookies cleared?

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...

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.

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/).

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 :)

Right now, you're right and that's because of the temporary centralized components:

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).

It's definitely in line with what Persona does. After all, Persona evolved from the "Verified Email Protocol" (https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol).

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.

Yes and we're tracking it here: https://github.com/mozilla/browserid/issues/2158

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.

Regarding the case-sensitivity issues, this pull request should have fixed all of the outstanding ones: https://github.com/mozilla/browserid/pull/3078

Of course, if you find anything we've missed, please file a bug :)

Indeed, you're not the only one confused by this flow, which is why there's an open bug for it: https://github.com/mozilla/browserid/issues/1232

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.

This talk gets into how the protocol works without getting too much into the crypto: https://www.youtube.com/watch?v=iZBTc7iEkQY

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.

Can you be more specific as to how you find the UX lacking?

Getting UX right is a priority for Persona.

Thanks, that's really good feedback.

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.

...and assuming it's written in Python (is it?), it should be pretty easy to do: https://github.com/mozilla/browserid-cookbook/blob/master/py...

> 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.

We'll also be looking into DNS-based delegation for the next beta: https://github.com/mozilla/browserid/issues/1523

You can manage your account (e.g. change password, remove emails) by signing into https://login.persona.org .

Gitorious.org on the other hand is an Open Source startup.

Indeed. Those were exactly the design goals I had when I wrote safe-rm (shortly after deleting my /usr/lib!).

PDF and rough MP3 recording up here: http://people.debian.org/~francois/nzcs/

The video should be available from http://www.innovation.org.nz at some point.