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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
