Hacker News Reader

Comment by worble | Hacker News Reader

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

View on HN

> At the risk of sounding conspiratorial, it feels like they're trying to hide in plain sight, pushing Chrome only features

I don't think that's too conspiratorial, I think that's exactly what is going on here.

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.

https://whats.new/shortcuts/

A bunch of other sites have also 'claimed' some .new domains, like vue.new goes to codesandbox.io and api.new to RunKit.

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.

Likewise, Google owns .dev.

Google doesn't give a shit about open web standard standards, rather they want to push their standards onto the open web.

The entire website should be treated with extreme suspicion. It's all the more insidious given the URL.

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

> Safari gets a lot of grief for being too slow

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.

> As someone who dabbles with Arduino

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?

I disagree that it's a terrible idea, particularly if the alternative is Wifi-enabled devices from dodgy vendors.

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.

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.

> It does create some interesting security implications that I hope get addressed properly.

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.

https://webapicontroversy.com

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.

> it likely won't be coming to Firefox at all, as they consider it harmful

Yikes. The original article should have definitely mentioned this, if it were not just a Google mouthpiece.

Web.dev alparently launched in 2018. Here's a story from when it went live: https://sdtimes.com/webdev/google-launches-new-website-for-w...

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.

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.

it seems fitting to me that a Google-ran blog about 'web development' in 2021 would look like this: https://i.imgur.com/XpyBoMR.png

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.

Okay, as someone who just used it for a few demo projects, I didn’t push it very hard. Thanks for explaining in more detail.

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

Google. doesn't. care.

[1] https://github.com/mozilla/standards-positions/issues/459#is...

[2] https://webapicontroversy.com

[3] https://web.dev/hid/

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

Presumably because you already know about the association. The ”about” page doesn’t even mention it. The only hint is the footer.

Reply on news.ycombinator.com