SecureContext requirements for all new features?

[Rick Byers]

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

Thoughts?

   Rick

---------- Forwarded message ----------
From: Jochen Eisinger <joc...@chromium.org>
Date: Thu, Sep 21, 2017 at 10:48 AM
Subject: Re: [blink-dev] Intent to Ship: CSS Paint API
To: Jeremy Roman <jbr...@chromium.org>
Cc: Mike West <mk...@chromium.org>, Ian Kilpatrick <ikilp...@chromium.org>, Rick Byers <rby...@google.com>, Boris Zbarsky <bzba...@mit.edu>, Xida Chen <xida...@chromium.org>, Matt Falkenhagen <fal...@chromium.org>, "blin...@chromium.org" <blin...@chromium.org>

On Tue, Sep 19, 2017 at 6:05 PM Jeremy Roman <jbr...@chromium.org> wrote:

On Tue, Sep 19, 2017 at 5:53 PM, Mike West <mk...@chromium.org> wrote:

Thanks for calling this out, Ian!

On Tue, Sep 19, 2017 at 9:56 AM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

One thing that was pointed out specifically on:

https://github.com/w3c/css-houdini-drafts/pull/379#discussion_r134282891

...which annevk mentioned was the concerns around secure contexts.

The minutes from the last time the HoudiniTF discussed this is here:

https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html

This is a difficult decision for this API. On the one hand its a new capability, which we typically try to ship for secure contexts only to aid in secure context adoption.

On the other hand the discussion with the HoudiniTF brings up some issues, specifically:

 - No ability to detect having a secure context within CSS. E.g. a CSS framework using this feature can't detect if its within a secure context. 

This seems like an argument for feature detection inside CSS rather than rejection of a constraint that would require feature detection. It seems that you'll need feature detection one way or the other, since the behavior specified by the `paint(...)` CSS value depends on support from the JavaScript side, right?

 

 - This subsets the rendering engine with feature policy - which we haven't done before, e.g. css grid wasn't shipped only to secure contexts.

I'd suggest that we need to start somewhere. The fact that this feature bridges across CSS (where we apparently don't have good feature-detection mechanisms) and JavaScript (where we do) makes it a pretty reasonable starting point, in my opinion.

(CSS non-expert question, sorry)

Can CSS @supports be used to detect this?

@supports (background: paint(foo)) { /* ... */ }

 

The discussion with the HoudiniTF (and TAG members who were in the room) didn't come to a concrete conclusion.

We can add [SecureContext] to the Worklet interface and CSS.paintWorklet attribute initially, and then relax, but would like to hear additional thoughts.

I don't think that fragmentation is a valid argument. We already have the web fragmented in secure and insecure, and we should just stop adding stuff to the insecure fragment.

This is not about pushing something forward via unrelated features, it is just that the modern web only exists on secure contexts.

 

However the above would be strange as there would be a difference between:

.no-paint-api {

  background: /* fallback */;

  background: paint(foo);

}

.paint-api-on-non-secure-context {

  background: /* fallback */;

  background: paint(foo); /* valid - but nothing displayed */

}

Why would this be valid? It would seem to make sense to treat this as `.no-paint-api` above which falls back to the workable definition. This is the approach we've taken in IDL by specifying `[SecureContext]` on a given interface/attribute/method, which removes it from the global object entirely if it's not a secure context.

 

.paint-api-on-secure-context {

  background: /* fallback */;

  background: paint(foo); /* valid - paint api displayed */

}

(The above is typically how a developer performs CSS fallback.)

On Thursday, September 14, 2017, Boris Zbarsky <bzba...@mit.edu> wrote:

On 9/11/17 9:58 AM, Emilio Cobos Álvarez wrote:

Yeah, I guess the "Intent to experiment"[1] does count as a positive
signal though :)...
[1]:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/uI5bHZil2KU

I should note that the "Risks" section of that is very real, and I have seen no evidence that the risks have been addressed.

As far as I can tell, the current state of this in Gecko is:

1) We're evaluating whether the idea makes sense at all, but the evaluation has stalled because it got deprioritized relative to other things.

2) We're not clear on whether it's a _good_ idea even if it does make sense as something one could do.

That's just on the basic concept.  I haven't been following the spec situation enough to tell you whether there are problems on that end.

-Boris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c580d3a3-d9d2-1882-b974-33ac706c0837%40mit.edu.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpR68bc8E8zqETudryw-gDo4i2S1Y0MycUOsyNnU%3D4mnEQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcimBE%2BC0d8-L2FC3y05XJC1uo6RfyFLR2g3t54gxpZ2w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13eLrmYas2hpTtu%3D4vSKSFGdHw7m14uBtUtY9H%3D%3D2bEjJg%40mail.gmail.com.

[Jochen Eisinger]

Thanks for forking the discussion!

On Fri, Sep 22, 2017 at 7:36 AM Rick Byers <rby...@chromium.org> wrote:

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

That's not how I see it. The "powerful" attribute is only useful when looking at existing features, when we consider the trade-off between breaking existing content and protecting users.

 

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

[Mike West]

Hey Rick!

I do personally believe that the bar for new features can be significantly higher than "powerful" (which seems like a reasonable bar for deprecation of old features). I haven't yet convinced the security team and/or wider Chrome team to join me in that personal belief, but Emily^2 and I have had productive conversations on that front (I owe them a document on that point). I also agree with you that whatever our policy, it should be applied across intents equally, and not piecemeal.

I don't intend to hold Worklets hostage, but I'm asking about this intent in particular because I raised the question of adding a security/privacy considerations section for Worklets in 2015, and there's still not one in the document. Ian has a patch out to add such a section, Anne asked about secure contexts in August, and didn't get a response until this thread.

I'd additionally note that the objections in this thread to adding such a requirement were not "That's a bad idea!" but "We don't have feature detection ability in CSS.", which I think is well worth pushing back against as a justification. The CSSWG discussion of this topic at https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html is worth reading here, and there's healthy (though by no means unanimous) support for restrictions in those minutes. It looks like they punted to the TAG, which is discussing the question in https://github.com/w3ctag/design-principles/issues/32 and https://github.com/w3ctag/design-principles/pull/75.

On Fri, Sep 22, 2017 at 3:14 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Thanks for forking the discussion!

On Fri, Sep 22, 2017 at 7:36 AM Rick Byers <rby...@chromium.org> wrote:

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

That's not how I see it. The "powerful" attribute is only useful when looking at existing features, when we consider the trade-off between breaking existing content and protecting users.

Along with agreeing with Jochen's suggestion here, I suspect that I take a broader view of "powerful" than you do, Rick. :) 

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

-mike 

[Rick Byers]

Jochen, Ojan and I had a friendly debate about this in Tokyo.  We realized we disagreed on our perception of what fraction of new development was likely done on sites that support (or require) https.  Jochen proposed adding some UseCounters for a variety of new features to track what fraction of PageVisits involving new features are secure.  This seems useful to me but since we're concerned here with developer impact, not user impact, I worry it biases heavily towards a small number of very large well-funded sites.  I argued the better metric was "what fraction of domains that are using new features support https", giving developers more equal weight.  Ojan and I suggested that maybe reaching a threshold like 90% of such domains would make such a policy reasonable (effectively impacting <10% of developers), while Jochen argued that something more like 50% seemed reasonable to him. Jochen indicated collecting such data seemed valuable in making progress in this debate.

I like this direction and encourage the folks interested in pursuing this policy to gather some hard data like this to quantify the developer impact.  Big picture, if it's true that the vast majority of new development is occurring on sites that already support https (i.e. we really have largely forked the web into legacy and new-https), then I think it's possible I could be convinced of this policy. There's still a question of whether library development can depend on being used in an https document, so it may not be enough for the site to support https but that it actually require https (to what extent could all sites that support https reasonably move to hsts to require it?). But this (and a reasonable threshold) seem like details we can hash out as we get a better picture with hard data.

More inline...

On Friday, September 22, 2017, 'Mike West' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Hey Rick!

I do personally believe that the bar for new features can be significantly higher than "powerful" (which seems like a reasonable bar for deprecation of old features). I haven't yet convinced the security team and/or wider Chrome team to join me in that personal belief, but Emily^2 and I have had productive conversations on that front (I owe them a document on that point). I also agree with you that whatever our policy, it should be applied across intents equally, and not piecemeal.

I don't intend to hold Worklets hostage, but I'm asking about this intent in particular because I raised the question of adding a security/privacy considerations section for Worklets in 2015, and there's still not one in the document. Ian has a patch out to add such a section, Anne asked about secure contexts in August, and didn't get a response until this thread.

That's definitely not great. I'm happy to hold this intent on having consensus on a security and privacy section getting added to the spec. 

I'd additionally note that the objections in this thread to adding such a requirement were not "That's a bad idea!" but "We don't have feature detection ability in CSS.", which I think is well worth pushing back against as a justification. The CSSWG discussion of this topic at https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html is worth reading here, and there's healthy (though by no means unanimous) support for restrictions in those minutes. It looks like they punted to the TAG, which is discussing the question in https://github.com/w3ctag/design-principles/issues/32 and https://github.com/w3ctag/design-principles/pull/75.

100% agree that's not an adequate reason (eg. I wouldn't accept it as a reason not to require a secure context for some new privacy-impacting CSS API).

On Fri, Sep 22, 2017 at 3:14 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Thanks for forking the discussion!

On Fri, Sep 22, 2017 at 7:36 AM Rick Byers <rby...@chromium.org> wrote:

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

That's not how I see it. The "powerful" attribute is only useful when looking at existing features, when we consider the trade-off between breaking existing content and protecting users.

Along with agreeing with Jochen's suggestion here, I suspect that I take a broader view of "powerful" than you do, Rick. :) 

I agree with this characterization that that policy is all about existing features, and so the trade-off with web compat. Thanks for clarifying

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

For something of the same scope of "should I support https", I'd agree.  I.e. if we were talking about an API that impacts a whole application (eg. a new HTTP header, origin policy, or manifest extension) then I think this argument would apply.

But most new web features have a finer scope than that - that of a library.  A library doesn't get to dictate whether the application is available via HTTPS or not.  For APIs expected to be used by libraries, requiring https can effectively make the api impossible to adopt for the library.  Eg. component libraries like Polymer have UI widgets implemented with a number of divs today and seek to be usable in all sorts of apps. If we told the Polymer team they could only use Custom Paint by restricting their libraries to be used in documents served via https, I strongly suspect they would just stick with the slower/heavier solution they have today (or, best case, maintain both the http and https versions of a widget indefinitely). If we did success in convincing Polymer to require https, I suspect it would cause a significant number of sites to stick with the older version of polymer they have that already works.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

I think this argument carries the most weight when the "non-trivial work" YOU have to do is within the magnitude of work you have to do to adopt HTTPS.  Eg. for my own tiny personal site rbyers.net, I still don't support https because I don't want the hassle of remembering to upgrade my certificate every couple of years and so I'm waiting for AppEngine to (finally) support Let's Encrypt automation (for many other people the constraint is the cost when their hosting doesn't support automation). Contrast this "work" to the dev work required to drop in a new version of a UI library I'm using.  It's significantly more work to add support for https than to update a library, so in practice I'll just not use the new API rather than take the pain.

-mike 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DfHDyULTZ%2BjN3eno04hKcCgDn0FpmKFtc3P7ABhuWFuZw%40mail.gmail.com.

[Emily Stark]

As Mike knows, I have mixed feelings on this issue. :) I definitely think the "powerful features" policy should apply only to deprecations and something stronger/stricter should apply to new features. Restricting all new features to HTTPS would, I think, send a strong message that if you want to be on the web these days, you have to be HTTPS for reals. OTOH, I'm concerned about burning the goodwill of both web developers and feature owners. I think there is more work to be done before we can require HTTPS for all new features without burning lots of goodwill. (For example: AppEngine should make it *hard* to set up an http-only site.)

On Sun, Sep 24, 2017 at 5:23 PM, Rick Byers <rby...@chromium.org> wrote:

Jochen, Ojan and I had a friendly debate about this in Tokyo.  We realized we disagreed on our perception of what fraction of new development was likely done on sites that support (or require) https.  Jochen proposed adding some UseCounters for a variety of new features to track what fraction of PageVisits involving new features are secure.  This seems useful to me but since we're concerned here with developer impact, not user impact, I worry it biases heavily towards a small number of very large well-funded sites.  I argued the better metric was "what fraction of domains that are using new features support https", giving developers more equal weight.  Ojan and I suggested that maybe reaching a threshold like 90% of such domains would make such a policy reasonable (effectively impacting <10% of developers), while Jochen argued that something more like 50% seemed reasonable to him. Jochen indicated collecting such data seemed valuable in making progress in this debate.

I like this direction and encourage the folks interested in pursuing this policy to gather some hard data like this to quantify the developer impact.  Big picture, if it's true that the vast majority of new development is occurring on sites that already support https (i.e. we really have largely forked the web into legacy and new-https), then I think it's possible I could be convinced of this policy. There's still a question of whether library development can depend on being used in an https document, so it may not be enough for the site to support https but that it actually require https (to what extent could all sites that support https reasonably move to hsts to require it?). But this (and a reasonable threshold) seem like details we can hash out as we get a better picture with hard data.

More inline...

On Friday, September 22, 2017, 'Mike West' via blink-api-owners-discuss <blink-api-owners-discuss@chromium.org> wrote:

Hey Rick!

I do personally believe that the bar for new features can be significantly higher than "powerful" (which seems like a reasonable bar for deprecation of old features). I haven't yet convinced the security team and/or wider Chrome team to join me in that personal belief, but Emily^2 and I have had productive conversations on that front (I owe them a document on that point). I also agree with you that whatever our policy, it should be applied across intents equally, and not piecemeal.

I don't intend to hold Worklets hostage, but I'm asking about this intent in particular because I raised the question of adding a security/privacy considerations section for Worklets in 2015, and there's still not one in the document. Ian has a patch out to add such a section, Anne asked about secure contexts in August, and didn't get a response until this thread.

That's definitely not great. I'm happy to hold this intent on having consensus on a security and privacy section getting added to the spec. 

I'd additionally note that the objections in this thread to adding such a requirement were not "That's a bad idea!" but "We don't have feature detection ability in CSS.", which I think is well worth pushing back against as a justification. The CSSWG discussion of this topic at https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html is worth reading here, and there's healthy (though by no means unanimous) support for restrictions in those minutes. It looks like they punted to the TAG, which is discussing the question in https://github.com/w3ctag/design-principles/issues/32 and https://github.com/w3ctag/design-principles/pull/75.

100% agree that's not an adequate reason (eg. I wouldn't accept it as a reason not to require a secure context for some new privacy-impacting CSS API).

On Fri, Sep 22, 2017 at 3:14 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Thanks for forking the discussion!

On Fri, Sep 22, 2017 at 7:36 AM Rick Byers <rby...@chromium.org> wrote:

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

That's not how I see it. The "powerful" attribute is only useful when looking at existing features, when we consider the trade-off between breaking existing content and protecting users.

Along with agreeing with Jochen's suggestion here, I suspect that I take a broader view of "powerful" than you do, Rick. :) 

I agree with this characterization that that policy is all about existing features, and so the trade-off with web compat. Thanks for clarifying

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

For something of the same scope of "should I support https", I'd agree.  I.e. if we were talking about an API that impacts a whole application (eg. a new HTTP header, origin policy, or manifest extension) then I think this argument would apply.

But most new web features have a finer scope than that - that of a library.  A library doesn't get to dictate whether the application is available via HTTPS or not.  For APIs expected to be used by libraries, requiring https can effectively make the api impossible to adopt for the library.  Eg. component libraries like Polymer have UI widgets implemented with a number of divs today and seek to be usable in all sorts of apps. If we told the Polymer team they could only use Custom Paint by restricting their libraries to be used in documents served via https, I strongly suspect they would just stick with the slower/heavier solution they have today (or, best case, maintain both the http and https versions of a widget indefinitely). If we did success in convincing Polymer to require https, I suspect it would cause a significant number of sites to stick with the older version of polymer they have that already works.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

I think this argument carries the most weight when the "non-trivial work" YOU have to do is within the magnitude of work you have to do to adopt HTTPS.  Eg. for my own tiny personal site rbyers.net, I still don't support https because I don't want the hassle of remembering to upgrade my certificate every couple of years and so I'm waiting for AppEngine to (finally) support Let's Encrypt automation (for many other people the constraint is the cost when their hosting doesn't support automation). Contrast this "work" to the dev work required to drop in a new version of a UI library I'm using.  It's significantly more work to add support for https than to update a library, so in practice I'll just not use the new API rather than take the pain.

-mike 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

[Ojan Vafai]

It's not just library authors, but also third party embeds that are unable to use the modern web in this model. As a concrete example, ads org is considerably less inclined to use serviceworker. Their JS and iframe content is all https, but they are often embedded on http pages. We could get numbers from doubleclick, but iirc the number of http pages they are on is quite high both as percentage of page loads and percentage of domains.

I'd really encourage that we get hard numbers on the impact this would have on developers (both site owners and popular libraries/embeds) as the next step in this proposal.

On Tue, Sep 26, 2017, 4:52 AM Emily Stark <est...@chromium.org> wrote:

As Mike knows, I have mixed feelings on this issue. :) I definitely think the "powerful features" policy should apply only to deprecations and something stronger/stricter should apply to new features. Restricting all new features to HTTPS would, I think, send a strong message that if you want to be on the web these days, you have to be HTTPS for reals. OTOH, I'm concerned about burning the goodwill of both web developers and feature owners. I think there is more work to be done before we can require HTTPS for all new features without burning lots of goodwill. (For example: AppEngine should make it *hard* to set up an http-only site.)

On Sun, Sep 24, 2017 at 5:23 PM, Rick Byers <rby...@chromium.org> wrote:

Jochen, Ojan and I had a friendly debate about this in Tokyo.  We realized we disagreed on our perception of what fraction of new development was likely done on sites that support (or require) https.  Jochen proposed adding some UseCounters for a variety of new features to track what fraction of PageVisits involving new features are secure.  This seems useful to me but since we're concerned here with developer impact, not user impact, I worry it biases heavily towards a small number of very large well-funded sites.  I argued the better metric was "what fraction of domains that are using new features support https", giving developers more equal weight.  Ojan and I suggested that maybe reaching a threshold like 90% of such domains would make such a policy reasonable (effectively impacting <10% of developers), while Jochen argued that something more like 50% seemed reasonable to him. Jochen indicated collecting such data seemed valuable in making progress in this debate.

I like this direction and encourage the folks interested in pursuing this policy to gather some hard data like this to quantify the developer impact.  Big picture, if it's true that the vast majority of new development is occurring on sites that already support https (i.e. we really have largely forked the web into legacy and new-https), then I think it's possible I could be convinced of this policy. There's still a question of whether library development can depend on being used in an https document, so it may not be enough for the site to support https but that it actually require https (to what extent could all sites that support https reasonably move to hsts to require it?). But this (and a reasonable threshold) seem like details we can hash out as we get a better picture with hard data.

More inline...

On Friday, September 22, 2017, 'Mike West' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Hey Rick!

I do personally believe that the bar for new features can be significantly higher than "powerful" (which seems like a reasonable bar for deprecation of old features). I haven't yet convinced the security team and/or wider Chrome team to join me in that personal belief, but Emily^2 and I have had productive conversations on that front (I owe them a document on that point). I also agree with you that whatever our policy, it should be applied across intents equally, and not piecemeal.

I don't intend to hold Worklets hostage, but I'm asking about this intent in particular because I raised the question of adding a security/privacy considerations section for Worklets in 2015, and there's still not one in the document. Ian has a patch out to add such a section, Anne asked about secure contexts in August, and didn't get a response until this thread.

That's definitely not great. I'm happy to hold this intent on having consensus on a security and privacy section getting added to the spec. 

I'd additionally note that the objections in this thread to adding such a requirement were not "That's a bad idea!" but "We don't have feature detection ability in CSS.", which I think is well worth pushing back against as a justification. The CSSWG discussion of this topic at https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html is worth reading here, and there's healthy (though by no means unanimous) support for restrictions in those minutes. It looks like they punted to the TAG, which is discussing the question in https://github.com/w3ctag/design-principles/issues/32 and https://github.com/w3ctag/design-principles/pull/75.

100% agree that's not an adequate reason (eg. I wouldn't accept it as a reason not to require a secure context for some new privacy-impacting CSS API).

On Fri, Sep 22, 2017 at 3:14 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Thanks for forking the discussion!

On Fri, Sep 22, 2017 at 7:36 AM Rick Byers <rby...@chromium.org> wrote:

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

That's not how I see it. The "powerful" attribute is only useful when looking at existing features, when we consider the trade-off between breaking existing content and protecting users.

Along with agreeing with Jochen's suggestion here, I suspect that I take a broader view of "powerful" than you do, Rick. :) 

I agree with this characterization that that policy is all about existing features, and so the trade-off with web compat. Thanks for clarifying

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

For something of the same scope of "should I support https", I'd agree.  I.e. if we were talking about an API that impacts a whole application (eg. a new HTTP header, origin policy, or manifest extension) then I think this argument would apply.

But most new web features have a finer scope than that - that of a library.  A library doesn't get to dictate whether the application is available via HTTPS or not.  For APIs expected to be used by libraries, requiring https can effectively make the api impossible to adopt for the library.  Eg. component libraries like Polymer have UI widgets implemented with a number of divs today and seek to be usable in all sorts of apps. If we told the Polymer team they could only use Custom Paint by restricting their libraries to be used in documents served via https, I strongly suspect they would just stick with the slower/heavier solution they have today (or, best case, maintain both the http and https versions of a widget indefinitely). If we did success in convincing Polymer to require https, I suspect it would cause a significant number of sites to stick with the older version of polymer they have that already works.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

I think this argument carries the most weight when the "non-trivial work" YOU have to do is within the magnitude of work you have to do to adopt HTTPS.  Eg. for my own tiny personal site rbyers.net, I still don't support https because I don't want the hassle of remembering to upgrade my certificate every couple of years and so I'm waiting for AppEngine to (finally) support Let's Encrypt automation (for many other people the constraint is the cost when their hosting doesn't support automation). Contrast this "work" to the dev work required to drop in a new version of a UI library I'm using.  It's significantly more work to add support for https than to update a library, so in practice I'll just not use the new API rather than take the pain.

-mike 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

[Emily Schechter]

I also agree that there is generally more work to be done before we can require HTTPS for all new features, some of which we have planned on Enamel OKRs (investigate adding checkbox to DevTools, enterprise policy, additional documentation etc). I also think implementing (or at least figuring out how to implement) these metrics would be useful. 

On Mon, Sep 25, 2017 at 4:16 PM, Ojan Vafai <oj...@chromium.org> wrote:

It's not just library authors, but also third party embeds that are unable to use the modern web in this model. As a concrete example, ads org is considerably less inclined to use serviceworker. Their JS and iframe content is all https, but they are often embedded on http pages. We could get numbers from doubleclick, but iirc the number of http pages they are on is quite high both as percentage of page loads and percentage of domains.

I'd really encourage that we get hard numbers on the impact this would have on developers (both site owners and popular libraries/embeds) as the next step in this proposal.

On Tue, Sep 26, 2017, 4:52 AM Emily Stark <est...@chromium.org> wrote:

As Mike knows, I have mixed feelings on this issue. :) I definitely think the "powerful features" policy should apply only to deprecations and something stronger/stricter should apply to new features. Restricting all new features to HTTPS would, I think, send a strong message that if you want to be on the web these days, you have to be HTTPS for reals. OTOH, I'm concerned about burning the goodwill of both web developers and feature owners. I think there is more work to be done before we can require HTTPS for all new features without burning lots of goodwill. (For example: AppEngine should make it *hard* to set up an http-only site.)

On Sun, Sep 24, 2017 at 5:23 PM, Rick Byers <rby...@chromium.org> wrote:

Jochen, Ojan and I had a friendly debate about this in Tokyo.  We realized we disagreed on our perception of what fraction of new development was likely done on sites that support (or require) https.  Jochen proposed adding some UseCounters for a variety of new features to track what fraction of PageVisits involving new features are secure.  This seems useful to me but since we're concerned here with developer impact, not user impact, I worry it biases heavily towards a small number of very large well-funded sites.  I argued the better metric was "what fraction of domains that are using new features support https", giving developers more equal weight.  Ojan and I suggested that maybe reaching a threshold like 90% of such domains would make such a policy reasonable (effectively impacting <10% of developers), while Jochen argued that something more like 50% seemed reasonable to him. Jochen indicated collecting such data seemed valuable in making progress in this debate.

I like this direction and encourage the folks interested in pursuing this policy to gather some hard data like this to quantify the developer impact.  Big picture, if it's true that the vast majority of new development is occurring on sites that already support https (i.e. we really have largely forked the web into legacy and new-https), then I think it's possible I could be convinced of this policy. There's still a question of whether library development can depend on being used in an https document, so it may not be enough for the site to support https but that it actually require https (to what extent could all sites that support https reasonably move to hsts to require it?). But this (and a reasonable threshold) seem like details we can hash out as we get a better picture with hard data.

More inline...

On Friday, September 22, 2017, 'Mike West' via blink-api-owners-discuss <blink-api-owners-discuss@chromium.org> wrote:

Hey Rick!

I do personally believe that the bar for new features can be significantly higher than "powerful" (which seems like a reasonable bar for deprecation of old features). I haven't yet convinced the security team and/or wider Chrome team to join me in that personal belief, but Emily^2 and I have had productive conversations on that front (I owe them a document on that point). I also agree with you that whatever our policy, it should be applied across intents equally, and not piecemeal.

I don't intend to hold Worklets hostage, but I'm asking about this intent in particular because I raised the question of adding a security/privacy considerations section for Worklets in 2015, and there's still not one in the document. Ian has a patch out to add such a section, Anne asked about secure contexts in August, and didn't get a response until this thread.

That's definitely not great. I'm happy to hold this intent on having consensus on a security and privacy section getting added to the spec. 

I'd additionally note that the objections in this thread to adding such a requirement were not "That's a bad idea!" but "We don't have feature detection ability in CSS.", which I think is well worth pushing back against as a justification. The CSSWG discussion of this topic at https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html is worth reading here, and there's healthy (though by no means unanimous) support for restrictions in those minutes. It looks like they punted to the TAG, which is discussing the question in https://github.com/w3ctag/design-principles/issues/32 and https://github.com/w3ctag/design-principles/pull/75.

100% agree that's not an adequate reason (eg. I wouldn't accept it as a reason not to require a secure context for some new privacy-impacting CSS API).

On Fri, Sep 22, 2017 at 3:14 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Thanks for forking the discussion!

On Fri, Sep 22, 2017 at 7:36 AM Rick Byers <rby...@chromium.org> wrote:

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

That's not how I see it. The "powerful" attribute is only useful when looking at existing features, when we consider the trade-off between breaking existing content and protecting users.

Along with agreeing with Jochen's suggestion here, I suspect that I take a broader view of "powerful" than you do, Rick. :) 

I agree with this characterization that that policy is all about existing features, and so the trade-off with web compat. Thanks for clarifying

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

For something of the same scope of "should I support https", I'd agree.  I.e. if we were talking about an API that impacts a whole application (eg. a new HTTP header, origin policy, or manifest extension) then I think this argument would apply.

But most new web features have a finer scope than that - that of a library.  A library doesn't get to dictate whether the application is available via HTTPS or not.  For APIs expected to be used by libraries, requiring https can effectively make the api impossible to adopt for the library.  Eg. component libraries like Polymer have UI widgets implemented with a number of divs today and seek to be usable in all sorts of apps. If we told the Polymer team they could only use Custom Paint by restricting their libraries to be used in documents served via https, I strongly suspect they would just stick with the slower/heavier solution they have today (or, best case, maintain both the http and https versions of a widget indefinitely). If we did success in convincing Polymer to require https, I suspect it would cause a significant number of sites to stick with the older version of polymer they have that already works.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

I think this argument carries the most weight when the "non-trivial work" YOU have to do is within the magnitude of work you have to do to adopt HTTPS.  Eg. for my own tiny personal site rbyers.net, I still don't support https because I don't want the hassle of remembering to upgrade my certificate every couple of years and so I'm waiting for AppEngine to (finally) support Let's Encrypt automation (for many other people the constraint is the cost when their hosting doesn't support automation). Contrast this "work" to the dev work required to drop in a new version of a UI library I'm using.  It's significantly more work to add support for https than to update a library, so in practice I'll just not use the new API rather than take the pain.

-mike 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Ojan Vafai]

I think custom paint is a bad example to talk about BTW because it's relatively easy for us to say we don't care if ads just don't use them. But I wouldn't say the same about IntersectionObserver, ServiceWorker, Tasklets, etc.

Happy to talk more about what metrics would be useful.

-mike 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DfHDyULTZ%2BjN3eno04hKcCgDn0FpmKFtc3P7ABhuWFuZw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rwVWvk6Y5dEcve-mMHp6uhuA4VdaJwmvTpHhgG2q7w1ug%40mail.gmail.com.

[Jochen Eisinger]

On Tue, Sep 26, 2017 at 4:02 AM Ojan Vafai <oj...@chromium.org> wrote:

I think custom paint is a bad example to talk about BTW because it's relatively easy for us to say we don't care if ads just don't use them. But I wouldn't say the same about IntersectionObserver, ServiceWorker, Tasklets, etc.

Although ServiceWorker is already secure only..

[Ojan Vafai]

On Tue, Sep 26, 2017, 4:07 PM Jochen Eisinger <joc...@chromium.org> wrote:

On Tue, Sep 26, 2017 at 4:02 AM Ojan Vafai <oj...@chromium.org> wrote:

I think custom paint is a bad example to talk about BTW because it's relatively easy for us to say we don't care if ads just don't use them. But I wouldn't say the same about IntersectionObserver, ServiceWorker, Tasklets, etc.

Although ServiceWorker is already secure only..

Yup. I soecifically mentioned it as a case that we already know is limiting the ability of ads to provide a good user experience. 

[Dimitri Glazkov]

On Sun, Sep 24, 2017 at 5:24 PM Rick Byers <rby...@chromium.org> wrote:

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

For something of the same scope of "should I support https", I'd agree.  I.e. if we were talking about an API that impacts a whole application (eg. a new HTTP header, origin policy, or manifest extension) then I think this argument would apply.

But most new web features have a finer scope than that - that of a library.  A library doesn't get to dictate whether the application is available via HTTPS or not.  For APIs expected to be used by libraries, requiring https can effectively make the api impossible to adopt for the library.  Eg. component libraries like Polymer have UI widgets implemented with a number of divs today and seek to be usable in all sorts of apps. If we told the Polymer team they could only use Custom Paint by restricting their libraries to be used in documents served via https, I strongly suspect they would just stick with the slower/heavier solution they have today (or, best case, maintain both the http and https versions of a widget indefinitely). If we did success in convincing Polymer to require https, I suspect it would cause a significant number of sites to stick with the older version of polymer they have that already works.

I would like to second this and express my dismay at the "forked the web" comment. I view PWAs as a tactic to get developer mindshare shifted from back from the apps world, not an end goal in themselves. I am worried that when we start thinking about Progressive Web Apps as a "new Web", we drastically (and incorrectly) simplify the problem space, inadvertently creating "hostage-taking" dynamics that Ian and Rick mention.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

I think this argument carries the most weight when the "non-trivial work" YOU have to do is within the magnitude of work you have to do to adopt HTTPS.  Eg. for my own tiny personal site rbyers.net, I still don't support https because I don't want the hassle of remembering to upgrade my certificate every couple of years and so I'm waiting for AppEngine to (finally) support Let's Encrypt automation (for many other people the constraint is the cost when their hosting doesn't support automation). Contrast this "work" to the dev work required to drop in a new version of a UI library I'm using.  It's significantly more work to add support for https than to update a library, so in practice I'll just not use the new API rather than take the pain.

Again, would like to +1 this and plead with y'all to have a more nuanced view.

:DG<

 

-mike 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DfHDyULTZ%2BjN3eno04hKcCgDn0FpmKFtc3P7ABhuWFuZw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAFUtAY9k2GF7J_yaF8um%3Dehc9VVDw9%2BK%3D6uMhkUkrg-m4C2MUQ%40mail.gmail.com.

[Ian Kilpatrick]

On Sun, Sep 24, 2017 at 5:23 PM, Rick Byers <rby...@chromium.org> wrote:

Jochen, Ojan and I had a friendly debate about this in Tokyo.  We realized we disagreed on our perception of what fraction of new development was likely done on sites that support (or require) https.  Jochen proposed adding some UseCounters for a variety of new features to track what fraction of PageVisits involving new features are secure.  This seems useful to me but since we're concerned here with developer impact, not user impact, I worry it biases heavily towards a small number of very large well-funded sites.  I argued the better metric was "what fraction of domains that are using new features support https", giving developers more equal weight.  Ojan and I suggested that maybe reaching a threshold like 90% of such domains would make such a policy reasonable (effectively impacting <10% of developers), while Jochen argued that something more like 50% seemed reasonable to him. Jochen indicated collecting such data seemed valuable in making progress in this debate.

Who is going to collect this data?

 

I like this direction and encourage the folks interested in pursuing this policy to gather some hard data like this to quantify the developer impact.  Big picture, if it's true that the vast majority of new development is occurring on sites that already support https (i.e. we really have largely forked the web into legacy and new-https), then I think it's possible I could be convinced of this policy. There's still a question of whether library development can depend on being used in an https document, so it may not be enough for the site to support https but that it actually require https (to what extent could all sites that support https reasonably move to hsts to require it?). But this (and a reasonable threshold) seem like details we can hash out as we get a better picture with hard data.

More inline...

On Friday, September 22, 2017, 'Mike West' via blink-api-owners-discuss <blink-api-owners-discuss@chromium.org> wrote:

Hey Rick!

I do personally believe that the bar for new features can be significantly higher than "powerful" (which seems like a reasonable bar for deprecation of old features). I haven't yet convinced the security team and/or wider Chrome team to join me in that personal belief, but Emily^2 and I have had productive conversations on that front (I owe them a document on that point). I also agree with you that whatever our policy, it should be applied across intents equally, and not piecemeal.

I don't intend to hold Worklets hostage, but I'm asking about this intent in particular because I raised the question of adding a security/privacy considerations section for Worklets in 2015, and there's still not one in the document. Ian has a patch out to add such a section, Anne asked about secure contexts in August, and didn't get a response until this thread.

That's definitely not great. I'm happy to hold this intent on having consensus on a security and privacy section getting added to the spec. 

I'd additionally note that the objections in this thread to adding such a requirement were not "That's a bad idea!" but "We don't have feature detection ability in CSS.", which I think is well worth pushing back against as a justification. The CSSWG discussion of this topic at https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html is worth reading here, and there's healthy (though by no means unanimous) support for restrictions in those minutes. It looks like they punted to the TAG, which is discussing the question in https://github.com/w3ctag/design-principles/issues/32 and https://github.com/w3ctag/design-principles/pull/75.

100% agree that's not an adequate reason (eg. I wouldn't accept it as a reason not to require a secure context for some new privacy-impacting CSS API).

On Fri, Sep 22, 2017 at 3:14 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Thanks for forking the discussion!

On Fri, Sep 22, 2017 at 7:36 AM Rick Byers <rby...@chromium.org> wrote:

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

That's not how I see it. The "powerful" attribute is only useful when looking at existing features, when we consider the trade-off between breaking existing content and protecting users.

Along with agreeing with Jochen's suggestion here, I suspect that I take a broader view of "powerful" than you do, Rick. :) 

I agree with this characterization that that policy is all about existing features, and so the trade-off with web compat. Thanks for clarifying

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

For something of the same scope of "should I support https", I'd agree.  I.e. if we were talking about an API that impacts a whole application (eg. a new HTTP header, origin policy, or manifest extension) then I think this argument would apply.

But most new web features have a finer scope than that - that of a library.  A library doesn't get to dictate whether the application is available via HTTPS or not.  For APIs expected to be used by libraries, requiring https can effectively make the api impossible to adopt for the library.  Eg. component libraries like Polymer have UI widgets implemented with a number of divs today and seek to be usable in all sorts of apps. If we told the Polymer team they could only use Custom Paint by restricting their libraries to be used in documents served via https, I strongly suspect they would just stick with the slower/heavier solution they have today (or, best case, maintain both the http and https versions of a widget indefinitely). If we did success in convincing Polymer to require https, I suspect it would cause a significant number of sites to stick with the older version of polymer they have that already works.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

I think this argument carries the most weight when the "non-trivial work" YOU have to do is within the magnitude of work you have to do to adopt HTTPS.  Eg. for my own tiny personal site rbyers.net, I still don't support https because I don't want the hassle of remembering to upgrade my certificate every couple of years and so I'm waiting for AppEngine to (finally) support Let's Encrypt automation (for many other people the constraint is the cost when their hosting doesn't support automation). Contrast this "work" to the dev work required to drop in a new version of a UI library I'm using.  It's significantly more work to add support for https than to update a library, so in practice I'll just not use the new API rather than take the pain.

-mike 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

[Jochen Eisinger]

On Thu, Sep 28, 2017 at 10:33 PM 'Ian Kilpatrick' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Sun, Sep 24, 2017 at 5:23 PM, Rick Byers <rby...@chromium.org> wrote:

Jochen, Ojan and I had a friendly debate about this in Tokyo.  We realized we disagreed on our perception of what fraction of new development was likely done on sites that support (or require) https.  Jochen proposed adding some UseCounters for a variety of new features to track what fraction of PageVisits involving new features are secure.  This seems useful to me but since we're concerned here with developer impact, not user impact, I worry it biases heavily towards a small number of very large well-funded sites.  I argued the better metric was "what fraction of domains that are using new features support https", giving developers more equal weight.  Ojan and I suggested that maybe reaching a threshold like 90% of such domains would make such a policy reasonable (effectively impacting <10% of developers), while Jochen argued that something more like 50% seemed reasonable to him. Jochen indicated collecting such data seemed valuable in making progress in this debate.

Who is going to collect this data?

Still trying to figure out what this exactly means. The current best proposal is selecting some features we consider "new" and look what fraction of Alexa top 1M uses them that also was recently updated (derived from last-modified date).

 

I like this direction and encourage the folks interested in pursuing this policy to gather some hard data like this to quantify the developer impact.  Big picture, if it's true that the vast majority of new development is occurring on sites that already support https (i.e. we really have largely forked the web into legacy and new-https), then I think it's possible I could be convinced of this policy. There's still a question of whether library development can depend on being used in an https document, so it may not be enough for the site to support https but that it actually require https (to what extent could all sites that support https reasonably move to hsts to require it?). But this (and a reasonable threshold) seem like details we can hash out as we get a better picture with hard data.

More inline...

On Friday, September 22, 2017, 'Mike West' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Hey Rick!

I do personally believe that the bar for new features can be significantly higher than "powerful" (which seems like a reasonable bar for deprecation of old features). I haven't yet convinced the security team and/or wider Chrome team to join me in that personal belief, but Emily^2 and I have had productive conversations on that front (I owe them a document on that point). I also agree with you that whatever our policy, it should be applied across intents equally, and not piecemeal.

I don't intend to hold Worklets hostage, but I'm asking about this intent in particular because I raised the question of adding a security/privacy considerations section for Worklets in 2015, and there's still not one in the document. Ian has a patch out to add such a section, Anne asked about secure contexts in August, and didn't get a response until this thread.

That's definitely not great. I'm happy to hold this intent on having consensus on a security and privacy section getting added to the spec. 

I'd additionally note that the objections in this thread to adding such a requirement were not "That's a bad idea!" but "We don't have feature detection ability in CSS.", which I think is well worth pushing back against as a justification. The CSSWG discussion of this topic at https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html is worth reading here, and there's healthy (though by no means unanimous) support for restrictions in those minutes. It looks like they punted to the TAG, which is discussing the question in https://github.com/w3ctag/design-principles/issues/32 and https://github.com/w3ctag/design-principles/pull/75.

100% agree that's not an adequate reason (eg. I wouldn't accept it as a reason not to require a secure context for some new privacy-impacting CSS API).

On Fri, Sep 22, 2017 at 3:14 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Thanks for forking the discussion!

On Fri, Sep 22, 2017 at 7:36 AM Rick Byers <rby...@chromium.org> wrote:

Let's fork this discussion of the appropriate use of [SecureContext] to a separate thread.

As I understand it, up until now we've said that we require [SecureContext] for "powerful" new features.  I've taken that to mean features where the user would really like some idea of WHO is using them (anything requiring a permission, something that lets the developer have more persistence than before, etc.).  Is that accurate?

That's not how I see it. The "powerful" attribute is only useful when looking at existing features, when we consider the trade-off between breaking existing content and protecting users.

Along with agreeing with Jochen's suggestion here, I suspect that I take a broader view of "powerful" than you do, Rick. :) 

I agree with this characterization that that policy is all about existing features, and so the trade-off with web compat. Thanks for clarifying

It sounds like now Mike and Jochen are arguing for ALL new features using [SecureContext].  While I love the HTTPS-everywhere effort and want to see it succeed 100%, I strongly believe holding all new features hostage for HTTPS is not a reasonable policy change for us to be making.  There are lots of scenarios where the cost of moving to HTTPS will outweigh the benefit of adopting some new feature and so it would add serious friction to evolving the web. At the same time there's already lots of pressure to use HTTPS - features like push notifications and service workers are incredibly big carrots.  Piling on more tiny carrots like custom paint seems really unlikely to advance the https-everywhere effort very much.

We're not holding new features hostage. My take is that PWAs are by definition only available on secure contexts, so we effectively forked the web into a legacy old and broken thing, and a new, shiny, and secure thing.

For something of the same scope of "should I support https", I'd agree.  I.e. if we were talking about an API that impacts a whole application (eg. a new HTTP header, origin policy, or manifest extension) then I think this argument would apply.

But most new web features have a finer scope than that - that of a library.  A library doesn't get to dictate whether the application is available via HTTPS or not.  For APIs expected to be used by libraries, requiring https can effectively make the api impossible to adopt for the library.  Eg. component libraries like Polymer have UI widgets implemented with a number of divs today and seek to be usable in all sorts of apps. If we told the Polymer team they could only use Custom Paint by restricting their libraries to be used in documents served via https, I strongly suspect they would just stick with the slower/heavier solution they have today (or, best case, maintain both the http and https versions of a widget indefinitely). If we did success in convincing Polymer to require https, I suspect it would cause a significant number of sites to stick with the older version of polymer they have that already works.

So for any API that is not just a tiny tweak to an existing API, you'll have to do non-trivial dev work anyways, so it only seems natural to do so on HTTPS.

I think this argument carries the most weight when the "non-trivial work" YOU have to do is within the magnitude of work you have to do to adopt HTTPS.  Eg. for my own tiny personal site rbyers.net, I still don't support https because I don't want the hassle of remembering to upgrade my certificate every couple of years and so I'm waiting for AppEngine to (finally) support Let's Encrypt automation (for many other people the constraint is the cost when their hosting doesn't support automation). Contrast this "work" to the dev work required to drop in a new version of a UI library I'm using.  It's significantly more work to add support for https than to update a library, so in practice I'll just not use the new API rather than take the pain.

-mike 

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DfHDyULTZ%2BjN3eno04hKcCgDn0FpmKFtc3P7ABhuWFuZw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAJL3UpTCHJykLvtq99g_eeNboz9K37kiGbrR74Y8L030GZchTQ%40mail.gmail.com.

[Dimitri Glazkov]

I am having doubts that "new vs. old" is the key criteria here. It seems that the discussion above was leading down the path that some features are more commonly used in component/composed/embedded use cases, where the author of the code has no control over whether the origin is secure or not.

That's the distinction that Ian was trying to draw around dependability/predictability of operation,  I believe. When the author of the site is using a custom element that relies on a CSS Paint, they will observe that their site will work well in development (localhost), but fail in production -- and it would require non-trivial amount of debugging to figure out what's going on.

Could I propose a simple rule of thumb here? If the feature's use cases include composition or embedding, we should not require SecurieContext. WDYT?

:DG< 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CALjhuifF44xER-B3zckr0Dy6XPTiFW_Spd6h5tpu6844b%2Bh8nQ%40mail.gmail.com.

[Rick Byers]

On Fri, Sep 29, 2017 at 1:52 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

I am having doubts that "new vs. old" is the key criteria here. It seems that the discussion above was leading down the path that some features are more commonly used in component/composed/embedded use cases, where the author of the code has no control over whether the origin is secure or not.

That's the distinction that Ian was trying to draw around dependability/predictability of operation,  I believe. When the author of the site is using a custom element that relies on a CSS Paint, they will observe that their site will work well in development (localhost), but fail in production -- and it would require non-trivial amount of debugging to figure out what's going on.

Could I propose a simple rule of thumb here? If the feature's use cases include composition or embedding, we should not require SecurieContext. WDYT?

I love this principle personally.  But I don't think Mike/Jochen find it compelling.

In terms of "new vs. old", in Tokyo Jochen argued that most new code being written is already being run in a secure context (which I take to mean in an https frame where all ancestor documents are also all https).  If that were true, than the above principle would be unnecessary. But composition (both library and iframe) is the #1 reason I strongly believe that claim is incorrect.  But I think we CAN measure that with data.   

That is, I think we're saying the same thing: breakage (in terms of developers impacted) will be high.  I'm just trying to say that if we can show hard data to the contrary (that modern code really does get used in only secure contexts almost all of the time) then that would change my opinion.`

:DG< 

On Thu, Sep 28, 2017 at 11:43 PM Jochen Eisinger <joc...@chromium.org> wrote:

-mike 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DfHDyULTZ%2BjN3eno04hKcCgDn0FpmKFtc3P7ABhuWFuZw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAJL3UpTCHJykLvtq99g_eeNboz9K37kiGbrR74Y8L030GZchTQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Dimitri Glazkov]

Got it.

:DG<

On Fri, Sep 29, 2017 at 2:08 PM Rick Byers <rby...@chromium.org> wrote:

On Fri, Sep 29, 2017 at 1:52 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

I am having doubts that "new vs. old" is the key criteria here. It seems that the discussion above was leading down the path that some features are more commonly used in component/composed/embedded use cases, where the author of the code has no control over whether the origin is secure or not.

That's the distinction that Ian was trying to draw around dependability/predictability of operation,  I believe. When the author of the site is using a custom element that relies on a CSS Paint, they will observe that their site will work well in development (localhost), but fail in production -- and it would require non-trivial amount of debugging to figure out what's going on.

Could I propose a simple rule of thumb here? If the feature's use cases include composition or embedding, we should not require SecurieContext. WDYT?

I love this principle personally.  But I don't think Mike/Jochen find it compelling.

In terms of "new vs. old", in Tokyo Jochen argued that most new code being written is already being run in a secure context (which I take to mean in an https frame where all ancestor documents are also all https).  If that were true, than the above principle would be unnecessary. But composition (both library and iframe) is the #1 reason I strongly believe that claim is incorrect.  But I think we CAN measure that with data.   

That is, I think we're saying the same thing: breakage (in terms of developers impacted) will be high.  I'm just trying to say that if we can show hard data to the contrary (that modern code really does get used in only secure contexts almost all of the time) then that would change my opinion.`

:DG< 

On Thu, Sep 28, 2017 at 11:43 PM Jochen Eisinger <joc...@chromium.org> wrote:

-mike 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DfHDyULTZ%2BjN3eno04hKcCgDn0FpmKFtc3P7ABhuWFuZw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAJL3UpTCHJykLvtq99g_eeNboz9K37kiGbrR74Y8L030GZchTQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

[Jochen Eisinger]

On Fri, Sep 29, 2017 at 11:53 PM Dimitri Glazkov <dgla...@chromium.org> wrote:

Got it.

:DG<

On Fri, Sep 29, 2017 at 2:08 PM Rick Byers <rby...@chromium.org> wrote:

On Fri, Sep 29, 2017 at 1:52 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

I am having doubts that "new vs. old" is the key criteria here. It seems that the discussion above was leading down the path that some features are more commonly used in component/composed/embedded use cases, where the author of the code has no control over whether the origin is secure or not.

That's the distinction that Ian was trying to draw around dependability/predictability of operation,  I believe. When the author of the site is using a custom element that relies on a CSS Paint, they will observe that their site will work well in development (localhost), but fail in production -- and it would require non-trivial amount of debugging to figure out what's going on.

Could I propose a simple rule of thumb here? If the feature's use cases include composition or embedding, we should not require SecurieContext. WDYT?

I love this principle personally.  But I don't think Mike/Jochen find it compelling.

In terms of "new vs. old", in Tokyo Jochen argued that most new code being written is already being run in a secure context (which I take to mean in an https frame where all ancestor documents are also all https).  If that were true, than the above principle would be unnecessary. But composition (both library and iframe) is the #1 reason I strongly believe that claim is incorrect.  But I think we CAN measure that with data.   

I'd argue that for the time being, composition use cases will have to support polyfills and fallbacks (assuming you're not willing to ship a up-to-date-chrome-only website). Adding secure contexts to the mix of reasons why you need the fallback might feel like an unnecessary burden, but it's just one of many reasons for you needing a fallback, not _the_ reason.

Now if we look a bit more into the future, when all browsers will have the cool new API, and you can possibly ship a library without a polyfill, I'd argue that you can also assume that the majority of the web will be accessed via TLS.

[Dimitri Glazkov]

On Mon, Oct 2, 2017 at 12:37 AM Jochen Eisinger <joc...@chromium.org> wrote:

On Fri, Sep 29, 2017 at 11:53 PM Dimitri Glazkov <dgla...@chromium.org> wrote:

Got it.

:DG<

On Fri, Sep 29, 2017 at 2:08 PM Rick Byers <rby...@chromium.org> wrote:

On Fri, Sep 29, 2017 at 1:52 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

I am having doubts that "new vs. old" is the key criteria here. It seems that the discussion above was leading down the path that some features are more commonly used in component/composed/embedded use cases, where the author of the code has no control over whether the origin is secure or not.

That's the distinction that Ian was trying to draw around dependability/predictability of operation,  I believe. When the author of the site is using a custom element that relies on a CSS Paint, they will observe that their site will work well in development (localhost), but fail in production -- and it would require non-trivial amount of debugging to figure out what's going on.

Could I propose a simple rule of thumb here? If the feature's use cases include composition or embedding, we should not require SecurieContext. WDYT?

I love this principle personally.  But I don't think Mike/Jochen find it compelling.

In terms of "new vs. old", in Tokyo Jochen argued that most new code being written is already being run in a secure context (which I take to mean in an https frame where all ancestor documents are also all https).  If that were true, than the above principle would be unnecessary. But composition (both library and iframe) is the #1 reason I strongly believe that claim is incorrect.  But I think we CAN measure that with data.   

I'd argue that for the time being, composition use cases will have to support polyfills and fallbacks (assuming you're not willing to ship a up-to-date-chrome-only website). Adding secure contexts to the mix of reasons why you need the fallback might feel like an unnecessary burden, but it's just one of many reasons for you needing a fallback, not _the_ reason.

Yes, you're right -- these use cases will require some sort of fallback. However, what gives me a pause is not the presence of the fallback, but rather the reason why it's triggered. It's the "why did the ink blots on this component suddenly stop working when I deployed" situation.

:DG<

 

Now if we look a bit more into the future, when all browsers will have the cool new API, and you can possibly ship a library without a polyfill, I'd argue that you can also assume that the majority of the web will be accessed via TLS.

I guess at the core of it is my hesitation with using platform dependability as the trade-off in encouraging TLS adoption. It seems to me we already have a pretty hairy platform that's difficult to develop on, and any time someone suggests that a dependability trade-off is okay, alarms go off in my head.

:DG<

[Dimitri Glazkov]

I would like to unblock CSS Paint Intent to ship. It's been nearly a month since the first email, and while we had a pretty insightful discussion, the net result is that we've blocked Xida and Ian. My current understanding is that:

1) We decided to hold off on the blanked SecureContext policy until we discuss it a bit more

2) Alex, Jochen, and Mike are strongly in favor of restricting CSS Paint to secure contexts only.

3) Rick, Chris, and I are worried that the TLS developer tax not being fully represented in cost/benefits equation.

Does that sound right?

:DG<

[Emily Schechter]

On Tue, Oct 10, 2017 at 2:24 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

I would like to unblock CSS Paint Intent to ship. It's been nearly a month since the first email, and while we had a pretty insightful discussion, the net result is that we've blocked Xida and Ian. My current understanding is that:

1) We decided to hold off on the blanked SecureContext policy until we discuss it a bit more

Yeah, I'd substitute "until we resolve dev hurdles with the actions we've enumerated" for "discuss it". 

2) Alex, Jochen, and Mike are strongly in favor of restricting CSS Paint to secure contexts only.

I still don't think I've heard the "powerful" argument, though maybe I missed something. Could you summarize?

[Mike West]

On Wed, Oct 11, 2017 at 6:00 AM, Emily Schechter <emilysc...@google.com> wrote:

On Tue, Oct 10, 2017 at 2:24 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

I would like to unblock CSS Paint Intent to ship. It's been nearly a month since the first email, and while we had a pretty insightful discussion, the net result is that we've blocked Xida and Ian. My current understanding is that:

1) We decided to hold off on the blanked SecureContext policy until we discuss it a bit more

Yeah, I'd substitute "until we resolve dev hurdles with the actions we've enumerated" for "discuss it". 

Have we clarified what those developer-facing hurdles boil down to? We've talked about doing something in devtools to specify a given origin as "secure enough", and adding an enterprise policy to configure the same for internal applications in a controlled environment. What else would y'all like to see happen?

2) Alex, Jochen, and Mike are strongly in favor of restricting CSS Paint to secure contexts only.

I still don't think I've heard the "powerful" argument, though maybe I missed something. Could you summarize?

As I've said on the internal thread and elsewhere, I don't think "powerful" is the right standard for forward-looking decisions about new features. It's a great standard for deprecation, where we're actively taking something away from developers. That is a painful action, and requires a high standard of justification that we're summarizing as "powerful". New features are different in kind: they have zero active user base, as they aren't yet shipping, and developer annoyance at not being able to use a cool new thing is substantially easier to justify than forcing developers to make changes to existing applications.

In this case, we've been talking about CSS Paint (and Worklets in general) as a new execution model that seems reasonable to restrict to secure contexts as a conservative measure while we figure out what they do, how they work, and what risk they present.. That seems right to me.

[PhistucK]

Frankly, I am utterly surprised that ECMAScript modules shipped on insecure contexts.

:(

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DcbkjqOs4vT47f5Rou_ewyb0Dr3eLPEArg3_bsyt3sE%3Dw%40mail.gmail.com.

[Dimitri Glazkov]

Proposal:

1) Yes, ship CSS Paint in secure context only

2) Commit to developing a coherent policy over the next 2 quarters.

WDYT?

[Jochen Eisinger]

+1

[Ojan Vafai]

Can we agree that we ship CSS Paint to insecure contexts if we're unable to agree on a policy at the end of 2 quarters? There's a risk of this discussion dragging on because we can't come to agreement. Time-boxing ensures we don't stay in limbo.

I want to see numbers showing that we're not holding the platform hostage. I'm pretty skeptical those numbers will pan out, but I'd be very happy to be proven wrong. 

If the numbers don't pan out, then we need to have a difficult discussion about the importance of HTTPS adoption vs. the growth of the web in general. I think that's the tradeoff we're making. Concrete example: if ads couldn't use IntersectionObserver, then there would still be a significant percentage of the web using expensive polling to determine ad visibility. Polyfills would be built with polling, so do not address the concern.

Unless the data shows that nearly all web content will be on HTTPS in the next couple years, the tradeoff we're making is directly one of HTTPS adoption vs. quality of existing web content. We should discuss whether that's the right tradeoff, but let's not pretend that restricting to secure contexts doesn't impact our other goals for the growth of the web negatively.

If we agree to the above, then I think we should probably have a meeting to discuss what data we should gather. I think agreeing on metrics will be rather tricky, so will need some up front discussion and brainstorming.

[Dimitri Glazkov]

Is this an alternative proposal? Help me understand this a bit better. Are you proposing that we hold off shipping CSS Paint for 2 quarters... or something different?

:DG<

[Ojan Vafai]

I'm suggesting a step 3 to your proposal.

1) Ship CSS Paint in secure context only.

2) Commit to developing a coherent policy over the next 2 quarters.

3) If we can't agree on a policy in 2 quarters, ship CSS Paint to insecure contexts.

[Dimitri Glazkov]

Ohh got it. I would be okay with that.

:DG<

--

You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

[Jochen Eisinger]

I'm not sure that this makes sense. On the one hand, we have reasons other than a global policy change for shipping CSS Paint on secure only (cross browser compat, new kind of worker). On the other hand, if we come up with a policy, we'll probably not apply the policy to all other features in retrospect either.

In my mind, CSS Paint and the question for a new policy are two distinct issues.

[Emily Schechter]

+1 for two distinct issues -- so I'd prefer steps 1 & 2 only:

1) Yes, ship CSS Paint in secure context only

2) Commit to developing a coherent policy over the next 2 quarters.

I agree with Mike's comment above that we can consider CSS paint a new execution model that should be restricted, in the same way that we restricted service workers. And independently, we punt the policy decision.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Rick Byers]

What do we do with all the other non-trivial intent-to-ships between now and the time we have a coherent policy worked out?  Do we need to debate each one individually as well?  As I see it there are only two practical self-consistent options in the interim while we work on this policy:

1. Continue with the status quo: require secure context for anything "powerful", otherwise leave it up to feature owners / standards consensus process to decide for each feature.  Anyone is, of course, free to try to influence this process for the CSS paint feature - but then it's not really a question for API owners.
   
2. Err on the side of being conservative and require features which MAY be subject to the new policy to be launched secure-only in the interim.

If we take #2, I don't think we can reasonably tell people that we won't be willing to reconsider adding insecure support after a feature has shipped (especially when they get developer feedback indicating it's limiting adoption).  So defacto I think that would be Ojan's "ship secure only now and revisit once there's a policy".

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

[Ojan Vafai]

On Mon, Oct 16, 2017 at 9:24 AM Emily Schechter <emilysc...@google.com> wrote:

+1 for two distinct issues -- so I'd prefer steps 1 & 2 only:

1) Yes, ship CSS Paint in secure context only

2) Commit to developing a coherent policy over the next 2 quarters.

I agree with Mike's comment above that we can consider CSS paint a new execution model that should be restricted, in the same way that we restricted service workers. And independently, we punt the policy decision.

There's a policy implicit in this statement. Why should a new execution model be restricted? Mitm'ed ServiceWorkers let you permanently hijack a page. That seems quite different than just a new execution model. CSS Paint, however, has less power than if we were to existing execution models and add a sync event that fired at paint time. The point of the new execution model is to limit what it can do.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

[Dimitri Glazkov]

On Mon, Oct 16, 2017 at 11:51 AM Ojan Vafai <oj...@chromium.org> wrote:

On Mon, Oct 16, 2017 at 9:24 AM Emily Schechter <emilysc...@google.com> wrote:

+1 for two distinct issues -- so I'd prefer steps 1 & 2 only:

1) Yes, ship CSS Paint in secure context only

2) Commit to developing a coherent policy over the next 2 quarters.

I agree with Mike's comment above that we can consider CSS paint a new execution model that should be restricted, in the same way that we restricted service workers. And independently, we punt the policy decision.

There's a policy implicit in this statement. Why should a new execution model be restricted? Mitm'ed ServiceWorkers let you permanently hijack a page. That seems quite different than just a new execution model. CSS Paint, however, has less power than if we were to existing execution models and add a sync event that fired at paint time. The point of the new execution model is to limit what it can do.

This is a really good point. It is hard for me to see how CSS Paint makes the Web less secure. Does it?

And do we need to pursue this line of reasoning? What is the actual motivation for requiring secure context in CSS Paint? Is it security mitigation or is it the developer tax to encourage HTTPS adoption? Both?

FWIW, I am uncomfortable with the concept of broad developer tax as means of encouraging shifts in the ecosystem. However, in this case, I can see that the current HTTPS-only momentum and new API development reinforce each other in a way that makes requiring secure contexts less costly for developments over time. That's what made me shift my opinion CSS Paint.

:DG<

[Dimitri Glazkov]

On Mon, Oct 16, 2017 at 9:36 AM Rick Byers <rby...@chromium.org> wrote:

What do we do with all the other non-trivial intent-to-ships between now and the time we have a coherent policy worked out?  Do we need to debate each one individually as well?  As I see it there are only two practical self-consistent options in the interim while we work on this policy:

1. Continue with the status quo: require secure context for anything "powerful", otherwise leave it up to feature owners / standards consensus process to decide for each feature.  Anyone is, of course, free to try to influence this process for the CSS paint feature - but then it's not really a question for API owners.
   
2. Err on the side of being conservative and require features which MAY be subject to the new policy to be launched secure-only in the interim.

If we take #2, I don't think we can reasonably tell people that we won't be willing to reconsider adding insecure support after a feature has shipped (especially when they get developer feedback indicating it's limiting adoption).  So defacto I think that would be Ojan's "ship secure only now and revisit once there's a policy".

Thank you for accounting for the delta between 1) and 2) in my proposal :) Your perspective is very clarifying. Here are my reflections:

a) When I wrote the proposal, it is clear to me now that I was implying #1 as the mode of operation.

b) It is not clear to me that this is the right choice. If it is, why is CSS Paint special here?

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

[Jochen Eisinger]

My understanding was that the proposal is to do #1

[Ojan Vafai]

I'm not really sure how that's possible in this case. As best I can tell, all the arguments for requiring SecureContext for CSS Paint on the intent to ship or standards threads have nothing to do with CSS Paint specifically. They're principled arguments that anything that we can easily ship only to SecureContexts should be restricted to SecureContexts.

[Jochen Eisinger]

hum, e.g., the argument that shipping on insecure contexts would make us non-aligned with Mozilla is independent of the policy discussion.

[Ojan Vafai]

But Mozilla is arguing to ship all new APIs to SecureContext only, not just CSS Paint. So, by that logic, we would apply this to all new APIs, right? Which gets me back to having trouble seeing how we can move forward with this without forming an agreed upon policy for all new APIs.

I don't understand the concerns with shipping CSS Paint to secure contexts only for now and shipping to insecure context in 6 months if we haven't resolved on a policy. We shouldn't let this discussion drag on for years. We should be able to find a policy to agree to. I just want something to force us to follow through and actually gather data and write something concrete down.

[Jochen Eisinger]

On Wed, Oct 18, 2017 at 6:34 PM Ojan Vafai <oj...@chromium.org> wrote:

But Mozilla is arguing to ship all new APIs to SecureContext only, not just CSS Paint. So, by that logic, we would apply this to all new APIs, right? Which gets me back to having trouble seeing how we can move forward with this without forming an agreed upon policy for all new APIs.

They said that a while ago, but as far as I can tell this didn't happen, so I'd see the feedback on CSS Paint as an isolated instance.

 

I don't understand the concerns with shipping CSS Paint to secure contexts only for now and shipping to insecure context in 6 months if we haven't resolved on a policy. We shouldn't let this discussion drag on for years. We should be able to find a policy to agree to. I just want something to force us to follow through and actually gather data and write something concrete down.

The current policy is that we argue on a case by case basis, and I think we have good arguments for CSS Paint. Launching CSS paint on insecure contexts in the future would be going back below our current policy from my point of view.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

[Dimitri Glazkov]

Jochen, Mike -- do y'all have the summary of the arguments for CSS Paint being a "powerful" API? If not, could you provide it in the I2S thread?

Let's go with the plan I proposed earlier, as amended by Rick's option #1:

1) Ship CSS Paint in secure context only

2) Commit to developing a coherent policy over the next 2 quarters.

3) Meanwhile, continue with the status quo: require secure context for anything "powerful", otherwise leave it up to feature owners / standards consensus process to decide for each feature.

:DG<

[Chris Harrelson]

The API owners met just now, and made the following decision (a slight variant on what Dimitri said):

1. Ship CSS Paint in secure context only, and also block future types of worklets on secure contexts.

2. Don't change policy regarding secure contexts for other features at this time.

3. Encourage security folks to work on a proposed plan going forward. (Mike will be point on facilitating this with the security team.)

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOtFfx4n5PMZWXtFuQeONFYk5rwsTkuVty0Y5EQdRyE1n91ChQ%40mail.gmail.com.

[Emily Schechter]

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Ojan Vafai]

Extending this to all worklets does not feel like a slight variant to me. Even just compromising on shipping just CSSPaint as SecureContext doesn't make sense to me either, but I wasn't going to say anything about that since it's not worth further blocking CSSPaint at this point.

At risk of repeating myself, we should have a real written down policy backed by data-driven arguments before making changes like this.

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

[Dimitri Glazkov]

On Thu, Oct 19, 2017 at 10:36 AM Dimitri Glazkov <dgla...@chromium.org> wrote:

Jochen, Mike -- do y'all have the summary of the arguments for CSS Paint being a "powerful" API? If not, could you provide it in the I2S thread?

Does my request make sense? I am a bit worried that it went unaddressed.

:DG<

[Jochen Eisinger]

On Fri, Oct 27, 2017 at 12:16 AM Ojan Vafai <oj...@chromium.org> wrote:

Extending this to all worklets does not feel like a slight variant to me. Even just compromising on shipping just CSSPaint as SecureContext doesn't make sense to me either, but I wasn't going to say anything about that since it's not worth further blocking CSSPaint at this point.

At risk of repeating myself, we should have a real written down policy backed by data-driven arguments before making changes like this.

I agree that we should have an updated policy, and we're committed to come up with one.

We also didn't want to block CSS paint further. It felt strange, however, to restrict CSS paint to SecureContext partly because it uses worklets, and now also talk about other upcoming APIs with worklets. The idea was to mainly have some consistency until the new policy is done.

I actually don't know how close other worklets are to shipping, so maybe we'll have a new policy by then?

We also talked about your request to ship CSS paint on insecure depending on how the new policy looks like. The conclusion was that we shouldn't commit to an automatic shipping, but revisit this when we have the new policy (could be just a new I2S) - depending on how the policy will look like.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTtCfK3QBjxD1wmmU_wDc595LVQf04jrMNeX6qUF0oe8Tg%40mail.gmail.com.

[Jochen Eisinger]

I'll comment on this on the I2S thread!

 

:DG<

[Ojan Vafai]

On Fri, Oct 27, 2017 at 4:35 AM Jochen Eisinger <joc...@chromium.org> wrote:

On Fri, Oct 27, 2017 at 12:16 AM Ojan Vafai <oj...@chromium.org> wrote:

Extending this to all worklets does not feel like a slight variant to me. Even just compromising on shipping just CSSPaint as SecureContext doesn't make sense to me either, but I wasn't going to say anything about that since it's not worth further blocking CSSPaint at this point.

At risk of repeating myself, we should have a real written down policy backed by data-driven arguments before making changes like this.

I agree that we should have an updated policy, and we're committed to come up with one.

SGTM. Can we commit to a date for a first draft? Maybe I'm being too paranoid, but I'm very worried about us not doing this in a timely fashion. Ideally we'd have this resolved before we want to ship AnimationWorklet.

We also didn't want to block CSS paint further. It felt strange, however, to restrict CSS paint to SecureContext partly because it uses worklets, and now also talk about other upcoming APIs with worklets. The idea was to mainly have some consistency until the new policy is done.

I see. That logic makes sense to me, but I think it has a potential unintended consequence. If we're saying we're going to ship SecureContext only, then we should go to working groups and lobby for that. But doing so seems premature to me if we might change our minds in the future. I think this is fine for now as long as we're not proactively trying to change this in specs until we've agree on a policy.

 

I actually don't know how close other worklets are to shipping, so maybe we'll have a new policy by then?

I think AnimationWorklet (or AudioWorklet?) is the closest to shipping? I haven't heard a recent timeline though.

 

We also talked about your request to ship CSS paint on insecure depending on how the new policy looks like. The conclusion was that we shouldn't commit to an automatic shipping, but revisit this when we have the new policy (could be just a new I2S) - depending on how the policy will look like.

As long as we for real push to get a new policy done, that's fine with me. I'm just worried we'll let it drag on and have the implicit policy above for worklets indefinitely.

[Emily Schechter]

As mentioned previously, we see this new policy discussion as blocked on a number of items (DevTools checkbox / enterprise policy / HTTPBadFinal) and in the meantime, we should continue to make decisions based on the current policy. I think it's very important for us to decide on and announce this policy at the right time, as there are real risks involved with the announcement. So I worry about committing to a specific timeline, i.e. before AnimationWorklet ships.

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOtFfx4n5PMZWXtFuQeONFYk5rwsTkuVty0Y5EQdRyE1n91ChQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Rick Byers]

The "current policy" is just the "powerful features" one, which we all agree doesn't apply to CSS paint, right?

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOtFfx4n5PMZWXtFuQeONFYk5rwsTkuVty0Y5EQdRyE1n91ChQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Ian Kilpatrick]

One thing I wanted to add to the discussion is the code complexity of doing this going forward. I at least didn't have a good sense of this before - but this is the change in order for the CSS Parser to understand what a secure context is:

https://chromium-review.googlesource.com/#/c/chromium/src/+/759112

This happens to be more complex than quirks mode behaviour, as you can't "default" to one mode or another if we end up flipping things to only secure contexts. (I.e. most of the time the CSS Parser acts in strict mode).

(this patch will probably end up more complex, editing code, etc, etc, etc).

We are adding something potentially more complex than quirks mode into the engine, and wanted to point out the maintenance/bugs burden that this will have.

[Dimitri Glazkov]

FWIW, I've changed my mind on this. After talking at the Houdini F2F, I realized that both Microsoft and Apple would object to adding both SecureContext for Paint and the notion of secure contexts in CSS parser to the spec. Mozilla representative abstained from expressing an opinion. Looking at Ian's change and the amount of what effectively is technical debt it creates, I am flipping back to dissenting voice on this.

I don't think we should require SecureContexts for Worklets.

:DG<

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOtFfx4n5PMZWXtFuQeONFYk5rwsTkuVty0Y5EQdRyE1n91ChQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

[Emily Schechter]

What were MSFT and Apple's specific objections?

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOtFfx4n5PMZWXtFuQeONFYk5rwsTkuVty0Y5EQdRyE1n91ChQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Jochen Eisinger]

Did they also say when they would ship worklets, or did they just say that if they were to ship, they'd ship them everywhere?

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOtFfx4n5PMZWXtFuQeONFYk5rwsTkuVty0Y5EQdRyE1n91ChQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTtCfK3QBjxD1wmmU_wDc595LVQf04jrMNeX6qUF0oe8Tg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rzHEEnXmJetVMDjmErAN6xc25d%2Br_Q4GZK56FArijBEbA%40mail.gmail.com.

[Dimitri Glazkov]

Emily, Jochen -- here's the link to the minutes: https://github.com/w3c/css-houdini-drafts/issues/505#issuecomment-343275248

:DG<

[Ojan Vafai]

Travis from Edge posted a summary of thoughts here: https://github.com/w3ctag/design-principles/pull/75#issuecomment-347964832

I think the idea of looking at degree of coupling matches the direction of my thoughts pretty well. Even *if* we were to agree to do as many new features in SecureContext only as we could, I think we would want to limit it to features that are loosely coupled to the rest of the platform rather than ones deeply intertwined with rendering/DOM.

In the case of CSS Paint, we're adding a cut to the death by a thousand cuts problem that is CSS parser performance/complexity.

[Ian Kilpatrick]

On a few benchmarks we've regressed by the additional work to pass the secure context bit into the css parser, e.g.

https://chromeperf.appspot.com/report?sid=f48949880af3294eaeb6b1da7bc3f79bb4bd83a9e4f343094404925ed0384f03&rev=518164

On Wed, Dec 6, 2017 at 5:37 PM, Ojan Vafai <oj...@chromium.org> wrote:

Travis from Edge posted a summary of thoughts here: https://github.com/w3ctag/design-principles/pull/75#issuecomment-347964832

I think the idea of looking at degree of coupling matches the direction of my thoughts pretty well. Even *if* we were to agree to do as many new features in SecureContext only as we could, I think we would want to limit it to features that are loosely coupled to the rest of the platform rather than ones deeply intertwined with rendering/DOM.

In the case of CSS Paint, we're adding a cut to the death by a thousand cuts problem that is CSS parser performance/complexity.

On Mon, Nov 27, 2017 at 10:29 AM Dimitri Glazkov <dgla...@chromium.org> wrote:

Emily, Jochen -- here's the link to the minutes: https://github.com/w3c/css-houdini-drafts/issues/505#issuecomment-343275248

:DG<

On Mon, Nov 27, 2017 at 10:03 AM Jochen Eisinger <joc...@chromium.org> wrote:

Did they also say when they would ship worklets, or did they just say that if they were to ship, they'd ship them everywhere?

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOtFfx4n5PMZWXtFuQeONFYk5rwsTkuVty0Y5EQdRyE1n91ChQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTtCfK3QBjxD1wmmU_wDc595LVQf04jrMNeX6qUF0oe8Tg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To post to this group, send email to blink-api-owners-discuss@chromium.org.

[Chris Harrelson]

BTW, Ian told me offline that the jump back up to performace at about 600 runs/s was due to a change to cache the computation of Document::IsSecureContext. It seems the remaining cost is due to a virtual function call and some other small, perhaps mostly unavoidable, overhead.

Chris

SGTM, thanks!

:DG<

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv92zNSf1xk%3DZ-1HZHLDsmbytALJVaW8fifb-xe5aVcpw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAqC9rxefBANB%3DDRH4jXwHZ0LF9RpND4D3NPbfXwyLa2Ww9MGQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTv0Bjv8BF3oKQkScmc%2Bf-DtmYQoUXEdS6OW1VXCXiNahA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOtFfx4n5PMZWXtFuQeONFYk5rwsTkuVty0Y5EQdRyE1n91ChQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANMdWTtCfK3QBjxD1wmmU_wDc595LVQf04jrMNeX6qUF0oe8Tg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsubscr...@chromium.org.

To post to this group, send email to blink-api-owners-discuss@chromium.org.