1018420 - Include the user's email address in the server's registration response

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: FindMyDevice, defect)

Comment 1

[JR Conlin [:jrconlin,:jconlin]]

Can I note that I'm tremendously against this. 

As it stands, someone who gains access to the data set will currently have just the device name, and two random IDs to associate back to a user. Currently, the "name" field is the local portion of the email address used when Authenticating the device. Ideally, this name would be replaced by the user with something more meaningful for display back to the user.

If we store the email of the user in the remote database, that means that any unauthorized party (or any party with sufficient legal force) can acquire the data set and easily determine who owns which device and require tracking information for that individual, possibly without that individuals consent or knowledge.

I would MUCH rather that the device manage and maintain whatever email address it requires and not use the remote server to provide this info.

Comment 2

[Guilherme Gonçalves [:ggp]]

I completely share your concerns about storing emails, and I agree it's not something we should do unless we really, really have to. However, notice that what this bug does not request that you _store_ it; only that you return the email after verifying the assertion provided in the registration request.

So I think the behavior here would be that once you get a registration request that contains an assertion, verify the assertion as you normally would, and return the email contained in it without storing it anywhere. If the registration request doesn't contain an assertion, then don't include an email field in the response.

Note that back when I filed this bug, I didn't expect to have to verify assertions in the client just to get an email, which I ended up doing anyway for another use case. It would still be nice if you did it for me on the registration case, but if you're still uncomfortable with this even without storing anything, I can manage another verification hack in the client. Just let me know.

Comment 3

[JR Conlin [:jrconlin,:jconlin]]

I am generating a unique hash for a given user based on the Assertion data. This hash is used by the server to identify a user and can be transmitted to the device. 

I'm not a Huge fan of this, but I can provide this as a "userid" value in the registration reply.

Comment 4

[Guilherme Gonçalves [:ggp]]

We've settled for providing a userid value, as per https://bugzilla.mozilla.org/show_bug.cgi?id=1000323#c21.