Re: [sysapps/runtime] cross origin XHR in packaged apps

On Wednesday, 3 April 2013 at 04:16, Janusz Majnert wrote:

> There are several ideas in this thread that make using cross-origin
> communication easier. I just don't see the advantage of packaged web app
> sharing origin with some arbitrary site, for example when compared to
> using WARP.  
>  

(broadening the scope a bit… because XHR is just the tip of the iceberg IMO)
  
From a dev's perspective, the advantage is that you don't need to change the conceptual development/security model for the app. It's just as if you are running off your own server. This may feel like a small thing, but in my experience it turns out to be quite a big deal in practice: consider, if you try to use Google Maps with W3C widgets, it's not just a matter of declaring the following:

<access origin="http://google.com" subdomains="true" />  

With WARP, you actually need to list a whole bunch of different origins that Google maps uses… and those change at Google's whim because of the inclusion of various dynamically included resources (images, scripts, etc.) - so it becomes really brittle and a huge pain in the arse to develop for. At the end of the day, once you are done trying to unravel all the different hops that google does to serve you maps, you could end up with 10-20 different WARP declarations and things could still break for users.  

OTOH, Hosted Apps are unaffected by changes because <script> handles all this just fine (CSP allowing). Faking the origin of a packaged app solves this also, in a sense: so long as the fake origin is applied consistently and not just to XHR.     

Consider that packaged apps implementations have always needed to special case XHR for this (Mozilla's "System XHR" and Opera widget's XHR relying on WARP, for example) … these "solutions" circumvent the Web's security model - of which CORS should be considered part - and this has make packaged apps not work well with the Web.  

In the days of W3C Widgets we discussed this stuff to death: we were kinda afraid to allow packaged apps to fake their origin because we didn't want them to be bound to a digital signature (and we didn't really have a concept of "hosted apps" - only of Web apps that used AppCache). However, hosted apps give us an "out" for this situation and offload the problem to packaged apps (which must be signed to fake their origin). That is, so long as we all agree that CORS is the accepted way to do cross-origin requests and when developers complain that they can't get at some data, it's likely because they don't have a CORS enabled server (and it's on them to deal with that to move the Web forward and make their apps work… this may be an unacceptable 'anti-pattern' to some … but do we really want to provide an API like "System XHR" that can basically just go an retrieve anything from anywhere? sure, it's convenient for developers, but it comes at the cost of breaking the Web's security model and will require us to eventually standardise that if we want any interop between applications/runtimes).  

Of course, faking origin should not be taken lightly and should only be reserved for those that can prove ownership of the domain they are faking. And there is also an issue that domains expire and change ownership regularly: once a domain changes hands, it might become impossible for a server to distinguish between legacy apps requesting data (which may no longer be allowed to do so, leading to some kind of "downgrade attack") from newer versions of an app built by the new owners of the domain.

So, to summarise, we end up with two classes of "packaged apps":  

1. run off app:// - all their resources are self contained (a lot like a "native app"). Web content can only be included through something like a sandboxed iframe or Google's proprietary <browser> tag (or whatever it's was renamed to).  

2. run off fake origin - behave just like a hosted app (+CSP adjustments). Can make use of things like Google Maps.  

Sorry this rant was kinda long and I hope it was coherent... it's something that's bugged me for a number of years about WARP.   

--  
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 4 April 2013 06:54:38 UTC