reillyeon
commented
2 years ago I think this proposal does lay the groundwork for that kind of opt-in. The current design explicitly allows communication with network hosts but it could be extended to allow applications to opt into a stricter Content Security Policy which blocked things like cross-origin HTTP requests and iframes. The primitive which Content Security Policy doesn't currently provide is the ability to block outbound navigation to cross-origin hosts, which would allow ex-filtration of data through the URL.
That seems like an interesting feature request for Content Security Policy and would be applicable outside of Isolated Web Apps. For example, some government sites and sites that allow user-generated content to include links use a "you are now leaving our site" interstitial. Having the server applying a "no external links" Content Security Policy to all pages except for that interstitial page could provide client-side assurance that the interstitial page is always used.
My concern with a "network access opt-out" feature in general however is that once it was built the standards community would have to be very careful when adding any new platform features to make sure that they didn't add a new channel for ex-filtrating data. However, given that part of the Isolated Web Apps design is that each application uses its own origin, this mostly comes down to preventing cross-origin data leakage which is already a goal for web platform privacy reviews. The existing issues around navigation-based data leakage are well-known in the web privacy community and currently being investigated.
josephrocca
Firstly, this is a super exciting proposal! Thank you for your work on this.
I'm not sure if this proposal is the right one on which to raise this idea, since there are quite a few ways in which it could be integrated into the web platform, but it seems like given how restrictive Isolated Web Apps already are in this proposal, it is a much smaller step to remove network access relative to removing it in other proposals, so it seems at least somewhat feasible from my potentially-naive viewpoint.
Basically, I think there would be a lot of utility in the ability for a non-malicious developer to "prove" to the user that the data they load into the web app (via
<input>s and File System Access API, for example) isn't secretly or accidentally uploaded to a server.For example, if I'd like to create an application that processes the user's genomic data in some way, or helps them filter/search a server log file, then it would be really useful to be able to give the user the certainty that I'm not going to upload anything to my server. People often reach for trusted native apps when they have to process sensitive files, but if there was a way for a web app to voluntarily revoke network access (in a way that is visible to the user), or not have network access by default, then even not-well-known web apps could be trusted with sensitive user data.
The lack of a means to create a web app that trustlessly processes user data creates an inherently centralizing force within the web ecosystem, because it means that only large, trusted companies are able to create certain classes of applications. For example, a few days ago I wanted to join two PDFs (with personal data) into one, and although there are lots of online web apps that do this with a simple drag and drop, I ended up going through the process of signing up for Adobe's cloud document management tool simply because I have more trust in Adobe - it being a very large and established company. They're probably less likely to have made mistakes or have compromised code.
There is some discussion of opt-in network access and various related points in this thread on crbug.