Hi David,

On 10/21/19 7:22 AM, L. David Baron wrote:
(That we haven't applied the policy that much because we've granted
exceptions because other browsers have shipped the features reduces
the effectiveness of the policy and its ability to meet its goals.
This is the sort of policy that is most effective if it applies to
the largest number of thngs, both because it has larger effects and
because it sets much clearer expectations about what will be limited
to secure contexts.  I think it's worth considering reducing that
exception to the existence of actual web compat problems from the
secure contexts limitation.)

Can you unpack this a little here?

Are we saying we would ship features in non-secure contexts because sites theoretically rely on that behavior due to another browser shipping as non-secure before we did? (This sounds like the current rationale for exceptions, I think).

Or are we saying we would ship a feature by default as secure and be willing (compelled?) to move to non-secure if we discover sites rely on other significant market share browsers not requiring a secure context for said feature -- once our users reported the bugs (or we did some kind of analysis beforehand)?

Looking at <https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts#Secure_context_restrictions_that_vary_by_browser>, I'm trying to imagine what that would look like.

Mike Taylor
Web Compat, Mozilla
dev-platform mailing list

Reply via email to