Intent to ship: CSS subgrid

[Mats Palmgren]

I intend to enable CSS subgrid by default for v71.

*Summary: *
The CSS Grid 2 subgrid feature allows nested grids to participate in the
sizing of their parent's tracks, on a per-axis basis.

*Bug to turn on by default: *
https://bugzilla.mozilla.org/show_bug.cgi?id=1580894

*Meta bug where this feature is developed:*
https://bugzilla.mozilla.org/show_bug.cgi?id=1240834

*Standard:*
https://drafts.csswg.org/css-grid-2/#subgrids

*Platform coverage:*
All platforms.

*DevTools bug:*
Subgrid is supported in devtools. Metabug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1464440

*Other browsers: *
Blink/WebKit doesn't support subgrid so far, but it is expected that they
eventually will. Folks from Igalia and others have been participating in
the spec discussions.

*web-platform-tests: *
https://github.com/web-platform-tests/wpt/tree/master/css/css-grid/subgrid

*Secure contexts:* N/A

*Note:*
There is one unresolved spec issue under discussion:
https://github.com/w3c/csswg-drafts/issues/4411 which might require
updating our implementation. I don't feel like it's a major issue that
needs to block us from shipping. There should be a resolution soon and
hopefully we can uplift any potential changes as a bug fix before it's
released.


/Mats

[Mats Palmgren]

[ikilp...@chromium.org]

On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren wrote:
> I intend to enable CSS subgrid by default for v71.
>
> *Summary: *
> The CSS Grid 2 subgrid feature allows nested grids to participate in the
> sizing of their parent's tracks, on a per-axis basis.
>
> *Bug to turn on by default: *
> https://bugzilla.mozilla.org/show_bug.cgi?id=1580894
>
> *Meta bug where this feature is developed:*
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240834
>
> *Standard:*
> https://drafts.csswg.org/css-grid-2/#subgrids
>
> *Platform coverage:*
> All platforms.
>
> *DevTools bug:*
> Subgrid is supported in devtools. Metabug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1464440
>
> *Other browsers: *
> Blink/WebKit doesn't support subgrid so far, but it is expected that they
> eventually will. Folks from Igalia and others have been participating in
> the spec discussions.
>
> *web-platform-tests: *
> https://github.com/web-platform-tests/wpt/tree/master/css/css-grid/subgrid
>
> *Secure contexts:* N/A

Replying as requested from: https://twitter.com/ecbos_/status/1184690249324290048

Subgrid is a new feature to CSS behind a new display value which only Gecko supports currently.
Does https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ apply here?

[Mats Palmgren]

On 10/17/19 5:35 PM, ikilp...@chromium.org wrote:
> On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren
> wrote:
>> *Secure contexts:* N/A
>
> Replying as requested from:
> https://twitter.com/ecbos_/status/1184690249324290048

Well, I just copy-pasted the email-template TYLin used in his
intent-to-ship for 'column-span' earlier, so I assumed "N/A" is
the correct term... :-)

Anyway, I don't think we constrain new CSS properties/values to secure
contexts in general. As far as I know, we don't even have a mechanism
for doing so. So "N/A" seems appropriate.


> Subgrid is a new feature to CSS behind a new display value [...]

No, 'subgrid' is not a new 'display' value. It's a new value for
the 'grid-template-rows/columns' properties:
https://drafts.csswg.org/css-grid-2/#subgrid-per-axis

> Does
> https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
> apply here?

As far as I know, we never constrain new CSS features to secure contexts.
At least not on the property/value level.


/Mats

[ikilp...@chromium.org]

On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren wrote:
> On 10/17/19 5:35 PM, ikilp...@chromium.org wrote:
> > On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren
> > wrote:
> >> *Secure contexts:* N/A
> >
> > Replying as requested from:
> > https://twitter.com/ecbos_/status/1184690249324290048
>
> Well, I just copy-pasted the email-template TYLin used in his
> intent-to-ship for 'column-span' earlier, so I assumed "N/A" is
> the correct term... :-)
>
> Anyway, I don't think we constrain new CSS properties/values to secure
> contexts in general. As far as I know, we don't even have a mechanism
> for doing so. So "N/A" seems appropriate.
>
>
> > Subgrid is a new feature to CSS behind a new display value [...]
>
> No, 'subgrid' is not a new 'display' value. It's a new value for
> the 'grid-template-rows/columns' properties:
> https://drafts.csswg.org/css-grid-2/#subgrid-per-axis

My bad, but the same principle applies.

>
> > Does
> > https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
> > apply here?
>
> As far as I know, we never constrain new CSS features to secure contexts.
> At least not on the property/value level.

According to https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ you should be?

"Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. "

Or does the policy wrong and needs to be updated?

>
> /Mats

[Mats Palmgren]

True, but we have never applied that policy for CSS features
as far as I know. Just recently we've added 'column-span',
the ::marker pseudo, new 'display' syntax with values like
'inline list-item', 'block ruby' etc, 'clip-path: path()',
and a long list of other CSS features since 2018.

As far as I know we don't even have a mechanism that I could
have used to restrict subgrid to secure contexts. And to be
clear: I have no intention of blocking subgrid on waiting for
such a mechanism.

> Or does the policy wrong and needs to be updated?

Maybe, but that's not for me to decide.

The issue you raise is a good one, but it's not really related
to subgrid specifically. Perhaps it would be better if you
start a new thread regarding how that policy applies (or not)
to CSS features in general?


/Mats

[ikilp...@chromium.org]

On Thursday, October 17, 2019 at 12:47:27 PM UTC-7, Mats Palmgren wrote:
> On 10/17/19 8:12 PM, ikilp...@chromium.org wrote:
> > On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren
> > wrote:
> >> As far as I know, we never constrain new CSS features to secure
> >> contexts. At least not on the property/value level.
> >
> > According to
> > https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
> > you should be?
> >
> > "Effective immediately, all new features that are web-exposed are to be
> > restricted to secure contexts. Web-exposed means that the feature is
> > observable from a web page or server, whether through JavaScript, CSS,
> > HTTP, media formats, etc."
>
> True, but we have never applied that policy for CSS features
> as far as I know. Just recently we've added 'column-span',
> the ::marker pseudo, new 'display' syntax with values like
> 'inline list-item', 'block ruby' etc, 'clip-path: path()',
> and a long list of other CSS features since 2018.

These features (broadly speaking) are different however. According to the above policy:
"Exceptions to requiring secure contexts"
" - other browsers already ship the feature insecurely"

Most (all?) of the non-trivial features above have shipped in other browsers insecurely before shipping in Firefox, hence the above exception applies.

"subgrid" is different as Firefox is shipping this feature first.

> As far as I know we don't even have a mechanism that I could
> have used to restrict subgrid to secure contexts. And to be
> clear: I have no intention of blocking subgrid on waiting for
> such a mechanism.

This should just involve passing a isSecureContext flag into the your CSS parser?

>
> > Or does the policy wrong and needs to be updated?
>
> Maybe, but that's not for me to decide.
>
> The issue you raise is a good one, but it's not really related
> to subgrid specifically. Perhaps it would be better if you
> start a new thread regarding how that policy applies (or not)
> to CSS features in general?

See above - I believe it actually is only related to this feature, as it is shipping in Firefox first.

Given this shouldn't a "...Mozilla’s Distinguished Engineers to judge the outcome..."?

>
> /Mats

[Sean Voisen]

On Thu, Oct 17, 2019 at 1:05 PM <ikilp...@chromium.org> wrote:

>
> These features (broadly speaking) are different however. According to the
> above policy:
> "Exceptions to requiring secure contexts"
> " - other browsers already ship the feature insecurely"
>
> Most (all?) of the non-trivial features above have shipped in other
> browsers insecurely before shipping in Firefox, hence the above exception
> applies.
>

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.

> "subgrid" is different as Firefox is shipping this feature first.
>

I believe we were also first to ship the support for multiple display
values, but again those are values. And I think we're the first on
::marker. These were not restricted.

> > As far as I know we don't even have a mechanism that I could
> > have used to restrict subgrid to secure contexts. And to be
> > clear: I have no intention of blocking subgrid on waiting for
> > such a mechanism.
>
> This should just involve passing a isSecureContext flag into the your CSS
> parser?
>

There's also the consideration as to whether allowing grid in non-secure
contexts, but NOT subgrid, even makes sense. I think it would oddly
fracture support for grid layouts as a whole (or at least potentially make
things confusing for developers — it's certainly more confusing than just
restricting access to a single property like backdrop-filter or something).
Perhaps we should ask what the value of restricting only subgrid to secure
contexts even brings. If part of the spirit of the policy (at least the
part that applies here) is to quicken adoption of secure contexts, is the
value of subgrid's contribution to this endeavor worth the trade-off of
potential user confusion?

> Given this shouldn't a "...Mozilla’s Distinguished Engineers to judge the
> outcome..."?
>

It's an interesting test of the policy. Thanks for bringing it up :)

[ikilp...@chromium.org]

On Thursday, October 17, 2019 at 3:15:49 PM UTC-7, Sean Voisen wrote:
> On Thu, Oct 17, 2019 at 1:05 PM <ikilp...@chromium.org> wrote:
>
> >
> > These features (broadly speaking) are different however. According to the
> > above policy:
> > "Exceptions to requiring secure contexts"
> > " - other browsers already ship the feature insecurely"
> >
> > Most (all?) of the non-trivial features above have shipped in other
> > browsers insecurely before shipping in Firefox, hence the above exception
> > applies.
> >
>
> 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.

I'd argue that the color example is a "trivial" feature, unlike subgrid. But the original framer of the policy would have a better understanding of what that meant.

FWIW most new CSS features are placed behind values/etc, so I don't believe that is the distinction in the policy.

>
> > "subgrid" is different as Firefox is shipping this feature first.
> >
>
> I believe we were also first to ship the support for multiple display
> values, but again those are values. And I think we're the first on
> ::marker. These were not restricted.

Again "multiple dipslay values" are probably in the "trivial" feature bucket (if that exists).

::marker (which seems like it was only shipped recently) probably should have been restricted to secure contexts by this policy?

>
> > > As far as I know we don't even have a mechanism that I could
> > > have used to restrict subgrid to secure contexts. And to be
> > > clear: I have no intention of blocking subgrid on waiting for
> > > such a mechanism.
> >
> > This should just involve passing a isSecureContext flag into the your CSS
> > parser?
> >
>
> There's also the consideration as to whether allowing grid in non-secure
> contexts, but NOT subgrid, even makes sense. I think it would oddly
> fracture support for grid layouts as a whole (or at least potentially make
> things confusing for developers — it's certainly more confusing than just
> restricting access to a single property like backdrop-filter or something).
> Perhaps we should ask what the value of restricting only subgrid to secure
> contexts even brings. If part of the spirit of the policy (at least the
> part that applies here) is to quicken adoption of secure contexts, is the
> value of subgrid's contribution to this endeavor worth the trade-off of
> potential user confusion?

For almost any CSS feature you could make a similar argument I believe.

I think one interesting part here is that (from my knowledge) this policy actually hasn't been applied yet, due to the "other browsers shipping insecurely" exception.

But all good questions!

>
> > Given this shouldn't a "...Mozilla’s Distinguished Engineers to judge the
> > outcome..."?
> >
>
> It's an interesting test of the policy. Thanks for bringing it up :)

No problem!

I trust the Mozilla community will decide on a reasonable outcome, and update the policy if necessary.

[Emilio Cobos Álvarez]

Kinda. For this case that'd probably be enough, since you are not
introducing a new property... The general case (handle different
properties being exposed differently in different contexts) is quite a
bit more work, since stuff like serialization of shorthands in a
declaration block could change depending on whether you're in a secure
context or not, for example.

I'm not particularly convinced of the value of restricting subgrid to
secure contexts (specially given no other CSS feature like that actually
is, and that it makes the feature harder to use by stuff like frameworks
or what not). But if people like Anne or Boris think it's valuable I'm
ok making this change. As people have pointed out, the policy is a bit
ambiguous as this could be seen as extending an existing feature or a
new feature.

AFAICT, modulo paint() in Chrome, which has an associated
[SecureContext] JS API, nobody has shipped such a restriction for any
new CSS feature whatsoever. For new features we've implemented:

* @supports selector():
https://groups.google.com/d/msg/mozilla.dev.platform/JNLPcIZRd2w/r6Boq0h2BQAJ
(I included my rationale for not doing this)

* The syntax changes to the display property:
https://groups.google.com/d/msg/mozilla.dev.platform/0WFI1WvBbic/2yVDD9_UCwAJ

* clip-path: path():
https://groups.google.com/d/msg/mozilla.dev.platform/RM5O36MZ4x4/FV5Tp9y4EQAJ

* Various text-decoration bits:
https://groups.google.com/d/msg/mozilla.dev.platform/Xsts-2ORpRY/j96vHsIRAAAJ


I guess the last two were implemented by safari at that point so we have
that escape hatch.

Chromium hasn't been doing any better either, which I guess it's not
necessarily an excuse... From a quick test, CSS.registerProperty and all
of Typed OM is available in non-secure contexts.

If people decide that following that post to the letter for the specific
case of subgrid is worth it I'm happy to do that, but in general (and
based on the above data) I think the post you linked too aggressive, and
having a hard mode switch between secure / non-secure contexts,
specially for "regular" CSS features that don't have associated
Javascript APIs, doesn't sound particularly appealing to me.

And finally, thanks for starting this discussion Ian, I think it's worth
clarifying the situation here.

-- Emilio

[Mats Palmgren]

On 10/18/19 12:31 AM, ikilp...@chromium.org wrote:
> I think one interesting part here is that (from my knowledge) this
> policy actually hasn't been applied yet, due to the "other browsers
> shipping insecurely" exception.

Do other vendors apply the same policy for new CSS features?

For example, Safari recently shipped a bunch of color scheme features:
https://webkit.org/blog/8840/dark-mode-support-in-webkit/
Are those restricted to secure contexts?

I'd argue that if other vendors don't apply the same policy then our
policy is pointless since it comes down to chance whether another
vendor shipped it for non-secure contexts first. And even if we
did follow our own policy when we're first, if another vendor then
ships it insecurely we'd have to enable it for non-secure contexts
too for web-compat reasons.


/Mats

[Mats Palmgren]

On 10/18/19 12:31 AM, ikilp...@chromium.org wrote:

> Again "multiple dipslay values" are probably in the "trivial" feature
> bucket (if that exists).

FYI, those weren't just syntax changes - we also added layout support
for 'inline list-item' and 'block ruby' for example, which I wouldn't
call trivial (not in the sense of "adding a new color value" anyway).


/Mats

[Emilio Cobos Álvarez]

On 10/18/19 12:31 AM, ikilp...@chromium.org wrote:

> ::marker (which seems like it was only shipped recently) probably should have been restricted to secure contexts by this policy?

FWIW (regardless of my opinion about the policy which I've stated on
another post) Safari does ship ::marker since long time ago.

-- Emilio

[Cameron McCormack]

On Fri, Oct 18, 2019, at 9:31 AM, ikilp...@chromium.org wrote:
> I'd argue that the color example is a "trivial" feature, unlike
> subgrid. But the original framer of the policy would have a better
> understanding of what that meant.
>
> FWIW most new CSS features are placed behind values/etc, so I don't
> believe that is the distinction in the policy.

That's true. And I agree it is not "trivial". The policy is (rightly) vague so we can make a judgement call, though I would probably side with others in thinking that this is an extension of an existing feature.

But I think we've ended up with practical considerations dictating whether we restrict a given CSS feature to secure contexts. I have some half written patches from a couple of years ago to add support in Gecko for hiding individual properties (though not values) behind a secure context flag. I ran into the issues that Emilio mentioned, where it affects shorthand serialization in a way that is not as easy to handle as pref-controlled properties, and would result in additional state propagated down onto declaration objects. Far from impossible to handle, but it made us stop and think whether it was worth it.

If I remember correctly, when the issue of gating CSS features behind secure contexts was brought up in the CSS Working Group last, the response was tepid.

So at this point I wonder whether it is worth trying to restrict features at the CSS syntax level. Secure context restrictions are a kind of best effort thing to help encourage authors to switch to https, and it's not necessary for 100% of new features to be restricted to achieve that. Unlike Web IDL defined features, where it's easy to drop in [SecureContext] in the spec and in our implementations, there is some work involved here to restrict CSS properties or values. If other vendors are willing to add the ability to make CSS properties and values be unavailable in secure contexts to their engines, then I can resurrect my patches. But if that's not likely to happen, I think it's probably best to concentrate our restriction efforts on DOM APIs, where I believe it's still the right thing to do. (Including for Paint API.)

I'm curious to hear if others think differently.

Thanks for raising this Ian, and I hope we can clarify our policy as a result of this discussion.

Cameron

[Daniel Veditz]

>From my (personal) security-team perspective this is a fine pragmatic
approach. Our overriding primary concern is whether exposing these new CSS
features over insecure transport puts our users at additional risk. I don't
see any meaningful privacy exposure here since these new features will be
in a stylesheet that's already insecure, and style doesn't typically
contain user data. There will be additional "attack surface" of course
(more features ~= more bugs) but it's trivially easy for an attacker to use
a secure stylesheet instead if that's required to access a buggy feature.

Coercing site authors into better behavior is a secondary concern (user
safety, once removed), and some amount of pragmatism is acceptable. These
features are being standardized through the W3C, and given W3C statements
about the importance of switching the web to secure transport we should
give those standards bodies a chance to do the appropriate thing. Web
compatibility with other browsers is important given Mozilla's market
share, and while we can take a stand against compatibility (and have) when
there's demonstrable user harm from a feature, these incremental additions
to CSS don't appear to come anywhere close to that bar.

-Dan Veditz

[Tantek Çelik]

Thanks Dan. I concur with the priorities, impacts, and conclusions
you've outlined.

In practice I believe 100% of the CSS features we have shipped (Intent
to Implement/Ship emails) in the past year+ have been exposed to
insecure contexts.

Based on your reasoning, and our consistent intent emails and shipping
behavior, I think we should consider updating the blog post on this
matter regarding all CSS features (cc: annevk), or posting a separate
update post accordingly, using the reasoning you've provided as our
guidance. I'd prefer the former as many have linked to that blog post.

Thanks,
Tantek

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Daniel Veditz]

On Fri, Oct 18, 2019 at 4:27 PM Tantek Çelik <tan...@cs.stanford.edu> wrote:

> Based on your reasoning, and our consistent intent emails and shipping
> behavior, I think we should consider updating the blog post on this
> matter regarding all CSS features (cc: annevk), or posting a separate
> update post accordingly, using the reasoning you've provided as our
> guidance.

Just to be clear I was not talking about "all" CSS features but mainly the
ones specified in text/css stylesheets. New CSS features that are
implemented through JavaScript APIs (like CSS Painting API) ought to be
restricted, and exemptions should require an explicit compelling argument.
Browsers have already invented mechanisms to expose properties
conditionally so it's not an implementation burden, and it's possible for
web developers to do feature detection and deal with it. The calculus comes
out differently.

[I note the CSS Painting API spec doesn't mention such restrictions
currently, but Chrome's implementation seems to have done so anyway.]

-Dan Veditz

[Tantek Çelik]

Agreed with clarification. Declarative text/css stylesheets not
restricted. Imperative new APIs (like Houdini APIs) should be
restricted to secure contexts by default. Thanks, Tantek

[L. David Baron]

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)

[Mike Taylor]

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

[L. David Baron]

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.

[James Graham]

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.

[Ashley Gullen]

On a practical point as a web developer, in this case CSS subgrid is a part
of the wider CSS grid feature. It seems odd to make parts of the CSS grid
feature available in insecure contexts while other parts (subgrid) are
unavailable. I would argue this decision should have been made for the CSS
grid feature as a whole, and apply consistently to all aspects of the CSS
grid feature, so we don't end up with the compatibility nightmare of
bits-and-pieces of features being available in some cases but not others.