Confirmed users
514
edits
Apps/PackagingProposal: Difference between revisions
→Packaging for Trusted and Certified apps
BillWalker (talk | contribs) |
BillWalker (talk | contribs) |
||
| Line 35: | Line 35: | ||
One obvious question once you go with a packaged solution is what URLs the packaged resources will be available through. My initial thought was to keep things as webby as possible and to make the resources in the package available as normal http or https URLs. The goal was that packaged apps would behave as much as possible as non-packaged apps. This would mean that in a trusted app a page that was part of the app would have URL <tt>https://developer.com/myapp.html</tt>, and a page which was part of the developer's website would have the URL <tt>https://developer.com/index.html</tt>. Yet the two pages would use different cookies, and any same-origin checks would have to say that the two pages are different. This is to satisfy the last two requirements in the bullet list at the beginning of this email. This is certainly implementable, however it seems very confusing for developers. | One obvious question once you go with a packaged solution is what URLs the packaged resources will be available through. My initial thought was to keep things as webby as possible and to make the resources in the package available as normal http or https URLs. The goal was that packaged apps would behave as much as possible as non-packaged apps. This would mean that in a trusted app a page that was part of the app would have URL <tt>https://developer.com/myapp.html</tt>, and a page which was part of the developer's website would have the URL <tt>https://developer.com/index.html</tt>. Yet the two pages would use different cookies, and any same-origin checks would have to say that the two pages are different. This is to satisfy the last two requirements in the bullet list at the beginning of this email. This is certainly implementable, however it seems very confusing for developers. | ||
Instead I think that we introduce a new protocol, <tt>app://</tt>, which is used to load all resources in trusted apps. This is an idea that Jim Straus came up with over in | Instead I think that we introduce a new protocol, <tt>app://</tt>, 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 <tt>app:// developer.com/myapp.html</tt>. 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 <tt>app://developer.com/</tt> to make network requests to <tt>http://developer.com</tt>. I.e. the app would be allowed to open <tt>XMLHttpRequest</tt> connections to <tt>http://developer.com/myapi.cgi</tt> without requesting any special privileges. Likewise images and videos loaded from <tt>http://developer.com</tt> 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. | 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 <tt>http://developer.com</tt>. I.e. the app would be allowed to open <tt>XMLHttpRequest</tt> connections to <tt>http://developer.com/myapi.cgi</tt> without requesting any special privileges. Likewise images and videos loaded from <tt>http://developer.com</tt> 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. | ||