Privacy-Safe Storage API

[privacycg]

Privacy-Safe Storage API

[annevk]

It's an interesting idea. I suspect you'll find it challenging to prevent communication with nested browsing contexts as width/height or history gives quite a few channels. And given the service worker backing it's not clear you can really prevent dynamic generation of nested browsing contexts. Or at least you'd have to provide more detail as to how that would work.

Another thing this would need is a way to update the website. I think that poses another challenge as you want to allow frequent updates for security reasons, but you do not want to allow it to be used as a communication channel of sorts. (And involving the users for updates is a non-starter I think from a usability perspective. That is, it seems attractive this allows the user to be involved for those that want that level of control, but that cannot be the default.)

[Minigugus]

@annevk Thanks for the feedback 👍

I suspect you'll find it challenging to prevent communication with nested browsing contexts as width/height or history gives quite a few channels.

As a work around, this proposal shouldn't work within embedded frames, only on main frames and workers, so that when a user navigate to a different page or origin, the website state is reset and is becomes possible to disable the storage access and re-enable network access without leak risks. Concerning the service worker, as explained in my previous message, requests and messages routing to service workers depends whether the client context is privacy-safe (has access to the privacy-safe storage), so that the target service worker inherits storage access permissions as well as network restrictions. When a user navigates using the history buttons, the main frame load the page using from the service worker without storage access, so there is no leak issues.

To sum up, the storage access affects the current tab only, not to the whole origin.

EDIT: Ok I just realized what you meant: indeed, since history can be manipulated dynamically, it becomes a sensible feature. As a work-around, maybe browsers could propagate storage access status to history entries, so that links opened by when the storage is accessible will force thoses links to be loaded with the storage enabled too. Anyway, they are already discussions about this with for instant Opaque Urls I think.

Another thing this would need is a way to update the website. I think that poses another challenge as you want to allow frequent updates for security reasons, but you do not want to allow it to be used as a communication channel of sorts.

Again, this is why this proposal suggests 2 services workers instances (the first with network access but no storage access, the second without network access but with storage access): the first one can update the cache safely as it don't have access to user data, and the second one can emulate a real API using cache and storage content, which would therefore be fully transparent for the main frame code.

[annevk]

So how do you trigger an update from the networkless context without leaking state?

[Minigugus]

So how do you trigger an update from the networkless context without leaking state?

@annevk You don't... 😅 Currently, service workers are already updated automatically by the browser, thus the automatic update of cached resources will still be possible (when the service worker is installaling, it runs in the context with network access, the switch to the networkless context when activated).
However, as you mentions, non-automatic updates (i.e. with manual user agreement) would require a different approach, but that should still be doable with multiple caches (the first service worker downloads updated resources in another cache and the second one only use the new cache when the user wants to update), or with a private cache storage (to be able to delete older versions, but this solution requires another change in browsers).
I agree that in some cases, this proposal introduce new privacy-oriented architecture (similar to the ownership and borrowing principles from the Rust world). I think reactions from the users and developers will determine the fate of this proposal.

[jkarlin]

Interesting. This is similar to the notion of a fenced frame that can get read-only storage access w/out a prompt and no network. And then if the user later wants to save state or something then they can use the standard rSA permission prompt.

I think it's preferable to perform this in a subframe (that starts off fenced) as opposed to the main frame of a page, since the main frame may not want to be network-less forever.

[Minigugus]

This is similar to the notion of a fenced frame that can get read-only storage access w/out a prompt and no network.

Interesting, I missed the issue you document you mentioned, thanks for the feedback 👍 Indeed, it's quite similar to what you mentioned, except the fact that the proposal presented here currently do not propose integration with unpartitionned storage, only traditional origin-restricted storage (I might be wrong about what is unpartionned storage thought).

I think it's preferable to perform this in a subframe (that starts off fenced) as opposed to the main frame of a page

I don't think so since this proposal requires the browser to inform the user that anything happening on the current frame while the browser UI is updated cannot be known or leave the browser. Moreover, this proposal do not require webbundles thanks to service workers.
As opposed to the fenced frame proposal, the goal here is not directly to limit user tracking across origins, but to offer a way to build complete websites without storing anything about the user server-side. I think the risk with only fenced frame is that only ads use them, not real world websites, especially if only web bundles are supported. Moreover, without updated browser UI, a user can easily be fooled by a phishing iframe that claim to be a fenced frame to the user. Finally, fenced frames do not play well with CDNs, again because of webbundles, even thought CDNs are not a problem for privacy when users data are stored client-side only.

the main frame may not want to be network-less forever.

By "main frame" I mean a top-level document like a tab or a popup. A main frame that don't want to loose its network access would still be able to open another main frame (popup or another tab) than then request network-less storage access. Therefore, it is also simpler for the user to understand what's happening.

[jkarlin]

Interesting, I missed the issue you document you mentioned, thanks for the feedback 👍 Indeed, it's quite similar to what you mentioned, except the fact that the proposal presented here currently do not propose integration with unpartitionned storage, only traditional origin-restricted storage (I might be wrong about what is unpartionned storage thought).

By unpartitioned storage I'm referring to origin-partitioned, but not top-site partitioned storage. E.g., third-party cookies and javascript storage.

I don't think so since this proposal requires the browser to inform the user that anything happening on the current frame while the browser UI is updated cannot be known or leave the browser. Moreover, this proposal do not require webbundles thanks to service workers.
As opposed to the fenced frame proposal, the goal here is not directly to limit user tracking across origins, but to offer a way to build complete websites without storing anything about the user server-side. I think the risk with only fenced frame is that only ads use them, not real world websites, especially if only web bundles are supported. Moreover, without updated browser UI, a user can easily be fooled by a phishing iframe that claim to be a fenced frame to the user. Finally, fenced frames do not play well with CDNs, again because of webbundles, even thought CDNs are not a problem for privacy when users data are stored client-side only.

Ah, sorry, I didn't catch that this was meant to support an offline app use case. In regards to fenced frames that don't have network access, we are considering allowing network access to caching-only servers from fenced frames that don't log user requests. That would help with the cdn case.

For the particular mode of fenced frame I am describing however, the fenced frame does have network until the frame accesses unpartitioned storage. So it's quite similar.

By "main frame" I mean a top-level document like a tab or a popup. A main frame that don't want to loose its network access would still be able to open another main frame (popup or another tab) than then request network-less storage access. Therefore, it is also simpler for the user to understand what's happening.

We're in agreement on main frame here. Multiple tabs/popups are pretty confusing for mobile users however.

[erik-anderson]

@Minigugus it doesn't look like there's been recent discussion on this. Is this something you're still interested in pursuing or should we close this?

[Minigugus]

@erik-anderson I've thought more about this and prefered creating a new issue, as they diverged too much. I think we can indeed close this one then, and redirect to #31 instead 👍