FYI, we discussed cross-origin service workers last week at the face-to-face meeting:
https://blog.wanderview.com/blog/2015/07/28/service-worker-meeting-highlights/#foreign-fetch It seems we're all in agreement that we should provide something here. We just need to de-conflict our two proposed specs. Implementation will take longer of course. Anyway, if you have feedback on the two proposals, please let us know in the issue: https://github.com/slightlyoff/ServiceWorker/issues/684 Thanks. Ben On Mon, Mar 23, 2015 at 9:38 AM, Benjamin Francis <[email protected]> wrote: > See also > https://groups.google.com/forum/#!topic/mozilla.dev.gaia/0CkXpQ25Wdc > > I think we're trying to solve similar problems in a slightly different way. > > It's possible navigator.connect with cross-origin onfetch events for > Service Workers could achieve some of this, and already has another browser > vendor interested in implementing it. > > Particularly for APIs which are privileged because they give access to > private user data rather than device features, it could provide a much more > webby solution that what we have today. > > On 10 March 2015 at 02:49, Jonas Sicking <[email protected]> wrote: > >> 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 >> > > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
