When introducing Web APIs for general use, I think it's a bad idea to show the example code using react and it's useEffect. Makes the examples less standalone, and harder for some to grok.
A lot of these don't work in any browser other than Chrome. Demos that work in Firefox:
- 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.
...the rest should probably be considered "Chrome APIs" rather than "web APIs".
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".
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.
Mozilla and Apple have publicly announced that they will not implement the Bluetooth and Battery APIs [1][2], which makes them definitely Chrome proprietary APIs.
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.
Mozilla and Apple have publicly announced that they will not implement the Bluetooth and Battery APIs [1][2], which makes them definitely Chrome proprietary APIs.
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.
If we really want to be pedantic, then I must point out that they're not W3C standards and likely never will be.
- 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.
If we really want to be pedantic the post your comment refers to never said they were W3C standards. It referred to them as W3C specs which since they are api specifications and published by the W3C is accurate even if they are not standards.
It seems like we're really far down the "arguing semantics" curve at this point.
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.
Fair point. I do tend to forget about Edge and Opera.
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.
If we are going to assume that the term 'Web APIs' doesn't presuppose W3C standard-track documents at a minimum, rather than just "the W3C has a document on this", then I think it's safe to say that we are more interested in being argumentative than in communicating.
Just to be clear, "Battery Status" is not a "W3C spec". The latest published version at https://www.w3.org/TR/battery-status/ is "Candidate Recommendation", and has been stuck there for over four years, precisely because it's failing to meet the bar to progress to "Recommendation".
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.
I remember Microsoft was generally pretty good about submitting their stuff to the W3C as part of the embrace, extend, extinguish policy - example the Note on VML https://www.w3.org/TR/NOTE-VML
> 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.
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.
> 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?
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".
I am my own favorite production end user and I use firefox.
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.
I have memories of a Microsoft evangelist in the 90s. He told us "IE4 is good but everybody uses Netscape." IE4 wasn't that good IMHO, IE5 was probably better than Netscape (the company was starting to collapse) and IE6 was the better browser by far, until it stagnated and Firefox appeared.
If your attitude had been prevalent in 200x we had still been stuck with IE6.
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
I am using Firefox, and I find that attitude among developers infuriating.
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.
Being portable and cross-platform doesn't mean you can't take advantage of things unique to a subset of platforms to provide a better user experience on those platforms. You just need to check for support and provide fallback on those platforms without support. One could easily argue that just using the lowest common denominator across platforms is in fact the lazy and/or incompetent option.
Also you mentioned in another comment there being 2 browser-engines. There are in fact 3 major browser-engines.
> 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.
Most of what I put on the public internet supports IE6 just fine.
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.
...and what if it is in the low single digits? 1% of 10000 is still a 100 (potentially paying) users. Should we abandon accessibility efforts as well because of the low single digits users?
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.
HN users are probably offended by this comment but the truth is outside of devs very few people use FF. What I see around me is that people use either Chrome or Safari, but mostly Chrome.
Personally, I tried to use FF a couple of months ago but it didn't work for me.
They also develop the browser that has the sheer majority of users and fund almost exclusively the only real technical competitor. This is really worrying.
The authors aren't listed in the spec. You're looking at the editors. Anyone can contribute to the spec, and lots of people from Mozilla do. Taking the first one as an example, https://github.com/w3c/clipboard-apis/graphs/contributors, marcoscaceres, janiceshiu, and Johanna-hub are current or former Mozilla staff, and plenty more who don't say one way or the other on their profile.
Firefox supports at least some of the clipboard APIs. They'll likely support a few more in future (like the async variants). But they tend to implement them a little slower and leave out a few bits due to privacy concerns.
Could it be that you've got antitracking mechanisms enabled? Noscript, enhanced tracking protection or something else? They could very well prevent Firefox from accessing said APIs
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.
Yeah, I'm not sure Firefox would choose to implement some of the APIs in the not implemented list. The chance they can be used for fingerprinting is pretty high.
Also, full screen doesn't work in iOS Safari. It was supported but that support was removed several years ago (I want to say 2014, but may be a little off).
Native File System API [1] is going to be the biggest game changer in 2021. So far it was little known and rarely used because of the origin trial limitations, but it will become available to everyone soon [2].
I'm sure there is a ton of design and thought put into making the native file system API safe and secure, but wow does it scare me right off the bat. Even if it has to be enabled by a user like camera or mic permissions, this can probably be used to get malware onto the machines of users that don't pay attention to permission requests or understand the implication of what they're doing.
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.
I doubt most casual users would know the distinction between "native filsystem access" and what the browser does already. They'll just (wrongly, in this case) assume the browser is safe as long as they don't download and install anything, and brazenly click Yes to every prompt that shows up.
The prompt that asks user for a permission to write a local file says: "<domainName> will be able to edit <fileName> until you close all tabs for this site [Cancel] [Save changes]".
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.
This is a security nightmare. It looks like major browser vendors have pushed back against it and for good reason. Even a website I absolutely trust should not be able to access my bare filesystem because I don't know if that website will get compromised, XSS'd, DNS poisoned, etc.
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.
Judging by the web.dev page this seems to be pretty well done though. Permissions are only granted to a subset of files and new sessions will need to ask for permission again.
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.
The level of security seems to be on pair with Electron apps running inside macOS sandbox. Even if the attacker manages somehow to inject and execute a script on the client side, it will have access only to the files that user has opened with the app recently, not the entire filesystem.
This is one of those APIs that I am equal parts excited and worried for. It'll enable awesome abilities for apps, and it's going to be a whole new level of exploits and browser fingerprinting for the malicious.
I expected to find the Sharing-API [1] in the list. I just found out about it recently and have used it multiple times since then. It even works on iOS.
Bluetooth API won't give useful fingerprinting information
unless the user allows it with a very obtrusive prompt.
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.
On the device side I've used a lot of code from the CanAirIO project: https://github.com/kike-canaries/CanAirIO. I do want to switch my code to the NimBLE stack instead of the default bluetooth stack at some point - apparently it uses a lot less memory.
I don't know about network info, but web bluetooth isn't really a practical fingerprinting channel. You can't get any info from it without some very loud prompts.
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).
The problem with prompts is that a user can be tricked to accept them, notably when they are hard to understand. That's the main reason Firefox does not implement such APIs.
I see how that's true of permission prompts in general, but I'm not really convinced in this case, and I'm firmly against the Firefox/Safari position here (even as a day-to-day Firefox user).
"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.
> ...but bluetooth and network info api surprised me. Sounds perfect for fingerprinting :S
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.
And some of them are considered harmful by other browsers than Chrome. E.g. Web Bluetooh or Network Information [1] (both enabled in Chrome by default [2])
I would add the ResizeObserver to the list of legit APIs too. It solves a common problem that happen with some complex layouts, and it's very easy to use (and widely supported!).
I've used the Bluetooth one pretty extensively...it isn't crazy and seems to work as documented.
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.
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.
SQLite semantics, in particular its loose typing, are pretty questionable. We shouldn't bake those into the platform forever just for convenience' sake, especially when you can have SQLite now via sql.js.
Many of these don’t work on iOS (or outside of Chrome for that matter.) I would add Web Share API to the list as it is well supported and provides a nice native interface for commonly needed website functionality.
Does anyone know of a way to do "fullscreen" where the screen is the window? It bugs me that to watch a streaming video my options are: box inside their ui which takes up a significant portion of my window real estate, or full screen on my entire monitor.
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.
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.
Given that this says copying to the clipboard, not reading from it, I'm curious, why would you want to block it? The worst a website could do it mildly irritate you by copying junk to your clipboard.
"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."
Once I copied a lone line of commands to run, from a code block on a website (a tutorial article). When I pasted it in the terminal, it contained a bunch of garbage like copyright, unrelated text, and new lines.
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.
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+).
It's a shame that Firefox has said they won't implement many of these. The Bluetooth and USB apis would legitimately be really useful. I'm not sure the privacy issues really matter if there's a dialog that the website is trying to use one.
Not really, if the user wants they can post their location, credit card number, etc online. They stand between themselves and their own exploitation. Removing apis doesn't change that.
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.
I got surprised by Network, Battery and Vibration info APIs built-in.
I have tested on my Android phone. Cool... but any user required permissions?
So no thanks.
