On Sun, Mar 8, 2015 at 1:01 PM, ANTONIO MANUEL AMAYA CALVO <[email protected]> wrote: >> >> Mediated systemXHR: allow systemXHR on a per origin and per >> destination basis, so the contacts app can access Facebook and Gmail, >> and only some specific URLs on those servers, for example. Or allow >> any random X app to access only the servers we deem it's safe for it to >> access to. > > Maybe, but seems far simpler to change the SystemXHR permission just > to also accept a whitelist of origins that the app will connect with. > > That is another option, to give every special navigator API much more > granularity. Writing it on gaia makes it more flexible and easier to update, > IMHO, though.
I think this gets to the core of what this proposal accomplishes. That by implementing these APIs in Gaia rather then in Gecko, it makes it both easier to implement the API (writing gaia code is "easier" than writing gecko code), and, if we host Gaia on a webserver, we can update it without getting the OEM to compile a new FirefoxOS distribution. I agree that this proposal accomplishes that, and that there are good sides to this. I don't, however, think that this proposal is any more "webby", would be any easier to standardize or would be any less FirefoxOS specific, than adding APIs the way that we currently do. But I don't think that's a big deal since I don't think any of the ways that we expose these "sensitive APIs" stand a particularly good chance of getting standardized no matter what solution we use. The main downside that I see is that this solution would mean that we'd hand out access to particular APIs, not through signatures, but rather though hardcoded (but updatable) lists of websites that can access a given API. This would mean that we can't enforce things like signatures and CSP policies. Which are two nice security features of our current system. Using signatures actually removes some of the need to update as often. You don't have to update the API implementation every time you want to expose the API to a new website. The decision to expose an API to a new website is done purely server-side. If all we're trying to accomplish is to enable Gaia to implement APIs, then we should simply expose IAC to 3rd party content. This is effectively what the <iframe> proposal does anyway. I.e. it creates a postMessage-based channel between 3rd party content and Gaia. We could even add the ability to let the gaia side of IAC to inspect what permissions the content on the other end has been signed for, which would enable us to still enforce things like signatures and CSP where we want to. The only caution I would give is that just because we're implementing APIs in Gaia doesn't remove a lot of the work that we need to do to design APIs. I.e. a lot of what makes APIs hard to expose is that once exposed, you have to maintain them essentially forever. Looking at the other place where we've enabled Gaia to implement APIs exposed to 3rd party apps, we don't have a good track record in well designed APIs. https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities#Firefox_OS_activities / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
