1788633 - Change "Cookies" label to "Cookies and Site Data" on sanitize dialog to match preference setting terminology and reduce user confusion

Status: NEW

(Toolkit :: Data Sanitization, task, P3)

Description

[Paul Zühlcke [:pbz]]

T4-2 : In Firefox on Windows, Linux, and macOS, the user's allow/deny selection is not erased after using the browser's data clearing mechanism. This implementation is also valid in Private Browsing Mode. This permission handling may not meet the expectations of users who use the data clearing mechanism for the purpose of erasing data stored in their browsers. Details on the types of permissions and status of permissions with this vulnerability are shown in Table VI in the paper.

This bug is from the report in Bug 1784741.

Comment 1

[Paul Zühlcke [:pbz]]

Could you please specify which browser clearing mechanism you mean?

The "clear recent history" dialog also clears permissions if that category is selected.
"Clear cookies and site data" from the identity panel (lock icon) does not.

Thanks!

Comment 2

[Kazuki Nomoto]

Thank you for reviewing our report.

In our analysis, we used the "Clear cookies and site data" feature for the following reason.

First, in the following document, "Cookies and Site Data" is explained as "to remove login status and site preferences".
https://support.mozilla.org/en-US/kb/storage#w_clear-all-information

Second, in the following document, "Site preferences" is defined as "Site-specific preferences, including the saved zoom level for sites, character encoding, and the permissions for sites (like pop-up blocker exceptions) described in the Page Info window."
https://support.mozilla.org/en-US/kb/delete-browsing-search-download-history-firefox

So, we concluded that "Clear cookies and site data" feature should clear "Site Preferences," which contain the permissions for the site.

Comment 3

[Daniel Veditz [:dveditz]]

The site is incorrect. "Site data" is data that the site has saved (cookies, localStorage, etc). If you go into the more extensive "Clear History" section there is a separate "Site settings" category which is the data that USERS have saved about the site (permissions, zoom settings, notification push keys, etc).

The intent of the panel option you're talking about is to clear the site's data in case it's not working. It is not synonymous with our "Forget about this site" feature available through the history dialogs.

Comment 4

[Daniel Veditz [:dveditz]]

Or maybe merely ambiguous. In the context of the storage page they use "site preferences" to mean the stuff a page would save if the site had it's own "preferences" (for example, GMail does). They are trying to briefly describe what the other page calls "Cookies" and "Offline Website Data". In fact, it mirrors the language of the cookies section that says

Cookies: Cookies store information about websites you visit, such as site preferences or login status.

On the "delete-browsing-search-download-history-firefox" page they describe seven types of data, and then show a dialog with seven checkboxes. Unfortunately they used the term "Site Preferences" as the section heading in the text part which is confusing given their earlier use of the word "preferences". That section should be titled "Site Settings" like the dialog pictured below (though that's still confusing)

I have updated the summary to describe T4-2 as I understand it using our terms for this data. If I have interpreted this accurately then this is working as intended. We think if users have gone to the trouble of overriding default permission settings they don't want the site to be suddenly unrestricted. And if they do, site setting overrides are in a panel next to the lock and they will see they are still there, and can change them from there.

While the functionality is as-intended, if your team was confused about what these options do then probably lots of other people are too. We may be able to improve the clarity of the UI.

Comment 5

[Kazuki Nomoto]

We agree that the documentation inconsistencies should be fixed.
Also, even if the documentation inconsistencies are fixed, many people could be confused with the functionality.
So, it would be desirable to enhance the UI of this feature in the medium to long term.
For example, it would be possible to mitigate user confusion by simply clarifying to the user the data that are not covered by the "Clear cookies and site data" mechanism and suggesting the use of the "Clear recent history" function if the user wishes to erase those data.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:pbz, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Daniel Veditz [:dveditz]]

Seburo: what's the procedure for getting a SUMO kb article fixed? See comment 2 and 3 here

Comment 8

[Seburo]

If you could specify what is wrong and what the correct text should be on what KB articles (so that I am clear on what needs to be done), I am more than happy to take care of the edit for you.

Comment 9

[Daniel Veditz [:dveditz]]

After a side chat, Seburo updated the SUMO "Storage" article referenced in comment 2 to make the terminology more consistent. The headline "Clear all information" was changed to "Clear data stored by all sites" so it was less likely to be interpreted overly broadly. The article topic is "local site storage" and "all" was meant to be limited by that scope (all sites, not all information).

English has a large amount of ambiguity "built in", but it should help that we have consistency amongst the wordings and consequent actions of:

• "Clear cookies and site data..." on the identity (lock) panel
• the "Cookies and Site Data" section in preferences
• the "Manage Cookies and Site Data" dialog that opens from the "Manage" button in that section
• the "Cookies and Site Data" checkbox on the "Clear Data..." dialog
  ... and now ...
• the SUMO article about Storage

Thanks, Seburo!

HOWEVER

The reporter is understandably confused when comparing this option to the language used in the second article mentioned in comment 2. I was wrong to blame SUMO in comment 3; I now believe SUMO is simply (though narrowly) representing the "Clear Recent History" dialog as it exists, but that the dialog wording itself is unhelpful and misleading.

From a "privacy" point of view we often simplify the concept of "data the site stores on your computer" as "Cookies". To a developer HTTP cookies, local storage, and indexeddb are very different things with different properties, different uses, and different APIs. But that's a lot to squeeze into a dialog or button, and at a high level they affect users similarly (can this site track me? save my session? what is this hysteria about "super" cookies?). Disabling or clearing "cookies" also disables or clears the other cookie-like storage mechanisms, for example, because it's conceptually easier for everyone (Firefox developers included!) to treat them the same. The "Clear Recent History" dialog uses the word "Cookies" in this broad metaphorical sense. The SUMO page could have helped by describing the broader senses of "Cookie" instead of taking it literally. Users who know about those other storage mechanisms are left wondering "how do you clear indexeddb and local storage in this dialog?" and possibly coming to very wrong conclusions (like "maybe it's this offline website data", which it is NOT)

We should make two changes:

1. Change the label on the Clear Recent History dialog to "Cookies and Site Data" to match the wording used by the preference section dealing with that data.
2. Change the delete history SUMO article description of "Cookies" to also mention the other data types. This could be done now independently of the dialog change, and then update the article again later (label and image) when the dialog gets updated.

pbz: if you agree with #1 then this isn't a "Site Permissions" bug, but I'm not sure what component owns that dialog. Toolkit::Data Sanitization? Or is that only the logic behind it and not the history dialog? Toolkit::Places (with other history UI) doesn't seem quite right either.

The original issue reported here is working as intended and is not a security bug: I'm going to un-hide this. But the UI doesn't make that intention very clear so I'm morphing this bug to address the source of confusion

Comment 10

[Daniel Veditz [:dveditz]]

The same options also appear in the "Settings for Clearing History" dialog and the label would have to be changed there as well. It's probably the same localized string, but mentioning it in case it was implemented as two independent copies

Comment 11

[Daniel Veditz [:dveditz]]

The "Cookies" support article looks like it was originally just about literal cookies, and then later was partially converted, or at least retitled, to define that as "Information that websites store on your computer", which would include "Site Data". The "Cookie Settings" section also was updated, and uses the phrase "Cookies and Site Data" at least three times in a very short section. The first part of the article, however, is talking about literal HTTP Cookies ("in Firefox, all cookies are stored in a single file").

The article doesn't describe cookies in any technical detail and most of what it says applies to any of the storage types. Depending on the audience you could either broaden it to be "Cookies and Site Data", or you could have a section on Cookies and add a section about "Site Data" . The latter wouldn't need to say much, but could name LocalStorage and IndexedDB as two forms of it if people want to go look up the APIs in MDN. Personally I'd go the (easier) make it more generic route.

Comment 12

[Daniel Veditz [:dveditz]]

The SUMO page about the Clear Recent History dialog has been updated to say the "Cookies" item clears other local site data as well
https://support.mozilla.org/en-US/kb/delete-browsing-search-download-history-firefox#w_what-information-is-included-in-my-history

Thanks again, Seburo!

The remaining work (that we agree on) is to update the label on the Clear Recent History dialog. browser/base/content/moz.build says that goes in the Data Sanitization component. Moving the bug, and updated the summary to clarify the task

This doesn't fully satisfy the reporter's request in comment 5 (this change will clarify what we do, not what we don't do). I'll spin out an RFE for that