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.