Skip to content
Naked Security Naked Security

Firefox locks down its future with HTTPS ‘secure contexts’

Firefox developers must start using ‘secure contexts’ for new features “effective immediately.”

Mozilla’s embrace of HTTPS, the secure form of HTTP, has ratcheted up a notch with the news that Firefox developers must start using a web security design called ‘secure contexts’ “effective immediately.”
This isn’t a surprise –  Mozilla mandated that security-sensitive geolocation be added as a secure context last March – but the signal is still significant.
Announced Mozilla:

All the building blocks are now in place to quicken the adoption of HTTPS and secure contexts, and follow through on our intent to deprecate non-secure HTTP.
Everyone involved in standards development is strongly encouraged to advocate requiring secure contexts for all new features on behalf of Mozilla.

The odd thing is that while secure contexts (also called ‘secure origins’) matter a lot to end user security, almost nobody beyond web devs has ever heard of the mechanism or pondered why it might be a big deal.
This could be about to change thanks to the publicity generated by the much better-known campaign by Google and others to migrate websites from insecure HTTP connections to encrypted HTTPS.
The principle of secure contexts is an incredibly simple one – that certain powerful web capabilities and APIs (whose risks users are often barely aware of) should be forced to work over HTTPS.
These mostly hidden functions currently include:

  • Geolocation
  • Bluetooth
  • HTTP/2
  • Web notifications API
  • Webcam and microphone access
  • Google’s Brotli web compression algorithm
  • Google’s Accelerated Mobile Pages (AMP)
  • Encrypted Media Extensions (EME)
  • The Payment Request API
  • Service Workers used for background sync and notification

(Another three – the AppCache API, Device motion/orientation, and Fullscreen – will follow in time.)

These could all work over HTTP, of course, but that would represent a security risk that attackers could exploit to steal credentials, track users, and intercept data using man-in-the-middle ruses.
Wouldn’t it be simpler to make all sites use HTTPS and be done with it?
Although HTTPS secures the browser’s connection to a website, a non-HTTPS function could still be opened in a separate window without that insecurity being obvious to the user.
Realising all this was becoming an issue as the web got more complicated, Google kicked off the secure contexts initiative in 2014, gradually adding these requirements to Chrome. Mozilla has busied itself doing the same for Firefox.
Since then, the whole thing has turned into a W3C draft proposal, another cog in the multi-dimensional drive to make all traffic between web users and websites encrypted, including the possibility of DNS queries in the future.
Mozilla is set to start using secure contexts for existing features too, on a “case-by-case basis.” The catch is that turning off support for HTTP in web technologies won’t necessarily be quick or without complication.
As Mozilla noted in 2015:

Removing features from the non-secure web will likely cause some sites to break.  So we will have to monitor the degree of breakage and balance it with the security benefit.

Google-centrism might be another factor, although given that Microsoft’s IE and Edge are the only major browsers that don’t yet support the idea, this is probably of minor importance.
The drag might be simply that the HTTPS movement has turned into a big undertaking, assertively pushing HTTPS by the front door and a fragmented series of secure contexts by the back.
Mozilla’s announcement reminds us that while the momentum is with it, this one has a way to roll yet.


For hobbyists and non-profits, this is becoming a problem as from what I’ve seen you typically have to pay more for hosting that is capable of HTTPS support. For my car clubs I’m having trouble figuring out why we’d need to have our site hosted on an HTTPS site.


Three words: security, integrity, authenticity. HTTPS isn’t just about the secrecy, it’s about your users being able to trust what they see served up in your name. Without HTTPS, anyone in their path (e.g. when they are on public Wi-Fi) can modify anything they view on your site (e.g. by stuffing coinmining software into your web pages) and they will never know it wasn’t you.
Read this, for example:


Thanks to letsencrypt, it is now fairly easy to add SSL encryption to any website. (Or at least any site hosted on reasonably recent Linux).
I run a private site hosted on a Debian 9 box, and for me setting up SSL was simply a case of installing the certbot tool with apt-get, running it once to setup the certificates via a wizard, then adding a monthly cron job to renew certificates as they expired. (By default letsencypt certs are only valid for 3 months).
The whole thing was extremely easy, only took about half an hour, and did not cost me anything.


> The drag might be simply that the HTTPS movement has turned into a big undertaking, assertively pushing HTTPS
Umm, yes. Trivial to register a domain name and put together a few pages. Getting a certificate and installing it are much more complicated and (until Let’s Encrypt) much more expensive. I still have one site that solicits no PII or credit cards–in fact no user input at all–on a provider that doesn’t offer TLS. One of these days I’ll have to port it and I know it will cost me more than the $70/year I’m paying now.


I don’t have a comment about the content of the article. I’m just curious why a photo of a red panda is associated with this subject…


This and the Expect-CT security header from Google Chrome ought to keep web developers busy for a while. And that’s assuming that the developers care. It seems that there are a lot of them that throw together a site or app and then call it good.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!