User-approved permissions

[ghost]

What about user-approved permissions, such as which files or directories the web applications can access via Filesystem Access API, or other eventual future permissions describing a "trusted desktop activity" such as running particular local programs or scripts, or accessing environmental variables ?

I think that for clarity, the application manifest should contain the permissions requested by the web application developper to the end-user.

[aarongustafson]

This would be best discussed in the manifest specification. I’ll move it there.

[aarongustafson]

Related: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/InstallTimePermissionsPrompt/Explainer.md

[ghost]

It seems to one that an Install Time Permissions Prompt is indeed the way to go for web applications.

In the case of more complex permissions, the browser prompt might also ask for user's input in order to override default permissions values and persist them for future sessions.

Also, the web application should be able to reprompt the user in the case there is a need for changing the permissions while using the application, a bit like a form of "application settings" that could be modified by the user at any time.

In Script Tag extension proposal (#6541), one suggested an install prompt mechanism, as well as a "permissions" key with an array of permissions objects, allowing arbitrary complexity for the permissions, such as:

{
    "permissions": [
        {
            "deno": {
                "allow-write": "path/to/mydocumentfolder",
                "allow-net": "https://application.com"
            }
        }
    ]
}

One could also imagine a description property into the permissions objects so that the user is better informed about what they are in the prompt.

For example:

{
    "permissions": [
        {
            "deno": [
                {
                    "name": "allow-write",
                    "description": "Allow the application to write into the local folder",
                    "value": "path/to/mydocumentfolder"
                },
                {
                    "name": "allow-net",
                    "description": "Allow network requests to the following domain(s)",
                    "value": ["https://application.com"]
                }
            ]
        }
    ]
}

[marcoscaceres]

A bit of background on similar requests in the past: https://github.com/w3c/manifest/issues/75 https://github.com/w3c/manifest/issues/218 https://github.com/w3c/manifest/issues/319 + some personal thoughts on the subject - and why we haven't added anything like this to the spec previously.

The tl;dr is that the web platform APIs provide use-time/in-context permissions, as do some OSs (e.g., iOS). So enabling these APIs might via manifest would be incompatible with how permissions work on the Web, and in some OSs.

For the hypothetical "deno" straw-person above, it would presumedly use the Filesystem API, which would itself ask the user where the API can read/write to. Providing a path probably wouldn't make much sense, as every OS uses a different path structure. Similarly, wit the "allow-net" permission... that would be extremely difficult to communicate to an end use in the form of a permission. Additionally, how network communication works is governed by the Fetch spec (CORS, etc.), so it wouldn't make much sense to have such a permission.

Some limited permissions may be relaxed or granted at install time, but those are usually not directly observable by web applications.

[ghost]

@marcoscaceres, at first, the idea behind having permissions within the manifest is not to enable those APIs via the manifest but simply to give the browser a clue, ahead of time, about what permissions the web application needs to request to the user, before the web application document is actually loaded. It's why at first one posted the issue in manifest-app-info, and why it makes sense that it would happen at install time.

At the difference of simple websites or PWAs, Web Applications need an install time in order to configure the environment, so that they can deliver a smooth experience to the user, but also so that the user is informed that the application is not just a regular website, but a more advanced use case of web technologies, which may offer functionality comparable to what can do native applications. It is a natural evolution of the web platfom, as over the years, the browser has gained a lot of technical features and scripting capabilities way beyond the simple display of an HTML document into the browser sandbox.

So, we need a way to smooth the experience for the users, as it would be very inconvenient that many different prompts appear randomly when using the application. Therefore, exposing the permissions to the browser ahead of time would be a way to aggregate those permissions before launching the application, so that the user gains a clear and global understanding of what the application will be able to do concerning sensitive features or APIs, such as a kind of "application settings", before actually using the application.

I know that traditional desktop applications (including web browsers) do not ask any permissions to the users and do many things without their consent, but in the web technology world, it makes sense that web applications differ from the "do what you want without user consent" model and be more respectful of the users' wishes and awareness.

In the example above, deno is not a person, it is (unlike the browser sandbox) a secure javascript runtime environment that actually enforces permissions for sensible operations. So, here, it is a way to give to web users, via granted permissions, a more secure environment for local computing (unlike the browser, which, for example, can do any kind of wacky network requests without user consent), as well as a way for the users to access local resources, without necessarily being monitored by spyware analytics or being pushed or forced to put all their web activity and documents somewhere in the cloud, like traditional web applications are doing because of a lack of user control and of native functionality beyond the browser sandbox.

[marcoscaceres]

Please note the "Progressive" in PWA means that "Web Applications" and "Websites" are indistinguishable.

This is by design. It's the "one web" principle that we have operated under for the last ~15 years.

We are striving not to build an installed/not installed dichotomy by making sure there only "web apps". What you are suggesting would create a false dichotomy.

[ghost]

One would rather say that PWAs are websites that pretend to be Web Applications but aren't yet, because the browser lacks the features that would be necessary for having real Web Applications, such as a better security model than the actual browser sandbox, which locks the user into the cloud.

The browser sandbox is indeed a double-edged sword: it protects the computer from invasion, but at the same times, it creates the conditions for an insecure javascript runtime with no user control within the sandbox, while also forbidding developers and users to securely access local resources and to use web technologies for local computing.

The problem is that for many decades, the security model of browsers has been placed between the browser and the computer, and not between the browser and the internet.

We are striving to build web technologies that are transparent and secure for the users and allow developers to enhance the user's local computing without compromising local privacy and security.

[ghost]

@marcoscaceres 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 the Web Application, such as in the case of an update to the Web Application resources.

[ghost]

Related in w3c/webappsec: #578

[ghost]

@marcoscaceres

This is by design. It's the "one web" principle that we have operated under for the last ~15 years

Keeping old designs as eternal truth is not what is going to make the web moves forward. 15 years ago, no one even imagined that javascript could be used on the server or onto the desktop outside of the browser, while now it is pretty common.

The thing is that we can not use the website model for web applications, as there is an intrinsic difference between a website and an application. 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.

So if it makes sense that websites are hosted and under the total control of external servers, web applications, by default, should not be so tied to external servers or running into a sandbox totally open to the internet, as it may compromise the privacy, the security and the intellectual property of the users of the applications and can not offer a secure environment for users.

Also, we should keep in mind that the web is not just the browser and a server in the cloud, it is also the local computer that allows the browser itself to operate. So we can not totally remove of the equation the user's local computer, otherwise we prevent users to use web technologies to their full potential, for local computing, and we keep the web as well as the rights of users in hostage by the cloud companies.

That's why web applications can not be the same as websites, as the website model has not be thought for applications. Web applications should not have internet access by default. This way, many kind of software scenarios could emerge that would allow developers to build secure applications for users with native functionality, all the way up to less secure applications much like website nowadays but with no access to local computing.

It is not about creating a dichotomy of install versus non install, it is about preserving the rights of users, the security of the internet, and using the web in the interest of users with its full potential.

[ghost]

Allow @Nuckijfuta, how are you ?

Presently, web browsers forbid developers to build secure applications for users, in proposing PWAs, which are insecure by default (totally open to the internet and to the hosting server). Other persons do not even want to distinguish between websites and applications, letting the developers with the only option to build a website with cloud functionality as the only means of creating an "application". That is not acceptable.

Security should not be based on the trust in a foreign web server and/or in the transport protocol between the user computer and the foreign server, but on the warranty that by default, user's privacy and security is truly met locally before anything else happens.

Therefore, by default, the application shell should be totally sandboxed, thus the need for exposing permissions to users, and ahead of time if possible. It is important because according to the permissions that are required, different software scenarios are possible, a bit like Tauri patterns: hermit, bridge, cloudish, cloudbridge, lockdown, etc. Many kind of software scenarios can be built on the basis of fine-grained user-granted permissions. However, presently, developers are forced to use only one scenario: "web-cloudish", which is not secure at all, even less than the cloudish one which uses localhost.

What are your thoughts about it ?

[alancutter]

Whatever restrictions a web app has on network access should be applicable to web sites as well. I don't think the manifest is the right place to further this goal. I could see this being a browser level feature when loading a web bundle to disallow network access for the site. Spec work could come into play to enable the site to ask for network access again, perhaps limited to specific origins.

[ghost]

Whatever restrictions a web app has on network access should be applicable to web sites as well.

The goal is not to create new restrictions for websites, but to make web applications secure by default. The expression "web app" is generally used for describing websites with cloud functionality. Those websites are directly reachable via an URL into the browser, such as github.com. It is not the same entry point as a bundled web application. It seems to one that web bundles are binaries that are first downloaded by the users and then subsequently launched into the browser. Therefore, the bundled application is not directly reachable from an URL on the internet like websites are.

I don't think the manifest is the right place to further this goal.

The manifest is able to provide information about the bundled web application. But I do not think that websites actually need a manifest, as they are not bundled.

I could see this being a browser level feature when loading a web bundle to disallow network access for the site. Spec work could come into play to enable the site to ask for network access again, perhaps limited to specific origins.

Yes, I think that if web bundles are the standardized solution for web application distribution, then the web bundle should not have network access by default. It makes sense as they are conceived to be offline first application. Network access should then be managed via user-permissions.

[ghost]

Related to the question of the network access that would be approved by the user in the context of an offline first Web Application:

Script tag extension: Per-Module Network Isolation #6547

[marcoscaceres]

Closing as out of scope.