Labs/Jetpack/Reboot/JEP/106: Difference between revisions
Jump to navigation
Jump to search
(added a strawman proposal.) |
Dandonkulous (talk | contribs) No edit summary |
||
Line 29: | Line 29: | ||
Jetpacks are accessible through the <tt>jetpack:</tt> protocol. Each Jetpack has a keypair associated with it, and a Jetpack's ID is the SHA-1 hash of its public key. Jetpacks must be signed using their private key, and will not be loaded unless signed; thus a Jetpack ID, if present in the system, is guaranteed to be unforgeable. | Jetpacks are accessible through the <tt>jetpack:</tt> protocol. Each Jetpack has a keypair associated with it, and a Jetpack's ID is the SHA-1 hash of its public key. Jetpacks must be signed using their private key, and will not be loaded unless signed; thus a Jetpack ID, if present in the system, is guaranteed to be unforgeable. | ||
=== Use-Cases === | |||
* The wants to display an image/resource/L10n bundled with a Jetpack - option for allowing exposure of resource location needs consideration | |||
* Developer debugging ergonomics | |||
* Dynamically created, cache enabled, resources | |||
=== Key Issues === | === Key Issues === |
Revision as of 22:24, 11 February 2010
JEP 106 - Registered Jetpack URLs
- Champion: Atul Varma - avarma@mozilla.com
- Status: Accepted/In-Queue
- Bug Ticket:
- Type: API
- Difficulty: 8
Problem Statement
Every file in a Jetpack package needs a unique identifier for a variety of reasons:
- If an error occurs in a Jetpack's code, the traceback needs to include a URL that doesn't give away potentially sensitive information about its location on the user's filesystem.
- If a Jetpack wants to embed one of its images in a web page, it probably needs to do so with a URL, although such could also be done with a data: URI.
- If a Jetpack wants to self-host a web-like UI, it needs a URL to display in the URL bar. This URL should preferably be memorable but doesn't need to be.
- If a Jetpack wants to process the data contained in a file in its package, it should do so via a URL (though a relative path can potentially be used).
A prerequisite for this is that each Jetpack must have a unique ID that cannot be spoofed. This is valuable for a number of reasons:
- The host environment needs a way to keep track of Jetpack-specific resources; thus each Jetpack needs a primary key. If a Jetpack is uninstalled and reinstalled later and the user wants to keep their data, then the primary key may need to be preserved.
- The host environment needs a way of telling that one Jetpack is an upgrade for another, while guaranteeing that the upgrade isn't a forgery.
Proposal
Jetpacks are accessible through the jetpack: protocol. Each Jetpack has a keypair associated with it, and a Jetpack's ID is the SHA-1 hash of its public key. Jetpacks must be signed using their private key, and will not be loaded unless signed; thus a Jetpack ID, if present in the system, is guaranteed to be unforgeable.
Use-Cases
- The wants to display an image/resource/L10n bundled with a Jetpack - option for allowing exposure of resource location needs consideration
- Developer debugging ergonomics
- Dynamically created, cache enabled, resources
Key Issues
There are a number of security issues involved in this.
- Jetpacks should have a way of specifying which of their resources is "private", i.e. accessible only by itself, vs. "public", i.e. accessible from external code like web pages.
- It shouldn't be possible for a Jetpack to "spoof" another by e.g. having the same ID.
- The security policy for HTML code needs to be well-defined; should it follow the Web's standard single-origin policy, or something else? Can scripts be loaded from remote pages?