The evergrowing scope of browsers, designed so only Google (and, by now, Mozilla, but only because Google allow them to exist) can create one and keep it updated.
It is good that Google still allows Firefox to exist. I hope this love for my go to browser lasts. Every day I pray it will last. I'm scared though, because deep in my heart of hearts, I know it won't last.
> It’s both surprisingly and dismayingly difficult to get people — especially computerists — to criticize the web and the web browsers — even more so perhaps today.
Definitely agree with this. People tend to view it as something handed down to them by Gods. It's not.
Edit 2: This needs a larger discussion. I just posted it as a new submission.
Ther other path is to view browsers as viewers of sometimes
dynamic documents. There is a certain power in limiting the amount of expressiveness in the web - it allows for a lot more creative repackaging.
Unfortunately this path doesn't allow for much targetted advertising opportunities, so that's why Google et al wisely abandoned this path. ( /s )
Dynamic documents fundamentally can't achieve the usefulness of modern web applications though.
The fact of the matter is that web still seems to be the last bastion of freedom where you have a decent chance of publishing your software without begging for approval from a Californian. It's also inherently portable and doesn't care which brand of laptop or phone did you buy.
Which is why the rent seekers are trying so hard to dismantle it instead of empowering it.
I'd say 99% of sites out there don't need the "usefulness of modern web applications" at all. They are strictly linked sets of documents, with some interactivity through forms and such.
It's also inherently portable and doesn't care which brand of laptop or phone did you buy.
What you're perfectly fine with is slimmer browsers. Crippled browsers, as in the ones in Apple's world, are browsers where the supported specs and features are selectively chosen for political / competitive reasons. It's absolutely not healthy.
Apple doesn't cripple Safari. They just don't want to engage in a losing war of implementing half-baked underspecified standards that Chrome rushes against any objections.
Mozilla is increasingly on the Apple's side these days.
You don't understand what "extend embrace extinguish" meant. It's a tactic MS used to take control of a technology it, with the goal of making it unviable -- see the "extinguish' part. Back then, it was in Microsoft's interest that people used native windows apps to keep them in the MS ecosystem. The web was good for makers of other OSs like Apple. Nowadays, Apple tries to keep the web in lame duck mode for the same reason. Google wants the web to be powerful not to neuter it but because it's in their interest. You can argue if the web _should_ be an app platform, but applying "embrace extend extinguish" to Chrome misunderstands the motivation of Google.
I'm more interested in Firefox vs Chrome. I simply want to be able to use the web without using Google.
By raising the bar on shiny but non-essential features, they make it harder for an open source browser to play. The new features may be fun options today but sooner or later those features will become standard, and website X won't work without Chrome.
From TFA:
> There is a long tail of human interface devices (HIDs) that are too new, too old, or too uncommon to be accessible by systems' device drivers
I can easily imagine a banking website one day requiring custom USB drivers for security. Similar things happened with ActiveX and IE in the MS EEE days.
Google's version of EEE is to churn the "standards" continuously by changing and adding to them rapidly to make it hard to even implement them, while also spreading widely the propaganda to cause developers to use the new parts --- even if not actually necessary. See all the static content sites turned into (increasingly often, Chrome-only) horrible SPAs.
There's a reason the word "deprecate" occurs so ridiculously often in the web development --- Google's weapon of monopoly is change: they are basically trying to outrun competitors. It's not Microsoft's proprietariness, but a brazenly open show of sheer power.
Occam's razor, and my familiarity with the industry, both tell me it's not malicious but rather just various shades of incompetence & misaligned incentives that are producing such high amount of "spec churn".
But if it were a strategy, "EEE" or "Embrace Extend Extinguish" is not a good term for it. Maybe call it EEEE. "Extend Extend Extend Extend".
> while also spreading widely the propaganda to cause developers to use the new parts --- even if not actually necessary
There's a good argument to be made that WebHID is exactly that. There is already a HID API. This new one is just supposed to be "better" ... somehow... in some way... I'm not exactly sure what it is... but some googler on the internet says you should support it.
I built various web interfaces to BLE devices and use the web BLE API but the biggest annoyance is having to select the device every time interactively. I really wish it were possible to "remember" access to devices that have already been given permission in the past. I wonder if the Web Serial API can do this over Bluetooth ...
When I hear "serial," my mind goes to those 9-holed round ports on the back of a computer in the 90s. Didn't pay any attention to that section until I read your comment. Thanks for the nudge.
I had a tech support job where one repeated irritation was end users that had removed and reinserted a USB to Serial device. Windows then randomly assigns COM92, or whatever. Now you have to walk the customer through figuring out what COM port got assigned.
The Windows UI (via Device Manager) allows you to change it, yes. The end users in this case, though, just wanted their "serial connected thing" to work, and weren't terribly technical. Also, if you remove and reinsert it (especially to a different USB port) it doesn't remember any of that.
But that’s not persistent. If I tell Windows that a specific flash drive gets T: (for whatever reason), if I unplug it and plug it in somewhere else, it will still be assigned T: (assuming it’s not in use by something else). With COM ports, if I say that this Arduino Mega gets COM10, then I unplug it and plug it back in, there’s no guarantee it’ll get COM10. That seems ridiculous IMO.
Web serial seems awesome! The ability to interface Hobbyist devices without the Arduino IDE (which I hope will work here) is one step closer to everything on web as a universal platform
It does look cool, but it appears that there are some legitimate concerns around privacy and security. Mozilla, for example, won't be implementing this:
Has there been any progression on manifest v3 support for uBO? Has the original maintainer shown interest in adding support, or any other forks? I'm curious to see what the performance/feature set looks likes. From my understanding, they upped the number of filters to 300K, which is 3x what most people use.
Nope, no progression. The uBlock Origin maintainer has explicitly stated that in current form it will kill the extension. The Chrome team closed the issue with no response to his concerns, if you're wondering where their intentions are (obviously they intend to kill ad-blocking).
I've seen this issue report before. It doesn't substantiate the earlier claims made though. Particularly as these comments predate the improvements made to declarativeNetRequest since this issue was posted.
Super excited to see WebHID landing! I have code to control lights via a browser application and finally will be able to release this!
Also NFC support is huge - I can imagine all kinds of neat activation features for a website. Imagine sending a flyer in the mail with an NFC chip built in and then having a webpage verify based on this... Lot of really neat IOT apps that can be created with this feature...
BLE is amazing and I really wish we had the query permissions API... since that would allow for heart monitors and other permeant native app like experiences...
Core NFC has been available since iOS 11 (https://developer.apple.com/documentation/corenfc). You don't have full access to implement for example contactless EMV payments, but you can read and write data to NFC tags.
I dont follow Chrome / Web App development closely ( I only like to work on Web pages ). But I am well aware of Google's shenanigans, dating back when they first state their "Do No Evil" BS.
Typing that makes me feel old. That was nearly 20 years ago.
I think it's also for call centers... which employee a lot of people... think head phones, even specialized hardware buttons to answer phone calls, place calls on hold etc... and being able to distribute the software part all via the web... WebRTC and WebHID - will be very happy together...
Is there some information on the "bandwidth"/latency of WebHID devices? Specifically, could it work with a low resolution-ish video feed?
I'm specifically thinking of a very niche type of device, specifically an inexpensive VGA/analog video capture usb "stick" called "EasyCap". This particular name has been re-used by many manufacturers who all sell EasyCaps with different chips in them, which makes finding a working driver a complete nightmare across almost all operating systems.
After much research, it turns out that Linux had native support for the chip in my EasyCap, and I was able to capture video using ffmpeg (under VirtualBox running on macOS). Happy to share notes! (reply here or email me)
Insane list of different drivers for EasyCaps under Windows: https://visser.io/2015/06/easycap-drivers-for-windows-8-1/ ("Below is a link to the Windows 7 drivers that were compatible with my EasyCAP device and further down a list of other EasyCAP drivers you can try.")
Info on existing versions/chips & Linux support: https://www.linuxtv.org/wiki/index.php/Easycap ("It seems that EasyCAP is not a company or brand name, but some chinese manufacturers use this label for at least four completely hardware different clones of equally looking audio and video capture devices. EasyCAP devices and clones are vastly sold in onlineshops at low prices.")
Do the EasyCAP devices actually use the HID device class? You could probably build a USB device that sends video over button presses, but that's not relevant for accessing hardware that already exists.
Reading the justification for WebHID I get the feeling I’m missing something:
> There is a long tail of human interface devices (HIDs) that are too new, too old, or too uncommon to be accessible by systems' device drivers. The WebHID API solves this by providing a way to implement device-specific logic in JavaScript.
> (...)
> The inability to access uncommon or unusual HID devices is particularly painful, for example, when it comes to gamepad support. Gamepad inputs and outputs are not well standardized and web browsers often require custom logic for specific devices. This is unsustainable and results in poor support for the long tail of older and uncommon devices.
So instead of only having to implement support for these devices once (in the browser), they now expect every website that would need support for these kind of devices to write their own code to handle all these ‘long tail’ input devices ?
How does that not make the problem infinitely worse ?
Instead of convincing one party to implement and support the code to handle your obscure HID, now you beee to convince potentially millions of websites. All running different implementations with their own unique bugs and issues.
This sounds less like an effort from the Chrome team to add support for these devices and more like a way to make it someone else’s problem.
Distributing print drivers via the internet?
Allowing the ultimate hardware hacking via the largest PC sandbox environment? Should have interesting security implementations for hardware fingerprinting.
More power to the developers. In the past you had to cross your fingers that the browser vendor would have implemented the gamepad the user wanted to use, and it not, you'd be out of luck.
The issue of "every site needing to reimplement every gamepad" can be fixed by developers making libraries with those implementations.
Are you suggesting developers will gain power by buying in to these APIs? If you are, then let me remind you of a slippery slope known as "lock in". Never, is when a developer is empowered by lock in.
I suppose someonte could create a HID service. That lets Games download WASM drivers for any device on demand, and new devices could be added without any change to the application.
Kinda like how webfonts mean a site no longer needs to rely on fonts being installed on the browser, and Google fonts means CMS providers don't need to provide every webfont. (If the platform allows Google Font's or similar).
It’s actually infinitely more scalable because now the device manufacturers or any developer can create a library to support any device. Before we relied on a single browser vendor or vendors to write the drivers... while google has an impressive engineering team as do all the browser vendors .. it’s not really reasonable or even as fun to have to only rely on them... imagine an IOT project adding support for HID device to control a robot or console style game... lot of neat possibilities
> It’s actually infinitely more scalable because now the device manufacturers or any developer can create a library to support any device.
Sure, but that means you as a device manufacturer have to convince all these websites to include your library and support your device. Why not have e.g. generic gamepad support in Chrome and let developers write a driver for their devices as an extension ?
Now all you get is horrible fragmentation, your device may work on website A but not on website B, and maybe kinda work but very buggy on website C.
It’s a recipe for a shitty user experience. In practice you’ll see that only a handful of popular devices will be universally supported.
> WebHID is good for long tail devices, or handling more unusual features of specific device
And that’s exactly why it will never be widely used. I’m not saying that there isn’t a use-case for it, I’m saying that the article overstates the usefulness of this API.
More likely it means there will be a few libraries that people who are into this stuff will maintain that cover most cases and they don't have to wait for the browser teams to bless their implementations. And even better if the project doesn't want to support your device you can just fork it and add it
Sure, for the use case of a device manufacturer who wants to make a niche gamepad and have it supported by many web games, it's not very helpful. But there's other use-cases here.
If you've made a specialized controller that needed something other than generic gamepad support, and a webapp, and you wanted them to talk to each other, your previous option was to lobby browser vendors to add support. Now you can build that integration yourself. I don't see how that's something to complain about
Is it possible to have a driver store? So the website would just load a library for Gamepad X from a global driver website, dynamically when you plugged it in
What isn't obvious to me: how is this safeguarded? Is there any provision to stop a malicious driver from generating fake input, which is then tainted as user generated input all the same?
> Is there any provision to stop a malicious driver from generating fake input,
I have the opposite concern: is it guaranteed that accessibility software will be able to spoof the kinds of inputs a site expects? And will my browser be able to generate dummy input data of the format a site demands, for the occasions that I don't want the site to have live access to that particular sensor/input?
On the one hand, it should be great for accessibility, testing (or even, handling cookie confirmation dialogs), but, on the other hand, it shouldn't be too difficult to, say, discern a certain button for enabling media sharing and handle any associated dialogs.
This increase in browsers leveraging hardware capabilities is not necessarily a bad thing. Think of it as the cost of advancement. Chances are that most devices nowadays come with sufficient memory to handle these. And for cases where this would harm overall experience, there are always toggles.
Though not to underestimate the vulnerabilities some of these advancements bring. Some tech such as Bluetooth have been exposed to security bugs in the not so recent past. Am also partly concerned about how complex & almost OS-like browsers have become today. Read ChromeOS etc. They also expose too much information at the hardware level to webpages.
Though as complex as the big browsers get. We'll always have simple browsers such as Webkit-based Epiphany that still stay true to the traditional Web browser in essence.
This is just the next step in the evolution of browsers into full fledged operating systems.
The Web APIs would become the next POSIX.
And we might end up with uni-kernels that would just be running browsers on bare-metal. Want to be stalked, here is your Chrome OS. Want privacy, here is your Firefox OS. (Where did I last hear of these? Hmm...)
Who knows, when all this is over someone might make a browser for this new browser OS.
Is the Chrome team still hellbent on killing ad-blocking with the half-baked Manifest changes that will render uBlock useless? How much longer will ad-blocking be supported?
When uBlock first came onto the scene, its main selling point was that it had vastly better performance than Adblock when using filter sets that had lots of block rules based on CSS selectors rather than just URL regexes. And third-party filterset subscriptions that made heavy use of CSS-based element blocking rules had become quite popular by then. So an API that only provides for URL blocking is missing almost the entire point of uBlock.
(I wasn't using any third-party filtersets at the time, so I found uBlock unimpressive and stuck with Adblock Plus for quite a while because I found its UI better for curating my own blocking rules.)
I don’t know how uBlock handles CSS rules, but you can just add your stylesheets or add your JavaScript to the page, it should be enough and as performant as possible.
AFAIK there are esoteric features like DNS filtering which is not possible with declarative API. But I’m not sure if it’s used widely, I never saw it.
They killed intelligent features like CNAME ad bypass detection, which effectively kills ad-blocking. So no, if there's an easy bypass of ad-blocking that's absolutely false.
Web nfc excites me because I want to play with an idea where my kids earn tokens and add them to their score cards. But I don't want to put a whole mobile application together.
Thanks for the info! Latest Chrome Beta (or Canary to be precise) speeded up my start time with some service workers from >30s to just above 7s, which is almost the same speed as Firefox (albeit with a few more extensions).
Would anyone happen to have a screenshot of the web share experience on Windows? Is it also on for OSX?
The API made a lot of sense to use on mobile - for example to send an SMS. You need to use apps to share. Bringing it to desktop, it may actually be less usable than just putting social share buttons directly on the page. I don't know a lot of people that use the OS-level apps on desktops (e.g. contact sync or logging into facebook). Does this end up a glorified `mailto` button for most people?
It might be a bit of a chicken and egg issue at the moment: a native app is needed to be a share target (e.g. by custom protocol, or mailto as in your example), people don't really use native apps for these things any more, therefore widespread use is rare. There are some uses I can think of - e.g. Spotify registers a custom protocol handler, as does Steam.
But in general I would expect enabling websites to be receivers of shared data will enable some interesting new use cases.
As an example, I wanted to create a web extension to automatically add something to Anki via AnkiWeb. The share API seemed to be the natural way to do this, but with it unsupported on desktop, that approach was dead in the water.
It has not yet been implemented on the desktop, but the Web Share Target API seems to be the solution for the future: https://web.dev/web-share-target/
I absolutely second this btw. Being able to use something like https://snapdrop.net/ from the share menu would finally add AirDrop-like convinience to the web.
I agree with both you and the parent from a principles perspective. There's no reason sharing on the web has to be somehow limited to whatever the website author chose to support.
My problem is that this just isn't a pragmatic choice right now. The chicken-and-egg problem is somewhat true, but the carrot was already there for web devs - iOS and Android implement web share. And it's an excellent UX - better than anything you can make yourself.
The problem with the desktop share experience is that it is strictly worse than putting 2-3 social buttons & copy link for 95% of people. Neither Facebook nor WhatsApp support the share target API right now (quick post-edit: Twitter does though). Even if they did, there's another hurdle [1]:
To register your app as a share target, it needs to meet Chrome's installability criteria. In addition, before a user can share to your app, they must add it to their home screen.
So, again, pragmatically what people are going to start doing is - change from "if (navigation.share)" to "if (navigator.share && isMobile)". And I think that sucks - there will have to be another slow-moving wave of change once the desktop share is "good enough" to enable for everyone.
That's a really ugly & weird dialog. I realise that some of the text at the top is from the page and the actions are empty (for some reason?), but it's essentially a huge dialog for what will be "copy link" in ~99% of cases.
While that is true, Google hasn’t always used OS abstractions. Case in point - the browser chrome (of Google Chrome to try to disambiguate). They could have used their own UX if they wanted. They just didn’t.
I'm not totally enthusiastic for this feature, but that doesn't appear to be the case either.
It looks like navigator.hid.getDevices() will only return devices that the site has previously explicitly requested (with the vendor and other IDs) and the user has granted permission to access.
So it doesn't look like drive-by enumeration is possible with this - websites have to explicitly request to connect to a specific device, and the user must manually approve each device.
Tried the PS4 dual shock demo. Error. this.device.open is not a function. I guess this isn't as ready as they claim. Maybe it should wait for some more testing.
The question is will Safari support this in the future? Also can users disable these integrations? I am really not interested giving websites access to NFC or HIDs.
I highly doubt Safari will ever support this on any of it's platforms. And to be honest, I'm not sure if I will really ever miss it.
I opened up the demo that flashed my backlight keyboard (after chrome prompted for some generic hardware permissions) and, while it was cool, I'm not entirely enthusiastic about websites being able to control my hardware like this with such low user intent.
Neither Safari nor Mozilla will support these features.
WebUSB is considered harmful by both. As is WebNFC if I remember correctly.
WebHID has the same concerns as WebUSB.
Moreover, some of these are implemented and rushed into stable versions of Chrome even before other browser implementors even had the chance to weigh in on the specification. See, for example, https://github.com/mozilla/standards-positions/issues/459
There is already Chrome OS, but that obviously has Linux under the hood. I'm guessing this will also benefit electron-based apps to be able to provide serial interaction.
reply