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.)

Written on 03 June 2018.
« Intel versus AMD for me (in 2018)
What I use Github for and how I feel about it »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 3 03:12:58 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.