Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

241–250 of 717 posts

Re: It’s time to kill the web app

#241
If, as the article (and much of this thread) seems to suggest, the problem we are trying to solve is

1) Serving a GUI application to multiple users in a way that they can trust

2) Maintaining up to date versions without client side updates

3) Storage of data on a remote server over the internet, enabling saas etc.

4) Easier GUI development using an IDE.

This points to needing something more akin to Citrix/RDP/Terminal services. Run full blown GUI apps on the server and serve an image of them over the network. This needn't be as bloated as the MS implementation, but seems to solve those issues above

Re: It’s time to kill the web app

#242

Earlier quoted context omitted.

Yep. Databases, web frameworks, GUI frameworks, editors, concurrency models, social networks, photo-sharing sites, and consumer reviews as well. Outside of computers, it applies to traffic, airlines, politics, publicly-traded companies, education & testing, and any industry related to "coolness" (fashion, entertainment, and all the niche fads that hipsters love). I refer to these as "unstable industries" - they all e…

How do we fix this?

That's not a million dollar question but one worth several 10's or even 100's of billions. If you can find the answer to it you'll push us across the hump and away from this local oscillating maximum.

Re: It’s time to kill the web app

#243
post #180
post #171

Earlier quoted context omitted.

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.

That's not how it works, the server wouldn't execute JS that is meant for a browser client, it would just serve it like any other static file.

What you're suggesting will actually hamper security, because scripts served from your domain have less limitations(see https://en.wikipedia.org/wiki/Same-origin_policy , https://en.wikipedia.org/wiki/Content_Security_Policy and other mechanisms)

Re: It’s time to kill the web app

#244
post #215
post #122

Earlier quoted context omitted.

How did gmail back then differ from hotmail or Yahoo mail? I was using both in the late '90s/early '00s.

Gmail was first massively used single page web application. Somewhat ironically it was built on top of technology meant for Outlook Web Access (ie. XMLHttpRequest as ActiveX component in IE and as an DOM extension in Gecko). AJAX is name that was conceived to describe that approach to webapps, with the somewhat funny fact, that google at the time described it as javascript (from time to time with the addendum: "done…

Funny thing about AJAX is that this acronym means nothing. Asynchronous JavaScript? Well, JavaScript was always asynchronous. And XML? What does it have with XML?

Re: It’s time to kill the web app

#245

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…

"Most web apps are built in languages that don't have buffer overrun problems."

You misunderstood the author's point. Things like SQL injection are really equivalent to buffer overflow attacks -- data creeping into the code because of poor bounds checking.

Re: It’s time to kill the web app

#246

Earlier quoted context omitted.

I don't really understand. You say that the web needs to be completely thrown out, yet you decided that your foray into web development should be to build a thick Javascript web application? Not some simple Flask endpoint? Because I assume you could figure out a basic request/response server, and your issue is that you dove into something like Webpack + React + Flux + Qux + Fux + Foo.

> Not some simple Flask endpoint? I don't even know what a "Flask endpoint" is. Actually I barely know what Webpack and React are either.

Flask is a Python framework for web servers. It's like 5 minutes to a HelloWorld webpage

Re: It’s time to kill the web app

#247
post #234

Earlier quoted context omitted.

C is not impossible to secure, actually. There are popular C programs which are more robust than your average high-level dynamic language program. It takes a deep commitment (hence a lack of good examples), but there is generally a clear path to a well-behaved program in C, and there's nothing about C itself which prevents you from writing secure code. On the web, you must actively mitigate pitfalls of the platform i…

How many really truly secure C programs have ever been released into the wild? Maybe qmail? But qmail did it by completely rewriting the C standard library.

Admittedly few, but generally in native land you have the ability to plaster over platform deficiencies with equally-well-performing code. On the web, you can never really compete with the execution speed or integration of the native code in the browser, so you have to accept whatever is there.

I'd say OpenSSH (since SSH2) has a better track record than most webapps, as unfair a comparison as that is. In terms of local robustness, there's SeL4, which is also a bit unfair (since it took about a decade for a team of geniuses to prove enough properties to make it probably not very buggy).

Re: It’s time to kill the web app

#248

Earlier quoted context omitted.

My alarm siren went off when the commentary started critiquing the “complexity” of Google docs as compared to Windows explorer circa 1998. Complex things are often complex because the work that we do as humans is, well, complicated. A journey map painstakingly built by an epic designer and smart person at large may design the ultimate document template that addresses every need that you are aware of. Then I come alon…

Your alarm shouldn't go off, because the example is very much apt. The article compared the UI offered by both, and they are indeed directly comparable. As for the work Google Docs do, come on, they're a glorified Markdown editor, they lose in any kind of comparison with Windows 95-era Word.

How do two people edit a document in Windows-95-era Word?

LaunchPlan2017Q4Final4Draft1Beta.doc with Track Changes on.

Re: It’s time to kill the web app

#249
post #116

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…

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. Back then the compilers sucked. They would take complete crap of code and still it would work. They were like browsers are today. (from my experience from going through one old MUD code) Today the song is different. Not only will the compilers warn you of many things, there's even tools for static analysis (and dy…

People always shit on C for security, perhaps rightly so. But I would like to point out that 99% of everything out there has C or C++ at its base. cpython is c, java is C++, rust is based on llvm which is C++. Yes implementing your user facing application in some non-c language may improve security, but you are still depending on C when you do so.

So is C the problem, or is it modern CPU architecture? C has stuck around for so long because of how close it is to assembly language. There will always be a need for a language that is one layer above assembly, and currently assembly is incredibly hard to secure.

Re: It’s time to kill the web app

#250

Earlier quoted context omitted.

Yep. Databases, web frameworks, GUI frameworks, editors, concurrency models, social networks, photo-sharing sites, and consumer reviews as well. Outside of computers, it applies to traffic, airlines, politics, publicly-traded companies, education & testing, and any industry related to "coolness" (fashion, entertainment, and all the niche fads that hipsters love). I refer to these as "unstable industries" - they all e…

How do we fix this?

You make the perfect product

You strive for excellence

You keep improving

Like Jiro did with sushi

And then the product dies with you

Post reply on HN