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
