Primary eng (and PM) emails
hb...@chromium.org, h...@chromium.org
Summary
WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.
Motivation
Explain why this feature should be deprecated (and eventually removed).
Interoperability and Compatibility Risk
Describe the degree of interoperability and compatibility risk. For a feature that is also supported in some other engine, do they support eventual removal?
Edge: Supports both Unified Plan (default) and Plan B (opt-in), positive towards removal of Plan B.
Firefox: Supports Unified Plan only, positive towards removal of Plan B.
Safari: Supports Unified Plan only, positive towards removal of Plan B.
Alternative implementation suggestion for web developers
If this feature goes away, what other techniques can developers use to achieve the same effects?
Unified Plan. Don't specify anything in the RTCPeerConnection constructor.Usage information from UseCounter
How much of the web are you going to break? How seriously would the removal break sites?
In terms of sdpSemantics usage, 55.22% don't specify which defaults to Unified Plan, 42.71% explicitly specify Unified Plan and just 2.06% overwrite this to explicitly ask for Plan B.
However those numbers can be misleading. What would "break" are the "complex" use cases of SDP. Comparing Plan B vs Unified Plan for complex use cases tells a different story:
Numbers in September:
Removal would likely break major conferencing websites. So let's deprecate before removing.
If possible, please link to usage details on chromestatus.com/metrics (example link)
If you haven’t instrumented this feature yet, say so.
Entry on the feature dashboard
The original Unified Plan feature is here: https://chromestatus.com/feature/5723303167655936
Does "deprecate sdpSemantics" need a separate feature?
The feature dashboard is used to keep track of web-facing changes in Blink (and V8) that matter to developers. Make sure your change has an entry if you think it merits outreach to developers (e.g inclusion in the Chromium Blog Beta posts). If there’s no entry, please explain why you think this change doesn’t need one (e.g. “small change”, “fits under an existing entry”). You may be asked to create one.
Please include a deeplink in your intent (e.g. https://www.chromestatus.com/features/5688366657961984).Primary eng (and PM) emails
hb...@chromium.org, h...@chromium.org
Summary
WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.
In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.Motivation
Explain why this feature should be deprecated (and eventually removed).
Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.
There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.
Interoperability and Compatibility Risk
Describe the degree of interoperability and compatibility risk. For a feature that is also supported in some other engine, do they support eventual removal?
Interoperability risks is discussed above about why we want to get rid of Plan B.For more nitty gritty details about Plan B vs Unified Plan, see migration guide.But to clarify, an app opting-in to Plan B but suddenly getting Unified Plan is likely to break. Removal cannot happen until usage goes down more. Hoping a deprecating warning will motivate people to migrate.Edge: Supports both Unified Plan (default) and Plan B (opt-in), positive towards removal of Plan B.
Firefox: Supports Unified Plan only, positive towards removal of Plan B.
Safari: Supports Unified Plan only, positive towards removal of Plan B.
Alternative implementation suggestion for web developers
If this feature goes away, what other techniques can developers use to achieve the same effects?
Unified Plan. Don't specify anything in the RTCPeerConnection constructor.Usage information from UseCounter
How much of the web are you going to break? How seriously would the removal break sites?
In terms of sdpSemantics usage, 55.22% don't specify which defaults to Unified Plan, 42.71% explicitly specify Unified Plan and just 2.06% overwrite this to explicitly ask for Plan B.
However those numbers can be misleading. What would "break" are the "complex" use cases of SDP. Comparing Plan B vs Unified Plan for complex use cases tells a different story:
Numbers in September:
Numbers today (December):
- SDPFormatReceived's Complex SDP usage: 59% Plan B, 41% Unified Plan.
- SDPFormatReceived's Complex SDP usage: 58% Plan B, 42% Unified Plan.
Removal would likely break major conferencing websites. So let's deprecate before removing.
If possible, please link to usage details on chromestatus.com/metrics (example link)
If you haven’t instrumented this feature yet, say so.
We use UMA counters WebRTC.PeerConnection.SdpSemanticRequested and SDPFormatReceived. See https://crbug.com/857004.
Entry on the feature dashboard
The original Unified Plan feature is here: https://chromestatus.com/feature/5723303167655936
Does "deprecate sdpSemantics" need a separate feature?
The feature dashboard is used to keep track of web-facing changes in Blink (and V8) that matter to developers. Make sure your change has an entry if you think it merits outreach to developers (e.g inclusion in the Chromium Blog Beta posts). If there’s no entry, please explain why you think this change doesn’t need one (e.g. “small change”, “fits under an existing entry”). You may be asked to create one.
Please include a deeplink in your intent (e.g. https://www.chromestatus.com/features/5688366657961984).?
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8df09267-7cc2-46b5-88c7-239f9976dd41n%40chromium.org.
Am Di., 22. Dez. 2020 um 14:03 Uhr schrieb Henrik Boström <hb...@chromium.org>:Primary eng (and PM) emails
hb...@chromium.org, h...@chromium.org
Summary
WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.
The last I heard Zoom stopped using RTCPeerConnection (datachannels only) again.In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.Motivation
Explain why this feature should be deprecated (and eventually removed).
Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.I think it is somewhat important to mention that that for the case of two browsers talking to each other 99% of the usage is not "complex" -- the only use-case here is sending and receiving video + screensharing at the same time.Given that this therefore largely affects non-browser endpoints I do not think it is appropriate to make "what do Firefox and Safari do" a driver for this.
There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.I would find fixing the reported issues with unified plan much more encouraging than a warning.It is very counterproductive if one spends effort to implement unified-plan and then has to roll back because unified-plan is broken while plan-b just works.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJsbaofgMv33KfGUU%3DvWTQ%3De0Z93PhbriED%2Buf3h1BcFA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJsbaofgMv33KfGUU%3DvWTQ%3De0Z93PhbriED%2Buf3h1BcFA%40mail.gmail.com.
On Thu, Dec 24, 2020 at 9:58 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:Am Di., 22. Dez. 2020 um 14:03 Uhr schrieb Henrik Boström <hb...@chromium.org>:Primary eng (and PM) emails
hb...@chromium.org, h...@chromium.org
Summary
WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.
The last I heard Zoom stopped using RTCPeerConnection (datachannels only) again.In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.Motivation
Explain why this feature should be deprecated (and eventually removed).
Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.I think it is somewhat important to mention that that for the case of two browsers talking to each other 99% of the usage is not "complex" -- the only use-case here is sending and receiving video + screensharing at the same time.Given that this therefore largely affects non-browser endpoints I do not think it is appropriate to make "what do Firefox and Safari do" a driver for this.Are non-browser endpoints using the unified plan or plan B?
There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.I would find fixing the reported issues with unified plan much more encouraging than a warning.It is very counterproductive if one spends effort to implement unified-plan and then has to roll back because unified-plan is broken while plan-b just works.That seems like a good point. Is there a list of issues currently blocking the migration to the unified plan?
On Tuesday, January 5, 2021 at 9:30:50 AM UTC+1 yo...@yoav.ws wrote:On Thu, Dec 24, 2020 at 9:58 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:Am Di., 22. Dez. 2020 um 14:03 Uhr schrieb Henrik Boström <hb...@chromium.org>:Primary eng (and PM) emails
hb...@chromium.org, h...@chromium.org
Summary
WebRTC is a platform for web conferencing and data transmission. The platform contains the JavaScript APIs that major websites use to implement their web conferencing products, including Zoom, Google Meet, Facebook Messenger, Skype Web, Google Duo and Cisco WebEx, just to name a few.
The last I heard Zoom stopped using RTCPeerConnection (datachannels only) again.In order for two WebRTC endpoints to set up a call they need to exchange a text-based description of what is to be sent and received (how many video feeds, which codecs are supported or preferred, etc). The protocol is called SDP (Session Description Protocol) and it is used by any WebRTC application that wishes to connect anywhere.The spec settled on a dialect of SDP called Unified Plan, which is currently the one and only version of SDP that browsers like Firefox and Safari implement.In Chromium-based browsers (like Chrome and now more recently Edge), Unified Plan has been the default SDP dialect for almost two years. However, unlike Firefox and Safari, Chrome allows applications to opt-in to a legacy SDP dialect called Plan B, which works slightly different than the web standard.The way to achieve Plan B is to construct the RTCPeerConnection with the non-standard dictionary attribute {sdpSemantics:"plan-b"}. We want to deprecate this attribute, and as a result, make it impossible to have modern browsers speak the Plan B dialect of SDP.Motivation
Explain why this feature should be deprecated (and eventually removed).
Unified Plan and Plan B are incompatible in "complex" conferencing setups. Complex means if there are multiple m= sections of the same media kind (audio/video). To simplify what this means, this roughly translates to 1:1 calling working between Plan B and Unified Plan clients (in most cases), but group calling breaking due to incompatibilities. Furthermore, some APIs that have been implemented in the last two years are only available when Unified Plan is used.We want to deprecate Plan B in favor of a spec-compliant and cross-browser compatible SDP format. We want to increase interoperability and compatibility long-term by deprecating a feature that is heavily used at present time, but if it was to be deleted today that would cause compatibility issues with apps not prepared for Unified Plan. Plan B and Unified Plan clients may talk, but SDP format has to be translated between them in application-specific ways. Some apps may simply not support spec-compliant endpoints.I think it is somewhat important to mention that that for the case of two browsers talking to each other 99% of the usage is not "complex" -- the only use-case here is sending and receiving video + screensharing at the same time.Given that this therefore largely affects non-browser endpoints I do not think it is appropriate to make "what do Firefox and Safari do" a driver for this.Are non-browser endpoints using the unified plan or plan B?It's a similar story there, most non-browser endpoints are using libwebrtc (the same library that chromium-based browsers are built on top of) which means they are free to choose what to use with sdp_semantics.
For historical reasons a lot of endpoints use Plan B
, but endpoints that want to interoperate with browsers like Firefox or default-constructed peer connections on Chromium-browsers would either use Unified Plan directly or have the means to convert between SDP formats. Like Harald said, server-based conferencing applications would be "complex" and do care if its Plan B or Unified Plan.
There is a risk if people develop and test on Chromium-based browsers and then their app is not compatible with Firefox and Safari.2 years have passed and Plan B is still heavily used for "complex" setups. We think a deprecation warning is justified to encourage people to stop doing this.I would find fixing the reported issues with unified plan much more encouraging than a warning.It is very counterproductive if one spends effort to implement unified-plan and then has to roll back because unified-plan is broken while plan-b just works.That seems like a good point. Is there a list of issues currently blocking the migration to the unified plan?There are no blocking issues that I'm aware of.
There are some discrepancies between Unified Plan and Plan B, e.g.
- Some which are inherent to the change in SDP: "removed" tracks don't fire the ended event, they fire the muted event. Re-adding tracks causes new m= sections, making the SDP "complex", etc. This is all working as intended.- Neither Plan B or Unified Plan implement a feature called "end-of-candidates" which affects what ICE candidate state is reported (when not "connected", should it be "disconnected" or "failed"?). Plan B implemented a spec-breaking work-around to this issue where it reports "failed" based on a timeout. Philipp has been upset in the past that Unified Plan does not implement the same timeout-based workaround to the issue and instead reports "disconnected" (as is the correct thing to do if you don't know about "end-of-candidates", but arguably less useful than a heuristic "failed"). This has shown to cause confusion, but in my experience updating an app to be prepared for this was a one line change or a a few lines if you want the timeout.
In either case, this is not a blocking issue to adding a deprecation warning in my opinion.
Philipp are you referring to anything else? Flat-out calling Unified Plan "broken" is not really helpful in an email thread like this, to aid conversation please be more specific.
Interoperability and Compatibility Risk
Describe the degree of interoperability and compatibility risk. For a feature that is also supported in some other engine, do they support eventual removal?
Interoperability risks is discussed above about why we want to get rid of Plan B.For more nitty gritty details about Plan B vs Unified Plan, see migration guide.But to clarify, an app opting-in to Plan B but suddenly getting Unified Plan is likely to break. Removal cannot happen until usage goes down more. Hoping a deprecating warning will motivate people to migrate.Edge: Supports both Unified Plan (default) and Plan B (opt-in), positive towards removal of Plan B.
Firefox: Supports Unified Plan only, positive towards removal of Plan B.
Safari: Supports Unified Plan only, positive towards removal of Plan B.
Alternative implementation suggestion for web developers
If this feature goes away, what other techniques can developers use to achieve the same effects?
Unified Plan. Don't specify anything in the RTCPeerConnection constructor.Usage information from UseCounter
How much of the web are you going to break? How seriously would the removal break sites?
In terms of sdpSemantics usage, 55.22% don't specify which defaults to Unified Plan, 42.71% explicitly specify Unified Plan and just 2.06% overwrite this to explicitly ask for Plan B.
However those numbers can be misleading. What would "break" are the "complex" use cases of SDP. Comparing Plan B vs Unified Plan for complex use cases tells a different story:
Numbers in September:
Numbers today (December):
- SDPFormatReceived's Complex SDP usage: 59% Plan B, 41% Unified Plan.
- SDPFormatReceived's Complex SDP usage: 58% Plan B, 42% Unified Plan.
These numbers are based on the metrics from https://bugs.chromium.org/p/chromium/issues/detail?id=857004#c31As I have pointed out in the bug, this is using the wrong baseline since it looks at the offers only and ignores the rather common case of the complex answer SDP. This means your numbers ignore Google Meet, Jitsi Meet (and probably a couple of other meets)Can you give ratios for SDPFormatReceivedAnswer as well as the ratio of SDPFormatReceived and SDPFormatReceivedAnswer?
(ironically one of the few arguments for unified plan was that you can apply per-mline bandwidth limits)
(arguably part of this is related to not using bundle) and last but not least
https://bugs.chromium.org/p/chromium/issues/detail?id=944821 (browser-specific SDP solves this but...)
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8010f2dc-2b17-4dd1-be42-a69b613e82c7n%40chromium.org.
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3c1bb547-87b2-466c-bc25-d36546003afen%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7c0ea26a-0dd3-4121-afbc-16e84475ba77n%40chromium.org.
How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiKa8ZL8np%2B-jnj-h6EjdYgE9%3D9GQK5unstSFfU2wUzi1g%40mail.gmail.com.
On Tue, Jan 12, 2021 at 10:17 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?We would not remove unless the numbers were low enough at time of removal. The team will have to come back to blink-dev to verify with the API owners that it's ok to actually remove the feature, based on data at that time (I mentioned this in my previous email). We'll know more in six months.
Part of the purpose of the deprecation is to provide pressure on the ecosystem to adopt the standardized version of the feature. I recognize that this creates work for site owners that use the Plan B API, but it's important for a compatible and standardized web to remove non-standard APIs. Otherwise, sites in Chromium-based browsers may not be compatible with other browsers, which is not a good situation.
Am Di., 12. Jan. 2021 um 19:27 Uhr schrieb Chris Harrelson <chri...@chromium.org>:On Tue, Jan 12, 2021 at 10:17 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:How is removing at 30 plan-b answers for every unified-plan answer "web-compatible"?We would not remove unless the numbers were low enough at time of removal. The team will have to come back to blink-dev to verify with the API owners that it's ok to actually remove the feature, based on data at that time (I mentioned this in my previous email). We'll know more in six months.This assumes the data is representing the usage correctly. The numbers posted do not which is why I keep asking for the other half.
Part of the purpose of the deprecation is to provide pressure on the ecosystem to adopt the standardized version of the feature. I recognize that this creates work for site owners that use the Plan B API, but it's important for a compatible and standardized web to remove non-standard APIs. Otherwise, sites in Chromium-based browsers may not be compatible with other browsers, which is not a good situation.I disagree that unified-plan vs plan-b is the #1 reason for this when it comes to WebRTC. This is just a boring schism without much impact on quality.
WRT removal of plan-b good luck. My attempt to remove a seven year old "TODO: remove this" of some obsolete plan-b SDP bits was reverted because it broke a "downstream project". Go figure ;-)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJxsvg%2Bbx50SyfgE9yVqPjROAW9i8zxnDTpjuO%3DE3Jx-A%40mail.gmail.com.
Part of the purpose of the deprecation is to provide pressure on the ecosystem to adopt the standardized version of the feature. I recognize that this creates work for site owners that use the Plan B API, but it's important for a compatible and standardized web to remove non-standard APIs. Otherwise, sites in Chromium-based browsers may not be compatible with other browsers, which is not a good situation.I disagree that unified-plan vs plan-b is the #1 reason for this when it comes to WebRTC. This is just a boring schism without much impact on quality.I hear you. Nevertheless, we won't get to full compatibility unless we keep making progress on all of the parts that differ. Also, one other data point: I have heard directly from Mozilla that they consider the Plan B incompatibility problem significant.
Emil, "staying with the warning" is exactly the strategy that we're planning to use until June.Before the reverse origin trial was proposed, the alternative we saw was a hard cutoff in June.Now we have a means to give people more time if they need it.
Hey Harald,
On Tue, Jan 12, 2021 at 2:37 PM Harald Alvestrand <h...@google.com> wrote:Emil, "staying with the warning" is exactly the strategy that we're planning to use until June.Before the reverse origin trial was proposed, the alternative we saw was a hard cutoff in June.Now we have a means to give people more time if they need it.My point is this: if you feel your browser is unnecessarily encumbered by code that is costly to maintain and that isn’t solving problems for real people or addressing your business goals: remove it.As long as Plan B is still available to anyone however, then the code is still there and I don't really understand the rationale about only offering it to some folks. What's the point of having to jump through the reverse trial hoop?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPvvaaKw626xRyw6N7F9gmgv2gTr_VJ%2Bt%3D4uJrzkkft1E4CBdQ%40mail.gmail.com.