Confirmed users
514
edits
Apps/PackagingProposal: Difference between revisions
Jump to navigation
Jump to search
→Packaging for Trusted and Certified apps
BillWalker (talk | contribs) |
BillWalker (talk | contribs) |
||
| Line 42: | Line 42: | ||
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. | ||
We also need to come up with an update mechanism. One solution would be to every now and then check the URL which we used to download the original package to see if a new version is available. Another solution would be to send a single request to the store enumerating all apps which we want to check for updates for. That would allow for less traffic in the common case of no apps needing any updates, but might be more complex to implement and could have privacy implications. | = Updates = | ||
We also need to come up with an update mechanism. One solution would be to every now and then check the URL which we used to download the original package to see if a new version is available. Another solution would be to send a single request to the store enumerating all apps which we want to check for updates for. That would allow for less traffic in the common case of no apps needing any updates, but might be more complex to implement and could have privacy implications. | |||
= Webby-ness = | |||
All in all this definitely means that trusted apps won't be as webby as normal apps. However as long as we have the requirements around signing by the store, an enforced CSP policy and a separate cookie jar, trusted apps simply won't be very webby. Whether we zip the files up in an package and deliver them the store for signing, or we deliver them through the store through http, is a relatively small difference which only affects the deployment of the app, not the development. | All in all this definitely means that trusted apps won't be as webby as normal apps. However as long as we have the requirements around signing by the store, an enforced CSP policy and a separate cookie jar, trusted apps simply won't be very webby. Whether we zip the files up in an package and deliver them the store for signing, or we deliver them through the store through http, is a relatively small difference which only affects the deployment of the app, not the development. | ||
In the long run I definitely want to make trusted apps more "webby". Both by changing our trusted apps work, and also by giving the web more capabilities so that they can meet somewhere in the middle. But I think the above proposal is a good way to start by doing something secure which will give us experience and help us develop something better in the future. | In the long run I definitely want to make trusted apps more "webby". Both by changing our trusted apps work, and also by giving the web more capabilities so that they can meet somewhere in the middle. But I think the above proposal is a good way to start by doing something secure which will give us experience and help us develop something better in the future. | ||