"best-effort" naming might be misleading

[domenic]

In particular, the JavaScript-visible API surfaces are not changed in a best-effort way. Instead this is referring to the potential behind-the-scenes process allocation logic.

I'm unsure how to thread this needle exactly. We kind of do want to allow this field to be used for implementation hints; see https://github.com/domenic/origin-isolation#string-based-enumeration. I think all of the proposed modes there would have the same observable effects, and would vary only on the way they hint to the implementation.

Potential ideas:

• Go with true for now, kind of punting on the problem. It's not a big deal if in the future we have an enumeration that is both string-or-boolean valued. E.g. true could mean something like "up to the browser to select from among the string-named variants".

• Lean harder into the implementation hint: e.g. name it "process-when-possible" or similar. Maybe it'll be clearer that "origin_isolation": "process-when-possible" causes origin isolation, of the particular flavor of asking for an isolated process when possible.

[domenic]

whatwg/html#5122 (comment) indicates that this whole proposal may end up working best as an implementation hint, in which case the explicitly implementation-hint-ish "process-when-possible" is starting to sound reasonable.

[annevk]

Can you sketch some examples where hints would result in the UA having a different strategy from its best effort? (And can the hints be used to create potentially dangerous setups?)

It sounds reasonable in the abstract, but I'm having some trouble figuring out who would give hints for what and why UAs would trust them over their own logic.

[domenic]

In Chrome, we have a balancing act between the number of allocated processes, and the desire for better isolation. The desire for better isolation has an additional dimension, once you start considering sites' desires for performance and memory isolation, in addition to security isolation. For example, security isolation still allows coalescing multiple same-origin top-level browsing contexts into a single process. But if you want performance isolation, or more-useful memory measurement, then you often want to be isolated even from other same-origin TLBCs.

Similarly, we have multiple technologies under consideration for performing isolation. There are efforts for "multiple Blink threads" and "multiple Blink isolates" which can give performance and memory isolation, as well as improved security isolation---but not the full, Spectre-protective security benefits of process isolation. (If I understand correctly.)

Finally, we have to deal with a range of form factors and devices, including resource-constrained ones where full site isolation for every site is not feasible. In such cases we're currently using heuristics like "does this page contain a password input" as a proxy for "should we use up one of our precious processes".

So in general, our best-effort heuristics don't really have enough information to go on, without some input from web authors. Such input might consist of answers to the following questions:

• How much do you care about protecting yourself from Spectre attacks?
• Do you expect to use a lot of memory, such that coalescing your heap with other documents' could start exceeding heap limits?
• Would you like to be performance-isolated from other documents (different event loop)?
• For all of the above three questions, does the answer differ between cross-site documents and cross-origin same-site ones?
• Do you plan to use the (proposed) process memory measurement API? (This is proposed to throw an exception if the browser is unable to restrict its measurements to only same-origin/CORPed resources, so planning to use it is a strong signal that you'd like memory isolation.)
• If you plan on using the process memory measurement API, would you prefer to exclude other same-origin TLBCs?

These sorts of hints could be used both for prioritizing process isolation in resource-constrained situations, and for deciding which isolation strategy to use, with regard to both same-origin TLBC coalescing and choice between process isolation vs. multiple threads.

BTW, writing out the above makes it clear that there is another approach, which is to have the website state answers to the above questions, instead of explicitly asking for a technology (like "process-if-possible"). That's probably better?