Add support for Firefox Accounts to keep track of which files belong to which user

[ExE-Boss]

Advantages	Disadvantages
Adds better ability to keep track of which user owns which file using Sync	Requires login to access these features (Some people prefer being more anonymous)
Opens up the ability to add more fine grained control over how long a file stays up and the ability to remove said file at any time manually without needing to download it yourself.

[ehuggett]

I didn't set out the write a wall of text when I came across your suggestion, I just get "pulled in" by complex problems so please don't take this the wrong way. I'm mostly trying to flesh out your proposed concept and avoid unknowingly introducing any weaknesses/trade off's into the service, which I hope you can appreciate.

NB Just about everything I know about Sync I learned from skimming https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol for what looked relevant to this issue. Call it out if anything I have stated/suggested appears incorrect or needs further reasoning.

Potential advantages (1 / 2), Its only one advantage and not two?

What advantage(s) does the user gain? I can see that in theory they would be able to move from one device to another and still see their uploaded files (if both are signed into sync), but I think both stated advantages are currently available to the user from the device they uploaded the file from so are not strictly advantages of using Sync, the (single) advantage is moving this data with Sync?

Do you think being able to see the full history, potentially years worth, of uploaded files would be useful in some way? (I suspect chat logs with the context in which the link was transferred would have more utility)

Just to clarify, you are NOT proposing it would be an advantage to the service/Mozilla to be able to associate file uploads with a Sync account/person? (but that the user being able to store data about their Send files inside their Sync data, hidden from Mozilla, to use it on multiple devices would be an advantage).

Disadvantage 1

As you say, authentication generally destroys anonymity. It would probably be impossible to prevent any correlations being made between Sync and Send activity with the data that would be available to Mozilla or an observer with "enough eyes", but that risk may be quite acceptable to anyone that would consider using the feature.

Disadvantage 2 (new)

I think its fair to consider the (deliberate) non-temporary storage of metadata about the files the user has transferred as a disadvantage? Even if the data is encrypted/decrypted by the Sync Client (to state the obvious stored data can always be retrieved somehow). I am not saying it would be an unacceptable risk, but perhaps I would go as far as to suggest it is an unnecessary one with my currently understanding of risk vs benefit?

Potential Advantage 2(?) (new)

However, using Sync for the temporary storage currently done by the client might be interesting, I suspect it wouldn't be possible to ensure it is not stored after the 24 hour expiry (as it can only be erased by an authenticated Sync client?), but so long as Send cannot retrieve expired metadata from Sync then the advantage would be NOT storing this metadata on the client in plaintext when the user signs out of Sync (but still having it available when they sign back in if it has not expired yet).

Disadvantage 3 (new)

Sync data is encrypted with a key derived from the user's sync password, In Send files (and hopefully filenames too ) are encrypted with a completely random key. This may decrease the affective security to the weakest of (the users Sync password | Sync Itself | Send), as Send does not have to store data long term it has the potential to be the strongest of the 3.

Potential Advantage 3(?) (new)

However, storing an asymmetric key pair (ie RSA) in the users sync data would be an interesting possibility... instead of appending the AES key to the send url in plaintext it could be wrapped by encrypting it to the recipients public key (and thus being able to observe the link being sent from the sender to the recipient would NOT yield the encryption key or the ability to retrieve the file). I will leave the problems associated with Public key discovery/distribution mostly unstated, it should suffice to say they are numerous and most "user friendly" services attempting "End to End encryption" have not really solved it without creating new/different problems such as asking an uninformed user (nearly everyone) if the new/replacement key should be trusted or blindly trusting public keys the server claims belong to the recipient (the server could send a public key for which it posses the private key instead).

[MikkCZ]

I think the both pros mentioned by @ExE-Boss can be also achieved without any login, just doing it the same way like Page Shot/Firefox Screenshots do. Being able to # (but not required) with Firefox Account can improve the experience when using Send on multiple devices. If the users are well informed about the pros and cons of signing in with FxA, I don't see an issue adding the (optional) support.

[johngruen]

Hey, we're exploring some better state management stuff on the whiteboard ATM. moving this to stretch b/c the background discussion is super helpful!

[dannycoates]

fxa is in vnext