Mozilla is on a mission to make encryption on the Web ubiquitous, but the cost could prove too high to pay.
In a blog post made last week, Firefox Security Lead Richard Barnes declared that Mozilla would be "setting a date after which all new features [in Firefox] will be available only to secure websites."
Without a secure connection, some features in Firefox would be disabled entirely, "especially features that pose risks to users’ security and privacy."
The date in question hasn't been set, and debate still lingers about the feature set, especially what constitutes a "new" feature. Barnes noted this could mean "features that cannot be polyfilled"-- features that couldn't be emulated by way of JavaScript shims. This might include "access to new hardware capabilities," such as future varieties of sensors not yet exposed through HTML5 APIs.
Why embark on such a radical plan? Mozilla's recent history provides a broad hint.
Back in November, Mozilla announced co-sponsorship of a certificate authority, Let's Encrypt. Its mission will be to provide free TLS certificates to any domain name owner, along with tools to take the hassle out of managing and rotating them. The initiative would, in theory, remove two of the biggest obstacles toward deploying HTTPS unilaterially: the expense and difficulty of managing certificates.
But even with a solution like Let's Encrypt readily available, developers would need a lot of concessions before they would feel comfortable with it.
Consider a developer working on a Web application running locally using an ad hoc server. Setting up a certificate for such a thing wouldn't be too practical. For that, developers might need to have access to a whitelisting mechanism, even if it only worked with development servers running on the local host or in a private network segment.
Sven Slootweg, a software developer with a number of cryptography-related projects to his name, took to his blog to criticize the idea, as well as many of the proposed solutions. Let's Encrypt, he noted, might not provide certificates for wildcard domains, and relying on them exclusively could constitute a single point of failure.
"Isn't the point of an 'open Web'," Slootweg wrote, invoking Mozilla's own terminology, "that the same features are available to everybody, regardless of financial means or other qualifications?"
When the HTTP/2 standard was first being drafted, one avenue explored for it was to have HTTPS, not HTTP, be the default for all HTTP/2 connections. The idea died, due to a host of objections, and in the end, the chair of the IETF HTTP Working Group, Mark Nottingham, decided the carrot would work better than the stick -- that is, it would be better to create incentives to move people to HTTPS than punish them for not doing so.
Mozilla seems aware that these issues have to be confronted to make this even marginally workable. It's wise to leave the timeframe open-ended, as this is bound to invite plenty of contention and debate galore from developers, Web and otherwise.