It’s time to kill the web app • Hacker News Board

Re: It’s time to kill the web app

#171

Post by clarry » Sat, Sep 23, 2017, 10:02 PM UTC

Pxtl wrote: post #57

untog wrote: post #37

Earlier quoted context omitted.

I agree and disagree. From the perspective of anyone making a web site it's very easy to secure yourself against JS running on a third party domain: don't load any. That sites do load these scripts says a lot more about their priorities and the state of online advertising than it does about browsers themselves.

But the problem is that the server is deciding for the user. If they want to show me sketchy ad content, they can go fetch it and send it to me as part of my request to them. Don't tell me to go get it myself. If an ad server is malicious, let it be the web server that has to deal with them, not me.

So suppose they go and fetch these malicious ads and forward them to you. Now you get that malware directly from the first party. The malware has all the same-origin access as the first-party application, and you can't trivially block it with things like uMatrix.

That's what I call server deciding for the user. And now you're in real trouble with security.

Re: It’s time to kill the web app

#172

Post by ivanhoe » Sat, Sep 23, 2017, 10:03 PM UTC

People used to do that, in 90s CGI scripts were usually written in C, or even assembly. And let me tell you since I'm old enough to remember it: no, it wasn't a great experience at all. It was actually quite horrible for web developers from the today's perspective. Development was slow and painful and hard to debug as hell. Also, it wasn't secure at all, hacker usenet groups were all about stack overflows back in those days.

One of my first jobs in late 90s was a complete rewrite of a huge web app into perl. It was originally written in pure C, and it had so many security and stability issues due to bad castings and stack overflows and null pointers and all that usual C stuff, that today it'd be considered completely unusable (back then corporate users were far more tolerant I guess). Perl rewrite fixed it all, no stack overflows, no worries about casting every input every freaking time, no sql injections (perl DBI used prepared statements), everything worked like a charm. And it took us only a fragment of the time it took for the original development. Programming cycle was like 10x faster since you didn't have to compile it first (just that was worth it), code was easier to read, we were much less likely to make stupid errors, etc. That's why everyone moved to perl and then php, python, ruby, etc. in the first place. They are simply better tools for the job, history has proven it already like 20 years ago.

Re: It’s time to kill the web app

#173

Post by stouset » Sat, Sep 23, 2017, 10:03 PM UTC

jacquesm wrote: post #162

aidenn0 wrote: 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. That's not really the problem. The problem is there is no distinction between data and control leading to everything coming to you in one binary stream. If the control aspect would be out-of-band then the problem would really go away. Length prefixes will just turn into one more thing to overwrite or inte…

Thank you.

This is the important takeaway here. Changing the encoding simply swaps out one set of vulnerabilities and attacks for another. Separating control flow and data is the actual silver bullet for this category of attacks.

Unfortunately, there’s rarely ever a totally clear logical separation between the two. Anything you want to bucket into “control”, someone else is going to want the client to be able to manipulate as data.

Re: It’s time to kill the web app

#174

Post by mmcnl » Sat, Sep 23, 2017, 10:03 PM UTC

This article addresses web apps at the micro level. Comparing a React based webapp to a 20-year old UI, the end result. It fails to address distribution. How did that UI end op on your display? Through 13 floppy disks. How did the React based web app end up on your display? In the blink of an eye. Distribution is key. Real artists ship.

Re: It’s time to kill the web app

#175

Post by disordinary » Sat, Sep 23, 2017, 10:04 PM UTC

ZenoArrow wrote: post #114

disordinary wrote: post #21

Earlier quoted context omitted.

Yep, also on speed: it seems to me that the microsoft office suite for instance slows down every generation despite only having minor improvements and not actually being that different now than from 95. The nature of developers is that they will use whatever resources that they have. Faster computers don't necessarily mean faster applications but faster software development cycles from bigger teams with less need for…

> "the microsoft office suite for instance slows down every generation despite only having minor improvements and not actually being that different now than from 95" I can't comment on most of the Office suite, but Excel evolved quite a bit since 95. Tables, PowerBI, Apps for Office, etc... If your needs are basic enough then even VisiCalc will do the job, but new features do make an impact for more demanding users.

That's not the point though. The example given in the article was Google Docs which has the same UI paradigm to Word. Under the hood it's massively different obviously with real time collaboration and constantly up to date syncing.

So, the reasoning is that UI is fundamentally the same (or worse if not done right) to native UI from the 90's, yet it hasn't had a massive speed increase which seems wasteful.

But modern UI in Office is only an evolution of what was there in the 90s and hasn't changed fundamentally either yet it doesn't feel any faster.

UI is only a small part of an app, a well designed app will have most of the work performed outside of the UI thread and it shouldn't feel any slower than a native implementation. My thoughts are rendering speed isn't the issue but application design.

Re: It’s time to kill the web app

#176

Post by goatlover » Sat, Sep 23, 2017, 10:05 PM UTC

Kwastie wrote: post #97

JoshMnem wrote: post #41

The article doesn't make sense without an alternative. What open standard is being proposed to replace the open WWW? Mobile apps and app stores are not a replacement for the open Web, and it can't reasonably be argued that locked-down mobile devices loaded with craplets and no root access are better than the WWW.

I agree, this article doesn't make any sense without proposing an alternative. Sure, I think most people would agree that the web is still a bit rough for (large) apps. (compared to desktop apps) But nothing that can't be fixed, right? I can't imaging that native phone apps will still be popular in 10 years. I think that they will be replaced by the web in a similar fashion as web-apps have replaced desktop apps.

There are still popular desktop apps. Native Office is still used widely despite Google Docs and web versions of Office. Adobe applications are still widely used. Most programmers use desktop editors and IDEs. I use a lot of the Mac applications.

Re: It’s time to kill the web app

#177

Post by a-dub » Sat, Sep 23, 2017, 10:05 PM UTC

annoying clickbait title and irrelevant trolltastic comparison to '90s windows garbage designed to incite anger.

1) yes, large webapps are hard to secure. but they're also infinitely easier to patch.

2) yes, the fact that google just shits out random things so people can get promotions (SPDY, NaCL, whatever) and it becomes a thing is a problem. this was not how the decentralized web was designed... but that doesn't mean that it's "time to kill the web."

Re: It’s time to kill the web app

#178

Post by SwellJoe » Sat, Sep 23, 2017, 10:05 PM UTC

ZenoArrow wrote: post #160

SwellJoe wrote: post #32

Earlier quoted context omitted.

How do you measure that, though? It seems like you have to ignore all value derived from networks in order to come to the conclusion that software is no more powerful than in the 90s. In the 90s I couldn't have met with my team, with members in Moscow, California, Pennsylvania, and Texas, in any reasonable way...today I can chat, including video and sound, on a whim! Managing source code today is massively more produ…

The Internet != The Web. Many of those benefits you listed are linked to the growth of the Internet. Package managers, video conferencing, distributed version control, all mostly Internet-based. The web is just one part of Internet activity. It's the part that requires use of a web browser. If you can do something online without using a web browser it's because of the Internet. The criticisms that are being levelled…

I get that and tried to make it clear that I get that, particularly in the paragraph about npm; Perl has the CPAN, Python has had a half dozen package managers (I don't even know which one finally "stuck"), Ruby has gems, but nothing exploded the way npm did. So, what's different? I would argue it's not that JavaScript is a better language (though it's a pretty strong language today). I would argue that it's a better platform, and that platform, ultimately, is the web.

Every package manager works over the internet. Only one represents the web-as-a-platform. And, it turns out that's the one that has dwarfed all others in size and scope, in a quite short time. Nearly everything I mentioned above requires the internet for interconnectivity, sure, but also a platform that delivers it to the user. Any platform for building apps that fails to deliver at least as much as the web will never be as successful as the web.

Edit: Also, desktop apps have had the Internet for decades. What have they done with it?

Re: It’s time to kill the web app

#179

Post by da02 » Sat, Sep 23, 2017, 10:08 PM UTC

mikebenfield wrote: post #20

It's probably not realistic, but I would love to see the web be completely thrown out and replaced with something reasonable. I write a decent amount of native code. I write Rust, C, and x64 assembly. I think I'm pretty good at this stuff. But the web is too much for me. Any time I think I'd like to do something with the web and sit down to learn, it's completely overwhelming. I've never been able to put together a c…

I felt the same way yesterday about writing a little app to position X windows in preconfiged positions.... in Crystal using C bindings. I would have to learn C, make, xlib, and a while bunch of other things just for a simple, non-buggy executable. I just gave up and decide to keep using Crystal and make external POSIX (ie shelling out) calls to the compiled wmctrl executable.

Re: It’s time to kill the web app

#180

Post by Pxtl » Sat, Sep 23, 2017, 10:09 PM UTC

clarry wrote: post #171

Pxtl wrote: post #57

Earlier quoted context omitted.

But the problem is that the server is deciding for the user. If they want to show me sketchy ad content, they can go fetch it and send it to me as part of my request to them. Don't tell me to go get it myself. If an ad server is malicious, let it be the web server that has to deal with them, not me.

So suppose they go and fetch these malicious ads and forward them to you. Now you get that malware directly from the first party. The malware has all the same-origin access as the first-party application, and you can't trivially block it with things like uMatrix. That's what I call server deciding for the user. And now you're in real trouble with security.

Yes, but then the malware can also compromise the server, since it now has js access to all the users and can Masquerade as them when they see the ad - even as admins. Keys to the kingdom. This is a feature, not a bug - it means the user and the server are now in the same boat, and the server will have some friggin diligence about whose code they run.

Also, means the server has to pay for the damned bandwidth.