Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

591–600 of 717 posts

Re: It’s time to kill the web app

#591
People who hate have either a severe depression or try to get easy attention.

Why hating web apps? Every app has their advantages.

- Native apps are great and I couldn't imagine how Sketch, Snapchat, etc. could be done as a web app

- Web apps are great because I wouldn't want to install apps just for those I use once in while or apps where I rather consume than interact

- Console apps are great when I focus on raw text manipulation and they get even better when working on remote servers

So, why they hate?

Re: It’s time to kill the web app

#592

Earlier quoted context omitted.

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…

> 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. I'm not sure programmers are much better. There's a long history of security vulnerabilities being reinvented over and over. Like CSRF is simply an inst…

> And blaming this on the market is a cheap attempt to dodge responsibility.

You are oversimplifying. Dunno in what programming area you work (or if it's software at all) but "we work with languages X and Y" is something you'll find in 100% of all job adverts.

Tech decisions are pushed as political decisions from people who can't discern a Lumia phone from an average Android. That's the real problem in many cases.

That there exist a lot of irresponsible programmers is a fact as well.

Re: It’s time to kill the web app

#593

Earlier quoted context omitted.

> >*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 impossible to secure. I…

"If the 90s "slowly reinvented UNIX", then the correct thing to do would be for the web today to either be a fully modern 2017-worthy technology, or at least take its starting point from where the 90s ENDED, not re-invent the 90s." Since when has an inexperienced mob of people ever done the correct thing on the first try? And, yet, the mob has continued the very fine legacy of those 90s (and 80s and 70s) software dev…

>Since when has an inexperienced mob of people ever done the correct thing on the first try?

Only web standards are not created by an "inexperienced mob of people" but by large multinationals, multiple CS PhDs, and seasoned developers.

And if we consider every generation of new developers an "inexperienced mob of people", then we have absolutely no claim to ever being called an industry and engineers.

>And, yet, the mob has continued the very fine legacy of those 90s (and 80s and 70s) software developers in pushing software into more places it's never been before. Somehow, it's working

Working in what? Mobile apps, counting in the millions, have actually "pushed software into more places it's never been before", and most of those are usually native, or done with non-web technologies (of course web stacks encroach there too). For most people, those mobile apps on their smartphones is how they interact most of the time with the internet, not www, even if they have a laptop at home or at work. For younger people even more so.

>But, if you show me something better, I'll gladly participate.

Better things come from people feeling the need to create them. They don't appear on their own, and people migrate to them. Else people can be stuck with the same BS for decades, centuries or millennia (consider dynasties ruling for centuries before the people of some country attempt to bring them down in favor of democracy).

Re: It’s time to kill the web app

#594

Earlier quoted context omitted.

I'm having a hard time seeing how having separate control and data streams would have an effect here. Using FTP to retrieve a document isn't more secure than HTTP... the problem is in how the document itself is parsed. If you added a separate side channel for requesting data (a la FTP), you'd still have the issue of parsing the HTML on the other side. Granted, if you made that control channel stateful, you'd make a l…

It makes sure that all your code is yours and that no matter what stuff makes it into the data stream it will never be able to do anything because it is just meant to be rendered. So abc would go as where datum 1 would refer to the first datum in the data stream, being 'abc' and no matter what trickery you'd pull to try to put another tag or executable bit or other such nonsense in the datum it would never be interpr…

Or, e.g. my preferred encoding of HTML:

    (html "abc")
This guarantees that no matter what is inside "abc" it simply can't escape into the control stream:

    (html "This is not (malicious \"boo\")")
This is just a pretty display of what would actually be these bytes:

    (4:html29:This is not (malicious "boo"))
It doesn't matter what one puts in the atom: it can't escape and damage the control stream.

Re: It’s time to kill the web app

#595
post #280

Earlier quoted context omitted.

Some would argue we've traded speed of execution for snake oil (so called speed of "productivity"). This tweet is an interesting visual that makes the same point: https://twitter.com/TheoVanGrind/status/888850519564984322

Software has become more increasingly complicated over time. Aside from adding new features, many companies have improved their efforts of providing accessible applications to a international audiences. Let's not forget we've drastically increased security by writing applications in safer languages. Oh, and newer applications tend to support a far wider variety of devices types, displays, inputs, etc. Developers defi…

> it's unfair to claim stuff is slower without improvements.

I claimed no such thing. You're arguing against a statement I never made. Isn't that what's called a straw man argument?

Re: It’s time to kill the web app

#596
Web app may not be as good as you wish, but I think GUI app development either on desktop or mobile is definitely worse. Otherwise there won't be a market for hybrid apps. For those desktop app guys who haven't heard of vue, spend some time going through its guide, you will find web development is actually much more advanced than anything you are using.

Re: It’s time to kill the web app

#597

Earlier quoted context omitted.

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.

I'm not sure what the argument you're putting forth is. All of the HTML-generating tools I'm aware of (barring dumb string templating tools) work sufficiently well and prevent human error. My point is that there's nothing wrong with HTML. HTML isn't a tool, it's a format for storing and transmitting hypertext. If you're using React or HAML or any of the other HTML-generating tools, you're effectively immune from XSS.…

The prevalence of XSS suggest that the web ecosystem has failed to produce the sort of tools you suggest. If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation.

However, no such tool exists. I think there's a deeper issue here: the sheer number of ways you can generate XSS alone, even ignoring the other exploit types, is far beyond what any tool is capable of stopping. Look at one of the XSS holes found by Homakov that I linked to from my article:

http://sakurity.com/blog/2015/06/25/puzzle2.html

The XSS occurs on this line of JavaScript, not HTML:

    $.get(location.pathname+'?something')
That's a simple line of JQuery that does an XmlHttpRequest to the same page that was loaded with an additional parameter. By itself, it is not an XSS. But if the backend is/was running Ruby on Rails (presumably some old version by now) then it could turn into an XSS due to a combination of features that all look superficially harmless.

Show me the tool that would have avoided that type of exploit, without already knowing about it and having some incredibly specific hardcoded static analysis rule.

When I argue that the web is unsafe by design, it's because cases like that aren't rare, they're common. To paraphrase Veekun, scratch the surface of web security and you'll find yourself in a bottomless downward spiral, uncovering more and more horrifying trivia.

Re: It’s time to kill the web app

#598
post #125

Earlier quoted context omitted.

If the length is not pre-defined, the input has to be parsed to look for the closing tag. That makes your code vulnerable if the input tricks it into finding the wrong closing tag. But if the length is fixed, you don't have to parse it at all. That would avoid a whole class of vulnerabilities.

True, assuming that programmers don't compute code (HTML,SQL, etc) from user input and miscompute the length of a fragment. It would be interesting to see if this idea could work in practice.

This isn't some theoretical design. Any native application that uses a binary protocol framework like protobufs over TCP to communicate with the backend will benefit from this approach.

Re: It’s time to kill the web app

#599

Earlier quoted context omitted.

SQL injection is not a web problem. If you create SQL queries based on any untrusted (e.g. user) input on any platform, you have to escape/explicitly type your input. Injection in general is simply a trust problem. If you can trust all inputs fully (hint: you can't, because nobody can), then you will never have an injection attack.

SQL injection is a problem with SQL, which is similar to problems with HTML. SQL was created as human-friendly query languages, it wasn't created to be built from strings in a programming language. Proper database API should be just a bunch of query builder calls and with this API SQL-injection is not possible.

Exactly.

Re: It’s time to kill the web app

#600
post #575
post #350

Earlier quoted context omitted.

Those communities are all very niche, and in fact part of their brand and image is in their design. Even though they are less flashy, that is the point. Try to convince the owner of a clothing ecommerce site that their store should look like a 4chan bulletin board while trying to sell high priced garments to the public, or that the Coke website can't have a vibrant design in line with the rest of their branding.

So Google and Amazon are niche? And if the plainness/unelaboratedness of deaign is part if Reddit's identity, why most subreddits use elaborate custom CSS? And what I'm saying is different anyways: when you provide some real value, your design is irrelevant. Otherwise you are employing the put-moar-sugar-in-it technique of marketing. Kudos if you make it work, but it's far fetched to say that it's necessary.

The are wildly popular but they are in a niche yes. When they were not the Google we know today there were not many providing the same service or value, and potentially still isn't, so that is why they could get away with bland design. It was never bad design mind you.

Amazon is also king of providing value in their markets, and their markets are also apathetic toward flashy design. I don't need animations when I am provisioning an AWS instance nor when I am buying goods at the lowest possible price I can find.

However if I were not me, and I were shopping for luxury or boutique goods, a site that looked like Amazon would not instill me with confidence.

My point is just that the web has diverse design and UX needs and the current toolset caters for that. If someone managed to build a platform with those benefits and more and the webs market penetration then I would be on board.

I will argue still that it is necessary if you want an alternative to the web, as the alternative has to be a better value proposition for the end user not the developer.

Post reply on HN