I don't think that's too conspiratorial, I think that's exactly what is going on here.
A bunch of other sites have also 'claimed' some .new domains, like vue.new goes to codesandbox.io and api.new to RunKit.
The entire website should be treated with extreme suspicion. It's all the more insidious given the URL.
Making it clear that it’s Chrome only (for now) would be good and they should do that more prominently. Making it possible for other browsers to implement by designing it with standardization in mind also seems good? (Unlike the situation with web extensions.) Lock-in is bad, Chrome-only websites are bad, so they should be trying to standardize things and avoid using it as a point of differentiation between browsers.
Not speaking for other browser vendors is also good. Like, it’s all very well for us to say that Firefox seems unlikely to pick it up, but someone on the Chrome team should definitely not say that, because it jinxes the effort and Firefox might change their minds if web developers seem to want it. (The comment you link to raises security concerns but I don’t think they claim to be giving the final word about Firefox’s position.)
So we see the state of standardization a bit hidden behind euphemisms like saying that there are “no signals” from other browsers yet.
There’s also the danger of having early articles become out of date by claiming that things are Chrome-only when actually the situation has changed and the person writing the article doesn’t know about it, so there is a tendency to avoid saying too much.
The underlying assumption is that web standards evolve by browser vendors starting to implement things ahead of getting consensus. Implementation and documentation start ahead of the standardization effort, which goes on in parallel.
(And underlying that assumption is the notion that rapid adoption of more powerful web api’s is desirable and “stagnation” is bad. Safari gets a lot of grief for being too slow, while Chrome gets grief for being too fast.)
Literally mostly from Google employees just mad their pet project doesn't work on iOS. I, and plenty of others, appreciate the position Safari (and sometimes Firefox) holds in only supporting web APIs that provide value greater than the security and privacy risks they introduce.
Google's busy trying to invent ways for websites to tamper with your USB devices, and it hasn't even managed to deal with how much malware it distributes through it's extension store alone, much less through it's ad platform and misuse of the notifications API.
You’re also trying to put yourself in a position of speaking for other developers, which is something we should avoid. How do we know what most developers want?
That is not what I said. I said they are trying to let websites tamper with your USB devices. Aka, they introduced WebUSB, yet another mostly-useless browser feature that exposes a large attack area to the web which I need to block by policy, that was probably solely introduced so they could release https://flash.android.com/ which very few people need or use, and could just as well be a desktop app.
As someone who dabbles with Arduino I actually do want USB support. I don’t particularly like installing everything but the kitchen sink on my desktop via homebrew just to get a decent development environment going. (Last time I tried it, the Python install failed because homebrew doesn’t support the OS version I’m running. I really dislike homebrew.)
Running embedded development in a browser and just giving access to a certain USB device would be an improvement, letting you do it on any machine or even a Chromebook. It’s going to take a long time to get there but I can see it being useful someday.
And you've just picked another extreme niche, like flashing Android ROMs.
Here's the problem with things like WebUSB that Google injects into Chrome: It's going out to over a billion users, including seniors, enterprise environments, and the technologically inept. And it introduces security risks. Why would anyone launch WebUSB out to, say, my grandma, just because maybe 100,000 people in the world might use features that require websites directly talk to a USB device?
Ironically, I could tell you how Google could fix this right now, but I'm confident they won't do it because it's not Googley enough: Leave it and a dozen similarly obscure web features permanently disabled by default behind an about:config flag. Google is obsessed with making things "just work", so they enable everything, even though something like WebUSB will only ever be used by people who are doing something sophisticated enough that flipping an about:config flag is in their wheelhouse.
As an IT admin, what's really frustrating is having to edit group policy every month to disable each and every new security hole and pop-up call-to-action feature browsers introduced that month. (Google is not alone in this, Firefox is guilty too to some extent, and Edge clones all of Google's bad ideas, of course.)
And for people at home, the thing is, non-technical users approve everything. They hit that accept button on every bloody prompt they get. And I know this because I spent a lot of time cleaning out the Privacy permissions tab on people's browsers when they have problems. "Why are three porn sites able to send desktop notifications on this browser?" Who the heck knows?
Just to make it easier for you to play with an Arduino, everyone else shouldn't have to play whack-a-mole with "features" silently injected into their browser via evergreen updates.
But the audience for WebUSB might grow. Many consumer electronic devices have companion desktop apps to configure them. Wouldn't it be nice if we didn't have to write them multiple times, and you could use the same software to configure them on Linux or a Chromebook as well?
You're claiming that Google just wants this for flashing Android but how do you know? Maybe they're thinking bigger.
If I was to characterize most of my issues with the Chrome team, it'd be that they need to stay in their own lane. They've injected a botched antivirus app into their releases before, DoH basically sidesteps the OS' networking stack because it was inconvenient for them they couldn't change it, etc.
At what point can we tell the Chrome team to stop feature creeping and just try to make their web browser waste less RAM?
It would be useful to have devices that don't talk to the network at all unless I plug them in and open a particular web app.
They won't. Both Mozilla and Safari pointed out the security issues and refused to implement WebUSB (along with a host of other APIs) as specified.
Google said: we don't care, it's now enabled by default in Chrome.
The most important thing to note here is that we're looking to escape vendor control. A lot of people miss that. If browsers can get feature parity with apps that means no more app stores. no more app stores means more freedom of choice. Maybe that's not good for grandma but it's good for you and me.
There are a few decisions by chrome developers that I will never support, like a bunch of stuff in Manifest V3 but hopefully with other browser companies will provide a way around boneheaded, selfish corporate decisions while we reap the benefits of better integration with the operation system.
Yikes. The original article should have definitely mentioned this, if it were not just a Google mouthpiece.
1. FileSystem API: (Note that this is one word, "FileSystem.") This deprecated API simulates a local file system that web apps can navigate around. With this API, you can develop apps that can read, write, and create files and directories in a sandboxed, virtual file system, but you can't use it to access files in the user's Documents folder.
You can polyfill this API, and IMO it's not very useful. It's typically backed by actual files, but there's no expectation that users will directly access that folder.
https://caniuse.com/filesystem https://caniuse.com/mdn-api_filesystem
2. File System Access API (formerly known as Native File System API and prior to that it was called Writeable Files API): This API lets webapps launch a picker to select a file or folder; from then on, the webapp can write to that file/folder without prompting the user (until you close the tab).
Without this API, if your webapp has a file you'd like to write, all you can do is let the user download it. Downloaded files always either automagically appear in the Downloads folder (and do not permit overwriting existing files; identical names get autorenamed), or they launch a picker, which nags the user with "Are you sure your want to replace this file?"
The FSA API cannot be polyfilled, and it's impossible-ish to implement a good web-based text editor without it. (Imagine if your favorite editor could only generate new files and never overwrite old ones, or if it nagged you "are you sure?" every time you tried to save your changes.)
That's the API you linked to above. There, a guy says he thinks it should be harmful, but that's not the standards position that Mozilla actually adopted. They currently mark it as "defer" (though they may decide to come around and mark it "harmful") https://mozilla.github.io/standards-positions/#native-file-s...
https://caniuse.com/native-filesystem-api
3. File Handling API: This is what TFA is about. It allows your webapp to say "I handle .txt files; when someone double clicks on a .txt file, open it in my webapp."
Mozilla lists this API as "defer" as well. https://mozilla.github.io/standards-positions/#wicg-file-han...
https://github.com/mozilla/standards-positions/issues/158 is where they discussed that. (Note this is issue 158, as opposed to issue 154 in your link.) I agree with Mozilla that it makes no sense to implement the File Handling API without the File System Access API.
While it wasn't the first example of this, I think Web Audio set the standard for this pattern - individual Chrome contributors making their best effort to design and implement a cool API, but then the org's scheduling and priorities result in it shipping before it's remotely ready and before other browser vendors have meaningfully contributed to the process. This early ship date combined with Google's market power results in applications building on top of these immature APIs, which means that other vendors have no choice but to implement and ship absolute garbage.
Web Audio is a great example because they kicked that steaming pile out the door in order to enable (Chrome-only, naturally) web ports of things like Angry Birds, even though in practice that API was barely usable for anything and had all sorts of undesirable characteristics that still aren't completely fixed nearly a decade later. At the time Mozilla was working on a design and implementation for an API that was actually good, but Google's unilateral move killed any chance of a good solution being shipped by multiple vendors.
Other Chrome-only APIs have been similar stories, though at least Native Client/Pepper - probably the worst example - failed because the doomed design and implementation made it impossible for it to even hit their own production targets and drove app developers (like Unity) away.
In some cases you can meaningfully argue that other vendors are just dragging their feet - Safari being the main example, where they simply have been years late to ship useful things that both FF and Chrome had - but in practice nobody else has the massive development resources Google has to waste on dead-end trash APIs and nobody wants to pay the cost of implementing something they'll have to throw out a year later with the knowledge that websites won't support their browser anyway.
The meaningful security/privacy concerns Apple and Mozilla use to reject new Google APIs are also a good example, because Google has the resources to just address these security issues via brute force. They can unilaterally deprecate an existing API and break tons of websites (Web Audio, video, etc) or just ship something busted and rapidly rework it to try and paper over the consequences (WebMidi etc being used for fingerprinting...)
In my time working on the nacl (then WebAssembly) team it became clear to me that most of the devs there weren't acting on malicious motives, the overall structure and priorities of Google as a whole just produced bad outcomes. Sadly with their de-facto monopoly there's no pressures to fix that.
Chrome does seem to be somewhat hasty, which can have a similar effect in practice. But it might seem different if you actually want a feature and don’t want to wait years for it?
I don’t think Web Audio is as bad as you say. There is the ScriptProcessorNode which is getting deprecated in favor of audio worklets because having JavaScript processing audio on the foreground thread is a bad idea. But other than that, it seems nice for making simple audio processing graphs, and the infrastructure for putting JavaScript in the background took a while to work out.
They also treated basic use cases like 'pause a piece of playing audio' as out of scope, which is simply bizarre.
Every web app or port I've ever touched had issues caused by the poor design and quality of the API.
Indeed. It's rarely designed to be a web standard. However, Chrome rams that through standards body, calls that a standard and enables it by default in Chrome.
Just look at WebHID. Firefox devs couldn't even understand the spec [1], it was so Chrome-specific. Guess what, it's enabled by default in Chrome [2] and Chrome says that it's a standard now [3]. Most of those non-standards are not even out of the "draft" stage of the standards process, with both Safari and Firefox objecting to many, many, many things in the specs.
Google. doesn't. care.
[1] https://github.com/mozilla/standards-positions/issues/459#is...
The fact that they tried and failed (if they did fail; maybe they will succeed eventually?) shows that they cared at least a little about standardization, even if it was somewhat half-hearted.
When negotiations fail, it's not a given that one side is entirely at fault.
The "request for Mozilla's position" was on December 1, 2020.
Chrome enabled it by default in Chrome 89 that was released only 4 months later, on March 3, 2021.
So they "requested Mozilla's position" and still went ahead, implemented it and enabled it by default. But so nice of them to update the spec two weeks after they released it.
> The fact that they tried and failed (if they did fail; maybe they will succeed eventually?) shows that they cared at least a little about standardization
As reality and facts show, they couldn't care less about standardization.
> When negotiations fail, it's not a given that one side is entirely at fault.
Please show me at which point this was a negotiation.
I don't think it is even a case of hiding at all. just a short domain handy to be linked to during talks, presentations etc...
At the risk of sounding conspiratorial, it feels like they're trying to hide in plain sight, pushing Chrome only features while constantly just saying "mordern web", and while they pay passing mention that the API is "currently in development" it doesn't add the fact it is not standardised, and it likely won't be coming to Firefox at all, as they consider it harmful: https://github.com/mozilla/standards-positions/issues/154#is...