> There are just some things that a web browser should not do. Exposing things that previously required escape from sandbox attacks is one of them.
Why is it any different from an app doing it, though? There will be the same permission prompts etc.
Why is it any different from an app doing it, though? There will be the same permission prompts etc.
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.
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 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).
From the article you have to "install" the web application for any of these features to be available.
> Apps also don't suffer from XSS.
From websites sure, but they do from other apps.
As far as the article is concerned, rendering a webpage as if it were an app takes away functionality (mainly, the ability to interact with the address bar). It does not discuss the security of web 2.0 features and it certainly does not claim that these features are only available when the webpage is pretending to be an app.
> From websites sure, but they do from other apps.
iOS uses capsiculum to isolate applications while Android uses SELinux. They aren't executing each others' code.
XSS isn't about executing other people's code, it is about performing commands that you shouldn't be performing. There are a ton of instances in the pass where cross application communications have lead to privilege escalation in the same way that XSS does.
It depends on the attack surface. However, something like WebBlueTooth has only one-click/tap authorization protecting it at best against software that is already downloaded and executing. Mis-taps/clicks are trivial. You do not have that with a new application that a website wants you to download. You also tend not to have installed software updated without your consent after you first obtained it (with the trend to use Javascript to add functionality to iOS apps being the glaring exception), but websites can be updated at any time, by both the web developer and by black hats who hack into it.