Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

[T K]

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 
> .
> - 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 
> ; plus some 
> technical 
> notes 
> 
> .
>
> On Wed, Jan 26, 2022 at 5:35 PM Daniel Bratell  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  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/1

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain

[T K]

Hi,
Do you know if there is  a way to get a Chrome version with those changes 
to see how those changes impact my site?
Thanks

On Friday, January 14, 2022 at 8:06:58 PM UTC+2 sligh...@chromium.org wrote:

> Daniel: 
>
> Salesforce use is concentrated in enterprises, and the enterprise opt-in 
> rates for metrics and crash reporting are very, very, very low. As a 
> result, I'm not sure we should trust UKM here. 
>
> Greg: 
>
> Thanks so much for looking into your code. I know it might take time for 
> your larger ecosystem to start sending y'all deprecation reports. How long 
> after the deprecation API starts reporting do you think it'll be before we 
> can get solid information from your service?
>
> Thanks.
>
> On Friday, January 14, 2022 at 5:17:25 AM UTC-8 Daniel Vogelheim wrote:
>
>> On Fri, Jan 14, 2022 at 1:46 AM Greg Whitworth  
>> wrote:
>>
>>> Hey folks,
>>>
>>> I'll be spinning up a thread with some internal folks here at Salesforce 
>>> to start doing some scans of code to determine utilization. Has this been 
>>> added to the reporting API for deprecation to possibly capture live hits 
>>> that way as well?
>>>
>>
>> Not yet. That'd be the first step once this intent is approved. 
>>
>>>
>>> I'll follow up on what I find and that will influence my opinion on 
>>> removal timeline.
>>>
>>
>> Thank you, this would be very helpful.
>> If it helps: salesforce.com (or other Salesforce country domains) do not 
>> show up in our telemetry, so with some likelihood you're among the >99% 
>> sites that do not even use this mis-feature. :-)
>> (Caveat: You might use other domains as well; or maybe your customers 
>> dis-proportionally disable reporting.)
>>
>> If you have a staging environment, you can simulate the deprecation by 
>> adding the "Origin-Agent-Cluster: ?1" header. This explicitly enables 
>> clustering by origin. document.domain setting will have no effect, and a 
>> console message will be printed. (In other words: This is behaviour we'd 
>> like to be the default.)
>> If you do find usage that you cannot easily replace, adding 
>> "Origin-Agent-Cluster: ?0" will disable this.
>>
>>
>>> ~Greg
>>>
>>> On Thursday, January 13, 2022 at 3:35:03 PM UTC-8 Charlie Reis wrote:
>>>
 Note that Daniel has already landed the enterprise policy for this in 
 https://chromium-review.googlesource.com/c/chromium/src/+/3317349 
 (99.0.4759.0).

 Charlie

 On Thu, Jan 13, 2022 at 2:32 PM Brandon Heenan  
 wrote:

> > This probably requires an Enterprise Policy, to reduce the risk for 
> managed installs. +bheenan@ for opinions on that front.
>
> I agree, this looks like a breaking change according to 
> go/chrome-enterprise-friendly and therefore needs a policy. 
> Instructions for implementing a policy are here: 
> https://source.chromium.org/chromium/chromium/src/+/main:docs/enterprise/add_new_policy.md
>  
> if you haven't done it before, and the enterprise team is happy to help 
> if 
> anything seems confusing. Having this implemented as a "soft removal" 
> with 
> a temporary policy escape hatch significantly reduces enterprise risk, 
> since even if we are surprised by a use case hiding behind many 
> enterprises' tendency to turn off metrics, those users can 
> break-fix themselves immediately while staying on the latest version.
>
> On Wed, Jan 12, 2022 at 12:45 PM Yoav Weiss  
> 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.
>>- 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?
>>- 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 
>>>