- From: abflow <notifications@github.com>
- Date: Tue, 30 Mar 2021 01:43:55 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/967/810036238@github.com>
@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. On the example above, deno is not a person, it is a [secure javascript runtime](https://deno.land/) environment that actually requests permissions to the user for sensible operations (unlike the browser, which, for example, can do any kind of wacky requests without user consent). So, it is a way to give to web users, via granted permissions, a more secure environment for local computing, as well as a way to access local resources, without necessarily being spied by spyware analytics or being pushed or forced to put all their web activity and documents somewhere in the cloud like in traditional web applications are doing because of a lack of user control and native functionality beyond the browser sandbox. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/manifest/issues/967#issuecomment-810036238
Received on Tuesday, 30 March 2021 08:44:08 UTC