1400679 - allow all storage to be blocked on a site-by-site basis with optional click-to-activate

Status: RESOLVED WONTFIX

(Firefox :: Site Identity, enhancement, P3)

Description

[Ben Kelly [:bkelly, not reviewing]]

I understand we are refactoring our permission UX right now.  One permission that has been requested by users is the ability to block storage for specific sites or even to require click-to-activate for any storage.  See:

https://superuser.com/questions/1250944/how-can-this-website-reidentify-me-even-after-deleting-all-of-my-browsers-histo/1251054

Its unclear to me if we have the necessary underlying platform bits to provide this or if it only requires UX work.

Please consider adding this feature to support privacy conscience users.

Hsin-Yi, can you again help me get this to the right storage/permissions people?  Thanks!

Comment 1

[Johann Hofmann [:johannh]]

Reading that post there is also clearly a problem in the page info window, where "Always Ask" does not accurately reflect the state of storage, as is evident by the storage amount that is displayed right beneath it. We should probably just open a separate 
bug to fix that in the short term.

That entry in page info maps to the indexedDB permission, but its default seems to be "Allow" rather than "Always Ask", so this _could_ be a frontend issue, depending on whether the storage backend supports an "Always Ask" value at all (doesn't seem like it, though they should IMO).

I don't think it's viable to make a doorhanger that blocks _any_ storage (even localStorage). There's the simple issue that localStorage access is sync and permission prompts require APIs to be async. Why can't people just use a private browsing windows or container tabs?

The three problems we should follow up on:

- Page Info is incorrectly displaying the default permission state for IndexedDB (and it's called "Offline Storage", which is a confusing term to me), that whole permission section is just confusing.
- IndexedDB data doesn't seem to be cleared with other browser history, is there a bug with clarification on why that is the case?
- IndexedDB does not seem to support showing a permission doorhanger (I could be wrong about this, I tried it but I didn't check their code yet).

I don't think, however, that there's something we can do in this bug/this component.

Comment 2

[manuel]

I think this can actually be solved without any drastic design changes. When a website writes something to local storage, do it as usual. Then ask: "Website xy has written local data. Do you want this data to persist after leaving xy?". And if the user says no, then delete it (and remember that decision) Because writing something to local storage does no harm. It's the persistence of that storage that's problematic. Problem solved and storage access can still be sync while messages can still be async.

I don't see why private browsing is an excuse for not caring about the privacy of regular browsing. Private browsing is very inflexible, doesn't allow any exception and is not practical for daily use. For example, I still want to have a browsing history so that I can find websites I visited earlier.

Comment 3

[Johann Hofmann [:johannh]]

(In reply to manuel from comment #2)
> I think this can actually be solved without any drastic design changes. When
> a website writes something to local storage, do it as usual. Then ask:
> "Website xy has written local data. Do you want this data to persist after
> leaving xy?". And if the user says no, then delete it (and remember that
> decision) Because writing something to local storage does no harm. It's the
> persistence of that storage that's problematic. Problem solved and storage
> access can still be sync while messages can still be async.

This is quite a complex feature to ask for, it's more a full-scale project than a simple bug. I don't see us investing time in developing this sort of thing, as useful as it may seem to you.

To me it also doesn't sound particularly great, it sounds like an even more annoying version of the "This website uses cookies" warning. Any remotely useful website utilizes some sort of storage these days, which means the user would be constantly seeing this message.

> I don't see why private browsing is an excuse for not caring about the
> privacy of regular browsing. Private browsing is very inflexible, doesn't
> allow any exception and is not practical for daily use. For example, I still
> want to have a browsing history so that I can find websites I visited
> earlier.

You should take a look at the containers project, it seems exactly like what you're looking for:
https://blog.mozilla.org/firefox/introducing-firefox-multi-account-containers/

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thanks Ben! I've looped Storage UX (Mark) and Preferences UX (Tina) as well as PM (Cindy) in.

Comment 5

[manuel]

(In reply to Johann Hofmann [:johannh] from comment #3)

> This is quite a complex feature to ask for, it's more a full-scale project
> than a simple bug. I don't see us investing time in developing this sort of
> thing, as useful as it may seem to you.
> 
> To me it also doesn't sound particularly great, it sounds like an even more
> annoying version of the "This website uses cookies" warning. Any remotely
> useful website utilizes some sort of storage these days, which means the
> user would be constantly seeing this message.

Thanks for your evaluation of this proposal. You are right, if there are too many notifications this can become quite useless. This was just one proposal.

Anything you can do to improve the "visibility" of this storage would be appreciated. At the moment, IndexedDB is quite hidden from the end-user leading to confusion and frustrating experiences as described in my initial question at superuser. The preference UX redesign in FF57 as described by Ben Kelly where you can actually learn about this storage in the preferences UI is already a step in the right direction, I appreciate that. And solving Bug 1400678 will further contribute to a more understandable behavior.

Comment 6

[James Hall]

Will this also be exposed to Webextensions?  Would be good if extensions like 'Cookie Autodelete' can handle some of the UI for when a websites's data gets deleted.

Comment 7

[Johann Hofmann [:johannh]]

Following up on my earlier comment:

> The three problems we should follow up on:

> - Page Info is incorrectly displaying the default permission state for
> IndexedDB (and it's called "Offline Storage", which is a confusing term to
> me), that whole permission section is just confusing.

I noticed that there's bug 1334411, which we should re-prioritise.

> - IndexedDB data doesn't seem to be cleared with other browser history, is
> there a bug with clarification on why that is the case?

Bug 1047098 took care of this.

> - IndexedDB does not seem to support showing a permission doorhanger (I
> could be wrong about this, I tried it but I didn't check their code yet).

I don't think it's worth filing a bug for that now, given bug 1334411.

> I don't think, however, that there's something we can do in this bug/this
> component.

I'm closing this bug as WONTFIX, given the limitations to the general approach outlined in comment 3.