pastarmovj@, what do you think about this bug?  Is this the right time to move forward?  Are there any special prerequisites for moving forward (e.g. some kind of deprecation period and/or communicating the changes to the enterprises?).

Assigning to desktop PM to lead conversation about deprecating the policy.

RE: #c2:

Just a small clarification:

1. SitePerProcess enterprise policy may be used to
   1.1. disable Site Isolation (by explicitly setting the policy to false)
   1.2. force-enable site-per-process mode of Site Isolation
        (by explicitly setting the policy to true)
        - this is usually a no-op, because site-per-process is already
          a default on desktop since M67
        - the only scenario where this is not a no-op is forcing Site Isolation
          for users who attempt to opt-out via
          chrome://flags/#site-isolation-trial-opt-out

2. IsolateOrigins enterprise policy may be used to
   2.1. disable Site Isolation (by explicitly setting the policy to an empty list of origins)
   2.2. add *additional* origins that should be isolated by Site Isolation

This bug is about removing support for 1.1 and 2.1.
This bug is NOT about removing the policies altogether.

lukasza, I don't understand 2.2... If force-enabling site-per-process is a no-op (as per 1.2), wouldn't adding sites explicitly also be a no-op?

I actually read this as we *should* remove the policies altogether. If they only have a security-increasing effect when users modify flags, they're really not doing much. Admins who wish to prohibit users from modifying behavior using flags should probably do that wholesale by blacklisting chrome://flags

site = eTLD+1 (e.g. example.com or example.co.uk)
origin = any origin (e.g. corp.example.com or prod.example.com)

site-per-process is turned on by default since M67.  Isolating additional, sensitive origins requires explicit opt-in via IsolateOrigins (2.2. above).
With site-per-process the same renderer process may be shared by mail.example.com and corp.example.com.  Enterprise admins may use IsolateOrigins policy to ensure that mail.example.com and corp.example.com never share a renderer process.

Therefore, IsolateOrigins has a security-increasing effect even when users don't modify any flags.  I agree that the value of SitePerProcess policy is low - it only has a security-increasing effect if users use chrome://flags (or cmdline switches) to disable site-per-process.

Ah, got it. Thanks. Re questions in Comment #1:

Full details at: https://sites.google.com/a/chromium.org/dev/developers/enterprise-changes


Please provide 3 milestones of notice before the change ships to stable. I can help you get this added to the M72 enterprise release notes (since M71 is already going out), which would allow you to target the change for M75. That work?

Typically, we ask that you include a policy to temporarily revert disruptive changes for a period of time. Looks like that doesn't really apply here, since you're asking about removing the policy that did exactly that.

+blumberg as FYI, since we were in touch about the enterprise policies for this earlier this year.

Also, let's be clear in the messaging that this is about the desktop policy and not the equivalent Android policy, which will continue to be available to enable or disable for the time being.

Comment 7: Agreed that this is about ending the temporary policy for reverting the disruptive change (Site Isolation), now that it has been live for several milestones (M67).

-blumberg
+privard :)

I've send out an email to chromium-enterprise@chromium.org - see here: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-enterprise/t3SVLDIEwEg

Re-assigning to bheenan@ who will help cover the deprecation in enterprise release notes for M72 (I hear that the work on release notes will happen in 3-4 weeks from now - so setting NextAction field as appropriate).

FYI this is now included in the M72 enterprise release notes draft

The NextAction date has arrived: 2019-01-02

The tentative plan for branching M75 is end of April - let's look at that bug again at that time.

Great, next action will be M75 then (though the upcoming notice will be repeated in release notes from now until then).