                                                                                                                                                                                                                                                                
Path: r9ni48566pbh.0!nntp.google.com!news2.google.com!postnews.google.com!js1g2000pbc.googlegroups.com!not-for-mail
From: Toby Elliott <toby.elli...@gmail.com>
Newsgroups: mozilla.dev.planning
Subject: Re: Sync in 2012: New Storage Service and Storage Format; Flag Day
Date: Thu, 12 Apr 2012 10:58:13 -0700 (PDT)
Organization: http://groups.google.com
Lines: 36
Message-ID: <3caf3e90-9bca-4e28-a8d2-0ea148beb622@js1g2000pbc.googlegroups.com>
References: <mailman.20662.1334196446.31724.dev-planning@lists.mozilla.org> <4F86BCE8.10106@mozilla.org>
NNTP-Posting-Host: 63.245.220.240
Mime-Version: 1.0
NNTP-Posting-Date: Thu, 12 Apr 2012 17:58:14 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: js1g2000pbc.googlegroups.com; posting-host=63.245.220.240; posting-account=1XhFmAkAAACxd39q7y798sOK6bYrpgzS
User-Agent: G2/1.0
Content-Type: text/plain; charset=ISO-8859-1

On Apr 12, 4:30 am, Gervase Markham <g...@mozilla.org> wrote:

> If it's not possible to make the client speak both 1.1 and 2.0, or make
> the server speak both 1.1 and 2.0 to the client, would it be possible
> for the 1.1 server to be hacked to pass through requests for data to the
> 2.0 server or backend data store for "migrated" accounts, modifying the
> requests to be correct on the way and massaging the data on the way
> back? Or would that be a similarly large amount of work?
>

Modifying the requests isn't possible - a lot of the payload is
encrypted, so we have no ability to mess with it on the server side.
Theoretically the 2.0 client could be made to speak the older storage
format. However, anything it saved in the newer format would be
unreadable by 1.1.

There are two radically different approaches to authentication with no
practical way to correlate users between the two systems (the auth
backends share zero data or code). That means, for example, that if a
user comes in through a 1.1 entrypoint, we have no way to know where
their 2.0 data lives even if we knew the corresponding browserid. And
we obviously can't proxy things, because the 1.1 protocol has no
support to give us browserid assertions.

In order to make this happen, we'd have to set up a separate UX to
allow users to "join" two accounts together, build a new set of
servers to keep that data, tunnel from one system to the other
bypassing authentication to get the new node and an authentication
token, then proxy the request. Setting aside the amount of throwaway
technical effort that would take, there's a couple of pretty nasty
security concerns in there. And that just gets us data flowing one
way. We'd have to do it all again to go the other direction. That's a
crazy amount of work for something that the vast majority of users
will never need or even realize.

Toby