index.md 3.8KB
title: Secure Contexts Everywhere
url: https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/
hash_url: e41a3e7efc
Since Let’s Encrypt launched, secure contexts have become much more mature. We have witnessed the successful restriction of existing, as well as new features to secure contexts. The W3C TAG is about to drastically raise the bar to ship features on insecure contexts. 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.
Requiring secure contexts for all new features
Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR. In contrast, a new CSS color keyword would likely not be restricted to secure contexts.
Requiring secure contexts in standards development
Everyone involved in standards development is strongly encouraged to advocate requiring secure contexts for all new features on behalf of Mozilla. Any resulting complication should be raised directly against the Secure Contexts specification.
Exceptions to requiring secure contexts
There is room for exceptions, provided justification is given to the dev.platform mailing list. This can either be inside the “Intent to Implement/Ship” email or a separate dedicated thread. It is up to Mozilla’s Distinguished Engineers to judge the outcome of that thread and ensure the dev.platform mailing list is notified. Expect to be granted an exception if:
- other browsers already ship the feature insecurely
- it can be demonstrated that requiring secure contexts results in undue implementation complexity.
Secure contexts and legacy features
Features that have already shipped in insecure contexts, but are deemed more problematic than others from a security, privacy, or UX perspective, will be considered on a case-by-case basis. Making those features available exclusively to secure contexts should follow the guidelines for removing features as appropriate.
Developer tools and support
To determine whether features are available developers can rely on feature detection. E.g., by using the @supports at-rule in CSS. This is recommend over the self.isSecureContext API as it is a more widely applicable pattern.
Mozilla will provide developer tools to ease the transition to secure contexts and enable testing without an HTTPS server.