Catching up on this thread after being on vacation, so I'd like to reply to a few points.
I think the intent of the policy about exposing new features only to secure contexts is that it should apply to CSS features. The purpose of the policy is to push web developers towards secure transports because this is important for our users. It should apply to all web developers. (I think it's possible one could argue that the timeline for applying it to CSS features should be different, but I'm not going to make that argument here and I'm not sure whether I'd agree with it.) Mats Palmgren asked: > Do other vendors apply the same policy for new CSS features? As far as I know, other vendors don't have this policy at all. But I think some other vendors might be interested in following us if we lead on it. But we haven't had much chance to test whether other vendors will follow since it's been relatively rare for us to be the first to ship a new feature that doesn't already have wide consensus to limit to secure contexts. (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.) Sean Voisen asked: > But it also says: "In contrast, a new CSS color keyword would likely not be > restricted to secure contexts." Given that this is a new value for > grid-template-*, and not a new CSS property, I'd argue it doesn't apply. At least if I were deciding what the intent was here, I'd probably refer to the text (particularly the first question/answer pair) that I wrote for an early draft (as of 85009e1c6b5d) of https://github.com/w3ctag/design-principles/pull/75 which ended up not being used both due to it being revised away and because the TAG couldn't reach consensus on the PR in its entirety: New features should be available only in <a href="https://w3c.github.io/webappsec-secure-contexts/";>secure contexts</a>. Adding a feature to the Web that is available in non-secure contexts is discouraged and requires strong justification. This restriction exists for two reasons. First, it helps encourage Web content and applications to migrate to secure contexts. Second, some new features depend on authentication, integrity, or confidentiality to prevent substantial increases to the privacy or security risks of using the Web. For more detail, see the W3C TAG Finding on <a href="https://www.w3.org/2001/tag/doc/web-https";>Securing the Web</a>. When deciding whether a change to Web technology should be limited to secure contexts, we suggest considering the following factors: : Is this change a new feature? :: A feature that is limited to secure contexts should be recognizable by the developers who use it as distinct from features that are available in non-secure contexts. This will reduce developer confusion about where the boundaries are. For example, a new CSS property is a distinct feature, whereas the ability to omit the commas in the CSS ''rgb()'' function is not. We also don't want to increase the complexity of implementations of Web technology by requiring tests for secure contexts in too many *types* of places. Changes that include additions made at the major points at which new features are added (such as additions of new IDL interfaces, namespaces, methods, or properties, or additions of new CSS properties) must be limited to secure contexts. Changes made entirely at more minor points where new capabilities are added to the platform (such as new IDL method *overloads*, or new *values* for an existing CSS property), or at expansion points where feature detection is not possible, do not necessarily need to be limited to secure contexts (and for the purpose of this section, need not count as a new feature). : Can the presence of the feature be detected? :: The existence of new features should generally be detectable. However, if, for some reason (a reason that requires serious justification), it is not possible for developers to detect whether a new feature is present, limiting the feature to secure contexts might cause problems for libraries that may be used in either secure or non-secure contexts. : Does the feature depend on being in a secure context? :: If a feature depends on the expectations of authentication, integrity, or confidentiality that are met only in secure contexts, then it must be limited to secure contexts, even if the other factors above suggest it doesn't need to be. For example, a feature that communicates with USB devices if those devices have allowed Web content from the site's origin to communicate with those USB devices depends on the authentication of the origin and the integrity of the data sent to the USB device, since sending untrusted data to a USB device could damage that device or compromise computers that the device connects to. Specification authors can limit most features defined in <a href="https://heycam.github.io/webidl/";>WebIDL</a>, to secure contexts by using the <code>[<a href="https://w3c.github.io/webappsec-secure-contexts/#integration-idl";>SecureContext</a>]</code> extended attribute on interfaces, namespaces, or their members (such as methods and attributes). Similar ways of marking features as limited to secure contexts should be added to other major points where the Web platform is extended over time (for example, the definition of a new CSS property). However, for some types of extension points (e.g., dispatching an event), limitation to secure contexts should just be defined in normative prose in the specification. Specifically on the question of subgrid, I think the strongest reason *not* to limit subgrid to secure contexts is one that Sean and Cameron already referred to -- that it is a feature designed to mitigate a key problem with the grid feature that we and other browsers have already shipped. In particular, needing to support grid implementations that do not support subgrid encourages developers to remove elements from their markup in order to match the grid model. This can harm anything that depends on the existence of those removed elements or that depends on the availability of the semantics that would have been in those removed elements, including accessibility and including interventions that we make on behalf of the user (many of which depend on the identity of objects in the DOM). So limiting subgrid to secure contexts while grid is available in insecure contexts would perpetuate these problems. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
