Feature request: "isolate web app" hint

[mgiuca]

Feature request: "isolate web app" hint

[aarongustafson]

I like the proposal. I do find "no_isolate" awkward, however. If we want to be explicit with the values, maybe "isolated” vs. " not_isolated" or "isolated" vs. "shared"? Or it seems like we could have the values be "true" and "false" or "yes" and "no" as the property name itself is pretty explicit.

[kenchris]

Anyway, it should be "not-isolated" with - and not underscore

[marcoscaceres]

It doesn't seem one would need "no-isolate" or "auto", IMO. Why not just declare the app_mode (or something) instead:

{
    "app_mode": "isolated"
}

If not present, it's the same as "auto" (user chooses). There is no case, IMO, where "no-isolate" makes sense, because in theory it's a user's choice to isolate the web app. Having "app_mode": "isolated" forces that choice on the user, but otherwise nothing else should be needed because by default no isolation happens (or a UAs doesn't support it, which again invalidates the need for "no-isolate").

[mgiuca]

Putting syntax aside, it seems the main contention of Marcos' comment is: whether or not an explicit "don't isolate" option makes sense (distinct from a default value of "don't care"). Since this is just a hint, a value of "don't isolate" will not be contractually binding anyway, so we could argue that "don't isolate" and "don't care" will be roughly equivalent.

We can imagine four possible implementations:

1. Never isolates no matter what (ignoring this field). e.g. current Chrome.
2. Always isolates no matter what (ignoring this field). e.g. current macOS.
3. Doesn't isolate by default, but does isolate apps if they request it in the manifest. e.g. what we are tentatively planning for ChromeOS.
4. Isolates by default, but does not isolate apps if they opt out it in the manifest.

The reason why this field is useful (and not just isolating all apps) is because we know that isolation can break some apps if they depend on interaction with other origins. For now, we are planning to let sites opt in to this potentially breaking behaviour, letting them test to make sure everything still works before turning this on.

The question here is: do we ever foresee a use for 4? For now, no such implementation is planned. But I could imagine we'd get to a point where we want to turn on isolation by default, but give apps an opt-out in case they are broken. For that reason, I think there is value in making this a three-value enum. (Or, a two-value enum, with the ability to add a third "don't isolate" value later if we want to implement 4.)

On the syntax (which is in the territory of bikeshedding but we can get into it here): I think if we're going to only have "isolate" or "don't care" then I would probably stick with a Boolean with false as the default. The enum was an attempt to give us a 3-way choice of "isolate", "don't isolate" and "don't care". Let's figure out whether we want an explicit opt-out option first, then circle back to the syntax.

[marcoscaceres]

I don't think some user agents would ever give that choice. I think the expectation from the WebKit side is that they are always isolated (if I've understood what that means correctly). I don't see a world where there would be an expectation for a website to not be isolated when installed. That they share state with the browser is not something they can ever depend on, particularly because installing can mean that the apps themselves are treated as running in an entirely different user agent.

[marcoscaceres]

I guess the opposite is worth considering: would a "no-isolate" put a user agent in a situation where they might end up having to implement that for compat reasons, where right now we live is a world where there is no expectation that an app will or won't be isolated.

And, to frame this differently, what's the value that users get from "no-isolate" that would motivate a user agent to support that? In the above, you mentioned that "we know that isolation can break some apps if they depend on interaction with other origins."

That's going to be the case regardless on MacOS/Safari, right? So I wonder if we should address that problem instead, which would solve that for everyone?

[mgiuca]

None of this is supposed to be binding (it's just a hint), so we shouldn't get into a situation where a site can depend on "no-isolate" to guarantee that there won't be isolation.

Of course we need to be worried about de facto standards, e.g. what if a giant browser implements Policy 4 above, and it becomes de facto that "no-isolate" is respected, and a website using "no-isolate" makes an assumption that it won't be isolated?

Well we can't be concerned about that because today, all browsers except Safari implement Policy 1, which means all sites today can (and do) assume no isolation. So introducing "no-isolate" doesn't give sites a new assumption that they can't already make today.

what's the value that users get from "no-isolate" that would motivate a user agent to support that? ... That's going to be the case regardless on MacOS/Safari, right?

The value would be that sites have a way to opt out of isolation for at least some browsers (but not Safari, which implements Policy 2 today). I see your point though: today we have no isolation option, we just have Safari implementing Policy 2 which breaks some sites. Today, there's impetus for sites to fix themselves to work in Policy 2 browsers. If we add "no-isolate" then sites may simply use that (fixing themselves for Policy 4 browsers) instead of properly being compatible with isolation.

The other side of this is that Policy 2 and 4 essentially violate the body of web standards as written (you can view the installed context as a "separate browser", but that "other browser" is broken in that it forwards all URLs outside of the app scope to the main browser, which breaks sites existing valid expectations based on what's written in the standards). Policy 4 would at least give sites a way to opt out of that broken behaviour.

I think the best course of action here is to not specify "no-isolate" (since it won't have any meaningful difference to "auto" in all known browsers), but choose a syntax that allows us to add it in the future if desired.

So I wonder if we should address that problem instead, which would solve that for everyone?

I assume by "address that", you're referring giving sites tools like being able to specify which URLs to handle within the app context, etc. I'm in favour of that. It may be the case that we don't need the opt-out if we can give sites tools to work properly when isolated.

[alancutter]

Nit: Don't forget to accept a list of strings for forwards compatible fallback behaviour.

[mgiuca]

I thought about that (the "list of strings" advice coming from our previous problem with extending display and having to add a new display-override member to allow sites to fall back to an existing one). I don't think it's necessary in this case - we aren't creating a potentially-ever-growing list of options, just a boolean (possibly with a tri-value "yes", "no", "unspecified default").

If we decide to not include "no-isolate" but keep it as an option for the future, we don't need a fallback chain, because "no-isolate" will implicitly fall back to the default, which is to not isolate, except for Policy 2 which doesn't give the site a choice.

[marcoscaceres]

Right, but wouldn't it be safer for developers to assume that they will be isolated? I don't foresee any situation (or if it would even be feasible for WebKit) to not isolate. So, "no-isolate" would never be helpful for developers.