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 > <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/56fd200e-b327-4252-8a32-1bdae6223039n%40chromium.org.
