Bug 199641 - LocalStorage in ephemeral session should be isolated per tab
Summary: LocalStorage in ephemeral session should be isolated per tab
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Sihui Liu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-09 14:40 PDT by Sihui Liu
Modified: 2019-08-02 14:01 PDT (History)
3 users (show)

See Also:


Attachments
Patch (6.00 KB, patch)
2019-07-09 15:04 PDT, Sihui Liu
ggaren: review-
ews: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews122 for ios-simulator-wk2 (2.78 MB, application/zip)
2019-07-09 16:45 PDT, Build Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Sihui Liu 2019-07-09 15:04:40 PDT
Created attachment 373771 [details]
Patch
Comment 2 Build Bot 2019-07-09 16:45:24 PDT
Comment on attachment 373771 [details]
Patch

Attachment 373771 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: https://webkit-queues.webkit.org/results/12702358

New failing tests:
storage/domstorage/localstorage/private-browsing-affects-storage.html
Comment 3 Build Bot 2019-07-09 16:45:25 PDT
Created attachment 373792 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122  Port: ios-simulator-wk2  Platform: Mac OS X 10.14.5
Comment 4 Peter Thomson 2019-07-15 03:28:28 PDT Comment hidden (obsolete)
Comment 5 Geoffrey Garen 2019-07-18 11:18:38 PDT
Looks like EWS found a failure in storage/domstorage/localstorage/private-browsing-affects-storage.html.

I tend to agree that LocalStorage in an ephemeral session should be similar to SessionStorage. But why does that mean that every new window should get its own StorageNameSpace? I would expect every session to get its own StorageNameSpace, not every window.
Comment 6 Sihui Liu 2019-07-19 12:07:23 PDT
(In reply to Geoffrey Garen from comment #5)
> Looks like EWS found a failure in
> storage/domstorage/localstorage/private-browsing-affects-storage.html.
> 
> I tend to agree that LocalStorage in an ephemeral session should be similar
> to SessionStorage. But why does that mean that every new window should get
> its own StorageNameSpace? I would expect every session to get its own
> StorageNameSpace, not every window.

That seems to be specified by the spec: https://www.w3.org/TR/webstorage/#the-sessionstorage-attribute.
Comment 7 Geoffrey Garen 2019-07-19 12:21:15 PDT
> > I tend to agree that LocalStorage in an ephemeral session should be similar
> > to SessionStorage. But why does that mean that every new window should get
> > its own StorageNameSpace? I would expect every session to get its own
> > StorageNameSpace, not every window.
> 
> That seems to be specified by the spec:
> https://www.w3.org/TR/webstorage/#the-sessionstorage-attribute.

I see: SessionStorage is specified to be per-tab (per-top-level-browsing-context).

Even though LocalStorage in an ephemeral session is similar to SessionStorage, I think it would be best if LocalStorage did not mimic the per-tab behavior. Mimicking the per-tab behavior creates a difference in behavior between ephemeral and non-ephemeral sessions.

One downside to this difference in behavior is that it might cause website incompatibilities (since the website might expect two tabs or windows to be able to see each other's LocalStorage.)

Another downside is that it gives websites a way -- admittedly an obscure way -- to notice and discriminate against ephemeral sessions, which is a privacy issue.

What is the current behavior of LocalStorage in an ephemeral session?

What would it take to make LocalStorage per-session in an ephemeral session?
Comment 8 Sihui Liu 2019-07-19 13:55:52 PDT
(In reply to Geoffrey Garen from comment #7)
> > > I tend to agree that LocalStorage in an ephemeral session should be similar
> > > to SessionStorage. But why does that mean that every new window should get
> > > its own StorageNameSpace? I would expect every session to get its own
> > > StorageNameSpace, not every window.
> > 
> > That seems to be specified by the spec:
> > https://www.w3.org/TR/webstorage/#the-sessionstorage-attribute.
> 
> I see: SessionStorage is specified to be per-tab
> (per-top-level-browsing-context).
> 
> Even though LocalStorage in an ephemeral session is similar to
> SessionStorage, I think it would be best if LocalStorage did not mimic the
> per-tab behavior. Mimicking the per-tab behavior creates a difference in
> behavior between ephemeral and non-ephemeral sessions.
> 
> One downside to this difference in behavior is that it might cause website
> incompatibilities (since the website might expect two tabs or windows to be
> able to see each other's LocalStorage.)
> 
> Another downside is that it gives websites a way -- admittedly an obscure
> way -- to notice and discriminate against ephemeral sessions, which is a
> privacy issue.
> 
> What is the current behavior of LocalStorage in an ephemeral session?
> 
It's basically isolated across tabs. The only issue is when we use window.open in ephemeral session, the new window uses the same localStorageNameSpace as its parent.
This patch is trying to make the behavior consistent.

> What would it take to make LocalStorage per-session in an ephemeral session?
We can associate localStorage on different tabs to the same LocalStorageNameSpace in network process, like by making all pages use same LocalStorageNameSpaceID.

We will also need a way to recover localStorage for ephemeral session if network process crashes. Currently we get data from web process because localStorage of the web page is only accessed by that page.
Comment 9 Geoffrey Garen 2019-07-19 16:13:36 PDT
> We will also need a way to recover localStorage for ephemeral session if
> network process crashes. Currently we get data from web process because
> localStorage of the web page is only accessed by that page.

If we wanted to recover ephemeral data after network process crash:

We could try to design a message to accumulate all the data from all web processes eagerly in order to try to recover.

Or we could store the data on disk, but with an encryption key that is only known in memory in the network and web processes.

But:

It's not generally our strategy to do that. It's kind of an edge case. And there's lots of other data you lose at the same time, like session cookies and in-flight transactions, and in-flight network connections. All of these things might break a webpage and force you to reload. Our main strategy here is just to crash the network process really really infrequently. (Perhaps we could do better in this design. But that's probably a broader question than just LocalStorage.)
Comment 10 Geoffrey Garen 2019-07-19 16:16:32 PDT
I think LocalStorage in an ephemeral session should use PageGroupID (i.e., always the same thing) as its StorageNamespaceID, just like it does for non-ephemeral sessions.
Comment 11 Sihui Liu 2019-08-02 14:01:07 PDT
Talked to Geoff, we should do the opposite, making LocalStorage in ephemeral session the same behavior as in persistent session, which is not isolated per page.