Re: Status of deprecating non-secure HTTP

[Boris Zbarsky]

On 9/25/17 11:45 AM, L. David Baron wrote:

So I don't think this requires any new *features* to be spec'd in
CSS (since @supports would work, and is the right thing to use),
although it probably does require a small amount of new spec prose
to explain how it works.


Well, it would need spec text somewhere that explains how to determine 
whether a stylesheet is a "secure context".


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

Re: Status of deprecating non-secure HTTP

[L. David Baron]

On Monday 2017-09-25 09:12 -0400, Boris Zbarsky wrote:
> On 9/25/17 9:01 AM, Anne van Kesteren wrote:
> > It does not seem hard to come up with solutions to those problems, if
> > we're actually committed to going down this path.
> 
> If we are, yes.  We need to decide whether we are...
> 
> > (E.g., just like globals have isSecureContext,
> > there could be a media query that can be used from CSS for the same
> > purpose. Or @supports could be used if we make parsing fail.)
> 
> Right, so we could block worklets on new CSS features to be specced in the
> CSSWGs copious free time.  ;)  I say this tongue-in-cheek, but the CSS
> editing situation is pretty horrible.  We _still_ don't have a spec for
>  at all, in any meaningful sense.  :(

I don't think this is a big deal.  What I proposed in
https://github.com/w3ctag/design-principles/pull/75 (which I think
the TAG will have a full discussion of this week) was that the
secure context restriction apply at the points where major features are
commonly added, and when they're feature-detectable.  So for new CSS
features restricted to a secure context, they wouldn't parse in a
non-secure context, and @supports would do the right thing.

So I don't think this requires any new *features* to be spec'd in
CSS (since @supports would work, and is the right thing to use),
although it probably does require a small amount of new spec prose
to explain how it works.

-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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Status of deprecating non-secure HTTP

[Boris Zbarsky]

On 9/25/17 9:01 AM, Anne van Kesteren wrote:

It does not seem hard to come up with solutions to those problems, if
we're actually committed to going down this path.


If we are, yes.  We need to decide whether we are...


(E.g., just like globals have isSecureContext,
there could be a media query that can be used from CSS for the same
purpose. Or @supports could be used if we make parsing fail.)


Right, so we could block worklets on new CSS features to be specced in 
the CSSWGs copious free time.  ;)  I say this tongue-in-cheek, but the 
CSS editing situation is pretty horrible.  We _still_ don't have a spec 
for  at all, in any meaningful sense.  :(


-Boris

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

Re: Status of deprecating non-secure HTTP

[Anne van Kesteren]

On Mon, Sep 25, 2017 at 2:47 PM, Boris Zbarsky  wrote:
> On 9/25/17 3:18 AM, Anne van Kesteren wrote:
>> But it would also be good if we could all communicate this on behalf
>> of Mozilla without caveats. E.g., Chrome might ship worklets soon and
>> being able to object to that happening (specification-wise) on
>> insecure contexts on behalf of Mozilla would be good.
>
> The Chrome intent to shop thread for CSS paint raises some good concerns
> about what exactly it would mean to not support paint worklets in insecure
> contexts.  Do they still parse but just fail to paint?  Do the not parse?
> Note that a _stylesheet_ doesn't have a concept of secure or insecure
> context right now

It does not seem hard to come up with solutions to those problems, if
we're actually committed to going down this path. Especially if we're
all aligned that the goal is restrict as many new features to secure
contexts as possible. (E.g., just like globals have isSecureContext,
there could be a media query that can be used from CSS for the same
purpose. Or @supports could be used if we make parsing fail.)


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

Re: Status of deprecating non-secure HTTP

[Boris Zbarsky]

On 9/25/17 3:18 AM, Anne van Kesteren wrote:

But it would also be good if we could all communicate this on behalf
of Mozilla without caveats. E.g., Chrome might ship worklets soon and
being able to object to that happening (specification-wise) on
insecure contexts on behalf of Mozilla would be good.


The Chrome intent to shop thread for CSS paint raises some good concerns 
about what exactly it would mean to not support paint worklets in 
insecure contexts.  Do they still parse but just fail to paint?  Do the 
not parse?  Note that a _stylesheet_ doesn't have a concept of secure or 
insecure context right now


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