SecureContext requirements for all new features?

90 views
Skip to first unread message

Rick Byers

unread,
Sep 21, 2017, 6:36:17 PM9/21/17
to blink-api-owners-discuss, Jochen Eisinger, Mike West, Ian Kilpatrick, Xida Chen, Emily Stark
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:
...which annevk mentioned was the concerns around secure contexts.

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

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

unread,
Sep 21, 2017, 9:15:04 PM9/21/17
to Rick Byers, blink-api-owners-discuss, Mike West, Ian Kilpatrick, Xida Chen, Emily Stark
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

unread,
Sep 22, 2017, 4:35:10 AM9/22/17
to Jochen Eisinger, Rick Byers, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Sep 24, 2017, 8:24:01 PM9/24/17
to Mike West, Jochen Eisinger, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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

unread,
Sep 25, 2017, 3:52:49 PM9/25/17
to Rick Byers, Mike West, Jochen Eisinger, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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

unread,
Sep 25, 2017, 7:17:04 PM9/25/17
to Emily Stark, Rick Byers, Mike West, Jochen Eisinger, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Schechter

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

unread,
Sep 25, 2017, 9:22:49 PM9/25/17
to Ojan Vafai, Emily Stark, Rick Byers, Mike West, Jochen Eisinger, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, 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

unread,
Sep 25, 2017, 10:02:06 PM9/25/17
to Emily Schechter, Emily Stark, Rick Byers, Mike West, Jochen Eisinger, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Schechter
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.

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

unread,
Sep 26, 2017, 3:07:36 AM9/26/17
to Ojan Vafai, Emily Schechter, Emily Stark, Rick Byers, Mike West, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Schechter
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

unread,
Sep 26, 2017, 4:49:37 AM9/26/17
to Jochen Eisinger, Emily Schechter, Emily Schechter, Emily Stark, Ian Kilpatrick, Mike West, Rick Byers, Xida Chen, blink-api-owners-discuss


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

unread,
Sep 26, 2017, 12:11:32 PM9/26/17
to Rick Byers, Mike West, Jochen Eisinger, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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.

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

unread,
Sep 28, 2017, 4:33:32 PM9/28/17
to Rick Byers, Mike West, Jochen Eisinger, blink-api-owners-discuss, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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

unread,
Sep 29, 2017, 2:43:46 AM9/29/17
to Ian Kilpatrick, Rick Byers, Mike West, blink-api-owners-discuss, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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.

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

unread,
Sep 29, 2017, 1:53:00 PM9/29/17
to Jochen Eisinger, Ian Kilpatrick, Rick Byers, Mike West, blink-api-owners-discuss, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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< 

Rick Byers

unread,
Sep 29, 2017, 5:08:13 PM9/29/17
to Dimitri Glazkov, Jochen Eisinger, Ian Kilpatrick, Mike West, blink-api-owners-discuss, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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.

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

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

unread,
Sep 29, 2017, 5:53:00 PM9/29/17
to Rick Byers, Jochen Eisinger, Ian Kilpatrick, Mike West, blink-api-owners-discuss, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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.

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

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

unread,
Oct 2, 2017, 3:37:35 AM10/2/17
to Dimitri Glazkov, Rick Byers, Ian Kilpatrick, Mike West, blink-api-owners-discuss, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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

unread,
Oct 2, 2017, 11:54:36 AM10/2/17
to Jochen Eisinger, Rick Byers, Ian Kilpatrick, Mike West, blink-api-owners-discuss, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai
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

unread,
Oct 10, 2017, 5:24:28 PM10/10/17
to blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Mike West, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai, Jochen Eisinger
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

unread,
Oct 11, 2017, 12:00:01 AM10/11/17
to Dimitri Glazkov, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Mike West, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai, Jochen Eisinger
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

unread,
Oct 11, 2017, 2:30:25 AM10/11/17
to Emily Schechter, Dimitri Glazkov, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai, Jochen Eisinger
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

unread,
Oct 11, 2017, 5:52:37 AM10/11/17
to Mike West, Emily Schechter, Dimitri Glazkov, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai, Jochen Eisinger
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

unread,
Oct 13, 2017, 8:15:40 PM10/13/17
to PhistucK, Mike West, Emily Schechter, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai, Jochen Eisinger
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

unread,
Oct 14, 2017, 3:36:09 AM10/14/17
to Dimitri Glazkov, PhistucK, Mike West, Emily Schechter, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter, Ojan Vafai

+1

Ojan Vafai

unread,
Oct 14, 2017, 12:53:27 PM10/14/17
to Jochen Eisinger, Dimitri Glazkov, PhistucK, Mike West, Emily Schechter, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 14, 2017, 1:30:26 PM10/14/17
to Ojan Vafai, Jochen Eisinger, PhistucK, Mike West, Emily Schechter, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 14, 2017, 1:37:25 PM10/14/17
to Dimitri Glazkov, Jochen Eisinger, PhistucK, Mike West, Emily Schechter, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 14, 2017, 1:38:39 PM10/14/17
to Ojan Vafai, Jochen Eisinger, PhistucK, Mike West, Emily Schechter, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 16, 2017, 2:28:41 AM10/16/17
to Dimitri Glazkov, Ojan Vafai, PhistucK, Mike West, Emily Schechter, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 16, 2017, 12:24:41 PM10/16/17
to Jochen Eisinger, Dimitri Glazkov, Ojan Vafai, PhistucK, Mike West, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, 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

unread,
Oct 16, 2017, 12:36:23 PM10/16/17
to Emily Schechter, Jochen Eisinger, Dimitri Glazkov, Ojan Vafai, PhistucK, Mike West, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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.

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

unread,
Oct 16, 2017, 2:51:21 PM10/16/17
to Emily Schechter, Jochen Eisinger, Dimitri Glazkov, PhistucK, Mike West, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 17, 2017, 12:01:12 PM10/17/17
to Ojan Vafai, Emily Schechter, Jochen Eisinger, PhistucK, Mike West, blink-api-owners-discuss, Rick Byers, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 17, 2017, 12:21:45 PM10/17/17
to Rick Byers, Emily Schechter, Jochen Eisinger, Ojan Vafai, PhistucK, Mike West, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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.

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

unread,
Oct 18, 2017, 3:07:38 AM10/18/17
to Dimitri Glazkov, Rick Byers, Emily Schechter, Ojan Vafai, PhistucK, Mike West, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
My understanding was that the proposal is to do #1

Ojan Vafai

unread,
Oct 18, 2017, 12:15:53 PM10/18/17
to Jochen Eisinger, Dimitri Glazkov, Rick Byers, Emily Schechter, PhistucK, Mike West, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 18, 2017, 12:19:56 PM10/18/17
to Ojan Vafai, Dimitri Glazkov, Rick Byers, Emily Schechter, PhistucK, Mike West, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 18, 2017, 12:34:06 PM10/18/17
to Jochen Eisinger, Dimitri Glazkov, Rick Byers, Emily Schechter, PhistucK, Mike West, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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

unread,
Oct 19, 2017, 3:06:58 AM10/19/17
to Ojan Vafai, Dimitri Glazkov, Rick Byers, Emily Schechter, PhistucK, Mike West, blink-api-owners-discuss, Ian Kilpatrick, Xida Chen, Emily Stark, Emily Schechter
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.
 

Dimitri Glazkov

unread,
Oct 19, 2017, 1:36:31 PM10/19/17