On Mon, Jul 21, 2014 at 5:12 PM, Gervase Markham <[email protected]> wrote: > On 21/07/14 12:18, Dirkjan Ochtman wrote: >> I think the recent Sync -> Firefox Accounts is a clear example of >> where safety was traded off against user experience. > > Well, possibly.
It seems to me that the privacy properties of New Sync are objectively weaker than those of Old Sync. New Sync is worse for privacy compared to Old Sync in three ways: 1) The encryption key is derived from something that the user supplies instead of being derived from a CSPRNG. This means the key comes from a worse entropy source. 2) Since the password will be used in other contexts, people who expect to have to enter the password often have an incentive to lower the entropy of the input to the key derivation even if they realized that they had the opportunity to generate their password from a CSPRNG on their own (worse usability than having Firefox do it for you!). 3) The Firefox Accounts password from which the Sync key can be derived is in some cases (I believe; please let me know if I'm wrong!) entered into forms that are accessible to JavaScript programs obtained from Mozilla's servers dynamically by HTTP GET. The third point opens up a Hushmail attack vector: With Old Sync, the attack to defeat the privacy of Sync was equivalent to the attack necessary to grab the passwords and history of a users who was not using Sync: delivering a Trojanized Firefox update or extension update from AMO. With New Sync, even if you use no extensions and build the browser yourself, a Mozilla-served JS file that implements a Firefox Accounts login form could be changed to exfiltrate your clear password (rather than some token derived from it), giving an attacker that also has access to the data on the Sync server enough information to decrypt the data. I think this makes New Sync have objectively weaker privacy characteristics than Old Sync. > But I think you could just as easily cast that in terms > of features. Notably, this didn't turn out to be an *addition of the option* of weaker privacy for those who want to trade off privacy in order to a) be able to forget passwords or b) be able to more easily pair devices without having both devices in the same location for pairing. Instead, this turned out to be the removal--even as an option--of the key characteristic of Old Sync from users who wanted *sync* without giving up any privacy compared to having Firefox store history and passwords in the first place instead of wanting profile *backup* with lesser privacy characteristics. Seems hard to reconcile with "user control" or "real choices". :-( See https://bugzilla.mozilla.org/show_bug.cgi?id=1034526 for restoration of the old level of privacy as an option (in a way that would require no server-side changes but would require UI changes on the clients). > We are told that users wanted to be able to retrieve their > data even when they lost all their devices. In order to provide that > feature, we needed to move to usernames and passwords rather than shared > keys. So are we currently actually providing that feature? New Sync's architecture supports data that is recoverable without the password and data that is irrecoverable without the password. Are we actually putting data in the former bucket? That is, did password fogettability even get delivered to those who wanted it for any subset of syncable data? Or did just pairing by password actually get delivered? > The updates are a response to change within Mozilla and beyond. In four > years, Mozilla has grown and expanded with new products and services that > didn't exist in 2010. In 2014, the world around is often described as > "post-Snowden", after his revelations sparked an international debate about > Internet privacy and surveillance. A post-Snowden mindset should result in the characteristics of Old Sync... :-/ > TITLE: > Previous: Mozilla Privacy Principles > New: Mozilla Trust & Safety Principles > Context: Intended to be broader than privacy, yet inclusive of both privacy > and security. The term Trust & Safety is used by Twitter, EBay, Airbnb and > others. The removal of the word privacy and adding trust seems rather Orwellian. The sort of privacy that involves the user having to *trust* Mozilla is worse than the kind of privacy the users can observe they have even if they don't trust Mozilla. (See above for Sync: Mozilla not having a Hushmail attack vector is better than having to trust Mozilla not only not to use the Hushmail vector on its own initiative but to have the capability to successfully fight off anyone who might want to use the Hushmail attack vector against Mozilla's wishes.) I'd much prefer Mozilla to deliver the sort of privacy solutions that can be shown to deliver privacy by mechanisms that are observable rather than trust-based. > LIMITED DATA > Previous: Collect and retain the least amount of user information necessary. > Try to share anonymous aggregate data whenever possible, and then only when > it benefits the web, users or developers. > New: Collect what we need, de-identify where we can and delete when no > longer necessary. > Context: Replaced "collect and retain the least amount" with the broader > "collect what we need". Removed "only when it benefits" seemed broad enough > that most things would fall in one of the three. Considered adding "collect > only" but concerns about differences in definition (ex: indirect benefit vs. > direct benefit). The lack of the word "only" after "Collect" makes the new wording look not very privacy-oriented... > TRUSTED THIRD PARTIES (relocated) > Previous: Make privacy a factor in selecting and interacting with partners. > Context: Incorporated into the introduction as "select and interact with > partners". All principles inform how we work with partners, so this does not > need to be a standalone principle. I suggest there should be a principle of minimization of having to have third parties that need to be trusted. E.g. it would be better if Mozilla had a self-hosted solution for gathering whatever Web site usage statistics Mozilla truly needs instead of giving all the user-behavioral data to Google Analytics and making what happens with that data over at Google's side a matter of trust. > IN-DEPTH DEFENSE (added) > New: Innovate multi-layered security controls and practices, many of which > are publicly verifiable by our global community. Looks like the transition from Old Sync to New Sync went in the wrong direction in the light of the principle of defense-in depth by opening up a new attack vector (see above). -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
