That's not a bug, it's a feature.
Javascript is a cancer that has lead to a slow, bloatware-, spyware-, and malware-infested web. Getting rid of it should be a priority.
What exactly is the big deal with having just static content?
I don't have JS enabled when I read HN. I just hit reload to load and read new comments. What exactly is the problem with doing that?
When I read some article on some news site or web forum, I don't need JS to just read a bunch of text or look at an image. All of that can be and often is static. JS is totally superflouous here.
The only legitimate uses of JS I can think of are for things like games, or data that you really need to be updated in real-time like stock market tickers. But those are a relatively minor subset of the web and can be made in to standalone apps anyway. I'd much rather have a standalone app than expose myself to all the malware, spyware, and tracking that comes with a JS web ecosystem.
>What exactly is the big deal with having just static content?
I don't read romance novels, so publishers shouldn't be allowed to print them.
The problem is that your personal opinion on the legitimate utility of javascript doesn't have any value beyond your own browser, and the entire rest of the world has decided that a purely static web is not what it wants.
Speak for yourself! I certainly agree with the parent that the Web is for content. And I believe many here around do as well. You do realize you're commenting here on a site which is as non-PWA/SPA as it gets, don't you?
I like Hacker News (obviously, since I spend far too much time here,) but I also like that I can run software in my browser and stream video and audio and play games. FFS, I'm running DOOM in a DosBox emulator in another browser tab as I type this. How is that not qualitatively better in terms of the breadth of content that the web allows than having it be limited to basic text styling and embedded images?
The point is that if I want to play DOS games I only need a URL and a modern browser, just the same as with text, images and other media. That "software" becomes just another content type the web can provide, in a way that's transparent and easy for the end user. If nothing else, the browser can act as a sandbox for software that operating systems otherwise don't seem to provide. A developer can't sneak "rm -rf /*" into their javascript and have it work the way they could natively.
> What a browser can and cannot do should be very carefully balanced, or you end up with a tangled mess of Chrome-only content and security/privacy catastrophes.
I would argue things have gotten more stable, not less, over time. Flash is more or less dead, as are web applets, and a lot of security issues in javascript WRT overriding object primitives, high frequency timing, cross origin requests, etc, have been dealt with. It's not entirely the wild west anymore.
I’m listening to Beethoven through my other fridge as I type this on my first fridge.
Yeah, 140 bytes of content the user wants and 140k of JS that is entirely superfluous if not outright user hostile.
And most of the rest of it is legitimate criticisms about the way javascript is used, but those are implementation and design decisions that are driven by culture, and can be changed by culture... and none of which really undermine the premise that computation in the browser has value.
No, we understand that answering the question "Is this Javascript I received from a unknown remote party safe to run and free of any malicious side effects?" is undecidable. If you want to defend the idea of running potentially hostile Turing complete code, you need to tell us how to answer that question or you are advocating that everybody should regularly accept the risk of running malicious code. I suggest first addressing the simpler question, "Does this Javascript program ever halt?"
> none of which really undermine the premise that computation in the browser has value.
Obviously Javascript - and computation in general - has value. I have never seen anybody suggest otherwise. Lots of things have value. The problem is that running Turing complete code is always going to be a risk, because describing the behavior of any grammar more complex than deterministic context-free is provably undecidable.
I don't really have to. Javascript has been a part of the web for over twenty years. Almost everyone else already runs it, and has already accepted that risk. You, rather, have to defend the premise that all of those people are wrong for doing so, given that most malicious code on the web comes from email attachments, downloaded binaries, and Internet Explorer.
I submit that blocking scripts will block ads (most of the time) and analytics and make sites (that work at all without it) run faster, but it won't really make you that much safer.
You're already running millions or billions of lines of potentially hostile Turing complete code that can do things javascript couldn't even dream of, and I doubt you've compiled all of it from source, or read all of the source if you have. The risk presented by javascript relative to every other programming language and runtime in existence is minimal.
>I suggest first addressing the simpler question, "Does this Javascript program ever halt?"
Yes. Hit escape, F5 or when the browser tells you a script appears to be hanging, have it kill the script.
I know you're referencing the halting problem there, but in practical terms it's not even an issue. You can, of course, just turn it off.
A lot of people without a CS background believing industry exaggerations and lies about security for many years does not mean they are acting safely. The frequent security issues is proof the risks exist. There were several decades where a lot of people smoked cigarettes, but we finally were able to make decent progress on educating everybody about that risk.
> most malicious code on the web comes from email attachments
The most malicious code in the long term is probably Google Analytics. The only reason it hasn't become a huge problem already is thanks to Google taking security seriously and not leaking everyone's browsing habits. An email virus/trojan at worst probably only ruins your computer and, in extreme cases, your bank account (i.e. with a keylogger). That's bad, but databases of your reading habits (and porn/etc habits) are a blackmail/manipulation risk that never goes away. The recent FB/CA drama should be seen as a warning about what can be done with enough data about you. It will be interesting when someone decides to steal GA (or other browsing history DBs) to sell it to insurance companies (possibly as a "risk evaluation" service so the insurance companies never have stolen data).
I don't expect you will strongly disagree and ignore this type of risk if your income is dependent on spyware continuing to exist.
> and I doubt you've compiled all of it from source
Actually, I have. Some of us do have the required technical background to understand this type of risk; the general public has to rely on someone else's word.
> The risk presented by javascript relative to every other programming language and runtime in existence is minimal.
Even if it was "minimal" (it isn't), you're taking that risk again every time you reload a webpage. I do not need to regularly compile new code simply to use the software I've previously installed.
> Yes. Hit escape,
Obviously, that interrupts the program, which is different from the program stopping (by reaching the end or running halt/exit).
> practical terms it's not even an issue.
Then please, in practical terms, tell me how I can answer the original question: is this random Javascript safe? My point is that this question is provably impossible to answer The halting problem is merely the easiest behavior to analyze; you cannot prove that a program will have any behavior in the general case.
You only need to look at the Android app ecosystem to see this. Ironically, because adblockers don't really work well on non-rooted phones, using native apps actually exposes me to a great deal more tracking than most of the websites I visit.
I would absolutely rather use Facebook, Twitter, or Reddit as websites than as native apps. And it's a great deal easier for me to block Google Analytics (just blacklist the domain) than it is for me to stop Google Maps, Uber, or Lyft from spying on me.
> Then please, in practical terms, tell me how I can answer the original question: is this random Javascript safe?
The only way to declare random code safe is to sandbox it. The web is one of the better sandboxes out there (although of course it's not perfect yet).
This is (one of) the reasons why we're starting to move towards Wayland in the Linux world - because we've realized that security by curation doesn't work for 99.9% of the population, and putting a sensible permissions model on top of applications is one of the few ways we can actually protect both advanced and average users.
If you're looking for 100% security, it doesn't exist, even for your self-compiled programs where you rigorously audited the source and all of the dependencies. Unless you've also taken steps to mitigate Trusting Trust?
Their problems with javascript aren't the technologies, its the ways they're abused. That's not a web problem or a javascript problem. I just kicked Facebook Messenger off my phone because every time I opened it, it would demand access to my address book.
If they want a particular app, they can click to download and run it explicitly. It's not a big deal.
From the developer and business standpoint, it might be a disadvantage not to have something like javascript available to use. It's more inconvenient, and now they can't spy on, advertise to, or track the user as easily.
But I'm for a user-centric web, not a business-centric or developer-centric web.
Edit: to be specific, it's a lot easier to allow access temporarily in a browser than it is using the Android permissions system. Not sure about Apple but I'd bet it's about the same as Android.
The guitar-tuning app is a special case that actually has a legitimate need to use a microphone, but I've seen countless apps that need all sorts of permissions that they don't legitimately need. Like calculator apps that need permission to access my microphone or contacts.
The sad thing is that most users will just click through a popup asking for permissions, just like they do the "Run as administrator" popups on Windows. Such things are just not very effective safeguards.
Even with limited permissions, allowing JS apps to run on my system opens me up to all sorts of JS exploits, tracking, and advertising that just aren't possible or much more difficult with static HTML (which has a much smaller attack surface than JS anyway).
Native apps are even worse. At least websites are ephemeral and you can pop open a dev console and inspect/block the traffic.
Native apps ask you for permissions and then can access those features for as long as they're installed on your phone, often in the background. Ever see what kind of data Google has on the average Android user? It knows their exact route through town every day. It's crazy.
Maybe the world would be a better place if 1999 MapQuest was still the most advanced app on the internet. But your fixation on Javascript in this thread sounds out of touch with the more inconvenient truths of modern technology, probably because Javascript happens to be the one you can live without.
I can't do anything about bad devs, but you've already decided that the path we are on (and will continue to be on because we're not getting rid of JS) is absolutely bad.
It's not 1999 anymore. We've gotta figure out how to do things right with today's tech, not a nostalgic view of how things were, because we're never going back.
It's a mistake to assume you don't have to do that for PWAs.
> Javascript is a cancer that has lead to a slow, bloatware-, spyware-, and malware-infested web. Getting rid of it should be a priority.
That may or may not be correct from developer's point of view. I am not sure and I am not going to argue that.
However, how about user's point of view. A lot of users (including me!) prefer not to install native apps but use Web apps especially when achieving one-time tasks. Do you have any thoughts/data on what users prefer?
Yes, use JavaScript when it's appropriate and makes the site/app better, or when it's necessary for the thing to function. Obviously something using your camera or microphone or what not should use JavaScript and might rely on it to function.
But if the site or app is meant to do something that'd work perfectly fine without JavaScript (or with progressive enhancement and a non JavaScript fallback), make it like that instead.
When you're delivering megabytes worth of scripts and relying on JavaScript only functionality for what's essentially a blog (read, many news sites and content platforms now), something is really wrong. The people at the likes of Reddit, Wikia, Medium, and a fair few news sites seem to be trying to deliver a simple product with enough technology to launch a space shuttle.
Fine. Why would I want any thing on a website accessing any of those things? Why can't an app handle that? What's wrong with using separate mediums for publishing and interacting with information?
Also, because the web incorporates hyperlinks, which means "apps" can link to "documents" and vice versa, which is useful, because you might have an attached blog or FAQ or something.
Because every device/os has its' own app store/ecosystem.
Because it takes a lot of effort (more than most will expend) to support even a handful of platforms with anything beyond the simplest of applications with native apps.
Facebook Messenger in a web browser can't read your phone contacts. That alone should be evidence enough that the web handles security better than native.
Stock Android doesn't even allow proper firewall support or adblocking without rooting or implementing hacks on top of a vpn. On the web I can block individual requests to specific domains, and even rewrite them on the fly.
The app model failed because the app model is the web model, just with bad sandboxing, less granular permissions, slower install times, and a worse development ecosystem.
Everybody loves native, I don't understand why. Native is terrible. 90% of native security boils down to "trust a global company to gatekeep out all of the malware." That's not good security.
The described experience of "loads instantly, uses almost no CPU/battery, and renders on everything everywhere and for people with accessibility issues." is clearly superior to all javascript-powered web sites in the observable universe.
Therefore your comment makes no sense, Sir.
The same is not true of native apps.
I don't think I have a career ahead of me in the trolling business either.
And now I'm wrong for having commented on the voting on comments. My bad, again.