Chris's Wiki :: blog/web/WhyHTTPSOnlyAPIs

Why I believe that HTTPS-only JavaScript APIs make sense

June 3, 2018

One of the things going on with browsers today is that they're moving to making more JavaScript APIs (especially new APIs) be available only for pages and resources loaded over HTTPS. One often believed reason for browsers to do this is that this helps drive adoption of HTTPS in general by providing both an incentive and a goad to site operators to move to HTTPS. If you want access to the latest attractive browser APIs for your JavaScript, you have to eat your vegetables and move to HTTPS. While I expect that browser people see this as one motivation for these restrictions, I think there are good reasons for 'must be served over HTTPS' restrictions beyond that. The easiest way to see this is to talk about site permissions.

Increasingly, JavaScript APIs are subject to user permission checks. If a website wants to use a location API to know where you are, or use your camera or microphone, or give you notifications, or various other things, the browser will ask you if you want to authorize this and then remember your choice. Beyond these special permissions, JavaScript from the same origin has additional access to cookies, data and so on that's not available to JavaScript from other origins (for obvious and good reasons; you wouldn't want my site to be able to fish out your cookies for Google).

The problem with these origin permissions is that if you give special permissions to a HTTP site, say, mygood.org, you are not really giving out the permissions that you think you are. Sure, you're allowing mygood.org to do these things, but you're also allowing anyone between you and mygood.org to do these things, because all of these people can inject JavaScript into pages as they fly by or simply redirect your connection to their portal or whatever. Your ISP can do this (and some have), the local coffee shop's wifi can, and so on. Everyone who can do this gets to act with whatever permissions you've given mygood.org. With sufficient cleverness they don't even have to wait until you visit the site itself; they can inject a redirection or an iframe that visits mygood.org for you.

In order for such site and origin permissions to really mean what they seem to mean, you need to be sure that you're only getting content from the origin; only then are you actually trusting only the origin, not the origin plus some extra places most people won't be aware of. The only general way we have to insure this is HTTPS. HTTPS makes sure that what you think is coming from the origin actually is. As a result, it's entirely sensible to restrict such special JavaScript APIs to be served over HTTPS, along with any API that you think might need per-site restrictions in the future.

(This is probably obvious to everyone who's deep in this stuff already, but it only occurred to me recently.)

Comments on this page:

By Aristotle Pagaltzis at 2018-06-03 10:12:58:

The only general way we have to insure this is HTTPS.

Well, the only general way of even trying to insure this. Even with HTTPS you are still trusting “the origin plus some extra places most people won't be aware of” – namely the whole CA ecosystem. I know I’m not telling you anything new, but you make this particular point as if TLS makes a difference in quality (that it precludes meddling) when it’s only different in quantity (it makes it harder for sub-government entities to meddle). (At this point. Browsers are doing what they can to make it harder to escape notice… but of course governments don’t have to care about that. Yada yada – you know all that as well as I do.) Your overall insight still stands, of course: it’s better to at least require TLS than to not require anything. But I do think it’s important to be accurate on this point.

By Aristotle Pagaltzis at 2018-06-03 17:31:38:

(Upon re-read, that sounds accusatory in a way I did not at all intend. Where it sounds like I’m saying “you should know better”, I was just trying to explain why I felt the need to nitpick this particular point, as well as convey that I’m not assuming that you don’t already realise the things I’m pointing out.)

By cks at 2018-06-04 01:16:14:

In theory you're right (and I considered including a mention of that in the entry before eventually deleting it). In practice I feel that there's at least an order of magnitude difference in the chances of these things happening. HTTP modification happens because they can be done (and sometimes they can be monetized or weaponized for nasty purposes), and as a result they've been done broadly and for petty reasons; ISPs have tampered with HTTP pages and destroyed customer trust for reasons as trivial as delivering 'you've used a lot of data' notifications. By contrast, HTTPS interception and modification now pretty much only happens because you're specifically targeted or you're a relatively broad victim of a nation-state (and even then it's an expensive attack, since these days the nation-state has probably just burned their access to a CA).

Written on 03 June 2018.

«	Intel versus AMD for me (in 2018)

What I use Github for and how I feel about it