Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

Post reply on HN
Print view View original

631–640 of 717 posts

Re: It’s time to kill the web app

#631

Post by scarface74 »

51stpage wrote: post #324
mbreese wrote: post #194

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…

SQL injection attacks are an excellent example where code and data are mixed. One solution is to do a lot of clever escaping of 'attackable' characters that instruct the DBMS to stop treating a character string as data and start executing things [1]. Escaping attackable characters attempts to partition data from code. This usually works but not perfectly. Or, run your data through stored procedures instead. It took m…

Stored procedures are bad in so many ways - they harder to deploy and revert than code, harder to unit test* , harder to refactor and every implementation that I have ever seen that has business logic in stored procedures instead of microservices/packages/modules have been a nightmare to maintain.

* At least with .Net/Entity Framework/Linq you mock out your dbcontext and test your queries with an in memory List

https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113)....

Re: It’s time to kill the web app

#632

Post by scarface74 »

mbreese wrote: post #355
thaumasiotes wrote: post #338

Earlier quoted context omitted.

> I finally figured out it was because a stored procedure does exactly what the grandparent post says: It treats all inputs as data with no possibility to run as code. This isn't well defined. Take this pseudocode stored procedure (OK, it's a python function): def retrieve_relevant_data(user_input): if user_input == 1: return BACKING_STORE[5] elif user_input == 2: perform_side_effects() return BACKING_STORE[1] else:…

> The security gain comes from replacing the full capability of the database ("run code on your local machine") with the smaller, whitelisted set of capabilities defined in the stored procedure. The security gain is that it you are only able to run queries that the DBA allows you to. If you can't write arbitrary queries, you won't get arbitrary results. If you can only run a stored procedure, you are abstracted away…

The security gain is that it you are only able to run queries that the DBA allows you to. If you can't write arbitrary queries, you won't get arbitrary results. If you can only run a stored procedure, you are abstracted away from those side effects. Another way of saying this -- the security risk is shifted from the app developer to the DBA. Someone is still writing a query (or procedure code), so there will always be some risk.

This could also be achieved with a well written microservice/package that developers go through without depending on dba.

Re: It’s time to kill the web app

#633

Post by petra »

zzzzerp wrote: post #366
petra wrote: post #257

Earlier quoted context omitted.

The web isn't the place to look for good tooling. Properiatery low-code tools built over the web are a better starting point.

I prefer no-code to low-code solutions. Good lord I hate this buzzword bingo. How the hell are proprietary low-code tools better? In what world is that a sane response?

They are simpler.

Re: It’s time to kill the web app

#634

Post by pjmlp »

gregmac wrote: post #630
pjmlp wrote: post #581

Earlier quoted context omitted.

Super easy, VB.NET with WPF or UWP layouts.

WPF is much closer to web development than the drag and drop WYSIWYG UI development (VB6 / WinForms) the OP was taking about. I've never done UWP but it sounds nearly the same as WPF.

WPF/UWP have exactly the same drag and drop WYSIWYG support as Windows Forms, specially when using Blend, actual components and an healthy market of companies selling them.

Re: It’s time to kill the web app

#635

Post by jonnytran »

TeMPOraL wrote: post #530
Fej wrote: post #433

Earlier quoted context omitted.

This might be the biggest dichotomy I've yet seen on HN. An opinion piece voted all the way to the top of the front page (with a clickbaity title, might I add), yet the top comment soundly debunks the article's arguments. Yeah, this is why everybody clicks on the comments link first.

To somewhat counter all the negative comments here - I read this article and agree pretty much 100% with every sentence in it. There are probably more people who agree with the post - hence the upvotes.

This kind of well thought out constructive criticism leads to interesting discussion and eventually improvements, even if I don't necessarily agree with it - hence the upvotes. Dissent should be welcomed, especially when it's in a well-meaning tone.

Re: It’s time to kill the web app

#636

Post by jimmaswell »

TeMPOraL wrote: post #522
naasking wrote: post #465

Earlier quoted context omitted.

> 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. If programmers paid more than lip service to responsibility, they'd push for safer languages. If programmers paid more than lip service to responsibility, the whole dumb paradigm of "worse is better" would not exist in the first place. As it is, we let the market decide, and we even indoctrinate young engineers into thinking that business ne…

The prime directive of code made for a company really is to increase profits or decrease costs, though. Most of the time just getting the job done is all that matters. Critical services and spacecraft code are exceptions.

Re: It’s time to kill the web app

#637

Post by luord »

> thesis [...] not talking about literally all web apps.

I think all my problems with this article are summed up in that paragraph. It's not so much that there're problems (there're of course) but it's just not the problems the author likes and thus goes into this exaggerating rhetoric.

Safe to say, I remain unconvinced about needing to kill the web and I'm sure whatever this guy suggests in the second part will have its own share of problems, probably even the same ones. Because, as it turns out, the web isn't that special in that area; every platform has problems, some identical.

Also, his description of the state of the art in the 90s suggests that the guy isn't that familiar with desktop development today (kind of surprising, given what the author has worked on). Safe to say, efficient binaries that run on just a few MBs of RAM is a) not what happens today or b) hasn't changed much in the last 20 years. Depending on what application we're talking about.

Also when did the web lose on mobile and when did developers "near universally" choose to write native mobile applications?

Re: It’s time to kill the web app

#638

Post by TeMPOraL »

jimmaswell wrote: post #636
TeMPOraL wrote: post #522

Earlier quoted context omitted.

> And blaming this on the market is a cheap attempt to dodge responsibility. If programmers paid more than lip service to responsibility, they'd push for safer languages. If programmers paid more than lip service to responsibility, the whole dumb paradigm of "worse is better" would not exist in the first place. As it is, we let the market decide, and we even indoctrinate young engineers into thinking that business ne…

The prime directive of code made for a company really is to increase profits or decrease costs, though. Most of the time just getting the job done is all that matters. Critical services and spacecraft code are exceptions.

Yes. Which is precisely the root of the problem. Increasing profits and decreasing costs are goals of a company, not of the people who will eventually use the software (internal tools are an exception). The goals of companies and users are only partially aligned (the better your sales&marketing team is, the less they need to be aligned).

Re: It’s time to kill the web app

#639

Post by mwcampbell »

chefandy wrote: post #396
mwcampbell wrote: post #335

Earlier quoted context omitted.

You make a lot of good points. My concern, as readers who have seen some of my other HN comments may guess, is that the next time someone starts over, they'll neglect accessibility (in the sense of working with screen readers and the like), and people with disabilities will be barred from accessing some important things. "How hard can it be?", the brave new platform developer might think. "I just have to render some…

FWIW I'd consider it the opposite of selfishness to want to improve accessibility.

Selfish that, in my heart of hearts, I want what benefits me and my friends (some of them), to the exclusion of what the rest of the industry seems to pursue (churn in UI design and implementation, pursuing the latest fashion in visual design).

Re: It’s time to kill the web app

#640

Post by HaoZeke »

Security is probably not the exact same thing as it was on desktops.. However anyone who's been burned by a Javascript miner (like on the pirate Bay) or whose data is mined for ad revenue knows that the web exposes you to a series of lesser assaults which we shrug off typically. Just because breaches in privacy and security are not as flashy as waking up to a computer which won't boot doesn't mean web apps are secure.
Post reply on HN