A malicious app must be installed before it can run and is likely vetted by the maintainers of a package manager or App Store. A webpage running JavaScript simply runs with no inspection from anyone.
Also, a malicious party usually cannot inject code into an installed app. Injecting it into a webpage you visit is far easier. Ad/tracking networks have been used for that. There is the possibility of a MITM attack if all parts of the page are not protected by HTTPS. There is also the potential for cross site scripting.
The web is not a place where I would want access to everything an installed application can access to be possible by design.
The Javascript has to request permission for each type of device access on first use, which is a lot better than the ask-for-everything-on-install model that older versions of Android use. Service Workers also only load over HTTPs. Generally xss attacks are prevented by the permission being granted to the domain of the script which is trying to use the service.
If you are uncomfortable that any given site will be properly secured you can always deny them the permissions just as you would decline to install their app, except that the website can offer you a degraded experience, where the uninstalled app will offer you nothing.
> The Javascript has to request permission for each type of device access on first use, which is a lot better than the ask-for-everything-on-install model that older versions of Android use. Service Workers also only load over HTTPs. Generally xss attacks are prevented by the permission being granted to the domain of the script which is trying to use the service.
If you are going through an app store, the app has been vetted. If that misses something and it is later found, it gets pulled. There is the possibility that you will never encounter the bad app by virtue of being one of the ones who would have installed it using it after it was pulled. On iOS, there is the possibility of signature revocation providing protection to disable it after it is downloaded. With a website, there is no such protection.
Plus, web servers are rarely patched and often exploited. Anyone who allows a website to use WebBluetooth effectively opens themselves to the poor security practices of the other end. Even without that risk, there is also the risk that an ad/tracking network is not used in a cross site scripting attack to gain access.
> If you are uncomfortable that any given site will be properly secured you can always deny them the permissions just as you would decline to install their app, except that the website can offer you a degraded experience, where the uninstalled app will offer you nothing.
If all users thought the way I did, WebBluetooth would never have been proposed. The reason being that WebBluetooth could be used to exploit other things even if the web browser's implementation has no exploitable bugs. If WebBluetooth becomes widely used, Black hats will have a field day with the users who do not know.
They need not even compromise a web server of a site that has a legitimate application for it. They might just ask users of some other site that they trust to enable it as few users ever say no to such prompts (or prompts in general).
Firstly, these powerful features are not available unless your site is properly (I.E. fully, absolutely nothing can be plain HTTP) protected by HTTPS. You cannot even create service worker without working HTTPS so any kind of PWA is out of question without HTTPS. Secondly, any browser that supports these capabilities also supports Content Security Policy which makes your site trivially immune to XSS and I expect that it will sooner or later become required to get access to the powerful features, on top of HTTPS. Thirdly, any powerful feature is behind a permission that is basically as hard to obtain as the consent to install an app in the first place.
First, black hats hack into sites protected by HTTPS all the time. Requiring HTTPS does not protect you when the server is compromised. Second, XSS is not needed to exploit devices on the other side. Third, users click/tap yes to just about any dialog, no matter what it says.
Also, a malicious party usually cannot inject code into an installed app. Injecting it into a webpage you visit is far easier. Ad/tracking networks have been used for that. There is the possibility of a MITM attack if all parts of the page are not protected by HTTPS. There is also the potential for cross site scripting.
The web is not a place where I would want access to everything an installed application can access to be possible by design.