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