64 ms·

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 ol

by takno 11y ago

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.

ryao 11y ago
> 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).

by takno 11y ago

ryao 11y ago

> 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).