Re: [w3c/manifest] Make unbounded navigation scope less broad (#550)

Resurrecting this issue due to a discussion I had with Marcos in December, and now seems fairly urgent to resolve due to Safari launching manifest support on iOS.

[This article](https://medium.com/@firt/pwas-are-coming-to-ios-11-3-cupertino-we-have-a-problem-2ff49fd7d6ea) explains:

> Android browsers typically open URLs within the scope of the PWA context and other links in a browser or a Custom Tab. If you don’t specify the scope of the Web App Manifest, Android usually takes the folder of the manifest as the scope, which is generally the expected behavior.
>
> Safari will not define a default scope if not specified and if that’s the case, then EVERY link in your PWA will open inside your App’s iOS window. What’s the problem? It’s iOS, and there is no back button and no back gesture, so the user might end up locked in an external website you link. If you specify the scope, everything works as expected similar to Android, destinations out of the scope will open in Safari — with a back button (the small one in the status bar) to your PWA.

So what Android (Chrome) does is actually a violation of the standard, while what Safari apparently does seems to match the standard. Still, I think there are big problems with this which is why we discussed changing the standard last year to match Chrome.

I wrote up a detailed analysis last year, a result of a long discussion with @dominickng, which I have now made public:
https://docs.google.com/document/d/1Nq3dqT7ULrztGe2hhCwU12uSc3JONJNteh7sHSlNJlQ/edit

Note: We **did not** start off from a standpoint of trying to justify Chrome's behaviour; instead worked through all the options and ended up arriving at the same conclusion as @pkotwicz and his team. Below I will summarize the doc:

The scope needs to be well-defined for two distinct purposes:

1. "App context navigation" (kicking you out of the app context if you navigate out of scope), and
2. "Deep linking" (sucking you into the app context if you happen to click a link into the app scope).

The current specification is that if "scope" is not present, it defaults to a special value called "unbounded scope" which is fairly non-sensical. For app context navigation, it's implementable but silly: it means you will *never* get kicked out of the app context, even if you navigate off-origin. As explained by [this article](https://medium.com/@firt/pwas-are-coming-to-ios-11-3-cupertino-we-have-a-problem-2ff49fd7d6ea):

> Safari will not define a default scope if not specified and if that’s the case, then EVERY link in your PWA will open inside your App’s iOS window. What’s the problem? It’s iOS, and there is no back button and no back gesture, so the user might end up locked in an external website you link.

A counter-point to that is that the [spec recommends](https://www.w3.org/TR/appmanifest/#navigation-scope-security-considerations) that if you have unbounded scope and navigate off-origin, that the user be shown the location bar and possibly dropped into browser UI. But this recommendation essentially makes "unbounded" scope equivalent to the origin of the `start_url`. So why not get rid of the concept of unbounded scope, and just specify a proper default?

For deep linking, an unbounded scope is not implementable (it would imply that all links in the universe should be redirected into the app context of an app with unbounded scope).

Thus, we considered four alternatives:

1. Containing directory of the `start_url`.
2. Containing directory of the manifest URL.
3. Origin of the `start_url`.
4. Scope of the longest-prefix-match service worker controlling `start_url`.

You can read the pros and cons of each in [the doc](https://docs.google.com/document/d/1Nq3dqT7ULrztGe2hhCwU12uSc3JONJNteh7sHSlNJlQ/edit#heading=h.6alojs1974o3), but in short, we chose containing directory of `start_url` as it seems to be the least surprising, and some sites (e.g., CNET) already rely on this behaviour in Chrome.

Thus, the required changes to the manifest spec are:

* In the [scope processing algorithm](https://www.w3.org/TR/appmanifest/#dfn-post-processing-the-scope-member), replace all of the “undefined” error cases with returning the containing directory of `start_url`. This removes the concept of **unbounded** scope.
* The [navigation scope security considerations](https://www.w3.org/TR/appmanifest/#navigation-scope-security-considerations) for **unbounded** scope no longer apply. However, as an orthogonal change, allow out-of-scope navigations to occur within the app window but recommend the CCT-like UI that is currently recommended for off-domain navigations in unbounded-scope apps.
* The [deep links](https://www.w3.org/TR/appmanifest/#deep-links) section needs to be much better specified, explicitly specifying that the UA *may* instantiate an application context when it navigates to a URL in-scope.

I plan to put up a PR to change this shortly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/550#issuecomment-361129547