LGTM1 to deprecate under the following conditions:
* As discussed, a 6 months deprecation period, as well as
broad-scope and targeted outreach, that would hopefully bring
usage down.
* A well-crafted deprecation message that indicates the timeline,
and at the same time indicates that we'll be responsive to
community feedback (or a link to a blog post/documentation page
that indicates the same)
* Sending a separate intent for the actual removal at the end of the
deprecation period, once the picture is a bit clearer.
On Fri, Jan 14, 2022 at 7:07 PM Alex Russell
<slightly...@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
<gregcwhitwo...@gmail.com> 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 <http://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
<bhe...@google.com> 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
<http://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
<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.
* 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
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?
* 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.
* Is there a plan to eventually remove the
opt-out option? Or is it the plan to have
it in place permanently?
Cheers,
Yoav
On Saturday, December 18, 2021 at 9:38:33 PM
UTC+1 Mike Taylor wrote:
On 12/16/21 5:52 PM, Charlie Reis wrote:
On Thu, Dec 16, 2021 at 7:28 AM 'Daniel
Vogelheim' via blink-dev
<blin...@chromium.org> wrote:
On Tue, Dec 14, 2021 at 11:51 PM Mike
Taylor <mike...@chromium.org> wrote:
On 12/14/21 11:35 AM, Daniel
Bratell wrote:
It seems more or less everyone
agrees on this being a good
thing, so it mainly comes down
to web compatibility.
How much of the web will break,
and how badly. The numbers
mentioned, 0.5% of sites set
document.domain, 0.05% seem to
depend on document.domain, are
quite high. One thing I didn't
quite pick up is what happens if
you try to set document.domain
when it's not settable. Will it
silently pretend to work, or
will that also be a possible
break point?
I would be surprised if it didn't
behave the same as setting an
arbitrary expando on `document` -
we should be safe there.
Almost. The error handling is mostly
the same. But while a foreign
attribute on document would return
the new value, document.domain (when
in an origin-keyed agent cluster)
does not.
So:
document.foo = "bla"
document.foo // Returns "bla".
document.domain = "bla" // Throws
SecurityException.
// On a domain www.host.com
<http://www.host.com>, site-keyed
agent cluster (current default)
document.domain = "host.com
<http://host.com>" // Succeeds.
document.domain; // returns "host.com
<http://host.com>".
// On a domain www.host.com
<http://www.host.com>, origin-keyed
agent cluster (future default)
document.domain = "host.com
<http://host.com>" // Doesn't throw.
Doesn't do anything else either.
document.domain; // Still returns
www.host.com <http://www.host.com>.
Risks: Interoperability
and Compatibility
*
No interoperability risks.
*
Compatibility risk exists, but
is fairly small as
document.domain is an already
deprecated feature. We’ve
detailed UKM metrics in place
and are planning to reach out
to top users as soon as we’ve
LGTMs for the plan.
As Daniel mentioned, I think the
compat risk should be considered
to be higher, despite this being
deprecated for a long time.
Yes, agreed.
*
*
Current usage of the
document.domain: 0.05%
<https://chromestatus.com/metrics/feature/timeline/popularity/2544>of
page views rely upon
document.domain to enable some
cross-origin access that wasn't
otherwise possible. 0.24%
<https://chromestatus.com/metrics/feature/timeline/popularity/2543>of
page views block same-origin
access because only one side
sets document.domain. Both
counters can be found
onhttps://deprecate.it/#document-domain
<https://deprecate.it/#document-domain>,
too.
(cool site, btw)
We’ve reached out in advance to
4 of the top current users -
TL;DR Most of their use cases
could be achieved already by
different APIs e.g. Audio/video
autoplay in iframes by adding
the ‘autoplay’ attribute,
support chat deployed across
subdomains.
Out of curiosity, did any of them
mention what couldn't be achieved
via existing APIs?
I checked back, and nothing
particular came up. It seems that
migrating off of document.domain
isn't blocked by a lack of options.
Activation - Deprecation plan
M98 - Add the devtools issue
and warning incl. a web.dev
<http://web.dev> blog post to
guide adoption
*
M98-M100 - Monitor use
counters and reach out
to current users
*
What's the plan if the use
counters don't move? Do you have
a minimum page view % in mind you
would want before proceeding to
the next step (even if it meant
delaying the timeline)?
We don't have a dead-set plan. The
primary idea is a combination of
delay-ing until usage is low enough,
and outreach to offending sites to
educate about the problem & available
alternatives.
*
M101 - Deprecate the
feature by default. No
reverse-origin trial is
planned as the
‘Origin-Agent-Cluster’
http header can be used
to gain access to the
feature.
*
Would this disabled-by-default
change ride the trains, or have
you considered finching it out to
assess compat risk?
My original plan was to enable it by
default in the 101 release, and have
a Finch switch as an emergency-off.
Reading the feedback here, maybe it's
better to incrementally enable it via
Finch. I'll be happy to follow
whatever path API owners prefer.
In my experience (caveat: I'm not an API
owner), it's harder to repro and triage
compatibility bugs that get filed if a
feature is only enabled for a percentage
of users via Finch. It tends to be
quicker to bisect reports and get
attention on a compat bug if the feature
is enabled on trunk instead, with an easy
way to revert if needed. (Finch is
certainly better when you care about
performance issues, which doesn't seem to
be the case here.)
Yeah, I hear you - the unpredictability is
a challenge. My preferred approach would
be to hold things at 100% in pre-release
channels for some period of time to sniff
out compat bugs - but AIUI, this isn't
really a thing that Finch is designed to
do, and pre-release comes with its own set
of biases that may not accurately reflect
release behavior. But where the risk is
non-zero, only breaking some users seems
better than breaking all users, even if
imperfect.
--
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/bd2f5a7b-a64c-4aa5-aa65-36e6f39fd7e8n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bd2f5a7b-a64c-4aa5-aa65-36e6f39fd7e8n%40chromium.org?utm_medium=email&utm_source=footer>.
--
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/CAL5BFfV9QYzcFoxNvV%2BaNS7p603s45F%2BqZ2z%3D6c0%3DHYPLmMeiw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV9QYzcFoxNvV%2BaNS7p603s45F%2BqZ2z%3D6c0%3DHYPLmMeiw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
