> We've anticipated some of this in the auth/key server, but haven't worked
> through the details. We track currently "active" devices with a long lived
> session token that the client uses to authenticate itself with auth/key
> server (e.g., refreshing the signature on the clients public key, which is
> required to generate assertions for authenticated to the storage server).
> Having a valid active session token means you're "attached". Changing or
> reseting your password invalidates all active, valid session tokens. There
> are lots of details to work out here, but I think this is a good start.
That'll need some decoupling: if I change my password, I don't want the first
client to arrive to think that I have no other clients, just because I couldn't
type quick enough! But good to hear that there's a start on this.
>> * Version negotiation. We need versioning at the protocol level, at the
>> storage level, and at the data model level. Sync has the first two, but
>> lacks the third, and it has no concept of negotiation at all -- because
>> negotiation requires external device management. (Sync stores its client
>> descriptors inside the system itself!)
>>
>
> What does storage level versioning mean?
The whole caboodle: how records are organized, how meta objects are arranged,
crypto schemes, envelope formats.
That's in contrast to data model versioning: v2 bookmarks have a color
attribute, v3 history items record whether you were using Reader Mode for a
visit, whatever.
> Here's Chromium's take on it:
>
> http://www.chromium.org/developers/design-documents/sync/sync-data-best-practices
To take a brief aside, I think Chromium takes the wrong approach here. It'll
work for some cases, and stands up to gentle scrutiny, but it causes silent
partitioning more often than not — even for trivial cases. Consider fixing
internationalized URIs, which Sync 1.1 does wrong.
Client New writes to just the new URI field, or to both the new field and the
old field.
Client Old doesn't see the new change; it doesn't even know the new field
exists.
Client Old makes a change, and updates the old field. It doesn't detect a
conflict that it can reconcile.
Client New downloads the record. Which field is right?
Sadness ensues.
One can think of plenty of other known Sync bugs that we couldn't fix like this
— altering the representation of history visits, for example. And throw in a
third client to get some real fun times.
It also requires that clients be able to preserve fields that they don't
understand. Android's internal data model is specifically designed to allow
this, with arbitrary columns, but Firefox is not.
The benefit that is has is to avoid large reuploads.
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
