Network access

[kenchris]

Reading this:

It made me realize that Google Play is currently disallowing TWAs distributed to kids (Family Policy), it seems to have to do with the fact that websites might be able to replace the content as they have full network access, so it might make sense to take this into considerations and maybe disallow network traffic or restrict it somehow.

[craigfrancis]

I'd like WebPackages to have a way to clearly request/show it has no network access.

This would make a perfect replacement for many PDF's (invoices, reports, terms and conditions, etc), which need to be completely self contained, stored/archived, forwarded; and would resolve several issues with PDF's (easier to author, layout responsive to screen size, accessible by default, etc)... more info.

I have an example invoice that clearly returns remote content.

[EternityForest]

@craigfrancis Honestly I think this this is the only way Bundles can succeed. As it is, the privacy advocates don't trust them.

If they're not onboard, the platfom will basically always be in danger of being removed from some browsers and will become inconvenient to use.

I think that bundles should never be allowed internet access without explicit user permission, regardless of where they came from.

The most compelling use case of bundles is for installable apps, and as a PDF Forms replacement. If something is meant to be edited and shared, and created without a domain name, people will be happy to know it can't phone home without a popup prompt.

[ghost]

In (whatwg/html#6553), was introduced a declarative way for web developers to easily reason about network permissions without having to deal with HTTP headers, via the allow-net attribute in insecure HTML tags. This declarative approach for defining network policies would be more in line with the HTML specification than current network policies approaches, while offering:

• no network access by default (offline-first documents and applications)
• enhanced, fine-grained network permissions,
• the possibility to gain network isolation for critical parts of the document/application (Script tag extension: Per-Module Network Isolation whatwg/html#6547)
• the possibility to define and even extend declarative cross-origin communication scenarios, by leveraging the Shared Worker technology (Proposal: Declarative cross-origin communication in iframe and popup tags via Shared Worker whatwg/html#6555).

[craigfrancis]

Ideally Virus and SPAM scanners (and people) can clearly identify packages with no Network Access - so they know those files can be trusted (no network requests to the local/private network, not retrieving new content, etc).

[josephrocca]

There is some related discussion here: https://bugs.chromium.org/p/chromium/issues/detail?id=995236

Imagine the following situation: You've got a file that you need to process, and there are a bunch of web apps out there that can do it for you, but it's a sensitive file and you don't trust that they're not going to upload your file to your server and snoop on your data. For example, you might want to:

• Crop/resize/rotate your passport scan: squoosh.app
• Read a 5GB server log file: readfileonline.com
• Read your DNA data: fastq.bio
• etc.

These sites (and many others like them) do all their number crunching on the client, and they assure users that all the potentially-sensitive data stays on the client. But how does the user know that they're not lying?
As a web developer I'd love to have the ability to give my users certainty that I can't even "see" their data at all. If this were possible, it would give web apps an advantage over native apps because (of course) the native apps could be malicious too - people just tend to trust them more for whatever reason. Adding a feature like this would extend the "trustlessness" of the web platform, which is one of its best features.

---

@alancutter: I can see this being useful for enterprise environments that want to use third party PWA web bundles with sensitive business data. I don't think unplugging cables is a necessary or reasonable solution to having data isolation.
Updates to the bundle can be pushed out by the enterprise admin just like they do for native software today.

If the browser talks to the origin at installation/upgrade time to verify that the bundle contents are valid it's not transmitting any user data entered into the app so that's okay.

---

There has been some discussion on Hacker News about this sort of feature in the context of online client-side message encryption tools: https://news.ycombinator.com/item?id=23541949
The tool that prompted the discussion: https://simon-frey.com/s4/
A related tool: https://bs.parity.io/#/-BananaSplit-shamir

And here:

[I] so far haven’t come up with anything better than “Dear user of my app, i promise to keep your data on your device and not upload it to my server. Just look at the minified source code after every launch of the app as a proof, have a nice day!”, but the UX is crap. The thing is, i do not even want my users to have to trust me. [...] Well, turns out something equivalent has been done before, called packaged web apps. Web app files are in a package on a download server, app has no network access unless it gets user permission. Implemented by e.g. chrome apps and microsoft UWP apps. IIRC even hosted UWP apps (hosted by the developer, not by microsoft store) can and have to request network permission from the user. IMHO, something like this should not be hard to specify or implement for the web.

And also, speaking very broadly, I love Deno's --allow-net flag, and bringing something vaguely like that to browsers in some shape or form would be really useful for some applications - moving webpages from "safe to browse" to "safe to interact" (allowing file system access, webcam, etc.).

(This post was mainly to pull a few related threads in other forums into this one)

[josephrocca]

From recent W3C Security and Privacy Questionnaire of Isolated Web Apps:

While it is not currently in-scope, this proposal provides a big piece of what would be necessary for developers to opt out of network access entirely and build truly "offline-only" applications. Issue 1 covers the kinds of applications which would benefit from being able to make such a strong privacy guarantee.