Re: Intent to ship: CSS subgrid

[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.


On Tue, 22 Oct 2019 at 09:54, James Graham  wrote:

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

Re: Intent to ship: CSS subgrid

[James Graham]

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

Re: Intent to ship: CSS subgrid

[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.

-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

Re: Intent to ship: CSS subgrid

[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 
, 
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

Re: Intent to ship: CSS subgrid

[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
  https://w3c.github.io/webappsec-secure-contexts/;>secure 
contexts.
  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
  https://www.w3.org/2001/tag/doc/web-https;>Securing the Web.
  
  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 

Re: Intent to ship: CSS subgrid

[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

On Fri, Oct 18, 2019 at 4:53 PM Daniel Veditz  wrote:
>
> On Fri, Oct 18, 2019 at 4:27 PM Tantek Çelik  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Daniel Veditz]

On Fri, Oct 18, 2019 at 4:27 PM Tantek Çelik  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[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




On Fri, Oct 18, 2019 at 10:32 AM Daniel Veditz  wrote:
>
> 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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

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

Re: Intent to ship: CSS subgrid

[Cameron McCormack]

On Fri, Oct 18, 2019, at 9:31 AM, ikilpatr...@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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Emilio Cobos Álvarez]

On 10/18/19 12:31 AM, ikilpatr...@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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Mats Palmgren]

On 10/18/19 12:31 AM, ikilpatr...@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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Emilio Cobos Álvarez]

On 10/17/19 10:02 PM, ikilpatr...@chromium.org wrote:

On Thursday, October 17, 2019 at 12:47:27 PM UTC-7, Mats Palmgren wrote:

On 10/17/19 8:12 PM, ikilpatr...@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?



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

Re: Intent to ship: CSS subgrid

[ikilpatrick]

On Thursday, October 17, 2019 at 3:15:49 PM UTC-7, Sean Voisen wrote:
> On Thu, Oct 17, 2019 at 1:05 PM  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Sean Voisen]

On Thu, Oct 17, 2019 at 1:05 PM  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 :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[ikilpatrick]

On Thursday, October 17, 2019 at 12:47:27 PM UTC-7, Mats Palmgren wrote:
> On 10/17/19 8:12 PM, ikilpatr...@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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Mats Palmgren]

On 10/17/19 8:12 PM, ikilpatr...@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.

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

Re: Intent to ship: CSS subgrid

[ikilpatrick]

On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren wrote:
> On 10/17/19 5:35 PM, ikilpatr...@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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS subgrid

[Mats Palmgren]

On 10/17/19 5:35 PM, ikilpatr...@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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform