search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
7.96k stars 2.6k forks source link

What kind of new 'session' is created on manual navigation? #6356

Open jakearchibald opened 3 years ago

jakearchibald commented 3 years ago

Some APIs and behaviours span across multiple session entries. But, if the page is navigated to a new entry by a means out of the current page's control (user enters something into the URL bar, selects a bookmark etc etc), which of these behaviours should continue across into the new page?

I'm going to refer to that type of navigation as "manual".

WindowProxy window references

  1. PageA uses window.open to open PageB in a new session.
  2. PageB's session is manually navigated to PageC.

Does PageA hold a reference to PageC?

Chrome: No if PageC is on a different origin to PageB, otherwise yes (unless PageC is cross origin isolated via COOP/COEP). Firefox: Yes, unless PageC is cross origin isolated via COOP/COEP Safari: Yes

Ideal behaviour: This was discussed in https://github.com/whatwg/html/issues/5767#issuecomment-763855860, and consensus was that PageA should not hold a reference to PageC in the cross-origin case, and this should be achieved by creating a new BCG for PageC. Although, it isn't yet clear what should happen to the reference PageA has, or what should happen if PageC's session is navigated back to PageB. We didn't discuss the same-origin case.

history.back and history.length

  1. PageA's session is manually navigated to PageB.

Can PageB navigate its session back to PageA using history.back? Is history.length greater than 1?

All browsers: Yes.

Ideal behaviour: ???

It feels like a minor security and privacy benefit to treat PageB as part of a new sub-session, that cannot observe or control history entries that came before it. Whether this differs if PageA and PageB are same-origin probably depends on what we do for the previous example.

Chrome already blocks history.back() in some cases, eg when it's called from a sandboxed iframe and the navigation would happen outside the iframe. I guess even a navigation within the sandboxed iframe impacts history.state in the parent, but we already know the history API is bad.

sessionStorage

  1. PageA has some session state.
  2. PageA's session is manually navigated to PageB.
  3. (if necessary) Use location.href to navigate back to PageA's origin.

Can the resulting page access the session state set in PageA?

All browsers: Yes.

Ideal behaviour: ???

It feels like the answer here should be the same as it is for history.back.

Related: Session storage and changing browsing contexts.

cc @annevk @domenic since we've already been talking about this stuff cc @mikewest anyone from security interested in weighing in here?

mikewest commented 3 years ago

Poking folks who know things, and who might be interested in weighing in.

asakusuma commented 3 years ago

Another similar scenario is "right click link, open new tab." For same-origin scenarios, it would be helpful for the origin and destination page to have references to each others WindowProxy objects. Consider a search page, with a bunch of results. Users will often scroll through and right click, new tab all the results that look interesting. From a UX perspective, all of the tabs are part of the same activity, a user searching, and it's helpful to be able to share state. Right now, I believe the best to handle this is to use query params with some identifier as lookup key in persistent storage. But nobody likes query params in their urls.

jakearchibald commented 3 years ago

@asakusuma I guess a service worker could create that association. Also, we've thrown around the idea of having some sort of clients API outside of service workers.

tabatkins commented 3 years ago

Purely from a personal perspective, I feel strongly that manual navigation should create an entirely new session. Typing into the URL bar should be semantically identical to closing the tab, opening a new tab, and then typing into the URL bar. Anything less than that is at least a privacy leak, and possibly a security leak, imo.

(At least when the new page is cross-origin. I don't have strong opinions on same-origin.)

ArthurSonzogni commented 3 years ago

Yes, I believe every "manual" navigation (Bookmarks, address bar, ...) should start a new Browsing Context Group. WindowProxy window reference shouldn't cross two Browsing Context Group, they should be closed. It would be lovely if the history seen from the new document and the SessionStorage could start from scratch.

WindowProxy window references

I filled several security issues against Chrome and Firefox in the past. They contains many useful informations that you can check out:

In Chrome (and I believe in Firefox too), we severe the WindowProxy relationship whenever we enter a new Browsing Context Group. I do believe we should continue to this way. That's even part of the specification for COOP+COEP.

In Chrome, this happens for:

More informations in RenderFrameHostManager::ShouldSwapBrowsingInstancesForNavigation(...)

I do believe we would like to always swap Browsing Context Group for "manual" navigation. This is tracked in https://crbug.com/1044951 and I believe +@carlscabgro was interested implemented this.

The main issue: If users navigate back, we won't be able to restore the WindowProxy correctly. Once it's broken, it's broken. That's why we sometimes require having no related Browsing Context before swapping Browsing Context Group. I do believe this is not a huge problem, compared to what we gain from a security perspective. COOP+COEP is a precedent into the specification about not restoring WindowProxy. So I believe this is now easier to go further into this direction.

history.back and history.length

Yes, this would be better to start them from scratch when entering a new Browsing Context Group. The new document shouldn't be able to history.back() across them. However the user should still be able to navigate back across several Browsing Context Group.

jakearchibald commented 3 years ago

@ArthurSonzogni

The main issue: If users navigate back, we won't be able to restore the WindowProxy correctly. Once it's broken, it's broken.

Yeah, I'm pretty sad about that. Some of that was discussed in https://github.com/whatwg/html/issues/5767#issuecomment-763855860. I'd prefer it if 'back' worked here, but it's not a hill I want to die on.

Yes, this would be better to start them (history and session storage) from scratch when entering a new Browsing Context Group.

That was my original thinking, but I think it conflates two things.

  1. User is on PageA
  2. User clicks link which takes them to PageB, which is cross-origin isolated
  3. User clicks link which takes them to PageC, which is on the same origin as PageA and is not cross-origin isolated

In this case all three pages exist in their own browsing context group (yeah?), but since all navigation was controlled by web content, I'd consider it to be part of the same browsing session. PageC would have access to the same sessions storage as PageA, and history.back() would work for both PageB and PageC.

In terms of modeling this, a browsing context group is part of a session, but multiple browsing context groups may exist within the same session. Does that make sense?

annevk commented 3 years ago

One thing I'd like to see clarified in this discussion is whether "manual" is "all manual" or "cross-origin manual". If a user manipulates a path or some such they might not expect to lose session history. (Otherwise I'm mostly aligned with Jake I think, except for restoring WindowProxy. Popups are the worst. 😊)

jakearchibald commented 3 years ago

Proposal: When the user manually navigates from PageA to PageB, which have different origins:

When the user manually navigates from PageA to PageB, which are in the same origin, the behaviour is the same as clicking a link to PageB in terms of the above behaviours. This preserves the 'hackability' of URLs as a form of navigation.

Modelling the above:

A set of contiguous entries in joint session history form a 'session'. There may be multiple sessions within joint session history, but they are always contiguous.

Session storage is associated with a session. If the user navigates into a new session, they get a new session storage.

history.back() and history.forward() are no-ops if they would navigate a navigable into a new session. history.length is the number of history entries in that session. The browser's history controls (back/forward buttons etc) may traverse to history entries with a different session.

Clicking a link in a page creates a history entry in the same session, although it may exist in a different browsing context group due to cross origin isolation etc.

Manual navigations to same-origin URLs behave the same as clicking a link in a page.

@ArthurSonzogni @annevk does that work? Any idea who should weigh in from WebKit?

Manual navigations to cross-origin URLs create a history entry with a different browsing context group and new session.

smaug---- commented 3 years ago

If PageA has been originally opened using window.open() from Page0, what happens to the reference in Page0? So basically the same question which is mentioned in the initial comment.

jakearchibald commented 3 years ago

@smaug---- I think that depends on whether navigating back to PageA should restore its connection with Page0. There's some discussion of that in https://github.com/whatwg/html/issues/5767#issuecomment-764498949, but I don't think we need to decide that before getting consensus on the 'manual navigation' stuff.

If we decide that manual navigation creates a new 'session', and therefore new browsing context group, then the window proxy behaviour will be the same as an in-page navigation to a cross-origin isolated page.

tabatkins commented 3 years ago

When the user manually navigates from PageA to PageB, which are in the same origin, the behaviour is the same as clicking a link to PageB in terms of the above behaviours. This preserves the 'hackability' of URLs as a form of navigation.

Yes, upon further thought I realized I did have strong opinions about same-origin, and wanted it to do exactly this, so that I could navigate myself around a site by hacking the url.

JakobJingleheimer commented 3 years ago

I think manual navigation is irrelevant:

If a user is on PageA and manually updates the URL in the address bar but maintains the same origin, history should persist (with the new entry added, length increased by 1, etc).

jakearchibald commented 3 years ago

@JakobJingleheimer compared to my proposal, you're asking for session history to limited further (in a way that's likely incompatible with the current web), and session storage to be limited less. Can you explain how this asymmetry makes sense to the user and how it benefits them?

JakobJingleheimer commented 3 years ago

With the web moving more and more toward application-like use, a window is essentially a container for an application and a tab is a workspace. Different views of the app need access to common resources, like the app's session (eg sessionStorage).

A user would expect limited isolation within the workspace: "undo" in workspace 1 should not spill over into workspace 2.

Anything within the same origin seems fair game to that origin—it already knows what happen before, so why make it more difficult?

I think something like a hard refresh (instead of a soft refresh) should reset history (as it resets everything else), but manually updating the URL seems just another (perhaps, advanced) way of interacting with the current context. If a user happens to know the route they need is /foo/bar and it's easier to update the address bar, that seems equivalent to clicking a link to /foo/bar, no?

jakearchibald commented 3 years ago

@JakobJingleheimer I'm worried this discussion is going to derail the thread. Let's discuss it over here. We'll report back here once we reach a conclusion.

rakina commented 3 years ago

This might be a separate question, but should crossing different COOP+COEP contexts cause a session change, or do we only change sessions on manual navigations?

I'm asking this because I think we have different levels of "browsing context group swaps" in Chrome: "proactive" and "mandatory". We will try to do proactive BCG swaps whenever possible (if there are no opener relationships), and this includes same-origin navigations. Meanwhile "mandatory" BCG swaps happen when crossing different COOP+COEP contexts and other security-related stuff.

I think it might make sense to make all "mandatory" BCG swaps to do session swaps also, since there are some stuff that proactive BCG swaps shouldn't do (especially on same-origin navigations):

WindowProxy: seems OK to sever on all BCG swaps, and as Arthur mentioned, Chrome is working on this. history.back() and history.length: this should still work after proactive BCG swaps, so we should block only when session changes. sessionStorage: same as history, this should still work after proactive BCG swaps, so we should block only when session changes.

annevk commented 3 years ago

My preference is to only reset the scope of the History API and session storage (not the back button though) on manual navigations.

jakearchibald commented 3 years ago

Agreed. BCG swaps ensure we don't put no-cors resource bodies in the same process as isolated pages. Sessions as described in this issue are something different. History entries can be part of the same session but their contexts can be in different processes.

jakearchibald commented 3 years ago

@rakina I created a little presentation to explain my thinking here, the relevant part starts 3:42 https://youtu.be/nZb0U3rFQXw?t=222

rakina commented 3 years ago

OK, so BCG might change and session stays the same. But if session changes BCG will always change. Yeah I think it's reasonable to reset sessionStorage and history API on session changes, and it's more conservative than resetting on BCG swap, which is good. Thank you!

domenic commented 3 years ago

FYI https://github.com/whatwg/html/issues/5381 is the issue for clearly speccing this.

domenic commented 2 years ago

It's not 100% clear to me what our proposed preferred behavior is for the same-origin case. This is relevant to https://github.com/whatwg/html/issues/7533 because our current spec and flagged implementation in Chromium for URL bar prerendering causes a BCG swap. (I.e., it creates a new prerendering browsing context in its own separate BCG, and then upon activate, it activates that BC/BCG in place of the old one.) We do this regardless of same-origin or cross-origin.

So concretely:

Without prerendering for https://example.com/foo: the opener relationship will be preserved. With prerendering: it won't be.

Is that OK?

annevk commented 2 years ago

That seems rather surprising. I guess ideally we'd always swap, but I'm not sure how feasible that is.

jakearchibald commented 2 years ago

Btw, this definition of a session can span multiple BCGs