plan for cross-origin alert()/confirm() deprecation

[Emily Stark]

Hi API owners,

Carlos and I just met with +Chris Harrelson to discuss the M92 cross-origin JS dialogs deprecation. We agreed to Finch the change off for 2 weeks to allow developers to adopt the reverse origin trial and to gather feedback from any developers for whom the reverse OT isn't sufficient for whatever reason. However, Carlos and I are concerned about the same thing happening again when we re-enable it -- yet more affected developers coming out of the woodwork then, delaying for yet another release, etc. Since this change has already been delayed several times, we want to see what we can do to make sure we don't just keep delaying indefinitely. In particular, we're hoping we can agree with you all that if no major partners are unable to use the reverse OT, that we'll re-enable in 2 weeks and not delay again.

We are also happy to discuss further outreach that could be done for this change. However, we feel like we've followed all the usual processes and at some point there are always going to be developers who only find out about a breaking change at the last minute, so we want to avoid getting into a cycle of perpetually delaying, especially when we've had so many escape hatches already (multiple announcements, enterprise policy, reverse OT, etc.).

Thanks!

Emily

[Yoav Weiss]

Hey Emily!

On Fri, Jul 30, 2021 at 1:01 AM Emily Stark <est...@chromium.org> wrote:

Hi API owners,

Carlos and I just met with +Chris Harrelson to discuss the M92 cross-origin JS dialogs deprecation. We agreed to Finch the change off for 2 weeks to allow developers to adopt the reverse origin trial and to gather feedback from any developers for whom the reverse OT isn't sufficient for whatever reason.

That sounds great!

 

However, Carlos and I are concerned about the same thing happening again when we re-enable it -- yet more affected developers coming out of the woodwork then, delaying for yet another release, etc. Since this change has already been delayed several times, we want to see what we can do to make sure we don't just keep delaying indefinitely. In particular, we're hoping we can agree with you all that if no major partners are unable to use the reverse OT, that we'll re-enable in 2 weeks and not delay again.

We are also happy to discuss further outreach that could be done for this change.

I think more outreach would be useful.

While the intent was discussed on blink-dev for a long while, and was communicated as part of the enterprise release notes, in retrospect it may have merited its own dedicated article (e.g. on web.dev or developers.chrome.com) and broader scope outreach, similar to what the Privacy Sandbox folks were doing with same-site cookies to get it to land safely.

+Paul Kinlan for his opinions on the above, and whether the Chrome DevRel team can help on that front.

 

However, we feel like we've followed all the usual processes

I agree that the blink process was properly followed, but as I said above, I think that (again - in retrospect) we could have done more on the communication front.

 

and at some point there are always going to be developers who only find out about a breaking change at the last minute, so we want to avoid getting into a cycle of perpetually delaying, especially when we've had so many escape hatches already (multiple announcements, enterprise policy, reverse OT, etc.).

I understand. I think that an honest attempt at broad communication would give us more leeway in removing those harmful features. At the same time, I'm not sure that 2 weeks would be sufficient for that. (although they might, as the actual breakage raised awareness...)

Thanks!

Emily

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAPP_2SatmpOrzQ14Tj1b4jca_Nwnz5C2ivP7aRak7iAVPEm%2Bmg%40mail.gmail.com.

[Daniel Bratell]

Not going to add much beyond what Yoav said, but I appreciate what you are trying to do, even if it's hard. This week will, for good and bad, have acted as a wake-up call for those that depend on it and it seems to have given us some information about who critically depend on it and were not reached by previous communication.

Please don't see our request to pause shipping as criticism of your work. You followed the process, and we (API owners) thought the change would work and if that was wrong, then we were also wrong. Now there will be some breathing room to figure out how to proceed (good thing you had it finchable!).

In the posts on blink-dev I have picked up a couple of things:

* "Cross origin" limitations are not fully understood. Some people think this is blocked for all iframes.

* Alternatives are not known/understood, be it document.body.innerText += "message" or console.log("message") or something else.

* Alternatives are not considered "good enough".

* The purpose of the change is not understood. In what way will web developers (long term) benefit from this change.

* The origin trial to buy an extra couple of months time is not understood, and will apparently not work for users behind certain firewalls.

Nothing here looks like a long term showstopper, but I'm not sure how to communicate all this to most of those that will need to hear it in a couple of weeks, if it turns out to be many of them.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWtbTqHbn9GvKHEFEW8mQeb_HnY6Xx4iw0T%3DiUcTgHOEw%40mail.gmail.com.

[Emily Stark]

Thanks Yoav and Daniel. Paul, we'd appreciate any guidance you have on whether a web.dev article is appropriate for this and what the timeline would be. However, I do think that spinning up a full outreach effort akin to Privacy Sandbox/SameSite cookies may be overkill for this change. Breakage for cross-origin dialogs is very very low compared to e.g. the SameSite cookie change -- 3-4 orders of magnitude lower, IIRC.

I suppose my goal for this thread is to come up with a concrete list of what we need to do and/or criteria for deciding whether the change can stick the next time we re-enable it. Should we be aiming for no escalations from major partners? Some maximum quantity of complaints/bug reports? Or if it's more subjective and we can't really come up with a concrete list, that's fine, but it'd be helpful to know that upfront so we can prioritize our time/energy.

Thanks again for the guidance,

Emily

Hey Emily!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAPP_2SatmpOrzQ14Tj1b4jca_Nwnz5C2ivP7aRak7iAVPEm%2Bmg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

[Paul Kinlan]

Sorry. I'm ooo. +Rob Dodson as fyi from a docs perspective.

It should be on developer.chrome.com with an explainer about what it is and some beat practices to mitigate it, and then be linked to from console warnings etc. It feels like there should be proactive engagement with partners, frameworks and other tools that exhibit this behaviour so they are at least informed of the change or actively working on it.... But that might have already happened given the change 

Do we have a way of working out the sites that are affected by this? Can we do a trawl of httparchiveto get a target list and see if there's any commonalities in who uses it?

I don't have anyone on the team free at the moment that can really drive the creation of assets and research, so it might be down to you to draft up, and then we can review and help get live.

Hey Emily!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAPP_2SatmpOrzQ14Tj1b4jca_Nwnz5C2ivP7aRak7iAVPEm%2Bmg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

[Domenic Denicola]

On Tue, Aug 3, 2021 at 2:56 AM 'Paul Kinlan' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Sorry. I'm ooo. +Rob Dodson as fyi from a docs perspective.

It should be on developer.chrome.com with an explainer about what it is and some beat practices to mitigate it, and then be linked to from console warnings etc. It feels like there should be proactive engagement with partners, frameworks and other tools that exhibit this behaviour so they are at least informed of the change or actively working on it.... But that might have already happened given the change 

FYI this change has cross-browser agreement. So web.dev would probably be better than developer.chrome.com?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CADGdg3A2H5FPu5G5oK5PJcCp4-%2B3Ez5AAMUQKb2WkwhLEv_HDw%40mail.gmail.com.

[Alex Russell]

I'm very worried about the 2 week window; it feels extraordinarily rushed given the scale of the breakage being reported. We wouldn't make any TLS changes w/ a window this short, e.g.

Would like for us to recalibrate this change in terms of releases rather than weeks, with metrics gating moving to each more restrictive stage.

On Tuesday, August 3, 2021 at 8:44:39 AM UTC-7 Domenic Denicola wrote:

Hey Emily!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAPP_2SatmpOrzQ14Tj1b4jca_Nwnz5C2ivP7aRak7iAVPEm%2Bmg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWtbTqHbn9GvKHEFEW8mQeb_HnY6Xx4iw0T%3DiUcTgHOEw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

[Emily Stark]

Alex, can you clarify how you are quantifying the scale of the breakage? Breakage is not extremely high by any of the typical metrics (<0.01% of page loads, <0.01% of HTTP Archive results), so again, we'd really like to know what goal posts we are aiming for. We have literally no idea right now if the metric we should be aiming for is usage metrics, complaints on the blink-dev thread/bug reports, major partner escalations, all of the above, or something else.

Two additional notes: (1) this change has nothing to do with TLS so I'm not sure if the comparison there is useful -- TLS deprecations are typically targeting a different audience (server admins rather than web developers) and have very different mitigation strategies, and (2) just to be clear, 2 weeks is not the deprecation period -- the original intent for this change was first sent over a year ago, and has already been delayed several times with ongoing advertisement in typical forums like chromestatus.com, release notes, and console messages. The last time we tried to ship this, we were asked to add a reverse origin trial, which we did and delayed by a release -- so this 2 week delay is intended to just give a break to sites that only just now found out about the origin trial.

Unfortunately, while we feel strongly that this change is the right thing for the web, it's not a super time-sensitive high priority for our team, and we don't have the resources to drive a full-scale outreach effort around it, especially one that includes 1:1 engagements, and especially if we can't define what would make it comfortable to ship. We may have to delay indefinitely if DevRel doesn't have the cycles for it either or if we can't find another owner to drive it. Not saying this as a threat :) just wanting to be clear and upfront about what amount of time we can commit.

On Tue, Aug 3, 2021 at 12:13 PM Alex Russell <sligh...@chromium.org> wrote:

I'm very worried about the 2 week window; it feels extraordinarily rushed given the scale of the breakage being reported. We wouldn't make any TLS changes w/ a window this short, e.g.

Would like for us to recalibrate this change in terms of releases rather than weeks, with metrics gating moving to each more restrictive stage.

On Tuesday, August 3, 2021 at 8:44:39 AM UTC-7 Domenic Denicola wrote:

Hey Emily!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAPP_2SatmpOrzQ14Tj1b4jca_Nwnz5C2ivP7aRak7iAVPEm%2Bmg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWtbTqHbn9GvKHEFEW8mQeb_HnY6Xx4iw0T%3DiUcTgHOEw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

[Alex Russell]

Hey Emily,

Great questions; thoughts inline:

On Tuesday, August 3, 2021 at 12:54:22 PM UTC-7 Emily Stark wrote:

Alex, can you clarify how you are quantifying the scale of the breakage? Breakage is not extremely high by any of the typical metrics (<0.01% of page loads, <0.01% of HTTP Archive results), so again, we'd really like to know what goal posts we are aiming for. We have literally no idea right now if the metric we should be aiming for is usage metrics, complaints on the blink-dev thread/bug reports, major partner escalations, all of the above, or something else.

Yeah, and I think that speaks to my fear here. We heard from major SAS providers that this was a crisis, and that fixes will involve a long chain of suppliers. Our collective data sets have a pretty bad enterprise blindness effect, which I think we're seeing in  here. Lacking data we can trust, ISTM that we're going to need to manage this on an enterprise-software time-scale, and perhaps solicit SAS vendors or enterprises who'd be willing to work with us to signal an "all clear" w/ their populations, e.g. by testing fractional rollout/removal of an OT.

 

Two additional notes: (1) this change has nothing to do with TLS so I'm not sure if the comparison there is useful -- TLS deprecations are typically targeting a different audience (server admins rather than web developers) and have very different mitigation strategies, and (2) just to be clear, 2 weeks is not the deprecation period -- the original intent for this change was first sent over a year ago, and has already been delayed several times with ongoing advertisement in typical forums like chromestatus.com, release notes, and console messages. The last time we tried to ship this, we were asked to add a reverse origin trial, which we did and delayed by a release -- so this 2 week delay is intended to just give a break to sites that only just now found out about the origin trial.

Understood, and thank you for all the care put into this.

My concern is that these breaks have a cumulative reputational effect on the project (we had another bad one last week that hadn't been as carefully managed related to media memory management), and that if we're in enterprise-time-scale waters, we might need new tools. The memory of showModalDialog() hangs over all this, and for similar reasons, folks who were in the same position you're in now had a harder time than I think any of us would like in getting that done.

 

Unfortunately, while we feel strongly that this change is the right thing for the web, it's not a super time-sensitive high priority for our team, and we don't have the resources to drive a full-scale outreach effort around it, especially one that includes 1:1 engagements, and especially if we can't define what would make it comfortable to ship. We may have to delay indefinitely if DevRel doesn't have the cycles for it either or if we can't find another owner to drive it. Not saying this as a threat :) just wanting to be clear and upfront about what amount of time we can commit.

Totally understood. ISTM that given the lack of time sensitivity, it's easiest to tell folks "Version XX includes this change", which is why maybe we can plan to move back to the reverse OT next release? There's no point in delay for delay's sake, and I don't have any doubt this is the right thing to do for the platform (y'all say it is, and I trust you). What I'd love is for us to move back to the more aggressive posture based on some data, or failing that, sampling the population of folks who have expressed concerns recently to validate that they've had enough time. Can we find enterprise volunteers to tell us they've got the R-OT deployed? Lots of big systems have long QA cycles, so maybe a full release isn't the right timeline, but 3 weeks is. IDK, but would trust folks who operate big systems to tell us.

Thoughts?

 

On Tue, Aug 3, 2021 at 12:13 PM Alex Russell <sligh...@chromium.org> wrote:

I'm very worried about the 2 week window; it feels extraordinarily rushed given the scale of the breakage being reported. We wouldn't make any TLS changes w/ a window this short, e.g.

Would like for us to recalibrate this change in terms of releases rather than weeks, with metrics gating moving to each more restrictive stage.

On Tuesday, August 3, 2021 at 8:44:39 AM UTC-7 Domenic Denicola wrote:

Hey Emily!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAPP_2SatmpOrzQ14Tj1b4jca_Nwnz5C2ivP7aRak7iAVPEm%2Bmg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWtbTqHbn9GvKHEFEW8mQeb_HnY6Xx4iw0T%3DiUcTgHOEw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

[Greg Whitworth]

For those that may not know me my name is Greg Whitworth, a director at Salesforce and lead our Standards & Web Platform v-team here (it's early days, but continuing to grow).

Thanks for adding me Alex, this thread captures my concerns as well as Salesforce was incredibly impacted by this with over 100 customer reports filed (while I can't share names, just assume many companies in the Fortune 100 were impacted with direct impact to their LOB). Many have direct impact on business efficiency and some were completely blocked due to the way in which some ISVs build on the platform.

Yeah, and I think that speaks to my fear here. We heard from major SAS providers that this was a crisis, and that fixes will involve a long chain of suppliers. Our collective data sets have a pretty bad enterprise blindness effect, which I think we're seeing in  here. Lacking data we can trust, ISTM that we're going to need to manage this on an enterprise-software time-scale, and perhaps solicit SAS vendors or enterprises who'd be willing to work with us to signal an "all clear" w/ their populations, e.g. by testing fractional rollout/removal of an OT.

If it's possible, can we move some of the proposed options to this doc I spun up for the retro of this as we're doing one internally at Salesforce as well and I'd like to leverage this moment to possibly discuss opening up the enterprise black box. I'm not sure how feasible the technical options are but it's worth discussing at the very least.

Chromium Enterprise Impact Retro - Google Docs

I suppose my goal for this thread is to come up with a concrete list of what we need to do and/or criteria for deciding whether the change can stick the next time we re-enable it. Should we be aiming for no escalations from major partners? Some maximum quantity of complaints/bug reports? Or if it's more subjective and we can't really come up with a concrete list, that's fine, but it'd be helpful to know that upfront so we can prioritize our time/energy. 

Completely agree with this sentiment and what I'd like to see done for breaking changes (known, unknown, or potential). While my proposal in the doc as Option 1 is procedural I know there is interest here at Salesforce to get data to keep this from happening in the future as this hurts our business as it hurts their business.

My concern is that these breaks have a cumulative reputational effect on the project

Yes, we displayed a banner that Chrome 92 was broken with a link to the known issue immediately following the initial reports. We did deploy the origin trial header in an e-release but that takes time to propagate. However it is there now but it will take time for me to determine the potential spread beyond Salesforce controlled content.

~Greg

Hey Emily!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAPP_2SatmpOrzQ14Tj1b4jca_Nwnz5C2ivP7aRak7iAVPEm%2Bmg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWtbTqHbn9GvKHEFEW8mQeb_HnY6Xx4iw0T%3DiUcTgHOEw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

[Domenic Denicola]

On Tue, Aug 3, 2021 at 5:31 PM Greg Whitworth <gwhit...@salesforce.com> wrote:

For those that may not know me my name is Greg Whitworth, a director at Salesforce and lead our Standards & Web Platform v-team here (it's early days, but continuing to grow).

Thanks for adding me Alex, this thread captures my concerns as well as Salesforce was incredibly impacted by this with over 100 customer reports filed (while I can't share names, just assume many companies in the Fortune 100 were impacted with direct impact to their LOB). Many have direct impact on business efficiency and some were completely blocked due to the way in which some ISVs build on the platform.

Yeah, and I think that speaks to my fear here. We heard from major SAS providers that this was a crisis, and that fixes will involve a long chain of suppliers. Our collective data sets have a pretty bad enterprise blindness effect, which I think we're seeing in  here. Lacking data we can trust, ISTM that we're going to need to manage this on an enterprise-software time-scale, and perhaps solicit SAS vendors or enterprises who'd be willing to work with us to signal an "all clear" w/ their populations, e.g. by testing fractional rollout/removal of an OT.

If it's possible, can we move some of the proposed options to this doc I spun up for the retro of this as we're doing one internally at Salesforce as well and I'd like to leverage this moment to possibly discuss opening up the enterprise black box. I'm not sure how feasible the technical options are but it's worth discussing at the very least.

Chromium Enterprise Impact Retro - Google Docs

This is a really helpful doc and I encourage people to read it. I think the solutions it proposes make a good deal of sense, although they have some notable open questions listed.

One question I was hoping you (or others) could give us insight into, is why this only flared up after the change hit Stable. I can understand that not everyone has time to read the beta release blog posts or monitor ChromeStatus. But I would have expected the in-product changes to help. Do any of your customers test with Canary/Dev/Beta? Did they see the console warnings that were logged for the last ~year? Any insight would be helpful here, when discussing the larger question of how to communicate breaking changes like this.

[Greg Whitworth]

One question I was hoping you (or others) could give us insight into, is why this only flared up after the change hit Stable. I can understand that not everyone has time to read the beta release blog posts or monitor ChromeStatus. But I would have expected the in-product changes to help. Do any of your customers test with Canary/Dev/Beta? Did they see the console warnings that were logged for the last ~year? Any insight would be helpful here, when discussing the larger question of how to communicate breaking changes like this.

This is a part of that internal retro I was referring to. I'll try and see what I can share from that. That said, we have gaps on our side for sure, as noted in the doc the author of the change did discuss this with some contacts at Salesforce so I need to figure out how to ensure those make it to the right people that can ensure that all of Salesforce, our subsidiaries and customers can help inform us if they'll be impacted. As it relates to testing this is done but not on the level that I'd like and it won't be a small investment on our end to get to the level where we can confidently run nightly builds against SF.

Customers do at times catch issues in beta (which is what happened in this case) or canary and ping us via our support channel but this is done to a varying degree not only for Chrome but other browsers too. So while I'm actively working with you all on this for Chromium I'd like to see something from Webkit & Safari as well. That said, I don't want to grow the scope until we've figured out what can/can't work as I don't want process for the sake of process (to Emily's point).

~Greg

[Emily Stark]

Thanks Greg for sharing the retro doc; I left a couple comments. Do you already have a contact on the Chrome Enterprise team who can participate in this doc? It would be great to have their involvement.

While the enterprise outreach conversation is definitely worthwhile, I'm not convinced that enterprise breakage is the main issue here. We've only heard from a couple large-scale enterprises about this change, and of the enterprise issues we have encountered, most seem to be easily accommodated by the enterprise policy and/or reverse origin trial. Individual web developers seem to be the most vocal on the bug report and blink-dev threads, with the primary use case being Javascript learning environments like codepen.io. That use case isn't going to be accommodated by delaying more -- it's a problem of legacy content (old programming tutorials that are probably not being actively maintained) and necessary breakage (codepen-style sites that specifically want to use alert()-and-friends for exactly the same reasons that we want to deprecate it).

[Greg Whitworth]

most seem to be easily accommodated by the enterprise policy and/or reverse origin trial

My desire for this retro is to ensure that Salesforce could have deployed the origin trial prior to 92 stable shipping; not block its implementation. Also to have some agreed upon engagement to influence the length of that trial. While I appreciate the desire to ship the change, as I note in my open question we should be able to figure out how we can deploy this safely to derive a reasonable timeframe for enterprises. To give a concrete example for Salesforce, we will need to identify not only our own code that is impacted by this change, but also inform our ISVs, custom component authors, etc. And while it's easy to assume that anyone building on the Salesforce platform is a developer that follows browsers closely this is not always the case.

Our changes will go into the next release once identified which won't be until Spring '22. And again that's ONLY Salesforce owned code and that's assuming we can identify all scenarios impacted by this ASAP since planning and code has already begun for that release.

And while outreach is one aspect, I do think we should explore Option 2 to limit the need for manual discussion. That said.

~Greg

[Emily Stark]

Yes, just to be clear -- I didn't mean to trivialize the Salesforce impact, nor to discourage the conversation about enterprise outreach in general; just to say that for this particular change, substantive complaints from enterprises have been the minority.

[Emily Stark]

Hi API owners -- since it doesn't sound like we have consensus on the original plan of re-enabling in a couple weeks, we've decided to roll back this change until at least January, until we have the cycles to form and execute a deeper outreach plan. We will likely need DevRel assistance, so we'll need to check in with them to see if they can help, maybe as part of Q4 or 2022 planning. Please let us know if you have any objections, otherwise we'll post about this delay publicly on blink-dev and the bug.

Emily

[Paul Kinlan]

Hi Emily, +Rowan Merewood  on my team who might be close to this given his focus on security and privacy. I'll also be back from ooo next week if you want to catch up.

[Chris Harrelson]

Hi Emily,

I think this is a good plan given the feedback so far. I'm sure you're a bit frustrated and disappointed at not being able to ship this change now, especially considering all the previous outreach steps. But I appreciate you and your team's respect for the feedback of web developers in moving to a slower approach with additional outreach.

Thanks,

Chris

[Yoav Weiss]

Hi Emily,

The plan sounds like exactly what's needed, so thanks for that. I wanted to add that seeing my Twitter mentions (and I imagine yours is worse), the reaction towards the team and speculation about y'all's intentions/motivations seems largely unfair :/ 

Thanks,

Yoav

[Alex Russell]

+1 to Yoav and Chris' points. Thanks for taking so much care; I'm looking forward to figuring out what we can do to help fill our enterprise data void. Teams like yours shouldn't be negatively surprised this way, and I dislike how this is slowing us down.

[Rowan Merewood]

Hey Emily, we can definitely support here. It feels like we could take a similar approach to what we did with the SharedArrayBuffer restrictions, e.g. articles across web.dev and developer.chrome.com with motivation, context, debugging guidance, reporting options, migration paths, and specifically covering enterprise needs as well - make sure we're linking that from DevTools Issues - follow up with individual affected sites to validate.

--

Rowan Merewood | Developer Relations Engineer | Chrome & web | mere...@google.com

[Simon Pieters]

Hi folks,

On Fri, Jul 30, 2021 at 12:24 PM Daniel Bratell <brat...@gmail.com> wrote:

Not going to add much beyond what Yoav said, but I appreciate what you are trying to do, even if it's hard. This week will, for good and bad, have acted as a wake-up call for those that depend on it and it seems to have given us some information about who critically depend on it and were not reached by previous communication.

Please don't see our request to pause shipping as criticism of your work. You followed the process, and we (API owners) thought the change would work and if that was wrong, then we were also wrong. Now there will be some breathing room to figure out how to proceed (good thing you had it finchable!).

In the posts on blink-dev I have picked up a couple of things:

* "Cross origin" limitations are not fully understood. Some people think this is blocked for all iframes.

* Alternatives are not known/understood, be it document.body.innerText += "message" or console.log("message") or something else.

* Alternatives are not considered "good enough".

I guess the alternatives (that are part of the web platform) are:

- console.log() for teaching purposes, and lose the "blocking" aspect

- console.log() and/or breakpoints in devtools for debugging purposes

- <dialog> for modal dialogs

As for good enough, for <dialog>, it's unfortunate that this issue is not yet resolved https://github.com/whatwg/html/issues/1929

cheers

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/5f230aaa-1884-516e-7d1d-01c456dcdd9c%40gmail.com.

--

Simon Pieters

Bocoup https://bocoup.com/