Web Applications should not have internet access by default

[ghost]

Context

The users of Web Applications expect them to be a more secure and controlled environment than a regular website, which can do any kind of wacky network requests, push or force them to upload their documents into the cloud, or even monitor their activity via spyware analytics.

Proposal

The difference between a website and a Web Application is that, by default, a website has internet access, whereas, by default, a Web Application should not, and only fine-grained, user-granted permissions should control internet access from within the Web Application, such as in the case of an update to the Web Application resources.

Why ?

Websites display something external to the user, while applications are softwares that allow much greater user inputs and concern the creation and/or the modification of documents and informations under the user's own intellectual property.

The users do not want to see their local privacy, security and intellectual property compromised when using a Web Application.

If internet access was on "by default", the users could not really control what happens to the Web Application activity and to their intellectual property from within the application, and the developers could not use native functionalities that would bypass the browser sandbox, such as interacting with the local machine for enhancing the local computing via local programs, scripts and resources from within the Web Application.

To turn "off", by default, internet access within Web Applications gives to users the warranty that their privacy, intellectual property and security is not compromised, and allows developers to enhance the user's local computing by being able to securely interact with local resources.

[awwright]

The users of Web Applications expect them to be a more secure and controlled environment than a regular website

Do you have a citation? This seems backwards to me. I expect websites to be documents that don't need fancy scripting and can't pull shenanigans. Applications, on the other hand, don't work without scripting.

[ghost]

I expect websites to be documents that don't need fancy scripting and can't pull shenanigans. Applications, on the other hand, don't work without scripting.

It is because Web Applications need scripting that they have to be dealt with securely and differently than mere web documents, even if web documents may also benefit from scripting. In fact, there is a wide spectrum of scenarios between a simple web document without any user input and a full blown application in which users may create and modify complex documents and files that they own. We can not treat them equally in regards to security, privacy and ownership concerns.

The vast majority of users do not really know what scripting is or only have a vague idea about it. However, what they do know, is that when they put their "stuff" in, they expect the whole thing to be secure, a bit like their bank account, because they do not want to be harmed or abused in anyway by the web application that they expect to trust. Users do not need to trust a web document, however they need to trust a web application in that regard. But at the difference of the bank account, in which it is the bank that manages the things for the clients in secure ways, in web applications, it is the users that often need to manage their own things locally and they do not want or need that their "stuff" go into exotic and remote places that no one, no institution, no authority will ever control or audit, contrary to what can be expected from financial institutions.

Also, in order for web applications to be used in secure environments, they need to be compliant with strict security schemes regarding network access. Many work places for example do not have direct internet access, or have constrained internet access, and thus web applications need not only to work offline, but also to be protected from potential risks coming from the external network.

Presently, complex web applications are often websites that have to make copies of the user's intellectual property, transport it through the network and store it into remote servers. This creates comprehensive and complex technical security issues as well as legal issues which are a drawback for many users, who are obligated to delegate to sometimes many different third-parties the management of their own "stuff".

By making Web Applications offline first, this technical and legal concern goes away, as well as the psychological concern and the worry that go along with when one delegates one's "stuff" to third-party agencies and remote locations. Such delegation should be in the control of the user if they need to, but not imposed by default by the web platform as it is actually the case with cloud-first websites/applications.

[ghost]

I expect websites to be documents that don't need fancy scripting and can't pull shenanigans.

It is worth to point out too that some exploits may not necessarily use scripting...

Such as the following news: New Browser Attack Allows Tracking Users Online With JavaScript Disabled (thehackernews.com)

So ultimately, it all comes down to internet access in the first place, from the very beginning. If the Web Application it not offline by default, the security is not warranty. However, if network access is controlled client-side with permissions and in isolation, such as with the proposal above for per-module network isolation, then it is a different story. Even if a web server or transport protocol gets compromised, it is still possible to maintain critical parts of the application offline.

[dveditz]

You seem to be describing an "Application", not a "Web Application". With "Web" right in the name I would totally expect that to have internet access. In any case, the "webappsec" group is about designing tools and technologies for the web application authors to use, and you're trying to put fundamental limits on the Web Application definition itself. That's not us so you might want to find a better forum for this request.

[ghost]

You seem to be describing an "Application", not a "Web Application". With "Web" right in the name I would totally expect that to have internet access.

I am not playing with words, I expect a "Web Application" to have the same characteristics than any other "Application", that is: security in mind for the users. I did not say that a "Web Application" should not have internet access... not at all... I say that it should be offline-first, and then, granularly (such as with per-module network isolation whatwg/html#6547), it could opt-in for internet access in a secure way, so that network access does not expose the user's data or compromise the application security itself. This is not the case if the web app runs in a half-sandbox totally open to the internet at any time of its lifecycle.

[craigfrancis]

@abflow, it looks like this has been discussed in #538, but I think this can be solved via a small addition to the WebPackage format.

This would give us a file that can be downloaded, and run by itself (isolated), with no internet access.

In my case I'd like a replacement to PDF documents (for invoices, contracts, reports, etc), to fix its flaws (accessibility, layout that works on small screens, etc), and those WebPackage documents must not have access to the network (where the user would need to download a new WebPackage to update).

More info in WebPackage Issue 576.

[ghost]

@craigfrancis, many thanks for the comment. As pointed out by @dveditz above, a "Web Application" should have internet access if needed, therefore a totally offline application is not desired, and not the goal of the proposal.

However, if the application requires no internet access, as in your case, it has to be possible too, and in fact, it should be the default behavior of the document / application. I have pointed out in (WICG/webpackage#576), the proposals that can be used to achieve security by default, while still allowing the possibility to grant internet access to the application in a confined way, which would not compromise security and privacy. Other issues should then take care of defining how, from a user point of view, the permissions mechanisms have to be conceived, for a seamless UX design.

[samuelweiler]

There is a set of Web Applications that don't need network access following page load, and I agree that the user would be well-served by having those applications give up network access and by being informed when that has (and hasn't) happened.

Take, for example, a compound interest calculator. You can't write it as a simple HTML document, and there's gain for the user in having it give up network access after loading.

I also know that many sites use JavaScript when they could get away without it, so there are also opportunities where a user would want to deny a site network access.

So while I'm intrigued by the idea, I share dveditz's doubts that this WG is the place for it.

[ghost]

Serious web applications, such as a local document creator or editor, need to isolate parts of their program from the network, such as with the per-module network isolation proposal mentioned above, both for the security and privacy of users and for being able to integrate local desktop activities into a trusted environment.

This implies a new security model for the internet that needs to be shifted from the remote server to the local machine hosting the browser. The remote server is always "potentially trustworthy" (as per the HTML specification) but not truly secure. What is truly secure for the users is the local machine hosting the browser. Thus the idea that Web Applications should have a local (and not remote) security model pertaining to network access.

One thought that W3C would have had more incentive to innovate than whatwg. Whatwg closed all the related proposals, asking first for browser implementation before even considering it. At the same time, it is very clear that they are lost into countless technical problems related to the actual content-security-policy, which could easily and elegantly be solved by declarative network isolation via a specific attribute within insecure HTML tags.

One doesn't really know what could be the place for it, apart from building an alternative World Wide Web which would be secure by default for users ( and that was in fact, it seems to one, the original intent of the web inventors : to have the ability to securely access local files in a local network, without the security model being defined remotely).