Secure Contexts

From Pin Eight
Revision as of 16:29, 14 August 2016 by Tepples (talk | contribs) (Consolidate external links from User:Tepples/axes to grind and Portfolio hosting)
Jump to: navigation, search

This is a mini-rant, a short essay refuting a common misconception among users of an Internet forum. If you think this essay is FUD, feel free to explain why on the essay's talk page.

As of 2016, certain major web browser publishers such as Mozilla[1] and Google have announced plans to make sensitive JavaScript APIs available only within sites that use HTTPS, not cleartext HTTP, as a way of encouraging more sites to implement HTTPS.

Secure Contexts

The W3C's Secure Contexts spec defines a "secure context" roughly as a document all of whose markup and scripts come from a "potentially trustworthy origin". In turn, a "potentially trustworthy origin" is any of these:

  • An origin using an authenticated scheme (https: or wss:)
  • An origin on the local computer using IP addresses in 127/8 (IPv4) or ::1/128 (IPv6)
  • An origin on the local computer using a scheme that the browser considers authenticated (file: and possibly packaged browser extensions)
  • An origin that the user has "configured as a trustworthy origin", through a user interface that has not been specified

Notice that this does not include the local on an RFC 1918 private network (10/8, 172.16/12, or 192.168/16). This means that by default, a browser will treat a server on your home LAN no differently from a random PC connected to a public Wi-Fi hotspot in a restaurant. So until user agents provide a way to mark an origin as "configured as a trustworthy origin", the only way to make a computer other than the local computer trusted is to implement HTTPS.


Like other applications of Transport Layer Security (TLS), HTTPS requires a certificate from a certificate authority (CA) that the device trusts. This poses little trouble for developers of applications that can be accessed through the Internet, even hobbyists, as the owner of a domain can obtain certificates for plenty of machines that it operates in that domain through the Let's Encrypt CA. And for developers testing applications internally before public deployment, it's enough to operate a private CA using free software such as OpenSSL. The developer can then issue a certificate to the test server and deploy the private CA's root certificate on all client devices used for internal testing. The same is true of an internal web application accessed by corporate-owned devices on a corporate network.

But some web applications are intended for use by those people who happen to be authorized to connect to a particular private network at any given time, such as guests in a home or at a museum[2] or employees of a company that tolerates bringing your own device (BYOD). Requiring users to trust a private CA isn't practical for production use, especially for servers intended for use by the non-technical users associated with these use cases. Mozilla acknowledges unavailability of a certificate from a public CA when "a device doesn't have a globally unique name"[1] as a problem but has put off solving it. One might try obtaining a globally unique name from a dynamic DNS provider, but Let's Encrypt issues only 20 certificates per domain per week,[3] which is far too low for a dynamic DNS provider with substantial traffic. Thus each server operator must purchase his own domain name, and if an app ends up installed on private servers in a million homes, that makes a million domains that have to be purchased and renewed annually.

To work around the problem of no PKI for the Internet of Things, it was suggested to install the certificate on a smartphone somehow using NFC or QR codes,[4] but this hasn't yet been deployed.


  1. 1.0 1.1 "Deprecating Non-Secure HTTP: Frequently Asked Questions". Mozilla, 2015-05. Accessed 2016-08-12.
  2. [ greggman's question
  3. "Rate Limits". Let's Encrypt. Accessed 2016-08-12.
  4. Minutes of a W3C meeting. W3C, 2015-10.

External links