Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

131–140 of 717 posts

Re: It’s time to kill the web app

#131
post #76

Earlier quoted context omitted.

> Most injection attacks are due to this; if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately No it wouldn't. It wouldn't fix sql injection and it also wouldn't fix the path bug the op linked. The problem is not length, it is context unaware strings. The problem is our obsession with primitive types that pervade our codebases.

The point is that if you know the length of some data up-front before starting to parse it, you don't have to inspect the data in any way to see when it ends. This means that you don't need to know what the SQL injection looks like and protect against it, or what JS looks like to sanitise your inputs – the problem does go away to a large extent.

This doesn't do anything for Bobby DROP TABLE injections, right? The whole thing is a user-supplied slug, there's no source of truth on how long a user's name is. Or am I missing something?

Re: It’s time to kill the web app

#134

I find this unconvincing. Every negative thing said about the web is true of every other platform, so far. It just seems to ignore how bad software has always been (on average). "Web development is slowly reinventing the 1990's." The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. "Web apps are impossible to secure." Programs in the 90s were written in C and C++. C is impossible to secure. C++ is im…

The security aspect was an interesting part of this piece, because one of the main reasons webapps took over from Windows apps is because they were perceived as more secure. I could disable ActiveX and Java and be reasonably confident that visiting a webpage would not pwn my computer, which I certainly couldn't do when downloading software from the Internet. And then a major reason mobile apps took over from webapps is because they were perceived as more secure, because they were immune to the type of XSRF and XSS vulnerabilities that webapps were vulnerable to.

Consumers don't think about security the way an IT professional does. A programmer thinks of all the ways that a program could fuck up your computer; it's a large part of our job description. The average person is terrible at envisioning things that don't exist or contemplating the consequences of hypotheticals that haven't happened. Their litmus test for whether a platform is secure is "Have I been burned by software on this platform in the past?" If they have been burned enough times by the current incumbent, they start looking around for alternatives that haven't screwed them over yet. If they find anything that does what they need it to do and whose authors promise that it's more secure, they'll switch. Extra bonus points if it has added functionality like fitting in your pocket or letting you instantly talk with anyone on earth.

The depressing corollary of this is that security is not selected for by the market. The key attribute that customers select for is "has it screwed me yet?", which all new systems without obvious vulnerabilities can claim because the bad guys don't have time or incentive to write exploits for them yet. Somebody who actually builds a secure system will be spending resources securing it that they won't be spending evangelizing it; they'll lose out to systems that promise security (and usually address a few specific attacks on the previous incumbent) . And so the tech industry will naturally oscillate on a ~20-year cycle with new platforms replacing old ones, gaining adoption on better convenience & security, attracting bad actors who take advantage of their vulnerabilities, becoming unusable because of the bad actors, and then eventually being replaced by fresh new platforms.

On the plus side, this is a full-employment theorem for tech entrepreneurs.

Re: It’s time to kill the web app

#135
post #95

Apart from some justified points on how confusing origins can be, the author fundamentally misunderstands Web development. Not only do users want fast sites and multiple of them open, so the performance point bears little weight, but the authors points to OOP techniques, presenting them as necessarily superior to FRP because they came later to Windows. Next the criticism on productivity and size of developer teams. P…

> "Next the criticism on productivity and size of developer teams."

Were we reading the same article? The main criticisms made by the author of the article were about web app security. If there was a mention of productivity it was only made in passing.

> "The author just basically wants to write desktop apps, but also be able to take advantage of the Web's discoverability."

Is this a bad approach?

Re: It’s time to kill the web app

#137

Earlier quoted context omitted.

If so I'm in full agreement. It's truly mind-blowing how much energy has been wasted on trying to shoehorn the web into an app delivery platform over the last decade. To what end? To make the browser a general purpose platform? We have that already, it's called an "operating system". Edit: that said, I disagree with many points and the general negativity in TFA

It's a great example of worse is better in action: a technically inferior platform winning out because it's better at one or two things that enable virality, which is the only thing that matters when all the money is looking for high growth. In this case, it's that webapps require zero effort and time from the user to get started with, and allow developers to get the closest to the "write once, run anywhere" dream th…

True, but I think the push for web apps is mostly about lock-in and ad-financed web services.

Re: It’s time to kill the web app

#138
The web is our best bet to converge to a single platform.

I find it extremely intellectually unfulfilling to write my code for three platforms (web/Android/iOS) instead of just one. So until there is a better common denominator, the web is my first choice, because at least it is accessible from all three platforms, and from the desktop.

Re: It’s time to kill the web app

#139
post #48

Earlier quoted context omitted.

> "Web development is slowly reinventing the 1990's." > The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. Yes, this reminds me of: "Wasn't all this done years ago at Xerox PARC? (No one remembers what was really done at PARC, but everyone else will assume you remember something they don't.)" [1] > "Buffers that don’t specify their length" > Is this really a common problem in web apps? Most web app…

> if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately. If this was the case, it would be near-impossible to write HTML by hand. And if you're writing HTML with a tool (React, HAML etc.), the tool could be doing HTML escaping correctly instead. This isn't an issue with HTML, it's an issue with human error.

If you have an issue with human error and don't design your programmed tool to avoid letting the errors out into the world, then it is the fault of the tool.

Re: It’s time to kill the web app

#140
post #48

Earlier quoted context omitted.

> "Web development is slowly reinventing the 1990's." > The 90s were slowly reinventing UNIX and stuff invented at Bell Labs. Yes, this reminds me of: "Wasn't all this done years ago at Xerox PARC? (No one remembers what was really done at PARC, but everyone else will assume you remember something they don't.)" [1] > "Buffers that don’t specify their length" > Is this really a common problem in web apps? Most web app…

> if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately. If this was the case, it would be near-impossible to write HTML by hand. And if you're writing HTML with a tool (React, HAML etc.), the tool could be doing HTML escaping correctly instead. This isn't an issue with HTML, it's an issue with human error.

> This isn't an issue with HTML, it's an issue with human error.

All security issues are due to human error. Those are solved by building better tools.

> If this was the case, it would be near-impossible to write HTML by hand.

If, besides the text form, there would be a well-defined length-prefixed binary representation, we could simply compile HTML to binary-HTML, which would immediately made the web not only safer, but also much more efficient (it's scary if you think just how much parsing and reparsing goes on when displaying a web page).

Post reply on HN