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

351–360 of 717 posts

Re: It’s time to kill the web app

#351

Post by ksk »

SwellJoe wrote: post #12

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…

>Every negative thing said about the web is true of every other platform, so far.

What are you basing this on? You can't put Ada, Erlang, Haskell, FORTRAN, etc in the same bucket as C or C++.

Re: It’s time to kill the web app

#352

Post by bitwize »

mixedCase wrote: post #17
bitwize wrote: post #14

All the more reason to switch to Urbit. Have you accepted Curtis Yarvin into your heart as your personal BDFL yet?

As soon as it does something useful, sure. As a power user I could not be any less interested in whatever I've been able to understand Urbit does.

Sorry, forgot the '/s'. :)

Re: It’s time to kill the web app

#353

Post by wpietri »

astura wrote: post #208
addicted wrote: post #105

Earlier quoted context omitted.

A lot of the churn is because the web is so young as an application platform. It’s been less than 20years since GMail which was probably the first thing that even approximated an application on the web. Chrome was released in 2008 less than 10years ago, and it was the first time the web had a runtime engine which was perform at enough to even build an app.

There were plenty of webapps before Gmail. There was even plenty of other webmail services before Gmail and Gmail wasn't much different from the status quo. I've been using webmail since 1997 and even my University had a web interface (SquirrelMail) for those who preferred using the web interface (almost everyone). This was pre Gmail.

Really? My recollection is that Gmail was substantially different in the extent to which it was an in-browser Javascript app built around server-side data requests. That's in contrast to something where applications were a series of mostly-static pages.

At the time this change was known as AJAX, and GMail is listed as a pioneer: https://en.wikipedia.org/wiki/Ajax_(programming)

Squirrelmail, by contrast, rendered a new page for most user actions. Especially the viewing of messages.

Re: It’s time to kill the web app

#354

Post by disordinary »

wpietri wrote: post #340
disordinary wrote: post #175

Earlier quoted context omitted.

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…

> 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. Sure, and Office in the 90s didn't feel any faster than the word processing I was doing on an Apple II+ in middle school. This is because the people buying (and building) software care about other things than processor efficiency. If it's generally fast enough for their n…

Yes, so it's pointless for the author to say that a problem with Web Apps is that they're slower than native apps. It's redundant now days and a well designed web app using modern techniques should not feel any slower to an end user than a desktop app, in fact with the advanced rendering engines within modern web browsers they can feel more responsive and more usable than native.

Re: It’s time to kill the web app

#355

Post by mbreese »

thaumasiotes wrote: post #338
51stpage wrote: post #324

Earlier quoted context omitted.

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…

> 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 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.

Re: It’s time to kill the web app

#356

Post by thaumasiotes »

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…

It doesn't sound like we disagree?

Re: It’s time to kill the web app

#357

Post by jodrellblank »

leeoniya wrote: post #40
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.

i dont expect site authors to give 2 shits about security when the alternative is ad revenue. that's assuming they even understand the security/privacy implications of spending 5 seconds to add that one-liner social sharing widget. 75% of web devs wont bother to consider it and the other 24% wont care. it's the job of browser vendors to provide saftey for the masses. of course the giant conflic of interest here is th…

"We show how third-party web trackers can deanonymize users of cryptocurrencies. We present two distinct but complementary attacks."

- "When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies", https://arxiv.org/abs/1708.04748

Re: It’s time to kill the web app

#358

Post by hutzlibu »

smitherfield wrote: post #235
vvanders wrote: post #27

Earlier quoted context omitted.

Having written things targeting WASM, when you can provide me an environment like Visual Studio that has breakpoints(including data) and a debugging I can step then we can talk. Until then WASM is cool, but not nearly as productive for C++ as the native platforms.

We could've had that years ago if Mozilla had not (as all the browser vendors do depressingly often[1]) decided to torpedo NaCl for nonsensical reasons that boil down to "NIH," in favor of creating a far-inferior, crippled spec practically designed to be aimlessly bikeshedded for years. [1] Mozilla usually pulls such NIH moves to sabotage the introduction or use of languages (even DSLs) other than JS on the web. See…

Erm, "Mozilla usually pulls such NIH moves to sabotage the introduction or use of languages (even DSLs) other than JS on the web." maybe it is also because their ressources are limited and implementing a new language like dart is somewhat expensive. And NaCL even more I think.

But I actually have some anger as well on them for enforcing indexedDB and killing everything else. So now we have to use f indexedDB for storing things locally. You apparently would have prefered WebSQL, I would have liked FileAPI.

Still, I don't believe it is out of evil attempt, just limited ressources mixed with stubbornness.

Re: It’s time to kill the web app

#359

Post by 3chelon »

mch82 wrote: post #87
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…

Any chance most of the software you're writing is headless? My experience has been the opposite. I first learned C in college, and loved making command line interfaces but never understood how to make GUI applications. When I was introduced to browser hosted front-ends, laying out interfaces for GUI apps seemed a lot simpler and made a lot more sense. Python was the first language where I was able to figure out how t…

So weird. I also learned C in college, but Python I love and use exclusively from the command line; I'd choose to write GUI code in almost anything else.

But your central argument is right, that UI stuff is ignored in non-web languages at the expense of "core" concepts, and that in turn probably does lead to insecurity.

The reality is, it's historically been hard enough to find decent coders without worrying about myriad security concerns too.

Post reply on HN