On February 18, 2015 at 12:49:39 AM, Dale Harvey ([email protected]) wrote:
> The problem is not browser support for CORS, which has for quite a long
> time had pretty good support. The issue is that there are applications that
> in order to function require access to arbitrary remote services which we
> do no control. This is entirely different from the decision (which I
> disagree with) for TLS to be required for ServiceWorkers (or Geolocation /
> GUM) where the developer in the typical case has control over the stack and
> can choose to implement https however the developer cannot control wether
> arbitrary remote servers implement CORS.
But that's the whole point. We don't want people going around taking other
people's content without permission on scale. That's just wrong. If site A
wants to talk to Site B, then they need to establish a CORS relationship.
> I will let others speak for particular use cases, however as I mentioned
> earlier there is a simple explanatory use case, a read it later / RSS
> application in which a user specifies a list of remote origins they would
> like data to be fetched from and stored offline to be read at their
> convenience.
That could be built into the browser also - in many cases, that shouldn't
require an app (for obvious CORS reasons). Like a "keep this tab for later"
option.
> If the developer did not have the ability to use systemXHR, then this app
> would be limited to reading a very small number of sites to the point where
> it would be a useless application, asking every site administrator on the
> internet to enable CORS is obviously unfeasible and there is not a
> particular incentive for site administrators that arent actually using CORS
> themselves to bother implementing it.
Again, that's kinda the point. It's supposed to encourage establishing content
aggregation relationships. More below, with a real, and extremely successful,
example.
> So by saying access to a remote server is a solved problem because CORS is
> saying that a read it later app / RSS reader are not and never will be part
> of the web, as well as a long list of other use cases I haven't mentioned
No, but they will require to do some work. Flipboard is an example of an app
that works because of established relationships.
https://flipboard.com/publishers/faq/
```
How do I get started?
To get started, email a brief summary of the type of content you produce and
why you'd like to be featured on Flipboard. Please ensure that your RSS feed
complies with our guidelines before contacting us.
```
It would be the same with a Flipboard clone for FxOS... or at least it would be
without SystemXHR. The Flipboard clone would say, "you need an RSS feed and to
enable CORS" - That makes sense to me, at least. And it's _exactly_ what I
would have expected.
> Its worth mentioning in the case of ServiceWorkers an entirely new api for
> network access that supported workaround for cors (no-cors requests with
> opaque responses) had to be implemented
It's tremendously distressing to hear that we are still choosing to circumvent
the web platform's security model :( Please stop doing that.
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
