Lesser-known Web APIs
blog.greenroots.info
blog.greenroots.info
At the same time you had stand-alone code-samples which were of dubious quality at best:
if (document.someBoolean) {
setEnabled(true);
} else {
setEnabled(false);
}
So yeah. Coupled with lots of Chrome-only APIs, I wouldn't consider this a very high quality article.
how about:
setEnabled(
Boolean(
document.someBoolean
)
)- Fullscreen
- Image capture
- Resize observer
- Broadcast Channel
Demos that don't:
- Clipboard API (not supported)
- Battery API (not supported)
- Performance information (says it's supported, but shows an empty page)
- Vibration API (supported by the browser, but doesn't actually vibrate because malvertisers abuse the API in their antivirus scams)
- Bluetooth API (not supported)
The fullscreen, image capture and broadcast channel APIs are nice I suppose, but the rest should probably be considered "Chrome APIs" rather than "web APIs".
Edit: even in Chrome on Android, the battery API is reporting fake information and the vibration demo doesn't work. That's the problem with experimental web APIs, you can't rely on them at all.
That's just plain wrong. They're web APIs that are maintained by the W3C (in various states) that Firefox doesn't support yet. That doesn't make them "Chrome APIs" just as a W3C spec that only Firefox supports isn't a "Firefox API".
Clipboard API: https://w3c.github.io/clipboard-apis/
Battery API: https://w3c.github.io/battery/
Performance: https://www.w3.org/TR/resource-timing/
Bluetooth API: https://webbluetoothcg.github.io/web-bluetooth/
The fact there isn't good cross-browser support is a reason to check whether or not a user's browser has support and use progressive enhancement to only show the feature to users who can benefit from it. It isn't a reason to avoid using the API unless you want to stick to the lowest common denominator for your users. In my case that would mean serving Chrome and Firefox users content that's developed for IE10. That would suck for people who are able to update their browser, so I prefer to put the effort in to adding features progressively.
These kind of proprietary APIs are exactly what Microsoft did 10-20 years ago as part of their "embrace, extend and exterminate" process. They extended IE with their proprietary APIs (such as HTML+TIME), which other browsers never implemented.
Bluetooth, Battery and many other Chrome APIs are just Google's and Microsoft's new attempt to "embrace, extend and exterminate" other browsers.
[1] https://www.zdnet.com/article/apple-declined-to-implement-16... [2] https://mozilla.github.io/standards-positions/
I realise this is a bit pedantic, but this is wrong. They're W3C specs that Mozilla and Apple have chosen not to support. Calling them "Chrome proprietary APIs" is loaded with unnecessary and unhelpful subtext.
- Battery Status API was on a standards track but the last published version is a Candidate Recommendation from 2016
- Web Bluetooth is just a Community Group Draft. It's not even formally adopted by a Working Group.
Neither is likely to progress to Recommendation status as the W3C - IMHO, wisely - requires to independent implementations before a specification is adopted as a web standard.
The practical consideration is: These APIs are only supported by one browser. Other major browsers have announced that they have no intention of supporting them. Therefore, use them with caution. If it's an Electron app and nothing but an Electron app, you're probably good to go. If, OTOH, it's a web page or site, and you don't want to alienate non-Chrome users (which would include all iOS users), then you should make sure you aren't doing anything janky when these APIs aren't available or don't work as advertised.
Looking at the netmarketshare stats for August there are 14 browsers which use the blink engine and have a reported market share. Brave is not on the list since it currently reports itself as Chrome. 2 of those browsers have a market share higher than Firefox, Microsoft Edge and Samsung Internet Browser. Samsung Internet Browser is a mobile only browser which ships on Samsung phones and tablets. Removing those and Chrome the remaining 9 blink based browsers combined still have a higher market share than Firefox.
I think the general thrust of what I'm trying to say stands, though: The grotty procedural details surrounding W3C standards are something that can be left to the W3C to worry about. For those of us who think C-SPAN is boring, the presence of a particular webpage at a particular location on the W3C's website serves as a really bad proxy for browser support statistics.
And the reason it's failing to meet that bar is because of fundamental and unaddressed privacy problems with the proposal.
Calling it a "Chrome proprietary API" is exactly correct at this point.
> This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
It's not a Chrome API because nobody else supports it yet, it's a Chrome API because nobody other than Chrome is going to support it. Ideally, Chrome itself should remove their implementation.
The Web Bluetooth debacle is a good example of why new browser APIs shouldn't be turned on for end users by default until after they get far enough in the standards process that they we know they're not going to be rejected.
In theory yes, in practice no.
If code doesn't run in 1 of 2 the browser-engines we currently have, I would consider that a major short-coming preventing me from using it in production.
Not only does WebKit exist, there are more WebKit users than Gecko users.
Or do you also want to include the fringe engines like kHTML, Trident, links, etc too...all of which also wouldn't run the APIs in question?
I haven't checked the others because I don't use them, but that one is.
Don't try to get me to defend a point that I never made in an argument that I never weighed in on. The only point I was making was to correct the more-than-implied false claim that we have "2 browser engines". And I think I made it clear by pointing out that WebKit is bigger than Gecko that if Gecko is a valid consideration that WebKit cannot be considered "fringe".
Do you think those numbers have anything to do with the fact that there's an encroaching browser monoculture right now, hearkening back to the IE6 days?
"Chrome isn't becoming IE6, Chrome is actually good" ~ A person who didn't use IE6 when it was new.
Still didn't mean I'd've been happy with a monoculture, no matter how swear-inducing things got.
Strange for me to think al these years later that my beloved Firefox came from the ashes of Netscape!
The reason we aren't is because we "old" devs fought against it and got lucky that Microsoft forgot IE at the same time as Firefox became really good.
Today Firefox is getting good again (edit: see added footnote [0]) and Google only needs to do a couple of mistakes, and that includes the one which they already seems pretty committed to - or maybe get some IMO really well deserved punishment for anti competitive behavior - before things become more competitive.
But that still depends on us fighting to keep the web cross browser compatible until then.
[0]: for my and many others purposes it was always better, I actually tried toblike Chrome back when it was the underdog and it just never cut it for me
If not enough users are using a platform, let's actively sabotage for that platform by making it less viable, further justifying your own laziness? Is that it?
As someone who has gone from Amiga, to Mac, to Windows PCs, to FreeBSD and now Linux (not to mention the smart-phone story!), I take pride in my work being portable and cross-platform friendly. I have absolutely no desire to go back to the mono-culture days of MSIE.
If you put it on the web, it should work everywhere, otherwise you're just being lazy and/or incompetent.
Also you mentioned in another comment there being 2 browser-engines. There are in fact 3 major browser-engines.
Fair enough. I was thinking in terms of browser-engine families (WebKit-based, Gecko-based) and tried to keep things simple, because I didn't want to overcomplicate my comment.
You're right though that there's Google WebKit (Blink) and straight WebKit and that does make a difference which matters in this context.
Everywhere? Do you support IE6 users too?
It might not look as pretty but if nothing else (TLS etc) stands in the way it should Just Work (TM) thanks to the magic of generating the content on the server side and also careful use of CSS.
What kind of thought lead to such questions even being asked in this community or presumably intelligent people ?
What you are observing is the same thing that got Microsoft in anti-trust trouble back in the days, but which is now being done web-scale instead of desktop-scale by Google.
Also, Google is/was bundling Chrome as a drive-by installation with lots of other popular downloads, so less competent users got their (other) browsers replaced by Chrome, possibly without knowing.
Personally, I tried to use FF a couple of months ago but it didn't work for me.
The four also seem really fit for fingerprinting. We don't need the web to have all the capabilities of a regular application.
Edit: never mind, I just checked some, and they're all not supported according to caniuse. Interesting to see Firefox used to support battery api, but was removed for public consumption as of 52 due to privacy concerns.
https://www.theguardian.com/technology/2016/nov/01/firefox-d...
[1] https://web.dev/native-file-system/
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=853326...
Many friends of mine will immediately, without thought, click to allow camera, microphone, or location data as soon as the prompt shows up. I can see the native file system permission following the same process.
It'll be interesting to see how it works. I'm sure Google has put in quite a bit of effort into securing it.
But before this prompt is even shown, user must first manually select the file with the native file picker dialog and click the "Open" button.
Therefore, giving accidental accesses to a file is not going to be as easy as with a camera or a microphone.
I understand wanting to save files with a webapp, but why not just use LocalStorage and deserialize/serialize from that? If you need persistence plug in a cloud solution like Amazon S3. That's what the web is for.
LocalStorage is okay but a user might not be aware when LocalStorage is cleared (f.ex. they might accidentally clear it when deleting cookies). Cloud Storage might not be in the user's interest in terms of privacy. You kinda have to add some export/import functionality on top in both cases.
Until now, I had to ask players of my game to download a webserver to be able to create new levels and test them in the browser. Not anymore!
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...
It's also easy to abuse [1]
[1]: https://blog.redteam.pl/2020/08/stealing-local-files-using-s...
The broadcast channel api is the only one i hadn't heard of that sounds legitly useful in a normal web app.
It's not something that's useful to the majority of websites, but I find it extremely useful for hobby ESP32-based electronics projects. It gives an easy way to configure individual boards, with no weird captive WiFi portal required. It's cross-platform (Windows, Mac, Linux, Android, just not iOS), and no native app required, an an easy-to-use API. This means means a lot less development overhead for my hobby projects. And it means I can give devices to family & friends without them needing to fiddle with firmware to configure the device.
Are there any good resources you could link to that you found useful when connecting to those kind of boards from Web APIs please?
On the web side I don't currently have any good public examples, but the generic Web Bluetooth samples here are a good starting point: https://googlechrome.github.io/samples/web-bluetooth/
Maybe I'll write a proper blog on this if I get some spare time.
I've seen this mentioned in a few places, and I think it'd be fair to class as FUD.
For starters, Web Bluetooth as implemented doesn't include a scanning API (a low-energy-only scanning API has been discussed, but isn't implemented in any form anywhere).
To connect or learn about any device, the page must specify the exact device id it wants to talk to, or a filter to match a range of devices, e.g. a manufacturer id or a type of bluetooth service, and then the browser will scan & shows the user a list of devices that match. The user can then individually pick one device, and provide permission for the page to connect to it. The web page only hears about (and can only communicate with) the specifically permitted device that you pick.
The page can only request a device in response to a user action - it can't show a prompt unrequested. The permission prompt is then shown to the user every time and waits for them to reject it, even if no devices match, so the page can't use instant failure to detect device availability. There's also a specified 'privacy mode', in which the browser randomizes all device ids (not sure if this is implemented anywhere yet though).
To usefully fingerprint a user, you'd have to scan for nearby phones, the browser would ask "can this page connect to one of these devices?", and the user would have to pick their phone and agree. Imo, it's probably as effective for fingerprinting as a prompt that asks for your phone number to 'win prizes' (non-zero, as some users will enter that, but quite acceptable from a platform perspective).
"https://example.com wants to connect to: ... Samsung 5s" -> click 'Samsung 5s' -> click 'Connect' seems fairly unambiguous to me.
I feel like any user who doesn't understand that, and who still clicks 'yes' would also merrily download and run an unprompted .exe download, or install an app from the play store, either of which is much more powerful than one Bluetooth connection, and much easier to do as an attacker.
That said, I agree this is a problem, I'd be totally on board with clearer & tighter browser permissions systems. I saw one proposal where permissions prompts weren't allowed at all, just floating icons in the address bar, so that the user must click the bluetooth icon (or other permission icon) in the address bar to even see the prompt in the first place. That's perfectly valid within the web bluetooth spec, and for sensitive permissions I'd be fine with it.
As you might expect, both are not supported by Firefox and Safari and work on Chrome and Edge. Same goes for battery status (though Firefox did support it throughout 2016 before removing the support), which I'd argue is one more thing websites should definitely not have access to.
They are only harmful when one is the underdog and plays security as selling point.
Or one has a store to sell native apps.
ChromeOS has "won" in a niche where no one was competing with it.
I've also used the MIDI one as well, good things to report, so long as the browser is supported, stuff seems to "just work"; and I'm doing it all from Debian.
So yes, I guess this is the future after all.
It's not only for music.
I've been doing it for years, it's pretty useful stuff.
Chromium has it of course. So does the battery API. Which gives out your battery percentage to sites.
As for the battery API, Firefox did support it before removing it at the beginning of 2017.
I know the kerfuffle about it, but the browsers these days are so big and complicated that only few are left anyway. So the idea that there needs to be differing implementations are almost impossible to achieve.
As opposed to, say, Javascript or IndexedDB, those famously strongly typed technologies?
can't I just have "fill window"?
Title bar displayed by window manager, not in xmonad by default. URL bar and tabs are not displayed for popup window [1]. Document content is different for each page, youtube embedded videos can be opened in new tab/window/popup by right click on title, resulting URL https://www.youtube.com/embed/xxxxxxxxxxx
Unfortunately at least in chromium <video> has only "Open video in new tab" and even than it does not fill available space.
[1] Convert To Popup https://chrome.google.com/webstore/detail/convert-to-popup/i...
Just a few examples but Youtube, Vimeo, and Twitch have a lot of noise (comments, chat, suggestions to watch next, etc) around the default video before it's maximized. But if you press F11 that all disappears.
Didn't know about the embed link for YT, that's handy, same for the Chrome extension. I just generally don't know why this isn't a standard feature by now. Surely I'm not in the minority here.
https://support.mozilla.org/en-US/kb/about-picture-picture-f...
Though it'd still be nice instead of pressing F11 to achieve full screen if I could press ctrl+F11 and it was "fill window" etc across browsers.
It works on the latest versions of Firefox, Chrome, Edge, and Safari. Not on mobile browsers at the moment, though.
It's something I've used on a few sites, and it's a shame chrome dropped support.
WTF...is there some way to block this API from being called in Safari?
Or indeed, put some malware site on my clipboard.
Either way, it’s my clipboard and no website should be able to change it without my permission.
Copied from https://webkit.org/blog/10855/async-clipboard-api/:
"The request to write to the clipboard must be triggered during a user gesture. A call to clipboard.write or clipboard.writeText outside the scope of a user gesture (such as click or touch event handlers) will result in the immediate rejection of the promise returned by the API call."
Thankfully it didn't run anything serious, but ever since then, I've been careful to paste things into an editor to make sure that the browser copied the exact text that I selected. I understand there are specific needs to programmatically copy things to the clipboard, but I'd consider it a risk/vulnerability open to abuse.
https://github.com/google/lovefield
Thin layer on top of indexdb for local persistence.
Lovefield is a relational database written in pure JavaScript. It provides SQL-like syntax and works cross-browser (currently supporting Chrome 37+, Firefox 31+, IE 11+, Edge, and Safari 10+).
If all we rely on to protect security & privacy of user data is a dialog, then there is little hope.
I wonder whether this could be abused by certain sellers to increase prices when your battery is almost dead. That would be evil, I hope nobody does it, but it is theoretically possible and I think the API should pre-emptively require permissions to prevent people from abusing it in that way.
For that reason, I don’t see them being implemented broadly, especially in iOS.
Many of these ideas were present in WebOS, Firefox OS already.