Consider exposing Shadom DOM and Custom Elements only in secure contexts

[smaug----]

Given that many of the new APIs will be exposed only in secure contexts, perhaps also
Shadow DOM and Custom Elements should be restricted that way.

@annevk @dglazkov @hayatoito @rniwa @adrianba

[annevk]

I'm supportive of restricting new features to HTTPS.

[dglazkov]

Don't want to be a wet blanket, but I am torn on this. On one hand, seems like a good thing (TLS FTW). OTOH, this would severely impact the simpler use cases, such as just using a component on an existing site.

[andyearnshaw]

Are there any benefits beyond encouraging devs to go secure on their sites?

this would severely impact the simpler use cases, such as just using a component on an existing site.

Also, local serving for testing is a pain if you have to self-sign certs and install them on other devices. With minor APIs like getUserLocation, graceful degradation on insecure contexts is easy (and there's an actual benefit beyond encouraging devs), but when a large amount of the page could be web components, it's not so easy to sidestep unless you already have a polyfill (which people likely won't have when support is ubiquitous).

FWIW in the original idea for restricting new features to secure contexts, the Chrome Security team referred to "particularly powerful features", defined as:

things like: features that handle personally-identifiable information, features that handle high-value information like credentials or payment instruments, features that provide the origin with control over the UA's trustworthy/native UI, access to sensors on the user's device, or generally any feature that we would provide a user-settable permission or privilege to.

And goes on to say:

“Particularly powerful” would not mean things like: new rendering and layout features, CSS selectors, innocuous JavaScript APIs like showModalDialog, or the like. I expect that the majority of new work in HTML5 fits in this category.

I'd say that web components fit into the latter category and there's no need to limit availability to secure contexts only.

[rniwa]

What's the rationale for restricting this to HTTPS? Are there any security concerns with web components?

[smaug----]

Just for the sake of exposing new major APIs to secure context only to persuade web devs to give up with less secure contexts.

[seancurtis]

Please do not restrict web components to only secure contexts. Local testing and development will become unnecessarily more difficult, and anyone running a web app (utilising web components) on an internal server will have to jump through more hoops.

Please list the main security concern you have which would be solved by only providing web components on HTTPS.

Web components shouldn't be used in some carrot+stick scenario to convince people to move to HTTPS. There are much better carrots (and sticks) available.

[chrisdarroch]

In total agreement with @seancurtis here. Arbitrarily restricting the use of web components may tend to... artificially restrict their adoption. I'm not sure stymying uptake of them is a good goal.

If there were tangible problems and implementation difficulties that existed in the behaviours of the Shadow DOM and Custom Elements, which could be solved trivially by restricting their usage to HTTPS, then it would be a different matter. I'm not aware of such difficulties, though.

[jpnelson]

@seancurtis @chrisdarroch agreed, for the API's that have been restricted to https only, it made sense to me, as there are valid security concerns using those API's when not on https.

This doesn't make as much sense for web components. As @seancurtis said, there are already much better carrots already available to encourage people to move to https.

[hayatoito]

I think we can agree that there is no technical reason to restrict Shadow DOM or Custom Elements to HTTPS. DOM (or Shadow DOM) can work the same way either in HTTP or HTTPS, basically.

Just for the sake of exposing new major APIs to secure context only to persuade web devs to give up with less secure contexts.

Thus, I think the point is that this motivation is important enough or not.

[ghost]

Just for the sake of exposing new major APIs to secure context only to persuade web devs to give up with less secure contexts.

Thus, I think the point is that this motivation is important enough or not.

Indeed. I would observe that the restriction of ServiceWorkers to HTTPS, though it was done for more direct security reasons, has been an effective motivator for migration. The same applies here: If this is an important feature for people, all the more reason for it to be restricted.

The "local testing" argument is pretty bogus. The Secure Contexts spec has a specific exemption for localhost. If you use a modern server, you can have HTTPS for zero cost in either dollars or time. And even making your own self-signed setup is just not that hard.

As far as "artificially restricting adoption" -- I realize it's unpleasant to spend effort on stuff and see it not catch fire right away. But if all we were after was adoption, we could just, say, remove all the sandboxing the web provides and give JS direct machine access. (It would make a lot of devs happy!) We need to balance adoption against what's right for the web.

[rniwa]

I don't think we want to change the HTML parser behavior based on the protocol if we were to resolve the issue #59 in favor of the parsing slot element like template element.

Also, while features like geolocation and service workers can be progressive enhancements to a given web page / app, web components seems like a fundamental bundling block of the said page / app, and not having them would force authors to use polyfills instead of degrading user experience. So imposing secure origin seems unusually hostile requirement to me.

[treshugart]

The "local testing" argument is pretty bogus.

Tell that to all of the people who use JSBin to mock up web components. There's also several sites out there that would benefit from using web components while not necessarily HTTPS. Some don't even have control over whether or not they use HTTPS.

The "we want to force people to use HTTPS through web components" is a brittle argument. As @rniwa pointed out, web components are a fundamental building block. One of the best examples of this is inspecting a <select> or <input> with Shadow Root inspection on. These are web components at the browser level. Should these be restricted to HTTPS as well? What makes this so much different?

It's worth being mindful of the voices in this thread who aren't invested in building browsers. There's at least five people in this thread who don't work for browser vendors and aren't part of the W3C, who all are currently against it. At least four of these people write web components on a daily basis and help to maintain polyfills for it. That should say something.

[domenic]

jsbin supports HTTPS

[smaug----]

One of the best examples of this is inspecting a or with Shadow Root inspection on. These are web components at the browser level.

That is totally browser specific stuff, and nothing to do with anything exposed as web APIs.

[treshugart]

jsbin supports HTTPS

Don't you have to pay for HTTPS support in JSbin? I don't think that invalidates the argument.

That is totally browser specific stuff, and nothing to do with anything exposed as web APIs.

That's fair. Maybe it's just like that in Chrome because of the way they implement their elements. I think it still stands as a valid argument, though. It seems to me if standard HTML elements can work over HTTP that it's a double standard to not allow authors to create custom elements over HTTP.

[rniwa]

FWIW, I don't want web component features to be restricted to HTTPS and I work on WebKit (used by Safari).

[ghost]

jsbin supports HTTPS

Don't you have to pay for HTTPS support in JSbin? I don't think that invalidates the argument.

I admit I'm not familiar with JSBin, and I was pretty dismayed to discover that, they supports HTTPS just fine, they just turn it off for the JS you type in. I don't think rent-seeking behavior should really be a guide to decision-making here.

[domenic]

jsbin supports HTTPS and does not turn it off. https://jsbin.com/zamizemupe/edit?html,output was created by a non-logged in user and runs the right-side iframe in HTTPS.

[gilmoreorless]

I see Service Workers being brought up as justification a few times. The difference here is that the SW spec was HTTPS-only from the start.

Service Workers can take full control of a user's browsing experience, it makes sense to restrict that to secure contexts. Geolocation has the potential for privacy violations, it makes sense to restrict that to secure contexts. Custom elements and Shadow DOM are ways to make new encapsulated HTML elements, with no security or privacy concerns that I can see, so why should that be restricted to secure contexts only?

Custom elements and Shadow DOM have been in progress for so long that a lot of library authors have built on top of them. Sure, many of them have been built on top of Polymer, but that was never meant to be the permanent solution. This decision suddenly says to all of them "sorry, your library won't work on plain HTTP pages any more, unless you build on polyfills forever"

As quoted by @andyearnshaw, the original Chromium announcement said:

“Particularly powerful” would not mean things like: new rendering and layout features, CSS selectors, innocuous JavaScript APIs like showModalDialog, or the like. I expect that the majority of new work in HTML5 fits in this category

Can you imagine the outcry if the recent(ish) <dialog> HTML5 element was restricted to secure contexts, for no reason other to "encourage" people onto HTTPS? What about <picture> that the RICG worked so hard to make available everywhere? Should the CSS Houdini APIs become HTTPS-only for the same "encouragement" reason? I sure hope not.

I realise that this comment is now long enough to be descending into "rant" territory, but I feel one final point is needed. In a time when many people are choosing React instead of Web Components, partly due to a perception of WCs never getting finished (I'm not in this camp, BTW, but I talk to many people who are), this decision is only going to convince more people to choose React. On the flip side, do you think React would have been as popular as it is now if Facebook had said it would only work in secure contexts?

[andyearnshaw]

The "local testing" argument is pretty bogus. The Secure Contexts spec has a specific exemption for localhost.

localhost, yes. But what if I want to fire up a node/express instance and test my component on a few phones and tablets? We have tons of test devices where I work, is everyone expected to install their self-signed certs on every single one of them?

[treshugart]

I was wrong about JSBin (and happy that I am). Thanks for pointing that out :).

[jarek-foksa]

I believe the top priority should be to make the Web Components easy to use by non-technical users.

Someone who knows only HTML should be able to import a component and use it right away without getting into the technical details of protocols or relative URL resolution.

[annevk]

Relative URL resolution? It seems you're highly likely affected by that in some way.

I also don't really follow the concerns. The end goal is that insecure HTTP does not exist. Why does moving up the pace matter at this point, given all the infrastructure for HTTPS is now trivially available?

[treshugart]

The end goal is that insecure HTTP does not exist.

But not for web components. This is conflating two completely separate issues.

Why does moving up the pace matter at this point, given all the infrastructure for HTTPS is now trivially available?

As time goes on, the web component spec seems to be losing a lot of steam in the community. I have seen far more skeptics than advocates for web components at work, meetups and on the internet without basing what I read on my personal bias. It's just as much conjecture for one to argue that this will help with HTTPS adoption as I would argue that it will hurt adoption of the spec and how it is portrayed within the community.

If we take out the HTTPS agenda, what is this actually solving?

[travisleithead]

On restricting Shadow DOM and Custom Elements to HTTPS:

• MS Edge position is not to restrict to Secure Context because
  • Web Components provides features that have been previously available without Web Components. they provide simplification of existing features using better architectural primitives and encapsulation.
  • Is a fundamental building block of the platform, and like the DOM Tree APIs, should be universally available.
  • Don’t believe that web components adds significant new privacy or security concerns to the web that would really justify considering it for secure context.
  • While we like the adoption of HTTPS everywhere, I’m not certain that Web Component adoption and HTTPS adoption are linked or linkable. One should probably not block the other.

[domenic]

Telecon agreement: we will not require secure contexts.