Hacker News Reader

Also important to mention is fun. The browser allows people to make fun stuff, be it a video game (using webGL) or a multiplayer instrument (using Web Audio API), and distribute it really easily. These API are well documented and are available to anyone to write and share. Thanks to the proliferation of web APIs you often don’t even need a server to make cool stuff and share with your friends.

If you have to create an executable for your fun little project, and make sure your friends have all the dependencies, and then your friends that have only Macs or Iphones won’t be able to use it because you don’t know how to share it with them, you might not bother making that thing in the first place, and the world becomes so much poorer as a result.

The web with it’s many features and API is really democratizing how we make fun interactive stuff and share it with each other. Most days there is a fun project that serves no purpose except to entertain strangers that makes it to the front page of HN. How many of those would still be made and shared if browsers would be as feature poor as the OP wants.

Perhaps the author is just dreaming of another browser in addition to the one you prefer. One with different/less features. It is interesting how this is somehow a controversial idea. Is there some reason that the number of web browsers needs to remain small.

Different browsers can be really useful. Personally I do not need want the browser the author suggests at all, but that's just me. Every user is different. I use "links" heavily for reading HTML; it is particularly good for printing HTML tables. I do not expect anyone else to use it. (But some do, including user who actually paid money for features.) A different browser is simply an optional program I choose to make use of. I do not use it for anything financial or otherwise sensitive. There are other browsers for that.

In recent years I frequently see comments that seem hostile to the mere idea of more web browsers. I do not understand this. If this author wants some browser with some certain set of features, that is his business.

"Disagreeing" with someone's desire for a browser with different/less features because of the annoyance of native apps. It make no sense. (Blame the developers of today's "native apps", not users who want alternatives.) AFAICT, there is no suggestion in this blog post of trying to take away anyone's preferred web browser and make them use native apps. The author just wants more options besides the popular ones. A browser with different/fewer features in addition to all the everything-but-the-kitchen-sink, do-everything-under-sun ones written by online advertising-supported organisations.

or even just a "web browser mode" vs "multimedia gateway mode."

the techwizardry demands of heavy hitters like YouTube and Facebook have created an "attack surface" that forces active and constantly evolving opt out behavior. the web is actively hostile towards the lay browser (person who browses.) a million notifications to allow and enable things on first visit to a site is a terrible experience. sane defaults should disallow these apis on most popular properties.

furthermore, I personally wouldnt mind a split between the browser and a communicator. a separate webrtc phonelike app that handles all teleconferencing. i get why people dont want a native app installed for each voip solution, but a single tool that is cross compatible, pushed out of the "web browser" would make web browsers safer.

the average person is using a web browser to look at celebrity news, pictures, youtube videos. delivering those things efficiently doesnt need to be much more complicated than the web was 10 years ago. having a separate button to launch "3d game rendering mode" would be preferable to every site on the web abusing the tech behind the scenes to deliver targeted ads.

You can sandbox native apps as well, without buying into all the complexity and unplanned obsolescence (have you tried browsing on an old 32bit computer?) that web browsers come with. Also, sandboxing web apps is incredibly limited; how do you restrict a web app from accessing the network?

Web apps also provide no degree of trust. You can't know what will be loaded in advance. Native software can allow you to inspect source code and modify it beforehand without resorting to maintaining a web server for self-hosting. Hell, Debian's working on reproducible builds and F-Droid has had it for years, while the web just figured out script verification with SHAs (entirely controlled by the vendor, which misses half the point).

> Gyroscope, accelerometer and compass APIs allow me to install fewer crappy small ad-packed native apps that I'll use one in a blue moon.

Even better: let's try to build a world where people don't have to run proprietary malware, on the web or otherwise.

> A built-in PDF viewer allows it to update frequently along with the browser and if properly sandboxes is probably more secure than installing some random PDF viewer setup.exe from somewhere.

Better idea: have a PDF reader that just opens documents without any scripts or internet connection. muPDF is a good option. Also, don't use random apps (native or web); distro packages are a good start for some trust beyond the vendor.

We've reached the point at which running two web apps cuts down battery life twice as much as me running my desktop, mail client, editor, newsreader, music player, and IRC client combined. The only "native" programs that come close to this level of resource abuse are Java IDEs. Web browsers are so complex that they essentially can't be forked or created anew without hundreds of millions of dollars in annual funding. And with the increasing footprint of web apps, it's no wonder people feel the need to turn their computers into e-waste every N years.

Yup!, the browser is such a great environment. It's sandboxed to death, easy to use/install, and cross compatible. (Can use any Modern Browser/OS combo). I'd rather play games in my browser than install a native app that has wide access to my personal documents.

Not to mention, Web Crypto API is the literal opposite of roll your own crypto. and is SOO much better than someone implementing cryptographic operations on JS. and can have so many use cases. End to End encryption with key stored in browser. (You can have the raw key inaccessible by JS even, only allow decryption/signing). Though I agree there are some APIs that are pretty dumb.

> Not to mention, Web Crypto API is the literal opposite of roll your own crypto. and is SOO much better than someone implementing cryptographic operations on JS

I'm glad someone is pointing this out as I felt like the author didn't even attempt to understand the Web Crypto API assuming an incorrect worst-case scenario.

WebCrypto is "roll your own crypto" as it implements low level algorithms instead of high-level protocols. The issue with rolling your own crypto wasn't "you will implement sha3 incorrectly" it was "you will use an algorithm for authenticated streaming symmetric encryption but accidentally reuse an initialization vector or fail to verify a checksum" or whatever.

100% on the possibility & amazingness of the platform, and hugely in agreeance that the wide range of well specified semi-publicly owned standards that make up the web is by far one of the best most empowering things we society have done. I have colossal awe & I can see use after use after use for all the sad salty disgruntled anti- opinions poses in the sad-sheet here.

still: I have some residual sympathies i'd share. for one, I am pretty terrified the webassembly based world will radically increase the un-observabity of the already virtualizing (as in, vdom) web dev world. understanding & working with the web medium we are given has gotten increasingly hard and the webassembly world sounds like an immoral indecypherable wreck for users with all good user agency pummeled away.

but, i would not halt that. the web medium needs great liberties to grow.

but, more so, in strong strong agreeance about "what we should do" that this article sets up, I think features should be flaggable. if someone wants to be a salty crufter, let em. it's the users right to their own experience. no website is obligated to function, to work, so if you disable webgpu, the good stuff just won't work: it's your choice to break maps, & dozens of others. let users turn features off broadly as they might & enable higher powers case by case.

I think the poster is a grizzly salty refusenik, a denialist, which we hear a lot from a lot, way overmuch. these people are ultra vocal. I'm so glad their attitude is condensed into somethong reasonable. and to me: sure, I think they should have their asks. we should give folks the abity to disarm parts of the web platform. to let them have the experience they want. mostly I think these folks are kind of idiots, devuan class reactionaries harking a denialist small minded set of expectations they falsely impose on others. but the web should allow them what they want. it should make turning things off easy. because the web is about user agency. and the cost of letting folks turn capabilities off is almost nothing. they can have their broken bad experiences, when various features are required by a site. maximalize the user, even when they want the web to still be living in a barrel.

There are many things I trust neither a native app nor a website to access. Most browsers seem to opt into far too many APIs and expect me to blacklist them all in hidden advanced options. But there is no reason that everything about reading from my computer isn't off by default. Geolocation, accelerometer, raw mouse data, battery level, hardware info, fonts supported, etc.

Heck, default to running code on every site is too much for me and the first thing I turn off. All the fine grained stuff is always I fight to find and remove.

This is a rosy picture of the browser but one of the reasons I really dislike my browser exposing all this is privacy: all if this is stuff that companies can use to uniquely identify you.

So hear me out... plugins ;)

If only we had tried making a browser plugin for multimedia applications with a separate runtime. We could call it something flashy, for example ... Flash. That totally went better than browser security.

Another option would be feature-enabling plugins, for example a plugin that enables WebRTC developed by some random company. I still don't see how it won't be massively worse than browser security.

Flash was AWESOME in that it enabled all that everyone whining on here wanted in their browsers, not to mention the lowest barrier to entry on content creation not reached again on this day.

But you had the option! Want your computer to the unsafe man-child playgroud? go ahead, install flash. Want something serious for work, don't touch it.

But the advertisement industry had their way and apple and microsoft started to include flash by default. Do you think Google fought flash because they care about you? heh. Google helped kill flash because it gave an edge to microsoft since their ad network at the time was text only and microsoft et al were making bank on swf banners.

anyway, you had the option! it was a plugin, not the browser. Instead of a better plugin, you killed the radio star, took over w3C so that feature for your ad network would be part of the standard.

Now chrome is worse than flash. Features like Federated Learning of Cohorts will be shoved down your throat like or not and it won't even allow you to play web games or something FUN.

no view source! that broke the basic treatise of the internet. it wasn't a protocol, wasnt a medium: it was someone else highjacking your shit & doing what they wanted in a filthy untouchable applicationized sandbox you had no power over it. you the user has no power, no visibility, no say. application,. it a medium: out of your reach.

very little of this submitted screed touches upon this area, but to me the anti-webassembly remarks feel very close fit to anti-flash remarks. js has gotten bad, but I continue to think eventually we'll see better actors (especially with an arisal of custom elements). webassembly makes me think the web will get anti-web anti-understandable, anti-user as a medium increasingly for the next 50 years probably, most of my remaining life. doing good & being a respectful medium will be just as possible as without webassembly, but there will be so much energy & focus on an industrialized non-user non-acessible non-user-agency dark world shadow-nightmare hell-web because of webhassembly, that will absolutely dominate & be enticing to so so so wide a range of the alpha geeks... while users lose & lose & lose.

flash 2.0 is coming & it will be cheered & celebrated & far far worse for users than the flash we have finally killed.

> no view source! that broke the basic treatise of the internet.

I was pretty young, but I'm pretty sure I remember opening someone else's swf file in a decompiler in middle school. It was a little weird but I was able to make the changes I wanted.

How editable is WASM code, really?

How editable is raw JFIF data, really? You need to run it through some fancy graphics library before you can do anything with it. /s

It's not as much how you can hack around it but more about open-by-default and open-by-design.

Well, that was my point about SWF files. You could edit them with the right tools. But like WASM, they are far less editable than the original source files.

Unfortunately, there are very practical performance reasons to send information in a "compiled," less-editable format. Which is why even static sites nowadays typically use some type of build system.

Yeah, that's very true.

I do wonder if with the 'somewhat standard' min.map files that can point out what the rendered versions relate to in the 'source' versions could somehow be enforced. That way you can still use the compact version first and if you do want to see what's happening you can just get the map and the source and explore.

Even if you do decompile the SWF & edit it, the flash can still interact with the page. In many cases you'd need to alter the page too, to inject your hacked swf.

Wasm code is editable via the very very good dev tools systems we have today, mostly dictated via the Chrome DevTools protocol which even Mozilla largely harkens to & which is being semi-standardized through wicg[1]. Still fairly early days but support is not bad! But... it's a monumentally harder challenge imo than JS. There are source maps, so if the site is nice, you can see what the authored uncompiled code was, but there's no facility to author in that language & recompile your changes via the debugger. And I fear few sites will post the source maps to make webassembly comprehendible. Few sites have morals, ethics, or respect for the web as a medium: they see it as a platform for them alone to dictate to you the user what you get. This, to me, is the sad end Flash had forced upon us, that the web was so much better than.

[1] https://github.com/WICG/devtools-protocol

Flash was a nightmare, but you know something that's good about flash?

It wasn't enabled everywhere by default and the majority of sites didn't assume you had it, unless it was something that genuinely needed it (like, habbo hotel, or youtube back in the day) it often never got enabled, meaning people couldn't use it for tracking me, or eating up all my local resources.

That's a freedom we've lost, disabling javascript just breaks everything.

Though webgl continues to be a toggle, though enabled by default.

it was pretty assumed you'd have it, it did have an install rate of over 90% at one point. I think it was just used less often for essential things since it wasn't as smooth to integrate with the rest of the page, and pages used to be less dynamic back then in general

> medical

You surely don't want medical data on the web, right? What could possibly go wrong?

Perhaps, but keep in the mind that Intranets exist. It is possible to have 'private' web services.

Factually we're already there. I've reviewed my own HIPAA-sensitive lab results in a patient portal for example. I'd go check out some of the solutions Epic Systems has put out if you're interested in current product offerings in the space.

Information wants to be shared, collaborated on, and worked on in real-time... both private intranets and/or public internet provide platforms to do this.

Yes, I do. Not all medical info need privacy.

It’s actually mandated now that providers allow free, on-demand, API access to patients for their medical data.

I can argue that it's easier to architect an intranet web medical data viewer right now than a typical desktop application accessing an intranet server.

Client-server desktop applications typically use custom protocols and custom servers leading to a higher likelihood of security issues.

They're harder/slower/trickier to update and administer within a big organization, leading to a higher chance of messing up.

Whatever security issues you can think of running it in a browser context, more exist when running it as native code.

If you run an intranet web service with the same security precautions as a public web service, which is currently very well explored, there are less things to go wrong.

Please don't shoot the messenger here, but your doctor and insurance company are very likely already using the web to exchange information about you. You can either have that in a way that is standards-complaint and vetted by a large group of browser engineers, or they could try to roll their own... which would you prefer?

Most of the offices use cloud based patient management apps. In my anecdotal experience, as soon as they enter my phone number into one of those, I start getting significantly increased spam call volume. The spike lasts a few weeks.

edit: typo

It seems they don't necessarily have to be using a cloud-based service to sell/leak phone numbers to a third party?