Bug 199641

Created attachment 373771 [details] Patch

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

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

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.

(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.

> > 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?

(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.

> 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.)

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.

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.