Can somebody please help me understand what is cool about this ? Seems like a web interface that can use bluetooth.
Was this previously impossible or something ?
Was this previously impossible or something ?
Its like if you needed to download a new web browser for every website you visit, absolutely ridiculous.
You say it like it's a bad thing.
>Its like if you needed to download a new web browser for every website you visit, absolutely ridiculous.
I really do hope websites do not try and enumerate Bluetooth on their right own. I know I'd never enable access to Bluetooth to a browser.
Actually the web is an OS: it has api for gui, for persistent data, for networking, for all kind of periphericals (gpu, gps, bluetooth) ... The problem you're raising (which i agree with) is that we already have an OS and we'd like to use that one.
I think this is actually superior to the security offered by mobile apps on android, which can enumerate bluetooth devices as soon as they have bluetooth permission.
Are you suggesting that I don't need to download anything to view a website ? I beg to differ.
If you check the article, namely the photo of the phone you can see there's a browser opened from localhost, so something must have been downloaded on the phone.
As opposed to downloading 1 app per vendor/product, each of which has its own attack surface and special way of doing things that may or may not support your specific hardware implementation.
Yeah there is, it’s called screen.
That's precisely what it is. Accessing bluetooth devices from a progressive web app affords a lot of interesting new functionality for web app developers.
Was this previously impossible or something ?
Web bluetooth has been around since Chrome 42 behind a flag, but it's only recently appeared in other browsers so maybe now is the time to start taking an interest.
Does anyone actually use progressive web apps?
Yes, is the correct but perhaps overly terse answer.
A more useful answer depends on exactly what you mean by PWA, as there are several common interpretations of the term.
Personally I'm not really interested in routinely circumventing my mobile platform's app store, nor do I really want more clutter. Plus it seems like a lot of the sites that have the capability are just trying to push their brand in the same sort of way they did by having their own apps a few years ago - newspapers and other information sources which are just fine in the browser.
That you can do manually with any web page (that isn't badly designed) as it is essentially just an icon that opens the page when selected. The only real difference IIRC is that it looks like a separate app (in your task list etc.) instead of being a browser tab and having less browser chrome.
Another common use for the features that come under the PWA banner are local storage and running options, which reduce transfers to/from the server(a) and allow offline working. There are a few apps I use that work this way and you don't notice that they are anything other than a simple web app until you find yourself properly disconnected for a time and they still work.
The second instance sounds like something that should be an actual app, installed from a trusted source, if it has access to storage and other device features. Particularly if it can run in the background, issue notifications etc etc.
But many people do. I have a couple of shortcuts to common pages on my phone's home screen (well, a folder there on) just as I have shortcuts to certain files that I regularly interact with on the device instead of going to the app and manually opening them from there.
> sounds like something that should be an actual app, installed from a trusted source
Why, when it isn't doing anything the web app can do anyway. LocalStorage isn't a PWA-only feature, nor is notifications, and both have a least some gates to access (LocalStorage should limit the amount stored, prompting the user as a soft quota is reached as well as having a hard quota, and sandbox sites from each other, notifications asking for permission before they are enabled). I assume other features like bluetooth access are similarly gated, so there is no less protection than found in app store apps.
Why make me install an app on my phone as well as using the site on desktop/laptop, and make the developers write both, when the website based application can perform both roles?
There are sensitive permissions that I wouldn't want to grant a PWA (access to my contacts for instance, access to other apps files) of course, not being able to be globally disabled if found to be malicious as is possible with an app-store based install makes that more dangerous. But with careful control PWAs can be very useful without being any more problematical than any other web app.
If anything a web page is more secure than a native app: they can't even request wider access to the local filesystem (there is the FileSystem API in Chrome, but IIRC that has little traction elsewhere and can only operate on files specifically selected by the user rather than being able to randomly trawl around your everything). Definitely more secure than an app on the desktop, which most of the time runs as you and can do anything to your files that any other app running as you can do.
Bluetooth: I've not looked into it in detail (a quick search finds https://medium.com/@jyasskin/the-web-bluetooth-security-mode... amongst other relevant looking articles, but I don't have time to go through them right now) though I find it hard to imagine this similarly would be any less secure than a native mobile app having access to Bluetooth as the web page is going to have to ask for permission to use the API then you need to pair it with the target device.
I'm really not sure I want my browser managing a second tier of these permissions, especially as it runs arbitrary code downloaded from the net. Maybe it's an artificial distinction, but I'd rather keep "code I stumble upon without even realising by browsing the web" very separate to "Things I give device access to".
On my laptop, yes I use some of the others. Mostly gmail and github, of those.