Confirmed users
514
edits
Apps/PackagingProposal: Difference between revisions
→Delivering Trusted Apps
BillWalker (talk | contribs) |
BillWalker (talk | contribs) |
||
| Line 15: | Line 15: | ||
However, there are a couple of problems with this solution. | However, there are a couple of problems with this solution. | ||
== Serving Trusted Apps from the Web Won't Work == | |||
As Brian Smith has pointed out, signing HTTP responses isn't trivial. There's a significant risk that proxies will change headers on the way between the server and the user's browser. There even some risk that proxies will change the contents of the response bodies themselves. During normal browsing this isn't a big deal. But when the responses are signed it means that the response is completely rejected, leading to a very bad user experience. The only way to really prevent this is to always use https to serve the resources. However, this can be a non-trivial cost for the app | As Brian Smith has pointed out, signing HTTP responses isn't trivial. There's a significant risk that proxies will change headers on the way between the server and the user's browser. There even some risk that proxies will change the contents of the response bodies themselves. During normal browsing this isn't a big deal. But when the responses are signed it means that the response is completely rejected, leading to a very bad user experience. The only way to really prevent this is to always use https to serve the resources. However, this can be a non-trivial cost for the app | ||