Re: CORS in PWA's

With what you're proposing, you visit my site, and I gain access to
anything you can access that's protected by something other than browser
credentials.

Are you running a local server to developer some super secret next version
of your company's product? I can see that now.

Is a colleague on the same network as you doing that? I can see that now.

Does your company have anything on it's intranet that's assumed to be safe
just because it's 'internal'? I can see that now.

Do any external pages behave differently because they're viewed from your
IP? I can see that now.

Do you have any IoT devices that assume they're safe because they're on
your personal network (remember, the 's' in IoT stands for 'security')? I
can interact with that now.

Etc etc. And yes, all of those things should be done in a more secure way,
but that isn't how it works in practice. And yes, those things are all
vulnerable to native apps. Native apps aren't as safe as the web.

On Fri, 9 Oct 2020 at 09:26, Daniel Betteridge <Daniel.Betteridge@arup.com>
wrote:

> Hello!
>
> I’ve done a bit of a search of the mailing list and aside from a somewhat
> antagonistic post (
> https://lists.w3.org/Archives/Public/public-webapps/2017OctDec/0044.html)
>
> I couldn’t find a thread on this topic, given the goal of client side
> web-apps to incorporate a lot of functions of ‘Native’ applications one of
> the big sticking points is the CORS restrictions that browser based
> applications face that their Native counterparts do not.
>
>
>
> I wrote a bit about the issue I was facing (
> https://danielbetteridge.com/a-lost-cors/) but essentially, If I want to
> write a PWA that uses any third party resources I need to either work only
> with servers configured with CORS (less then I’d like) or create a proxy to
> work around the issue.
>
> What are the barriers or issues with (for example) allowing GET requests
> to a different origin within specifically an installed PWA where the fetch
> request has credentials set to “same-origin”, this would allow a lot of the
> functionality that is currently blocked (RSS feeds, Podcasts etc).
>
> I did read Boris’s response in the link above, but unsure how this is
> congruent with non-browser usage of resources. If a webpage relies on CORS
> to secure its resources, are they not effectively open to anyone who uses
> something other than a browser to access the site such as CURL/Custom
> browser without CORS etc.
>
>
>
> Thankyou!
>
> Daniel
>  ____________________________________________________________
> Electronic mail messages entering and leaving Arup business systems are
> scanned for viruses and acceptability of content.
>