Hi , 
When will the Enterprise Policy be released, and how it will look like?
For on premise customers patching the system, it is a long process that 
might take more than M106 (around September)  
Thanks, 
Tuvia.


On Monday, February 14, 2022 at 7:28:18 PM UTC+2 Daniel Vogelheim wrote:

> Hi all, just a brief update:
>
> - The warning should go live on M100 
> <https://chromiumdash.appspot.com/schedule?mstone=100>.
> - Flipping the default is planned for M106 but there'll be a 
> separate intent (and thus additional discussion), as requested.
> - A deprecation warning for cross-domain access (based on previous 
> document.domain setting) is in the works, and will either make it to M100 
> also, or will land shortly after.
> - Additional info: Blog post 
> <https://developer.chrome.com/blog/immutable-document-domain/>; plus some 
> technical 
> notes 
> <https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/document-domain.md>
> .
>
> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell <brat...@gmail.com> wrote:
>
>> LGTM3
>>
>> /Daniel
>> On 2022-01-14 13:58, Daniel Vogelheim wrote:
>>
>> Hi all,
>> Hi Yoav,
>>
>> Thanks for the feedback. I'd like to modify the intent timeline as 
>> follows:
>>
>> M99: Start showing a deprecation warning.
>> M99-105: Watch use counters + outreach to top-N users.
>> M105: Deprecate the feature by default.
>>
>> Enabling/disabling will be via Finch, so we have an emergency shut-off.
>>
>> An enterprise policy is already in place.
>>
>> On Wed, Jan 12, 2022 at 6:45 PM Yoav Weiss <yoav...@chromium.org> wrote:
>>
>>> Hey Daniel! 
>>>
>>> While searching for this intent review, I stumbled upon 
>>> https://developer.chrome.com/blog/immutable-document-domain/ 
>>> That's a useful piece of documentation! Thanks +Eiji Kitamura!!
>>>
>>> This intent was just discussed at the API owner meeting (where Chris, 
>>> Rego, Daniel, Philip, Alex, MikeT and myself were present).
>>> This change seems risky in terms of potential breakage when looking at 
>>> our stats, and that's even before talking about enterprises, where a lot of 
>>> the API owners feel the risk is even higher.
>>>
>>> Given that, here's a few potential next steps to try and reduce that 
>>> risk:
>>>
>>>    - UKM and outreach to specific large users of the API can maybe help 
>>>    drive the usage down. 
>>>
>>>
>> Will do. With Lutz' help I just checked the UKM we have on this, and it 
>> seems the usage is quite heavily concentrated on large sites. The 
>> top-quartile of remaining public usage is just 9 sites; top-half is ~35. 
>> We'll try to reach out to them.
>>  
>>
>>>
>>>    - A deprecation period of 3 milestones feels a bit short here. Is 
>>>    the expectation that turning on the opt-out header can be done under 
>>> that 
>>>    period? 
>>>
>>> As above, we'll happily go up on this.
>>
>> My reasoning why 3 milestones would be reasonable was that there is a 
>> "safe" opt-out. That is, if one wishes to preserve old behaviour, or isn't 
>> sure, or just wants to postpone the issue, one can just add 
>> 'Origin-Agent-Cluster: ?0" and deal with it later. This is quite different 
>> from e.g. CSP, where adding new CSP headers might require a lot of work and 
>> testing.
>>  
>>
>>>
>>>    - A report-only mode could have allowed sites to try and enable 
>>>    this, without risking actual breakage for their documents/properties 
>>> that 
>>>    use document.domain. This is doubly true for platforms that want to warn 
>>>    their customers about this upcoming deprecation, but without taking 
>>> risks 
>>>    on their behalf. At the same time, it is true that they could collect 
>>>    deprecation reports (thanks for adding those!) instead during the 
>>>    deprecation period, which can be considered an on-by-default report-only 
>>>    mode. Can y'all add specific guidance on deprecation reports to the 
>>>    documentation? 
>>>
>>>
>> We see the deprecation warning - without any behavioural changes - as 
>> effectively being the report-only mode. We'll be more clear in the 
>> documentation.
>>  
>>
>>>
>>>    -  It'd be helpful to reach out to enterprise folks and see what 
>>>    their responses may be for this. +Greg Whitworth.
>>>    - This probably requires an Enterprise Policy, to reduce the risk 
>>>    for managed installs. +bheenan@ for opinions on that front. 
>>>
>>> I agree, and an enterprise policy is already in place.
>>  
>>
>>>
>>>    - Is there a plan to eventually remove the opt-out option? Or is it 
>>>    the plan to have it in place permanently?
>>>    
>>>
>> There is no plan. The current logic is relatively easy to maintain, so we 
>> have not made any plan to remove the opt-out.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1e6e989a-3e73-4b04-8112-c999522a6a88n%40chromium.org.

Reply via email to