Foreign Origin Space

This could be a proposal for adding a PWA only feature that would allow developers to fetch websites from predefined foreign origins. PWAs and the ongoing efforts from Chrome and Edge with new features like the FileSystemApi or desktop support for PWAs, changes the js landscape today to a point where we could scrap Electron and subtitute it with PWAs. But there is one important feature missing to make viable PWA apps today: The Cross Origin Fetch. Now with the implementation of CORS, developers have a hard time without a backend to create thirdparty clients for social-media sites, email clients, rss feeds, podcasts or other interact with other obscure APIs that tend to have not implemented cors or even refuse to. The Workaround for this is often times a (third party) backend that proxies every request, potentially exposing secret user information or secret data. Today there are multiple requests/proposals that requests like unrestricted network access, which clearly shows the need for such an API but also currently misses a few points in the security model to prevent abuse. This Proposal has a different take on foreign origin fetches and tries to be as safe as possible, yet open to any improvement/input from the community.

Proposed Process

1. Developer declares a foreign origin space in his Webmanifest he would like to access.

   {
    "foreign_origin_space": [
        "https://graphqlapi.com/query"
        "https://api.example.com/*",
        "https://thirdexample.com/api/*",
        "https://*.anotherexample.com/*",
    ]
   }
   

2. User installs the PWA.
3. User opens the PWA and gets asked if he would like to allow the defined origin spaces, with checkboxes to deselect urls that he (or the company policy) doesnt want.
4. PWA can detect which urls are granted through grantedOriginSpace which lists allowed urls.

   {
    allowed: [
        "https://api.example.com/*",
        "https://*.anotherexample.com/*"
    ],
    disallowed: [
        "https://thirdexample.com/api/*",
        "https://graphqlapi.com/query"
    ]
   }
   

5. User can manage origin spaces in the permissions settings like every other permission (camera, microphone, etc.)

How to secure foreign origin spaces?

• Only in a secure context (TLS/HTTPS)
• PWA has to be installed. (added to the Homescreen on firefox)
• User has to intentionally open the PWA and grant permission
• No Cookies are shared with the PWA. Using Partitioned Cookies like CHIPS for Chrome and Firefox State Partitioning
• The Origin Space is bound to the Webmanifest.
• No additional urls can be requested through js calls
• User has the option to deselect certain urlspaces.
• Companies have an option to implement a Company Policy, which forbids certain urlspaces.

Potential Risks

• Drive-by Permission Grabbing
  The User has to intentionally install the app and has to open the app to grant the permissions. The nagging website would have to go through some serious hoops to get permission.
• User doesnt know about potential bad urls
  Desktop apps typically dont reveal their apis, this approach shows them the urls in questions, asks for permission and sandbox existing cookie jars.
• Companies could reveal internal websites, through this
  Firefox, Edge & Chrome have a Company Policy feature where companies can preset various amount of settings. A new setting for could be disallowed origin spaces.
• A PWA could sniff the network and then ask for access
  PWAs are bound to their Webmanifest and cannot dynamically ask for new urls through js calls.

I hope that I could give this stalled request a new spin and am happy for your feedback.

I was just about to write a half-baked proposal for this use case.

I would like to add my two cents.

It should be in the manifest, but it should act similar to android in that you only ask for the permission when you need it so there would be a JS method for requesting permission with a pop-up. (though again, still has to be in the manifest.)

Pop ups should say something like: ${app name} would like to act as you on the following websites:

• Website Domain
  • URL Schema
  • URL Schema
• Website Domain
  • URL Schema

With the URL Schemas in a expandable portion since it’s better for people to freak out over giving a app too much permissions over confusing them about the specific url’s. The website domains should also show the website favicon.

Other than that you have a much more thought out preposal and I hope it gets pushed forward quickly so people can make community PWA’s for websites that could really use them.