650201 - Figure out if and when sharing account settings should be wiped

Status: RESOLVED FIXED

(Cloud Services :: Share: Firefox Client, defect)

Description

[Philipp von Weitershausen [:philikon]]

With bug 642660 we now store the oauth tokens and all other account related data on the chrome side. We should figure out if these should be wiped when the user wipes certain privacy sensitive data, and if so, which it should be linked to.

Comment 1

[Philipp von Weitershausen [:philikon]]

BUMP! This bug is 99% policy decision and 1% code, we just need that decision :)

Comment 2

[David Ascher (:davida)]

what are the choices available?

Comment 3

[Philipp von Weitershausen [:philikon]]

This is what I can come up with:

a) don't ever wipe
b) wipe when user chooses "Remove All Passwords" in Options -> Security -> Saved Passwords
c) wipe when user chooses "Remove All Cookies" in Options -> Privacy -> Remove individual cookies
d) (b) + (c)

There might be others, I'm not sure.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

Aside from oauth tokens, what else can be wiped?

Comment 5

[Sid Stamm [:geekboy or :sstamm]]

(In reply to comment #1)
> BUMP! This bug is 99% policy decision and 1% code, we just need that decision
> :)

For clarity: who needs to make this decision?  This bug is not currently assigned to anybody.

Comment 6

[Philipp von Weitershausen [:philikon]]

(In reply to comment #4)
> Aside from oauth tokens, what else can be wiped?

It's the whole account blob:

* your user name for that service
* the oauth token
* contacts within that service (your twitter DM contacts, facebook friends, etc.) for the automcomplete stuff

I might be missing an item, too. Firefox doesn't really care or know what gets stored, it just makes sure it's stored securely and can be wiped (if we want to).

(In reply to comment #5)
> For clarity: who needs to make this decision?  This bug is not currently
> assigned to anybody.

I don't know.

Comment 7

[Sid Stamm [:geekboy or :sstamm]]

(In reply to comment #6)
> > For clarity: who needs to make this decision?  This bug is not currently
> > assigned to anybody.
> 
> I don't know.

Okay, I'll weigh in then.

It sounds like this data is stored much in a similar fashion to localStorage / DOM Storage, but the two key differences are that (1) it is encrypted with the MP when set and (2) it contains a authentication tokens not usually kept in localStorage.

In general, I think people clear their private data for two different purposes: to protect their privacy from remote sites (e.g., clear cookies) and to protect their privacy from local users (e.g., clear history/cache/auth sessions).  I think in general, users who want to clear sharing data are not concerned about the remote entities tracking them, so the focus should be on local users who might hijack their sessions or learn something from locally stored data.  Some of this is mitigated by master password use, but we should still provide a way to clear/reset sharing.

Here are my recommendations:

- Given that (correct me if I'm wrong) the account blob gets entirely repopulated when the user re-authorizes F1 for a given service and
- Given that this feature storing tokens for authenticated sessions and
- Given that people probably assume sharing in Firefox is storing authentication data
-> We MUST clear all sharing data when users clear "authenticated sessions" 

- Given that the data is stored in a localStorage-like mechanism and
- Given this data is cached in the browser on behalf of the sharing web site and
- Given that some of the stored account info is involuntary (such as contacts, again correct me if I'm wrong)
-> We SHOULD clear all sharing data when users clear cookies (see bug 599724)

I feel strongly about clearing sharing data when clearing authenticated sessions.  If someone can make a good argument why this data should be more sticky than local storage, I'm happy to drop my second (SHOULD) recommendation.

Comment 8

[Philipp von Weitershausen [:philikon]]

Attachment: v1

This wipes the Share account data when all logins are removed. Currently, the Password Manager UI doesn't call the right bits, though, see 654812.

Comment 9

[Philipp von Weitershausen [:philikon]]

Pushed: https://hg.mozilla.org/users/pweitershausen_mozilla.com/fx-share/rev/06d943bad046. This implements Share account wiping on password wipe. If we should also do wiping on cookie wiping, we should do that in a separate bug. Note that that would require changes to the cookie code to send out an observer notification that we can listen to.

Resolving this now, added bug 654812 as directoy dependency to bug 651668 so that we can track it.