Chrome 89 Beta: advanced hardware interactions, web sharing on desktop | Hacker News Reader

Chrome 89 Beta: advanced hardware interactions, web sharing on desktop

blog.chromium.org

156 pointspjmlp130 comments

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...

NFC is going to be Great and could replace a lot of ugly QR Code usage.

But NFC is currently locked on all iOS devices.

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.

OH wow. I stand Corrected. Thank You.

I wish Safari implement something like WebNFC soon. I just dont like QR Code.

Neither Safari nor Mozilla will implement this due to security concerns that Chrome ignores.

None of the new APIs (except web sharing) advertised in the original post will be implemented, as a matter of fact. For the same reasons.

Their positions are open and are helpfully tracked by Chrome. See a rundown here [1]. I wish more people paid more attention to Google's shenanigans.

[1] https://twitter.com/dmitriid/status/1356125702513418249

>paid more attention to Google's shenanigans

Agree. Thanks for pointing it out.

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.

Except NFC readers are missing in a good portion of Android phones sold to countries where most of people live.

Just through that alone, QR codes will be a default choice over NFC.

NFC feel to be on the way becoming a US version of FeliCa.

I think it is mostly for cloud gaming

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.")

HID is not built for that kind of use.

Thanks! HID in general? WebHID? Is it a bandwidth/data limitation? Something enforced by Chrome?

HID stands for Human Interface Device and usually means things like keyboards, mice, trackpads, etc

https://en.m.wikipedia.org/wiki/USB_human_interface_device_c...

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.

No, they're UVC (at least the one I have is).

Thanks a lot, I learned something! I was also confused by seeing "Webcam" under the "Common HIDs" heading on Wikipedia: https://en.wikipedia.org/wiki/Human_interface_device

In all cases -- got it. HID -> not webcams. :-)

Cheers!

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.

It's not like every device will or could be supported reasonably by a browser. This allows support to be done by those who care about it.

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.

>> More power to the developers

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.

> Why not have e.g. generic gamepad support in Chrome

All the browsers have generic gamepad support at this point: https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API Unfortunately, it is a bit lowest common denominator.

WebHID is good for long tail devices, or handling more unusual features of specific devices: https://web.dev/hid-examples/

> 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.

I don't think I like this trend of web browers having so much power over hardware - seems like a huge vulnerability.

Also, how much memory do these changes involve? With these chromium updates every single elektron app I use will be affected?

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.

Gary Bernhardt saw this coming long back. https://www.destroyallsoftware.com/talks/the-birth-and-death...

Couldn't you have used web midi to control lights? I thought it was somewhat common application for midi.

Let me curb your enthusiasm: https://news.ycombinator.com/item?id=25986079

Tangentially related: if you have noticed that the CPU of your Mac is going crazy since the release of Chrome 88, a fix will be out on Tuesday: https://bugs.chromium.org/p/chromium/issues/detail?id=115279...

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).

Very cool. How's uBlock Origin support? It's funny how these days I have to check before upgrading that uBO won't be crippled.

There currently is no public date for the deprecation of Manifest v2 extensions, so I think you'll be fine with uBlock Origin for a while to come.

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).

It's expected to be trivial to block ads in Manifest v3. The API is a more powerful version of Safari's API which also allows adblocking.

uBlock Origin may not be willing to change, but other adblockers will fill that niche.

Basically it still does all capabilities needed by the extentions.

No, that's a lie. Manifest v3 is carefully designed to allow spying, but prevent blocking.

Can you substantiate that claim? What can't be effectively blocked, and how was it "carefully designed" to allow spying?

You can read it all in its full glory at https://bugs.chromium.org/p/chromium/issues/detail?id=896897

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.

Firefox's uBO support is doing fine.

This is a Chrome thread and the OP wants to know the status of manifest v3 in Chrome.

You should switch to Firefox than to keep using a browser whose owners are pretty obviously trying to kill uBO.

Or Brave, best of both worlds.

If Google removes support for Manifest v2 from Chromium, is Brave prepared to maintain it? Honest question.

https://twitter.com/flamsmark/status/1088170219695071232

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:

https://github.com/mozilla/standards-positions/issues/336

https://github.com/mozilla/standards-positions/commit/18aa5e...

https://mozilla.github.io/standards-positions/

While I would like to be dazzled buy new features to me the strikes a real privacy concern without proper permissions.

The user has to choose the device to connect via a browser pop-up.

Well that may be true it still is another vector for a identity based on hardware since it's numerated.

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.

Thank you for clarifying! That puts me a little bit more at ease.

I don't care for most of that. But what's unlisted is the fix for android autofill that is landing with it.

Is this autofill triggering an onchange event?

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.

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.

[1] - https://web.dev/web-share-target/

I downloaded Chrome Canary and found a demo page, made this screenshot on Windows 10: https://imgur.com/a/pXoWGR5

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.

The design is Microsoft's doing, not Google's. Chrome is calling out to an OS-provided API for this functionality.

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.

> Web Serial API

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 ...

I agree - I can't wait for the query permissions API, I believe that has specs to solve this problem... Check it out here: https://webbluetoothcg.github.io/web-bluetooth/#permission-a...

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.

Is it possible to assign a “port” to a specific device? (Similar to how I can assign a flash drive a specific drive letter)

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.

Yes, it's terrible :)

Chrome 89 also fixed a bug on Android that caused unreliable Autofill popup.

https://bugs.chromium.org/p/chromium/issues/detail?id=101494... is the bug.

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

> In Chrome 89, web sharing is available on Windows and ChromeOS

Seems odd that OSX isn't getting this feature. Anyone know what prevents that?

Because it calls out to an OS-provided API, they have to implement it separately for each platform. It appears to be in development for macOS: https://bugs.chromium.org/p/chromium/issues/detail?id=114492...

It's ironic that this page is using a GIF image instead of video. It is suppose to be the forefront of web tech advancement

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.

sadly at the moment webnfc only implements ndef standard and not reading arbitrary nfc tags.

Remember when browsers did one thing and one thing well? Chrome is slowly becoming an operating system and less of a browser

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.

New attack surface just dropped. Good news for team red.

Call me cynical but with things like HID and NFC, this feels very "embrace extend extinguish".

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.

>> but only because Google allow them to exist

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.

Yeah. Browsers are unfortunately OS:es now, finally realizing pmarca's dream of reducing Windows to a "poorly debugged set of device drivers".

Alan Kay reckons they aren't OS:es enough https://www.quora.com/Should-web-browsers-have-stuck-to-bein...

Very interesting, thanks for posting!

Edit: I removed some stuff I first wrote.

> 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.

It's still not is but it is has all the necessary APIs to replace native desktop APIs. So browser are the new display server. The Xorg replacement

So what's the other option? Apple world where browsers are crippled and everyone builds software for proprietary platforms with gatekeepers?

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.

ChromeOS is the end goal of Google, beware of the basket where you are putting your eggs on.

I wish there could be a clear distinction between applications (like gmail) and web pages (like nyt).

I agree with you on that.

4 javascript devs disagree, apparently.

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.

...as long as it's running Google's software.

> Apple world where browsers are crippled

I’m perfectly fine with crippled browsers. In fact I prefer them to be. Even current browsers are way beyond scope and IMO should be slimmed down.

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.

and, by now, Mozilla, but only because Google allow them to exist

Why does Mozilla need permission from Google to exist? That sounds very very wrong.

Because if Google stops paying them, they will go out of business.

It needs their money.

Doesn't the fact that it's all open-source put a damper on that particular conspiracy?

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".

In Google’s case it’s perhaps EELIE, embrace, extend, lose interest, extinguish.

> 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.

The competition is already pretty much extinguished.

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?

There’s dedicated API to support url blocking. Some uBlock features might be unavailable, but most features can be implemented with new API.

Features beyond mere URL blocking are what made uBlock popular in the first place.

What features are you talking about?

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.

Now it's perfect. So now, Sergey will let people pwn your 3D printer over a browser?

Even IE6 was not such a security model garbage. Even ActiveX was trying to sandbox itself from access to the hardware.

Reply on news.ycombinator.com