825538 - [email/activesync] Need to allocate unique device ID's for multi-device access to ActiveSync

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

ActiveSync will be messed up if used from multiple Firefox OS devices and need to resynchronize all of its data anytime another Firefox OS e-mail app connects.

We always use a device id of "v140Device" and a device type of "SmartPhone".  We were previously thinking this might cause problems with multiple devices and it turns out it does.

It appears that the hotmail server keys its synckey mapping off of our device id.  Here's an example of what can happen.

1) Create account on device A (a day ago; the automatic sync range ends up different than on device B for this reason)
2) Open inbox on device A, get 32 messages.
3) Hit refresh on device A, get "empty response".
4) Create account on device B
5) Open inbox on device B, get 99 messages.
6) Hit refresh on device A, get 99 messages (!!)
7) Hit refresh on device A, get bad sync key notification, then 32 messages.
8) Hit refresh on device B (noting we did not hit refresh and so have not gotten an "empty response"), get bad sync key, 99 messages.


I verified that if I change one of the instances to use a different device id ('v141Device' in this case), device A and device B no longer fight each other.


I think the best course of action is probably for us to create a random identifier when we create the MailUniverse and use that for all ActiveSync accounts.  Other possibilities and the rationale against:

- Create a unique identifier every time we create a new ActiveSync account.  The argument against this is that we might needlessly waste the server's resources if the user deletes the account and re-creates it, since the server may perceive us to be a different device and therefore leave all of the other device's sync keys alive and tracking changes, at least until some time/data threshold is reached and it destroys the sync keys.  Since about the only user-exposed solution to deal with account problems would be to delete an account and re-create it, we are likely to suggest this in support docs, so it seems like a nice thing we could do.

- Extract some unique entropy from the device and use that directly or as the input to some deterministic hash process.  There's potential privacy ramifications to directly exposing serial numbers.  Using an expensive one-way hash makes it harder to brute-force reverse, but the entropy source we pick might not actually have a wide range (serial numbers, MAC addresses), so brute-forcing would not be required.  The reason we would want a deterministic process like this would be so that if the device gets reset we could again be friendly to servers.  But it doesn't seem worth the data exposure risk, and in various situations (web browsers, unprivileged use) we probably wouldn't be able to get the entropy anyways, so we will need the proposed solution or the former solution as a fallback anyways.

Comment 1

[Dylan Oliver [:doliver]]

Tagging this bug to put it in the productivity backlog

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Attachment: have fake-server be able to tell us what device id's it has seen

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Attachment: generate a random device id for new accounts/upgraded accounts/transparent upgrade accounts

:squib, if you're feeling like you don't actually want a bunch more ActiveSync reviews, feel free to redirect reviews to :mcav ;)

Comment 4

[Jim Porter (:squib)]

Comment on attachment 8440231 [details] [review]
have fake-server be able to tell us what device id's it has seen

Looks good to me!

Comment 5

[Jim Porter (:squib)]

Comment on attachment 8440232 [details] [review]
generate a random device id for new accounts/upgraded accounts/transparent upgrade accounts

Looks good! It's nice that jsas already had the capability of specifying a custom device ID! ;)

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jim Porter (:squib) from comment #5)
> Looks good! It's nice that jsas already had the capability of specifying a
> custom device ID! ;)

Yes, bonus points to you for thinking ahead! :)

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

landed in mail-fakeservers/master:
https://github.com/mozilla-b2g/mail-fakeservers/pull/16
https://github.com/mozilla-b2g/mail-fakeservers/commit/0f29cdccbeedf5dcef1f1e17c16702f25dfda640

published as mail-fakeservers 0.19 in npm:
$ npm publish
npm http PUT https://registry.npmjs.org/mail-fakeservers
npm http 201 https://registry.npmjs.org/mail-fakeservers
+ mail-fakeservers@0.0.19

landed in gelam/master:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/313
https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/ba0df44aa0b4b6998452c47700282ced2c4ada28

landed in gaia/master:
https://github.com/mozilla-b2g/gaia/pull/20525
https://github.com/mozilla-b2g/gaia/commit/b47b5d1f08dce81fdf16bb3eeebea6ce7e5d225b


This is going to want to be uplifted to various branches; I'll mark the blocking relationship from the bugs and request appropriate blocking/uplift/whatever status.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Requesting 1.3? for uplift since this is believed to be the root cause of current 1.3+ blocker bug 1008046.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8440232 [details] [review]
generate a random device id for new accounts/upgraded accounts/transparent upgrade accounts

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Never worked.
[User impact] if declined: Any ActiveSync account created on multiple Firefox OS devices will be indistinguishable from the server's perspective, and due to nuances in the ActiveSync protocol, will result in bizarre and arbitrary failures.  (See the rest of the bug for more details on that.)  This disproportionately affects QA testing where multiple devices may be involved.
[Testing completed]: Tested against hotmail/outlook.com and there are back-end unit tests providing reasonably thorough coverage of this reasonably small change.
[Risk to taking this patch] (and alternatives if risky): It's a cert blocker, so...  But anywho, QA and power Firefox OS users (with multiple devices) will continue to experience unreliable synchronization.  Although we believe hotmail/outlook are fine, it's conceivable there are servers out there that could get upset.
[String changes made]: None.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/96904cad15956f8fb2c536d01c2d4455372c6178
v1.4: https://github.com/mozilla-b2g/gaia/commit/1a2d092eb742f6019e82c320e741689f17e12fd1

Also, tracking-b2g18:28+ ?

Comment 11

[Ryan VanderMeulen [:RyanVM]]

v1.3: https://github.com/mozilla-b2g/gaia/commit/d8e51e24e8f1e620f28f209153b7de1987ef4e5b