Closed Bug 798160 Opened 8 years ago Closed 8 years ago

About:support should not copy the sync username and account as it may be personally identifiable

Categories

(Toolkit :: General, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
firefox17 --- unaffected
firefox18 + fixed

People

(Reporter: MattN, Assigned: mossop)

References

(Depends on 1 open bug, )

Details

(Keywords: privacy)

Attachments

(1 file)

We have always avoided including personally identifiable information (e.g. printer names, proxy server hostnames/IPs, and directory paths) in about:support. Bug 720997 added the Sync username and account name which are even more likely to identify a user. The patch in bug 620465 received r- from Mossop and opposition from Gavin because of this same reason but this was landed in a new bug. See bug 620465 comment 7 and bug 620465 comment 9 for rationale.  With the new ability to copy the raw data (bug 554174), it's even less likely the user will notice the privacy leak.

A form which needs to collect the sync information can easily have a separate field asking for the username and account.

I don't think having the information in the page is as much of a problem as having it easily copied to the clipboard.  I propose that those two pieces of data are not copied to the clipboard (see bug 787289 for how to prevent the text from being copied) otherwise, they should be removed from the page.
Duplicate of this bug: 620465
We should back out bug 720997 from aurora next week unless we already have a fix for this before the merge.
gps - you specifically requested that info be added there, does it really *need* to be displayed there?

(Also channeling mconnor & ally.)
Assignee: nobody → ally
Jared pointed out that even if our copy buttons don't include the sensitive information, some users may manually select all and copy the whole page when instructed to copy the information from about:support.  We would need to use an oncopy handler to censor the clipboard data for that case so it seems like removing the data is safest.  Another case is the user saving the page to a file and sending it to someone for support.
(In reply to Blair McBride (:Unfocused) from comment #3)
> gps - you specifically requested that info be added there, does it really
> *need* to be displayed there?

On one hand, services.sync.username is a SHA-1 of services.sync.account. Not cleartext. But not fully anonymous either.

On the other, if we are diagnosing a Sync issue, we'll ask to see a Sync log which will expose all this stuff anyway, so meh, the value in about:support isn't extremely high.
(In reply to Gregory Szorc [:gps] from comment #5)
> (In reply to Blair McBride (:Unfocused) from comment #3)
> > gps - you specifically requested that info be added there, does it really
> > *need* to be displayed there?
> 
> On one hand, services.sync.username is a SHA-1 of services.sync.account. Not
> cleartext. But not fully anonymous either.

Both services.sync.username and services.sync.account are both my plaintext username for me and both are exposed in about:support
(In reply to Dave Townsend (:Mossop) from comment #6)
> (In reply to Gregory Szorc [:gps] from comment #5)
> > (In reply to Blair McBride (:Unfocused) from comment #3)
> > > gps - you specifically requested that info be added there, does it really
> > > *need* to be displayed there?
> > 
> > On one hand, services.sync.username is a SHA-1 of services.sync.account. Not
> > cleartext. But not fully anonymous either.
> 
> Both services.sync.username and services.sync.account are both my plaintext
> username for me and both are exposed in about:support

Oh, right. Early Sync users (before Firefox 4 IIRC) have usernames and not email addresses. For hysterical raisins we copy account into username for these users.
Attached patch patchSplinter Review
Assignee: ally → dtownsend+bugmail
Status: NEW → ASSIGNED
Attachment #668607 - Flags: review?(mnoorenberghe+bmo)
Attachment #668607 - Flags: review?(mnoorenberghe+bmo) → review+
I landed this at https://hg.mozilla.org/integration/mozilla-inbound/rev/6136aa2c5dd4 but then after seeing the l10n issues with the original patch I backed it out as a part of https://hg.mozilla.org/integration/mozilla-inbound/rev/3f1fc99346b6.

This bug should be marked fixed once that gets to m-c since there will no longer be an issue and the changes here should land with bug 720997.
This is FIXED by the backout - no need to track this here, bug 720997's new patch will presumably not have this problem.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.