SecureContext requirements for all new features?

[Rick Byers]

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

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

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

Thoughts?

   Rick

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

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

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

Thanks for calling this out, Ian!

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

One thing that was pointed out specifically on:

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

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

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

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

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

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

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

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

 

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

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

(CSS non-expert question, sorry)

Can CSS @supports be used to detect this?

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

 

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

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

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

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

 

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

.no-paint-api {

  background: /* fallback */;

  background: paint(foo);

}

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

  background: /* fallback */;

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

}

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

 

.paint-api-on-secure-context {

  background: /* fallback */;

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

}

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

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

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

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

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

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

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

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

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

-Boris

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

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

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

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

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

[Jochen Eisinger]

Thanks for forking the discussion!

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

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

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

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

 

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

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

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

[Mike West]

Hey Rick!

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

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

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

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

Thanks for forking the discussion!

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

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

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

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

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

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

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

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

-mike 

[Rick Byers]

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

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

More inline...

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

Hey Rick!

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

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

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

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

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

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

Thanks for forking the discussion!

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

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

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

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

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

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

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

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

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

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

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

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

-mike 

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

[Emily Stark]

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

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

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

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

More inline...

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

Hey Rick!

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

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

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

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

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

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

Thanks for forking the discussion!

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

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

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

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

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

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

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

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

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

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

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

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

-mike 

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

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

[Ojan Vafai]

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

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

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

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

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

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

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

More inline...

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

Hey Rick!

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

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

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

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

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

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

Thanks for forking the discussion!

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

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

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

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

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

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

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

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

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

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

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

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

-mike 

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

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

[Emily Schechter]

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

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

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

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

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

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

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

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

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

More inline...

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

Hey Rick!

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

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

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

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

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

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

Thanks for forking the discussion!

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

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

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

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

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

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

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

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

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

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

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

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

-mike 

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

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

[Ojan Vafai]

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

Happy to talk more about what metrics would be useful.

-mike 

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

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

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

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

[Jochen Eisinger]

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

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

Although ServiceWorker is already secure only..

[Ojan Vafai]

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

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

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

Although ServiceWorker is already secure only..

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

[Dimitri Glazkov]

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

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

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

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

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

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

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

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

:DG<

 

-mike 

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

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

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

--

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

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

[Ian Kilpatrick]

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

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

Who is going to collect this data?

 

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

More inline...

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

Hey Rick!

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

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

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

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

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

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

Thanks for forking the discussion!

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

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

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

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

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

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

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

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

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

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

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

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

-mike 

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

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

[Jochen Eisinger]

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

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

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

Who is going to collect this data?

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

 

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

More inline...

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

Hey Rick!

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

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

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

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

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

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

Thanks for forking the discussion!

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

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

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

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

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

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

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

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

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

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

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

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

-mike 

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

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

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

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

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

[Dimitri Glazkov]

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

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

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

:DG< 

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

[Rick Byers]

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

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

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

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

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

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

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

:DG< 

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

-mike 

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

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

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

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

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

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

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

[Dimitri Glazkov]

Got it.

:DG<

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

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

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

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

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

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

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

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

:DG< 

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

-mike 

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

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

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

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

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

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

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

[Jochen Eisinger]

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

Got it.

:DG<

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

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

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

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

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

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

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

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

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

[Dimitri Glazkov]

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

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

Got it.

:DG<

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

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

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

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

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

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

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

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

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

:DG<

 

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

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

:DG<