rfk

Any sort of verification presumes that you have an initial trusted checksum against which to verify, so I don't believe this solves the separate problem of obtaining such a checksum.

IIUC your question here boils down to "what is the point of a hash tree?" as opposed to e.g. a list of individual chunk hashes. The answer is that a hash tree lets you verify an individual chunk by looking at the hashes of O(log(N)) chunks rather than having to look at the hash of every chunk.

There are plenty of mischievous things an attacker could do if you just verify each chunk separately, including reordering or omitting chunks, and truncating the file.

For no reason other than "legacy reasons" - much of the client-side crypto code in the current Firefox Sync is inherited from an earlier system that predates widespread acceptance of GCM as a best practice. If we designed it from scratch today it would almost certainly be using GCM instead.

Hi, Firefox Accounts developer here. You're correct in your understanding that that login flow is ultimately driven by a webpage, and this is a deliberate trade-off that we made in the interests of reach and usability of the system.

It's certainly a trade-off that not everyone is comfortable with, but we're confident it's the right one for the majority of our users. You can read some previous discussions on the topic in these bugs (and additional suggestions/feedback therein is definitely welcome):

  * https://bugzilla.mozilla.org/show_bug.cgi?id=1034526
  * https://bugzilla.mozilla.org/show_bug.cgi?id=1447656

FWIW, as a developer on the Firefox Accounts team, I strongly endorse the sentiment of this article. We've occasionally found ourselves merging microservices back together because the abstraction boundaries we designed up-front weren't working out in practice...

Because I typo'd the date; thanks, fixing now...

> Unmaintained critical infrastructure is bad news.

(article author here)

To add to @callahad's excellent points: unmaintained critical infrastructure on your security perimeter is even worse, and a service like Persona is about as security-critical as you can get!

Persona was (and will remain until the end of November) covered by Mozilla's bug bounty program, meaning that it has been getting regular security bugs filed against it. Most have been spurious, some have not, but each of them has been a fire-drill because Persona gates access to so many of Mozilla's internal services.

We have been able to respond effectively so far, because there's a core of ex-Persona developers kicking around other projects at Mozilla, who we've been able to pull back in for these critical maintenance tasks. But that's not sustainable indefinitely.

The only responsible choices for a security-sensitive service like this are (a) staff it properly, or (b) tear it down gracefully. I'm personally quite disappointed that we couldn't find a path to success for Persona at Mozilla, but I'm grateful we've at least found the resources to do (b).

Yes indeed; I have bugs open to get those added to all our public-facing Persona docs.

Not that it really matters after this announcement, but it has always been possible to disable the suggested tiles, from the little settings gear icon on the newtab page.

This thread suggests that Hello is indeed being considered for similar treatment:

https://mail.mozilla.org/pipermail/gofaster/2015-November/00...

> Firefox Accounts has an active userbase orders of magnitude larger than Persona's.

> We may be able to reintroduce a notion of federated identity into FxA at some point in the future

As a member of the team working on Firefox Accounts, here's one (hypothetical!) way that might play out in practice:

* grow FxA userbase to significant size, integration with Firefox to significant quality

* allow websites to add "log in with Firefox" via OpenID Connect and get a really slick experience for Firefox users

* influence OpenID Connect ecosystem to be more of a level playing field for smaller IdPs (e.g. increasing adoption of IdP discovery and dynamic registration)

* a win for openness on the web!

Not as big a win as widespread adoption of Persona would be, but a win nonetheless.

This sort of thing isn't exactly on our concrete roadmap, our short-term focus remains on supporting Mozilla's own service ecosystem. But be assured that it's on our minds.

Not sure I understand your question, but the thing I'm talking about is a new "Firefox for iOS" product being worked on right now, due for release pretty soon IIUC, that will include syncing among its core capabilities:

  https://github.com/mozilla/firefox-ios

Yes, proper syncing with Desktop Firefox is a core part of the new Firefox for iOS initiative.

Mozilla could be just as easily compelled to turn over user data as Pocket, they're both US companies bound by US law.

It's not hard to imagine how this concept could expand to the web at large. Rather than deciding what ad to display by consulting a user profile built on cross-site history tracking, a site could simply ask the browser for advice on what to show, without the site having to learn anything in particular about the user.

Good for the site because they get better advice; good for the user because they get more privacy and control.

(I've nothing to do with the team behind this at Mozilla, and have no idea what their roadmap actually is. But it's pretty clear that this is just a first step in a broader version of re-inventing advertising on the web, not a stand-alone attempt to generate a bit more revenue).

Indeed, the whole point of this (and all the verbiage about "respecting user privacy") is that the browser will do the analysis locally without sending history data back to Mozilla.

it's a slidedeck from a presentation, you can use the arrow keys to advance slides.

I had not considered this, it's currently just using whatever default colours matplotlib selected. Thanks for the heads-up!

> The old one let you run your own server.

This is still possible with the new system, although I'll admit the ease and usability of such a setup needs work (and IIRC there are some changes required before android devices can properly use a third-party server; it may take a few releases before this become as easy as it was with the old system).

> As it is, it's possible the new sync has a backdoor, > even one many people at Mozilla don't know.

Both the client and server are open-source, and you can verify that the client follows the protocol [1] and doesn't leak anything more than a PBKDF2-stretched password derivative to the server. It's about as backdoor-proof as any client/server system is likely to get.

But yes, it is more dependent on the strength of your password than the previous sync system.

[1] https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc...

Unfortunately this server is not compatible with the new sync protocol. It will continue to work while there is still old-sync support in the browser (a few versions after FF29 at least) but will eventually need to be upgraded to the new system.

> It also let you sync through your own server rather than Mozilla's which I don't think the new version does yet

This is possible with the new version, but it's not (yet) as simple as it was with the previous one:

   https://docs.services.mozilla.com/howtos/run-fxa.html
   https://docs.services.mozilla.com/howtos/run-sync-1.5.html

(edit: actually IIRC there's an open bug around allowing android devices to use a custom sync server; desktop devices definitely work fine with it via some about:config settings)

Heh, actually it might be possible to cheat a little with this backend as well, using http://www.jsil.org/ to translate the output of the cli backend into javascript. Trying C+Emscripten versus CIL+JSIL would be a very interesting comparison.

I got my acronyms wrong, it's called the "CLI" backend, but it's definitely in there: http://doc.pypy.org/en/latest/cli-backend.html

The RPython toolchain has another mode of operation, which outputs higher-level class-based code rather than low-level C-style code. They use this for a CLR backend, but it would be interesting to try implementing a JavaScript backend at that level and compare it to the lowlevel+emscripten approach.

(This may have been tried in the past; in the post "10 years of PyPy" it's mentioned that there was once a JavaScript backend but it was removed because it was a horrible idea: http://morepypy.blogspot.com.au/2013/02/10-years-of-pypy.htm...)

A big part of the current size problem is the way that the stdlib files are bundled - the contents of each file are encoded, byte-for-byte, as a list of base-10 integers. So "hello" gets bundled as "[104, 101, 108, 108, 111]", resulting in quite a bit of overhead.

I agree that 139M is pretty ridiculous for any practical purpose! I'm going to work on lazily loading just the files that are needed, which should make a big difference.

I recently set up my personal domain as an identity provider, using static HTML/javascript files and a bit of crypto:

  https://www.rfk.id.au/blog/entry/persona-identity-provider/

There are some things to be mindful of w.r.t. security in this approach, but it seems to work very nicely for me.

Mozilla Services is the team within Mozilla that builds/runs much of the backend infrastructure, e.g. the firefox sync servers, marketplace servers etc. The existence of separate "mozilla" and "mozilla-services" github projects is largely a historical accident, since different teams started moving to github organically at different times.

(Source: I work for Mozilla, on the Services team)

In the case of gmail, they're note even waiting. There is active development on a gmail-to-persona proxy so that you can authenticate with just your gmail password:

    https://github.com/mozilla/browserid-bigtent