Firefox locks down its future with HTTPS ‘secure contexts’

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.