807065 - [Browser] Clear Private Data needs clarification on what it will & won't clear (especially when it differs from Firefox on Android)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Browser, defect, P1)

Description

[Daniel Holbert [:dholbert]]

The B2G Browser's "Clear Private Data" action is very vague about what it's actually trying to clear.

For comparison, Android Firefox's "Clear Private Data" action will clear *everything*, including e.g. browser-history, and it pops up a list of checkboxes telling you explicitly what it's going to clear.

In particular:
* B2G Browser's "Clear Private Data" does *not* clear browser-history.  (which I initially expected it would, based on my Android-Firefox experience.)  If that's the intended behavior, we should be much more explicit about that.

* The only type of data that it specifically calls out in its 'confirm' message is cookies, and it doesn't even seem to clear those (which is covered in bug 807059.)

* If there's anything else that it's supposed to clear, beyond cookies (I assume there is?), we should explicitly mention it, so that users know what will & won't be cleared.

Comment 1

[:Margaret Leibovic]

Are there UX specs somewhere for this?

Comment 2

[Josh Carpenter [:jcarpenter]]

cc'ing Larissa (UX owner of Browser) for input.

Comment 3

[Larissa Co [:lco]]

Tom, do you have more definite privacy requirements for "clear private data" in the browser?

What I can think of so far:
- cookies
- stored user names and passwords
- form data

We separated "clear private data" from "clear history" because users often want to do one without the other.

Clearing history impacts:
- Awesomescreen
- Start page thumbnails

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Larissa Co from comment #3)
> We separated "clear private data" from "clear history" because users often
> want to do one without the other.

(In a vacuum, I think that's a very sensible decision, FWIW.  But we're not in a vacuum -- we have an already-existing mobile Firefox browser, with its own "Clear Private Data" button, which means users may have expectations about what that button will do.  If we make B2G-Firefox's identically-labeled button behave differently (in a potentially-privacy-leaking sort of way), I think we need to (a) have a very good reason for that difference, and (b) communicate that *very* clearly to the user. (e.g. "Note that this will NOT clear x, y, or z" in the confirmation dialog.)

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Larissa Co from comment #3)
> We separated "clear private data" from "clear history" because users often
> want to do one without the other.

One more note on this, for the record: as a user, my initial guess at the distinction between these buttons' behavior was that "Clear History" would be a quick history-wipe (correct), and "Clear Private Data" would go a step further and clobber my entire profile (sort of like "reset Firefox to factory defaults"). (incorrect)

Comment 6

[Larissa Co [:lco]]

> (In a vacuum, I think that's a very sensible decision, FWIW.  But we're not
> in a vacuum -- we have an already-existing mobile Firefox browser, with its
> own "Clear Private Data" button, which means users may have expectations
> about what that button will do. 

Actually, we're trying to move Android over to more refined privacy controls. B2G is just leading right now.

 If we make B2G-Firefox's
> identically-labeled button behave differently (in a
> potentially-privacy-leaking sort of way), I think we need to (a) have a very
> good reason for that difference, and (b) communicate that *very* clearly to
> the user. (e.g. "Note that this will NOT clear x, y, or z" in the
> confirmation dialog.)

I don't think the difference will be a big issue since Android and Firefox OS users will likely represent two unique user groups, at least in the beginning.

But you're right: in general, we need to have the same policy for Android, FX OS, and our desktop browser, and that's something we're trying to figure out right now. This is something we would need to agree on with the privacy team.

Comment 7

[Tom Lowenthal]

In the absence of other clear signposts, I think that users expect "clear private data" to do two things:

1. remove any local state that a site could use to check that this is the same user, and
2. prevent a future user from knowing what this user has done in the browser.

Essentially: "reset me" as seen by (1) sites, and (2) other users of this device. This meshes well with Daniel's point, since these are already the results of the feature on Android, even though Android provides a lot of ancillary notice and control*.

I further concur with Daniel that (whether these expectations are a priori or come from use of Firefox for Android) we would be remiss if we implement a feature which a user would expect to do *something*, when it actually does *a different thing*, and that results in unexpected loss of the user's privacy.

If we want different behavior, perhaps we should give these two features different names to better reflect what they do? If we're sticking with what we have now, let's keep both the name and the (expected!) behavior.

TL;DR: http://j.mp/VObP7n

- - - -

*For reference: on Android (I'm using 18.0a2), "clear private data" provides a pre-checked list of items to clear. Users can un-check one or more items, then confirm. The list is:

* Browsing & download history
* Form & search history
* Cookies and active logins
* Saved passwords
* Cache
* Offline website data
* Site preferences

Clearing these things does pretty well at achieving the two results suggested above.

Comment 8

[Larissa Co [:lco]]

If "clear private data" includes your browsing & DL history, then I suggest we amend the two labels to:

"Clear all private data"
"Clear browsing history only"

In this case, we should also change the dialog text that comes up for "private data" to be more specific about some of the things we're clearing.

Comment 9

[Alex Keybl [:akeybl]]

We're marking this bug with the C1 milestone since it follows the criteria of "unfinished feature work" (see https://etherpad.mozilla.org/b2g-convergence-schedule).

If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.

Comment 10

[Tom Lowenthal]

@Larissa: For reference, android has only one button, which produces a checklist. I think that's a more valuable target behavior, because then users (and we!) don't have to second-guess what this feature does.

Comment 11

[Ben Francis [:benfrancis]]

Can we please make any change as minimal as possible.

Clear History clears global history (which is stored by the browser app in IndexedDB) and now also clears session history from the platform.

Clear Private Data clears cookies, localStorage, IndexedDB and appcache stored by web content in the platform.

We DON'T save form data or save any passwords and the platform doesn't store any global history itself.

It seems all we need to change in the browser is to refine the text of the Clear Private Data confirmation dialog to clarify what is actually getting cleared.

Note that clearing data stored by *apps* is a separate thing entirely, which currently only happens when you un-install an app, because bug 792892 was punted to v2.

Comment 12

[Ben Francis [:benfrancis]]

Larissa or Josh,

This has been classified as feature work which needs completing by November 19th. If this is just a simple text change then I am happy to do it, but if it's more then I may need to re-assign.

Would you be able to provide us with a decision and/or some final copy so this change can be made ASAP?

I think we just need to change the text in the comfirmation dialog.

Thanks

Comment 13

[Larissa Co [:lco]]

Ok, for v1, let's make this a simple text change. Ben, please let me know if this text accurately reflects what we're currently doing.

Button: "Clear cookies and stored data"
Confirmation Dialog text:
"Clear cookies and other data stored by sites on this device?" 


Button: "Clear browsing history"
Confirmation Dialog text:
"Clear browsing history?" (note that I changed this to sentence capitalization rather than the title capitalization I had in my wireframes to be consistent with our string formats)

Comment 14

[Larissa Co [:lco]]

(In reply to Tom Lowenthal [:StrangeCharm] from comment #10)
> @Larissa: For reference, android has only one button, which produces a
> checklist. I think that's a more valuable target behavior, because then
> users (and we!) don't have to second-guess what this feature does.

My initial impression though is that the detailed checklist that you mentioned is too much information for most of our users. My worry is that the more refined control we give users, the more confused they will be that they don't know the "right" combination of levers to pull in order to keep themselves safe. 

The options I think are unclear:
* Cookies and active logins
* Cache
* Offline website data

Also, after having just gone on some fieldwork, I can tell you that most of our participants had a very vague idea of what "clearing the cache" or "cookies" did. They just did so as part of their routine because they had a trusted tech source who told them to do so.

In addition, most people did these things because they thought it would make the browser run "faster". Most didn't have a privacy-related intent when using these options.

So my personal bent is for a simple one-button UI with more refined controls hidden on a secondary screen. I'm open to redesigning this for v2, and hopefully getting the point across to the Android and desktop UIs as well.

Comment 15

[Josh Carpenter [:jcarpenter]]

> So my personal bent is for a simple one-button UI with more refined 
> controls hidden on a secondary screen. I'm open to redesigning this 
> for v2, and hopefully getting the point across to the Android and 
> desktop UIs as well.

+1

Comment 16

[Ben Francis [:benfrancis]]

https://github.com/mozilla-b2g/gaia/pull/6402

Comment 17

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/6402

Comment 18

[Ben Francis [:benfrancis]]

Comment on attachment 681509 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/6402

r+dale (in pull request on GitHub)

Comment 19

[Staś Małolepszy :stas]

This was merged in before I could gt to it.  Can you please add me on "r?" for any changes that touch *.properties files?

Can you please change the identifiers of the affected strings, as per https://wiki.mozilla.org/L10n:B2G/Developers#Changing_strings_after_the_string-freeze ?

Comment 20

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/6504

Comment 21

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 683155 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/6504

r+.

Stas we need this code to be landed today and I was unable to find you on IRC. The changes sounds fine to me though.

Comment 22

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/87309ebb25d71b4cac954405035ed6f529e3e945

Comment 23

[Staś Małolepszy :stas]

(In reply to Vivien Nicolas (:vingtetun) from comment #21)
> Stas we need this code to be landed today and I was unable to find you on
> IRC. The changes sounds fine to me though.

Thanks, Ben & Vivien.  I was traveling on Monday.

Comment 24

[Darren]

Verified as fixed on Unagi build 20121231070201.