Limiting sever timing to secure origins

[valenting]

We plan to implement this in Firefox bug 1423495.
However, per Mozilla's policy, we will restrict new features to secure origins.
The result of this will be that for HTTP requests, the serverTiming attribute will return an empty array - same behaviour for cross-origin requests.

[valenting]

Is there any chance the spec could explicitly recommend how user agents that do not want to expose the interface to insecure origins should behave?

[igrigorik]

In processing section (https://w3c.github.io/server-timing/#processing-model) we have the TAO check (step 1) for cross-origin resources. We could add an optional clause for HTTPS origins.. the net outcome is the same: if either condition fails, empty sequence.

@cvazac wdyt?

[yoavweiss]

Personally, I'm not super excited about policies which ban new feature support from insecure contexts without actual justification for that. (security, privacy, etc)

@valenting - is there a reason for such HTTPS-only limitation, beyond the policy? If not, do other feature specifications explicitly state that UAs may not implement them in insecure-contexts?

[valenting]

As far as I know, there are no other reasons for not supporting this. Meaning we haven't identified any security issues with supporting this under HTTP.

As far as the policy goes, there are a bunch of specs that specify HTTPS only behaviour: https://www.digicert.com/blog/https-only-features-in-browsers/

[yoavweiss]

As far as the policy goes, there are a bunch of specs that specify HTTPS only behaviour: https://www.digicert.com/blog/https-only-features-in-browsers/

Each one of these features have a well documented reason for it being HTTPS-only, be it privacy, security or deployment reasons.

My question is: are there features where none of the above concerns apply and which their specifications explicitly indicate that UAs may not implement them in insecure-contexts due to internal policies?

[valenting]

My guess is that HTTP2 is like that. An plain text H2 connection is just as secure and easy to deploy as a plain text H1 connection, but we made the decision to only support it over TLS.

As a note, we'll be marking the interface [SecureContext], meaning that the attribute will be undefined on insecure origins.

[yoavweiss]

My guess is that HTTP2 is like that. An plain text H2 connection is just as secure and easy to deploy as a plain text H1 connection, but we made the decision to only support it over TLS.

That is not true due to middle boxes that assume port 80 traffic is HTTP/1.1. (The same goes for brotli compression)

[annevk]

Personally, I'm not super excited about policies which ban new feature support from insecure contexts without actual justification for that.

There is justification given at https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/. The goal is to get rid of HTTP-sans-S. The means is giving incentives to web developers to stop deploying non-secure setups by giving them better sites over HTTPS.

This might be slightly different from the rationale Chrome has used to restrict some features in the past, but I don't think it's any less valid.

[yoavweiss]

There is justification given at https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/. The goal is to get rid of HTTP-sans-S. The means is giving incentives to web developers to stop deploying non-secure setups by giving them better sites over HTTPS.

I'm a big fan of ridding the web from HTTP-sans-S, but think new features are hardly the incentive we need for that.

Regardless, are there precedents for specs that recommend HTTPS-only with no technical reason behind it? Alternatively, is there an [optionallysecurecontext] IDL instruction?

[annevk]

That point is hardly compelling, at some point the combined set of features will be enough to convince 3rd parties and management to take the plunge.

[cvazac]

I think browsers will have their own philosophy on this, and a RECOMMENDED secure context note, especially one without a technical reason, isn't going to convince implementors.

[yoavweiss]

What @cvazac said.

That point is hardly compelling, at some point the combined set of features will be enough to convince 3rd parties and management to take the plunge.

Maybe. But Mozilla's policy is not a web-wide policy afaik.

So, my questions below still stand.

are there precedents for specs that recommend HTTPS-only with no technical reason behind it? Alternatively, is there an [optionallysecurecontext] IDL instruction?

[yoavweiss]

cc @digitarald following our discussion from last week

[cvazac]

Closing, resolved via #59.