13 ms·

Lesser-known Web APIs

400 points by Sandeepg33k 6y ago

ForHackernews 6y ago
Most of these sound like terrible half-baked ideas that should be removed from browsers quickly before anyone gets the idea to use them.
- pjmlp 6y ago
  Haven't you heard we are now all ChromeOS developers, with the exception of iOS devices. Many of these ideas were present in WebOS, Firefox OS already.
- joseluisq 6y ago
  Concerned about why any of those APIs don't require user permissions.
- rusk 6y ago
  Well I wouldn’t worry, given Google’s track record they’ll probably be discontinued just as an ecosystem has developed around them.
bawolff 6y ago
Most of these i had heard of before, but bluetooth and network info api surprised me. Sounds perfect for fingerprinting :S The broadcast channel api is the only one i hadn't heard of that sounds legitly useful in a normal web app.
- Signez 6y ago
  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!).
  - rado 6y ago
    Also Mutation Observer, it's great.
  - rikroots 6y ago
    IntersectionObserver is something I've come to rely on - allows me to start/stop canvas element animations so they only play when the canvas is visible in the viewport - https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API https://developer.mozilla.org/en-US/docs/Web/API/Intersectio...
- input_sh 6y ago
  > ...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.
  - dmitriid 6y ago
    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]) [1] https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/ [2] https://www.chromestatus.com/features https://www.chromestatus.com/features
    - pjmlp 6y ago
      Mozilla used to think otherwise with Firefox OS. https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API
      - dmitriid 6y ago
        Because there's a difference between an OS and a browser.
        pjmlp 6y ago
        ChromeOS has won, in case you haven't been paying attention.
        dmitriid 6y ago
        Why are we talking about OSes all of a sudden? ChromeOS has "won" in a niche where no one was competing with it.
  - pjmlp 6y ago
- ffpip 6y ago
  Firefox and Safari removed it. Chromium has it of course. So does the battery API. Which gives out your battery percentage to sites.
  - input_sh 6y ago
    Correction: Firefox and Safari didn't remove the support, they never supported them in the first place. As for the battery API, Firefox did support it before removing it at the beginning of 2017.
- kristopolous 6y ago
  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. So yes, I guess this is the future after all.
  - tiborsaas 6y ago
    WebMIDI is amazing. It's so cool to be able to hook up hardware controllers to websites so easily. It's not only for music.
    - kristopolous 6y ago
      Correct. Midi is generalized cheap input controllers. How one uses it is up to them. I've been doing it for years, it's pretty useful stuff.
- matharmin 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - orobinson 6y ago
    I’ve got an ESP32 board sitting in a box somewhere that I’ve been meaning to get out and fiddle with. This has certainly piqued my interest. Are there any good resources you could link to that you found useful when connecting to those kind of boards from Web APIs please?
    - matharmin 6y ago
      On the device side I've used a lot of code from the CanAirIO project: https://github.com/kike-canaries/CanAirIO 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. 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/ https://googlechrome.github.io/samples/web-bluetooth/ Maybe I'll write a proper blog on this if I get some spare time.
- richeyryan 6y ago
  I've used BroadcastChannel and it is much more convenient than postMessage. My usecase was synchronizing logout between multiple tabs on the same SPA.
- pimterry 6y ago
  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).
  - vbernat 6y ago
    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.
    - pimterry 6y ago
      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 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.
joseluisq 6y ago
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.
lwansbrough 6y ago
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.
ChrisMarshallNY 6y ago
Many of these are quite cool, but give me the security heebie-jeebies. For that reason, I don’t see them being implemented broadly, especially in iOS.
areille 6y ago
For a complete list of HTML5 APIs, with more details on browser support : https://whatwebcando.today/ https://whatwebcando.today/
matsemann 6y ago
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.
- josteink 6y ago
  I noticed that too, and thought the very same thing. 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); } I mean... Really? :) So yeah. Coupled with lots of Chrome-only APIs, I wouldn't consider this a very high quality article.
  - ConcernedCoder 6y ago
    lol... yes, that's SMH level stuff... how about: setEnabled( Boolean( document.someBoolean ) )
    - lytedev 6y ago
      Just curious, but why `Boolean()` over `!!`?
      - angrais 6y ago
        I would imagine because it's much easier to read. What does '!!" Do again I just thought :)
    - deleted 6y ago
      [deleted]
leokennis 6y ago
> Interestingly, copying content to the clipboard is open as in, there is no need of a user permission. WTF...is there some way to block this API from being called in Safari?
- esperent 6y ago
  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.
  - jacobush 6y ago
    shell code?
  - leokennis 6y ago
    Like jacobush mentions: copy some shell code to clipboard, tell unknowing user to open terminal and do CMD+V and enter. 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.
    - teichmann 6y ago
      I don't know about other browsers, but Webkit/Safari only allows writing to the clipboard when triggered by a user interaction. Copied from https://webkit.org/blog/10855/async-clipboard-api/ 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."
      - leokennis 6y ago
        That is reassuring to hear, thanks for digging that up
    - 6y ago
a_imho 6y ago
Thanks, I was not aware of these apis. I would really love to know more how the image/video capture works.
hanselot 6y ago
Well, they aren't lesser-known anymore :P
joseluisq 6y ago
I was thinking that this HN link was a CVE report.
irthomasthomas 6y ago
Here is another good collection of free public APIs https://github.com/public-apis/public-apis https://github.com/public-apis/public-apis
- bmn__ 6y ago
  This isn't what the article is about. In case you didn't read it: think https://developer.mozilla.org/docs/Web/Reference/API https://developer.mozilla.org/docs/Web/Reference/API, not https://www.programmableweb.com/apis/directory https://www.programmableweb.com/apis/directory.
jeroenhd 6y ago
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.
- dastx 6y ago
  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.
  - Phrodo_00 6y ago
    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.
- onion2k 6y ago
  ...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". Clipboard API: https://w3c.github.io/clipboard-apis/ https://w3c.github.io/clipboard-apis/ Battery API: https://w3c.github.io/battery/ https://w3c.github.io/battery/ Performance: https://www.w3.org/TR/resource-timing/ https://www.w3.org/TR/resource-timing/ Bluetooth API: https://webbluetoothcg.github.io/web-bluetooth/ 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.
jacquesm 6y ago
Personal favorite: https://github.com/google/lovefield 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+).
kekub 6y ago
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. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...
- timendum 6y ago
  It only works on mobile (not Firefox) and on Safari. It's also easy to abuse [1] [1]: https://blog.redteam.pl/2020/08/stealing-local-files-using-safari-web.html https://blog.redteam.pl/2020/08/stealing-local-files-using-s...
  - kevincox 6y ago
    This looks more like an implementation flaw than being easy to abuse. The API is still useful after it is patched.
metafunctor 6y ago
I would add this: webkitdirectory allows recursively uploading entire folders. It works on the latest versions of Firefox, Chrome, Edge, and Safari. Not on mobile browsers at the moment, though.
andai 6y ago
This page renders with part of the text cut off on my phone and I can't scroll to it.
jarek-foksa 6y ago
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]. [1] https://web.dev/native-file-system/ https://web.dev/native-file-system/ [2] https://bugs.chromium.org/p/chromium/issues/detail?id=853326#c231 https://bugs.chromium.org/p/chromium/issues/detail?id=853326...
- Jyaif 6y ago
  Wow, this is indeed going to be a game changer for me. 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!
- vorpalhex 6y ago
  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.
- jjice 6y ago
  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.
  - zelly 6y ago
    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.
Ciantic 6y ago
I want SQLite back as an Web API. 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.
- pcwalton 6y ago
  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.
  - filleduchaos 6y ago
    > in particular its loose typing As opposed to, say, Javascript or IndexedDB, those famously strongly typed technologies?
lachlan-sneff 6y ago
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.
- warkdarrior 6y ago
  > I'm not sure the privacy issues really matter if there's a dialog that the website is trying to use one. If all we rely on to protect security & privacy of user data is a dialog, then there is little hope.
  - lachlan-sneff 6y ago
    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.
badrabbit 6y ago
Webauthn would be a good addition. Devs need to support it a lot more: https://webauthn.me/ https://webauthn.me/
altdatathrow 6y ago
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. can't I just have "fill window"?
- kencausey 6y ago
  Would Picture-in-Picture (PiP) work for you? https://support.mozilla.org/en-US/kb/about-picture-picture-firefox https://support.mozilla.org/en-US/kb/about-picture-picture-f...
  - altdatathrow 6y ago
    Yep, that's awesome, that's a new feature to me, thanks! 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.
- sergeykish 6y ago
  Which UI? 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 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/ipbclffpmnocdigdcpmahfmdlibcggal https://chrome.google.com/webstore/detail/convert-to-popup/i...
  - altdatathrow 6y ago
    > Which UI 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.
dzonga 6y ago
you can't say well less known web api's. most of those api's are not standardized.
dheera 6y ago
> Battery Status API 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.
flingo 6y ago
Here's one that's Firefox exclusive, and still seems to work: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contextmenu https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... It's something I've used on a few sites, and it's a shame chrome dropped support.

400 points by Sandeepg33k 6y ago

Most of these sound like terrible half-baked ideas that should be removed from browsers quickly before anyone gets the idea to use them.

pjmlp 6y ago
Haven't you heard we are now all ChromeOS developers, with the exception of iOS devices. Many of these ideas were present in WebOS, Firefox OS already.
joseluisq 6y ago
Concerned about why any of those APIs don't require user permissions.
rusk 6y ago
Well I wouldn’t worry, given Google’s track record they’ll probably be discontinued just as an ecosystem has developed around them.

bawolff 6y ago

Most of these i had heard of before, but bluetooth and network info api surprised me. Sounds perfect for fingerprinting :S The broadcast channel api is the only one i hadn't heard of that sounds legitly useful in a normal web app.

Signez 6y ago
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!).
- rado 6y ago
  Also Mutation Observer, it's great.
- rikroots 6y ago
  IntersectionObserver is something I've come to rely on - allows me to start/stop canvas element animations so they only play when the canvas is visible in the viewport - https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API https://developer.mozilla.org/en-US/docs/Web/API/Intersectio...
input_sh 6y ago
> ...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.
- dmitriid 6y ago
  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]) [1] https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/ [2] https://www.chromestatus.com/features https://www.chromestatus.com/features
  - pjmlp 6y ago
    Mozilla used to think otherwise with Firefox OS. https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API
    - dmitriid 6y ago
      Because there's a difference between an OS and a browser.
      - pjmlp 6y ago
        ChromeOS has won, in case you haven't been paying attention.
        dmitriid 6y ago
        Why are we talking about OSes all of a sudden? ChromeOS has "won" in a niche where no one was competing with it.
- pjmlp 6y ago
ffpip 6y ago
Firefox and Safari removed it. Chromium has it of course. So does the battery API. Which gives out your battery percentage to sites.
- input_sh 6y ago
  Correction: Firefox and Safari didn't remove the support, they never supported them in the first place. As for the battery API, Firefox did support it before removing it at the beginning of 2017.
kristopolous 6y ago
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. So yes, I guess this is the future after all.
- tiborsaas 6y ago
  WebMIDI is amazing. It's so cool to be able to hook up hardware controllers to websites so easily. It's not only for music.
  - kristopolous 6y ago
    Correct. Midi is generalized cheap input controllers. How one uses it is up to them. I've been doing it for years, it's pretty useful stuff.
matharmin 6y ago
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.
- deleted 6y ago
  [deleted]
- orobinson 6y ago
  I’ve got an ESP32 board sitting in a box somewhere that I’ve been meaning to get out and fiddle with. This has certainly piqued my interest. Are there any good resources you could link to that you found useful when connecting to those kind of boards from Web APIs please?
  - matharmin 6y ago
    On the device side I've used a lot of code from the CanAirIO project: https://github.com/kike-canaries/CanAirIO 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. 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/ https://googlechrome.github.io/samples/web-bluetooth/ Maybe I'll write a proper blog on this if I get some spare time.
richeyryan 6y ago
I've used BroadcastChannel and it is much more convenient than postMessage. My usecase was synchronizing logout between multiple tabs on the same SPA.
pimterry 6y ago
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).
- vbernat 6y ago
  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.
  - pimterry 6y ago
    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 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.

joseluisq 6y ago

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.

lwansbrough 6y ago

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.

ChrisMarshallNY 6y ago

Many of these are quite cool, but give me the security heebie-jeebies. For that reason, I don’t see them being implemented broadly, especially in iOS.

areille 6y ago

For a complete list of HTML5 APIs, with more details on browser support : https://whatwebcando.today/ https://whatwebcando.today/

matsemann 6y ago

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.

josteink 6y ago
I noticed that too, and thought the very same thing. 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); } I mean... Really? :) So yeah. Coupled with lots of Chrome-only APIs, I wouldn't consider this a very high quality article.
- ConcernedCoder 6y ago
  lol... yes, that's SMH level stuff... how about: setEnabled( Boolean( document.someBoolean ) )
  - lytedev 6y ago
    Just curious, but why `Boolean()` over `!!`?
    - angrais 6y ago
      I would imagine because it's much easier to read. What does '!!" Do again I just thought :)
  - deleted 6y ago
    [deleted]

leokennis 6y ago

> Interestingly, copying content to the clipboard is open as in, there is no need of a user permission. WTF...is there some way to block this API from being called in Safari?

esperent 6y ago
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.
- jacobush 6y ago
  shell code?
- leokennis 6y ago
  Like jacobush mentions: copy some shell code to clipboard, tell unknowing user to open terminal and do CMD+V and enter. 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.
  - teichmann 6y ago
    I don't know about other browsers, but Webkit/Safari only allows writing to the clipboard when triggered by a user interaction. Copied from https://webkit.org/blog/10855/async-clipboard-api/ 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."
    - leokennis 6y ago
      That is reassuring to hear, thanks for digging that up
  - 6y ago

a_imho 6y ago

Thanks, I was not aware of these apis. I would really love to know more how the image/video capture works.

hanselot 6y ago

Well, they aren't lesser-known anymore :P

joseluisq 6y ago

I was thinking that this HN link was a CVE report.

irthomasthomas 6y ago

Here is another good collection of free public APIs https://github.com/public-apis/public-apis https://github.com/public-apis/public-apis

bmn__ 6y ago
This isn't what the article is about. In case you didn't read it: think https://developer.mozilla.org/docs/Web/Reference/API https://developer.mozilla.org/docs/Web/Reference/API, not https://www.programmableweb.com/apis/directory https://www.programmableweb.com/apis/directory.

jeroenhd 6y ago

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.

dastx 6y ago
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.
- Phrodo_00 6y ago
  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.
onion2k 6y ago
...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". Clipboard API: https://w3c.github.io/clipboard-apis/ https://w3c.github.io/clipboard-apis/ Battery API: https://w3c.github.io/battery/ https://w3c.github.io/battery/ Performance: https://www.w3.org/TR/resource-timing/ https://www.w3.org/TR/resource-timing/ Bluetooth API: https://webbluetoothcg.github.io/web-bluetooth/ 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.

jacquesm 6y ago

Personal favorite: https://github.com/google/lovefield 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+).

kekub 6y ago

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. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...

timendum 6y ago
It only works on mobile (not Firefox) and on Safari. It's also easy to abuse [1] [1]: https://blog.redteam.pl/2020/08/stealing-local-files-using-safari-web.html https://blog.redteam.pl/2020/08/stealing-local-files-using-s...
- kevincox 6y ago
  This looks more like an implementation flaw than being easy to abuse. The API is still useful after it is patched.

metafunctor 6y ago

I would add this: webkitdirectory allows recursively uploading entire folders. It works on the latest versions of Firefox, Chrome, Edge, and Safari. Not on mobile browsers at the moment, though.

andai 6y ago

This page renders with part of the text cut off on my phone and I can't scroll to it.

jarek-foksa 6y ago

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]. [1] https://web.dev/native-file-system/ https://web.dev/native-file-system/ [2] https://bugs.chromium.org/p/chromium/issues/detail?id=853326#c231 https://bugs.chromium.org/p/chromium/issues/detail?id=853326...

Jyaif 6y ago
Wow, this is indeed going to be a game changer for me. 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!
vorpalhex 6y ago
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.
jjice 6y ago
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.
- zelly 6y ago
  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.

Ciantic 6y ago

I want SQLite back as an Web API. 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.

pcwalton 6y ago
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.
- filleduchaos 6y ago
  > in particular its loose typing As opposed to, say, Javascript or IndexedDB, those famously strongly typed technologies?

lachlan-sneff 6y ago

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.

warkdarrior 6y ago
> I'm not sure the privacy issues really matter if there's a dialog that the website is trying to use one. If all we rely on to protect security & privacy of user data is a dialog, then there is little hope.
- lachlan-sneff 6y ago
  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.

badrabbit 6y ago

Webauthn would be a good addition. Devs need to support it a lot more: https://webauthn.me/ https://webauthn.me/

altdatathrow 6y ago

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. can't I just have "fill window"?

kencausey 6y ago
Would Picture-in-Picture (PiP) work for you? https://support.mozilla.org/en-US/kb/about-picture-picture-firefox https://support.mozilla.org/en-US/kb/about-picture-picture-f...
- altdatathrow 6y ago
  Yep, that's awesome, that's a new feature to me, thanks! 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.
sergeykish 6y ago
Which UI? 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 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/ipbclffpmnocdigdcpmahfmdlibcggal https://chrome.google.com/webstore/detail/convert-to-popup/i...
- altdatathrow 6y ago
  > Which UI 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.

dzonga 6y ago

you can't say well less known web api's. most of those api's are not standardized.

dheera 6y ago

> Battery Status API 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.

flingo 6y ago

Here's one that's Firefox exclusive, and still seems to work: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contextmenu https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... It's something I've used on a few sites, and it's a shame chrome dropped support.