Re: [blink-dev] Re: Intent to Experiment: User Agent Reduction Origin Trial

[Noah Lemen]

Are there any plans to extend this Origin Trial? We (Meta) are considering 
using it to test the impact of UA reduction, but just noticed that its "end 
date" is tomorrow, and was marked with availability ending after version 
103.
On Thursday, October 14, 2021 at 5:29:45 PM UTC-4 abe...@chromium.org wrote:

> Just an FYI, the blog post has been updated to give instructions on how to 
> participate in the User-Agent Reduction Origin Trial as a third-party 
> embed: 
> https://developer.chrome.com/blog/user-agent-reduction-origin-trial/#how-to-participate-in-the-origin-trial-as-a-third-party-embed
>
> On Tue, Sep 14, 2021 at 9:39 AM Ali Beyad  wrote:
>
>> A blog post just went out for this OT: 
>> https://developer.chrome.com/blog/user-agent-reduction-origin-trial/
>>
>> On Thu, Aug 12, 2021 at 9:47 AM Ali Beyad  wrote:
>>
>>> An update on this: it will be too rushed to get the User-Agent Reduction 
>>> OT into the M94 branch cutoff (this Thursday), so we moved this OT for the 
>>> M95 release.
>>>
>>> On Wed, Aug 11, 2021 at 4:02 PM Ali Beyad  wrote:
>>>
 An update on this: it will be too rushed to get the User-Agent 
 Reduction OT into the M94 branch cutoff (this Thursday), so we moved this 
 OT for the M95 release.

 On Thu, Jul 15, 2021 at 6:39 PM Ali Beyad  wrote:

> Thanks for the feedback and the LGTMs, everyone!
>
> On Thu, Jul 15, 2021 at 6:30 PM Rick Byers  
> wrote:
>
>> I agree this OT is quite different from a regular OT, there's not 
>> really a "burn-in risk" to be worried about since this isn't really 
>> about 
>> any new functionality sites want access to. So LGTM3 for a longer trial.
>>
>> If necessary I'd also be supportive of expanding usage limits 
>> arbitrarily. The more usage we can get of this trial, the lower the 
>> compat 
>> risk will be of making the breaking change later. So in this case it 
>> makes 
>> no sense to worry about excessive usage of the OT. 
>>
>> I'm glad to hear the inherited JS semantics will match that of the 
>> header. Like for the header, I'd otherwise be worried about masking 
>> potential compat issues if that JS APIs were unaffected.
>>
>> Rick
>>
>> On Thu, Jul 15, 2021 at 11:18 AM Ali Beyad  
>> wrote:
>>
>>>
>>>
>>> On Thu, Jul 15, 2021 at 4:02 AM Mike West  
>>> wrote:
>>>
 Thanks for the clarifications, Ali. This looks pretty reasonable to 
 me. LGTM1 % the below:

 I would recommend that you adjust the design doc to remove the 
 reference to "a client hint token that will reduce the User-Agent 
 header", 
 as it doesn't sound like that's what you're aiming to experiment with. 
 My 
 understanding of your response is that you'll only adjust the UA in 
 the 
 presence of the Origin Trial token.

>>>
>>> I updated 
>>> 
>>>  
>>> the design doc to make the point clear that the UA will only be reduced 
>>> in 
>>> the presence of the OT token, and I clarified the role of the new 
>>> client 
>>> hint in all this.  Thanks for the feedback!
>>>  
>>>

 With regard to the OT schedule, ~6 months from M94 would take us 
 more or less through M100. In 
 https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/dhfejxAtj84/m/vr889GowAgAJ,
  
 we agreed (but I don't think documented... I'll fix that) that we'd be 
 taking ~4 milestones as a typical OT length as we shift into a 4-week 
 cadence.

 That said, it sounds like you want to use this experiment as a 
 lead-in to a behavior change and deprecation trial, and holding you to 
 4 
 milestones would put you squarely in the holiday season of M98. I'm 
 comfortable with y'all extending this out a little longer than usual, 
 but 
 I'd appreciate two other API owners weighing in to confirm that plan.

 -mike


 On Mon, Jul 12, 2021 at 4:55 PM Ali Beyad  
 wrote:

> Hey Mike,
>
> Thanks for your questions.  Answers inline.
>
> On Mon, Jul 12, 2021 at 9:15 AM Mike West  
> wrote:
>
>> Hey Ali,
>>
>> There are a few details here that I'm not sure I understand.
>>
>> 1.  The linked design doc describes opting into UA reduction 
>> through both an origin trial, and a client hint-based opt-in. Does 
>> this 
>> intent include both mechanisms? Or is it only about the origin trial?
>>
>
> The I2E is for an origin trial that would control two behaviors:
>
>1. The Javascript 

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

[Noah Lemen]

Any updates on the deprecation warning for cross-domain access? We're now 
looking into setting up the Reporting API to capture this once 
available. Which milestone do you estimate it will ship?

On Monday, February 14, 2022 at 12:28:18 PM UTC-5 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 

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

[Noah Lemen]

At Meta (formerly known as Facebook) we have a fair amount of dependencies 
on domain lowering via document.domain. We've discussed this internally, 
and feel that the most difficult aspect of this for us currently is 
identifying where we depend on domain lowering. We feel that something that 
may be helpful for us would be a reporting API not on document.domain, but 
rather on any cross-origin accesses that are only working because of domain 
lowering. Would a reporting API like this be possible to add to help us 
along the deprecation process?

On Tuesday, January 18, 2022 at 12:41:22 PM UTC-5 T K wrote:

> 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