should URLPattern require a SecureContext?

[wanderview]

There is a trend towards requiring secure contexts for new features, although sometimes it seems this is only applied to "powerful" new features. Should URLPattern require a SecureContext?

@annevk @domenic what is the current school of thought on this in standards?

[annevk]

I think we're still pretty inconsistent about it, but it makes sense to do so to me.

[domenic]

I like SecureContext-ing all the things, but I think most new features of this sort (a pure input, output processor) are not restricted in such a way. So, you could face pushback from others.

That said, we may have reached the point though that enough people are using secure contexts that there won't be much resistance anymore. Which would be great.

Basically, I'd say start with [SecureContext] if you're comfortable doing so, and wait for someone to complain before reconsidering :).

[wanderview]

After further though I'm actually leaning towards not requiring a secure context for URLPattern.

My rationale is that one of the main uses of URLPattern is as a router within a client-side framework. It would be difficult for frameworks to have a big chunk of their functionality go away based on the protocol of the site they are used on. Requiring a secure context would create API adoption headwinds for what seems little benefit.

[annevk]

The benefit is always small in isolation, which is why we should keep doing it when we can, so the ecosystem shifts to HTTPS-only.

[wanderview]

I just don't agree in this case since there is not a reasonable way for frameworks to deal with the issue besides packaging replacement code which obviates the entire API. I think the cost is too high for the use case.

[annevk]

Well, frameworks can also become HTTPS-only. Again, if enough features do this, that's the outcome.

[wanderview]

I've given this some more thought and have a more structured argument to express why I am leaning away from requiring https.

I think requiring https is quite reasonable and good in many cases. It seems effective when the API provides a low level capability that is not yet present in the browser; i.e. something that cannot be polyfilled.

In this case, however, URLPattern is a high level convenience feature that can be polyfilled. This means we have no leverage over developers. If we make this https-only they will simply ship a polyfill as its the lowest friction solution available to them. This means the limitations of https-only URLPattern would accrue as increased negatives for the end user in the form of larger javascript payloads.

Its possible one day we will get to an https-only everywhere world, but its very unlikely to be due to making polyfillable APIs like URLPattern https-only.

[annevk]

In theory the web crypto API can be polyfilled, yet it was restricted.

[wanderview]

The draft spec (still needs some polish) is written and currently does not require [SecureContext]. Leaving this open for now given @annevk's objection.

[wanderview]

Its been a year and this has shipped. I am closing for now.