On 22/10/2019 00:07, L. David Baron wrote:
On Monday 2019-10-21 16:01 -0500, Mike Taylor wrote:
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)?
I'm saying that we've been doing what you describe in the first
paragraph but maybe we need to shift to what you describe in the
second paragraph in order for the policy on secure contexts to be
effective.
Shipping a Gecko-first feature limited to secure contexts, when we don't
have evidence that other browsers will follow suite, runs the risk of
sites breaking only in Gecko once the feature is widely deployed.
Although we can always change the configuration after breakage is
observed, the time taken to receive a bug report, diagnose the issue,
and ship the fix to users, can be significant. This is a window during
which we're likely to lose users due to the — avoidable — compatibility
problems.
I would argue that in the case where:
* There is no compelling security or privacy reason for limiting a
feature to secure contexts
* There is reason to suspect that other browsers will ship a feature in
both secure and insecure contexts (e.g. because limiting to secure
contexts would be significant extra work in their engine, or because
their past behaviour suggests that the feature will available everywhere)
the trade-off between nudging authors toward https usage, and avoiding
web-compat hazards should fall on the side of minimising the
compatibility risk, and so we should ship such features without limiting
to secure contexts.
Alternatively we could have a policy that allows us to initially ship
Gecko-first features meeting the above criteria as secure-context only,
but that requires us to remove the limit if other browsers start
shipping to their development channels without a secure-context limit.
That minimises the compatibility risk — assuming we follow through on
the process — but adds extra bureaucracy and has more steps to go wrong.
I doubt the incremental effect on https adoption of this policy variant
is worth the additional complexity, and suggest we should use this
approach only if we misjudge the intentions of other vendors.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
