Confirmed users
514
edits
Apps/PackagingProposal: Difference between revisions
Jump to navigation
Jump to search
no edit summary
BillWalker (talk | contribs) |
BillWalker (talk | contribs) No edit summary |
||
| Line 37: | Line 37: | ||
Instead I think that we introduce a new protocol, app://, which is used to load all resources in trusted apps. This is an idea that Jim Straus came up with over in bug 707625. Introducing this new protocol certainly has the disadvantage that it feels less webby, however I think the benefit in clearing up the confusion above outweighs it. It makes it very clear which pages will receive which cookies, and which pages are same-origin and thus can reach in to each other. To make things as webby as possible though, I think such URLs should be given a "real" domain, like app:// developer.com/myapp.html. This would be the domain of the developer, i.e. a domain that the developer has to own. We would have to come up with some mechanism for verifying this ownership though. | Instead I think that we introduce a new protocol, app://, which is used to load all resources in trusted apps. This is an idea that Jim Straus came up with over in bug 707625. Introducing this new protocol certainly has the disadvantage that it feels less webby, however I think the benefit in clearing up the confusion above outweighs it. It makes it very clear which pages will receive which cookies, and which pages are same-origin and thus can reach in to each other. To make things as webby as possible though, I think such URLs should be given a "real" domain, like app:// developer.com/myapp.html. This would be the domain of the developer, i.e. a domain that the developer has to own. We would have to come up with some mechanism for verifying this ownership though. | ||
To make things more similar to how web pages normally work, we could allow pages from app://developer.com/ to make network requests to | To make things more similar to how web pages normally work, we could allow pages from <tt>app://developer.com/</tt> to make network requests to | ||
http://developer.com. I.e. the app would be allowed to open XMLHttpRequest connections to http://developer.com/ <http://developer.com/.>myapi.cgi without requesting any special privileges. Likewise <tt><img></tt>'s and | http://developer.com. I.e. the app would be allowed to open XMLHttpRequest connections to http://developer.com/ <http://developer.com/.>myapi.cgi without requesting any special privileges. Likewise <tt><img></tt>'s and <tt><video></tt>'s loaded from http://developer.com would not be considered cross-origin for example for the purposes of tainting when drawn into a <tt><canvas></tt>. This way most of the code which would work for a website would work in a packaged app, except that the packaged app would have to ensure to use absolute URLs when wanting to connect to the website. | ||
In order to keep applications isolated from each other (except through explicit APIs like WebActivities) the app:// protocol always maps to loading from the package that the load is initiated from. Consider a user which has a facebook app and a google maps app installed. Whenever the facebook app loads an app:// URL, we always look in the package which contains the facebook app. If the resource isn't found there we return a 404 error. I.e. we never even look at the google maps package, even the facebook app tries to load something like app://google.com/map.html, the result is simply a 404. This also means that it's not a problem to install two apps from google which both contains the same app:// google.com/library.js URL. Each app would simply load the library.js file from its own package. | In order to keep applications isolated from each other (except through explicit APIs like WebActivities) the app:// protocol always maps to loading from the package that the load is initiated from. Consider a user which has a facebook app and a google maps app installed. Whenever the facebook app loads an app:// URL, we always look in the package which contains the facebook app. If the resource isn't found there we return a 404 error. I.e. we never even look at the google maps package, even the facebook app tries to load something like <tt>app://google.com/map.html</tt>, the result is simply a 404. This also means that it's not a problem to install two apps from google which both contains the same <tt>app:// google.com/library.js</tt> URL. Each app would simply load the library.js file from its own package. | ||
There are still lots of parts that we need to figure out. First of all we need to define an exact format for the package. There are lots of formats out there for signed packages, .jar which is commonly used by java, .xpi which Firefox uses for addons, .crx used by Chrome, etc. We can either pick an existing one, or design a new one. I'll explicitly declare it off topic for this thread to come up with the specific format. Please start separate threads about that. | There are still lots of parts that we need to figure out. First of all we need to define an exact format for the package. There are lots of formats out there for signed packages, .jar which is commonly used by java, .xpi which Firefox uses for addons, .crx used by Chrome, etc. We can either pick an existing one, or design a new one. I'll explicitly declare it off topic for this thread to come up with the specific format. Please start separate threads about that. | ||