Closed Bug 1161553 Opened 10 years ago Closed 8 years ago

[UX] Create design spec for local storage permissions, notifications and preferences

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox40 --- affected

People

(Reporter: agrigas, Assigned: mark_liang)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ux][storage-v1])

Attachments

(1 file)

There are several issues that need to be addressed to better allow users to manage local storage permissions. Some issues include: -modify preferences to allow users a way to manage storage across all sites given access -clear local storage from a website a user has granted storage permission -notify users when their computer's storage is X% full and link to where they can clear stored data from Preferences -combine clearing cookies with clearing local storage to simplify the number of local storage actions a user has to confront
Flags: firefox-backlog?
Flags: qe-verify-
Flags: firefox-backlog?
Flags: firefox-backlog+
Whiteboard: [ux]
Blocks: 1147820
Blocks: 1275599
Assignee: nobody → thsieh
No longer blocks: platform-ui-team
In London we discussed how to combine cookies, which can span several origins (e.g., phonebook.mozilla.org, mozilla.org, mail.mozilla.org can all share a cookie) and site storage, which is origin-bound (those same domains do not share site storage), and how to expose that in the UI. I think we tentatively concluded that using just mozilla.org in the UI might be okay, but that does not really match other permissions or indeed the web's security model that well (to which cookies are an exception). I since learned that Chrome's plan is that when you clear an origin's storage, you will also clear its cookies, which will potentially include the cookies for other origins. So when you clear storage for phonebook.mozilla.org, the cookies will be deleted for all three origins mentioned earlier. This allows us to consistently use origins throughout the UI and dialogs, while not allowing cookies to revive site storage. I think we should go with that model.
(In reply to Anne (:annevk) from comment #1) > I since learned that Chrome's plan is that when you clear an origin's > storage, you will also clear its cookies, which will potentially include the > cookies for other origins. So when you clear storage for > phonebook.mozilla.org, the cookies will be deleted for all three origins > mentioned earlier. I think Chrome's plan is comprehensible. As we tested on Chrome before, we found that Chrome's UI seemed to clear storage per origin (but it might potentially clear cookies per site). However, when we cleared storage (including cookies) for Calendar.google.com, the account was still logged in. It only logged out after we cleared the storage for google.com. Is it align with the "clear cookies per site" rule? The screenshots are attached above. > This allows us to consistently use origins throughout the UI and dialogs, > while not allowing cookies to revive site storage. I think we should go with > that model. Thank you for clarifying this! It helps a lot! : )
Flags: needinfo?(annevk)
Based on what you're observing it might be that they only clear cookies for the origin's host, and not necessarily all the cookies that can reach the origin in question. That is a little more conservative and does not quite have the same privacy characteristics, but the privacy aspects are a little fuzzy anyway since clearing this doesn't prevent you from being tracked. I'll try to find out the exact semantics. The upside is that clearing your calendar will not log you out of your email.
Flags: needinfo?(annevk)
I'm told Chrome might be changing the details here (more like comment 1), so it's mostly up to us what we want to do here in terms of cookie-removal scope.
Whiteboard: [ux] → [ux][storage-v1]
Assignee: thsieh → mliang
I think we should start with something like the view that I proposed in https://people.mozilla.org/~mnoorenberghe/PermissionManaagerPrefs.png which first lists permissions and then gives global settings for that permission followed by a list of sites where that permission is given or denied. Listing by site first is problematic since different permissions use different groupings to define a "site" e.g. cookies don't include the scheme. It also means we wouldn't be able to global settings for permission types in that context where it's most relevant. This problem is one of the reasons why about:permissions failed and was inaccurate and I would rather we don't even try to provide this view since Control Center already provides this view for a specific site when you visit it.
Flags: needinfo?(mliang)
Copy review for V1 scope is complete.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(mliang)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: