Labs/Jetpack/Reboot/JEP/106: Difference between revisions

From MozillaWiki
< Labs‎ | Jetpack‎ | Reboot‎ | JEP
Jump to navigation Jump to search
No edit summary
(added more stuff)
Line 9: Line 9:


=== Proposal ===
=== Proposal ===
* What will it do?
* What does it enable internally/externally?
* How hard is it to implement?


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.


=== Key Issues ===
=== Key Issues ===
* chrome URL issues with content being given escalated privileges in a one-way, downstream fashion


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?


=== Dependencies & Requirements ===
=== Dependencies & Requirements ===
* Are there any Firefox platform bugs blocking it?
* Does other Jetpack platform code need to be modified or added?
* Does its implementation affect any other projects or code?




=== Internal Methods ===
=== Internal Methods ===
* What methods, mechanisms, or resources does this provide internally within the Jetpack platform code.




=== API Methods ===
=== API Methods ===
* What are the pretty API wrapped methods externally exposed to Jetpack developers?

Revision as of 23:09, 5 February 2010

JEP 106 - Registered Jetpack URLs

  • Champion: Atul Varma - avarma@mozilla.com
  • Status: Accepted/In-Queue
  • Bug Ticket:
  • Type: API
  • Difficulty: 8


Proposal

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.

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?

Dependencies & Requirements

Internal Methods

API Methods

Retrieved from "https://wiki.allizom.org/index.php?title=Labs/Jetpack/Reboot/JEP/106&oldid=200207"