Security/Features/Content Hashing

From MozillaWiki
Jump to: navigation, search

Once you have created your Feature page, please remove this paragraph and link to your page from the Features Inbox, where a team will triage it and move it into the appropriate Feature list. If you have any questions, please contact Deb.

Feature Status ETA Owner
Content Hashing One or two sentence status report. YYYY-MM-DD Sid Stamm

Summary

This feature adds an HTML attribute to HTML elements that load files from external sources. The attribute allows the developer to specify the "hash" of the resource which is verified by the browser and used for loading commonly used items from cache across sites.

Wants:

Cross-Site Caching 
Precisely the same JS libraries' versions and images are regularly used by many sites at once.
Integrity Verification 
A site should be able to ask the browser to ensure that the file received and used is the file transmitted by the server.

To provide these two functions, a site should be able to specify the digest or hash of a file it references so that the user-agent can (1) locate the resource in cache of other origins for use across sites and (2) ensure the file delivered is the same file expected by the developers of the site. This feature will provide developers with an HTML attribute they can use to specify a hash of the file expected to load; the browser will identify an identical file in the cache from the same or other origins, or it will load the file specified and ensure it matches the hash before using it on the site. For more details, see the design below.

Team

Who's working on this?

  • Feature Manager: whoever is responsible for doing the day-to-day work of driving the feature to completion and updating the status on this page
  • Lead Developer:
  • Product Manager:
  • QA:
  • Security: Curtis Koenig
  • Privacy: Sid Stamm
  • Designers: Elie Bursztein, Chinmay Soman

Release Requirements

Complete checklist of items that need to be satisfied before we can call this feature "done".

  • Use cases are clearly identified to scope the feature (and prevent it from growing too large)
  • Future extensibility is designed to ensure it will work with future hashing functions and phasing out old ones.
  • Security threat modeling must be performed to help identify potential additional attack surfaces and design this feature so it does not introduce new threats.

Next Steps & Open Issues

  • [ON TRACK] Identify and specify use cases/requirements
  • [ON TRACK] Design solution and create specification
  • [NEW] Security/privacy design review
  • [NEW] Create test plan
  • [NEW] Write and land patch

Open issues include unanswered questions, things that need to be explored, decisions that still need to be made, etc. Again, including the name of who's responsible for each item can be useful.

Related Bugs & Dependencies

Links to the feature tracking bug & other relevant bugs; links to related plans (test plan, product marketing plan, etc.); notes about things that depend on this, etc.

Risks

Identify, prioritize, track and communicate any risks associated with this feature/project.

  • If implemented poorly, this feature could introduce cross-site injection attacks whereby an attacker who can create a file with hash matching a commonly used JS library could completely control sites that embed the common library.

Use Cases

Performance Improvement 
many sites embed a common version of jQuery but the browser must fetch and cache a copy of the same file from each site that uses it. Firefox should be able to just keep one copy and use it on all sites it encounters that deploy the same version of the same library.
Untrusted CDN 
a site may use a content distribution network (CDN) to serve the majority of their site (images, stylesheets, scripts) but may not want to rely on them to serve the right files. The site can serve the document and reference CDN-hosted content with hashed references to provide an integrity check.

Designs

Any and all mockups, design specs, tech specs, etc. Either inline or linked to.

Test Plans

Any and all test plans and strategies. Either inline or linked to.

Goals

The high level goals for the feature (which the release requirements checklist should fulfill). These are the guiding light and overall vision for the feature. Refer to this if there is confusion or are disputes about direction, designs, planning, etc.

(Taken from above)

Cross-Site Caching 
Precisely the same JS libraries' versions and images are regularly used by many sites at once.
Integrity Verification 
A site should be able to ask the browser to ensure that the file received and used is the file transmitted by the server.


Non-Goals

  • This will not provide DRM capabilities for use-based content policies
  • This will not provide encryption (secrecy) of hashed data

Legend (remove if you like)

  Healthy: feature is progressing as expected.
  Blocked: feature is currently blocked.
  At Risk: feature is at risk of missing its targeted release.
ETA Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date.


Please remove this line and any non-relevant categories below. Add whatever other categories you feel are appropriate.