Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

51–60 of 717 posts

Re: It’s time to kill the web app

#51

the biggest security blunder of the web platform is allowing third party domains to inject code into https pages, which completely violates the trust that https is meant to establish. and it's here to stay, folks! because the entire trillion-dollar ad industry is built upon it, vacuuming up data about users across the internet. a huge amount of security and privacy issues would vanish overnight simply by requiring sa…

Absolutely, let the server go to the advertiser and fetch the ad content to push, don't make the client do it. I'd go far as to say that any content coming from a 3rd party - even images - has caused more trouble than it's worth.

Re: It’s time to kill the web app

#52

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…

That's cause the web is full of hype. Try Python Flask. A three line Python function and you are going. No magic. Just request and response. It is easy. Bang out a model class and read the SQLAlchemy tutorial. The web and RDBMS with just enough magic. Screw HTML front ends. Write the ugliest HTML you want. Never spend time in HTML. Make your app / idea work. Get your data right. Front ends and modern front end tech s…

[deleted]

Re: It’s time to kill the web app

#53
It's probably not possible to evaluate this post without waiting for part two, where the author says they'll outline their plan for The One True Platform, because after reading part one I come away saying "yeah, so what?".

I don't think many people working on the web platform evangelise it as the most amazing software development platform that's ever existed. But they do recognise the reasons why it has proven to be as popular as it is, and what can be done to improve it. That's why we've got WebAssembly for native code, Service Workers for offline capabilities, WebGL for performant graphics, so on and so forth. Yeah, it's scrappy, but it has much more chance of being successful than some start-from-scratch idealised standard (that will have no security vulnerabilities, naturally) that someone just brewed up.

But hey! Maybe I'm wrong. Maybe part two will blow the web dev world away. But I'm not holding my breath.

Re: It’s time to kill the web app

#54
While i understand the article and agree with it, i love programming webapps. The combination of html/CSS is much easier (for me at least) to work with than most other rendering framework, also JavaScript while not perfect is very good for fast moving target, and with "extension" like typescript you can even manage very large application in a progressive way (you can mix js and typescript).

I also work with the android layout system and a bit of the iOs one, and they are a lot more confusing, (Constraint-layout fixed a couple of problem on android recently). Currently i work manly with legacy asp.net app at work, and shiny all-js webapps at home, but i done a lot of work also with winform and android apps

Also the ability to update the app "on the fly" and be able to download only the part of the application that you need is pretty cool. Your can make your user always use the last version and quickly deploy hotfix. I understand that this are not propriety desirable for every type of application but sometimes are game-changer.

What i really want to have is a lighter implementation, i think that Facebook did something similar with is Facebook lite app.

Here's a gist with what i really want for a layout/app runtime. * Using a Url style system for retrieving resource.

* A binary protocol similar to protobuf,capnproto etc.. for talking with the server.

* A clear separation between the template and the data, so that i can cache the entire page and only request the data for populating it.

* A Module and a Permission system, with versioning (for backward and forward compatibly),maybe integrated.

* One way to store data (i personaly like key-value system, but i think a document system would be more suitable).

* A Unified syntax for html and css.

* a Component system(this is a big one), ideally the spec should only define a div-style generic container that can be specialised in a new component by adding to it, a name, style and optionally a script witch control is behaviour, (I'm not a fan of the web-component spec as it is).

What would you want from an alternative layout/runtime system for web-like app? I'm really curious!

PS: I really hope there will be more engineering post about the Facebook lite app, it seem a concept really cool that could be used for a lot of other apps!

edit: adjusting formatting

Re: It’s time to kill the web app

#55
I don't get the section on JSON, which seems to assert that XML is more secure than JSON. It does this by linking to a Wikipedia page that includes the security consideration that you shouldn't call eval on JSON. True, but at least that's a tractable problem. Your linter can check for code that calls eval.

In contrast, there are plenty of XML attacks (DOS with billions of laughs, entity references), and parsing XML is a lot more complicated, which matters a great deal if you're using non-memory-safe libraries for parsing. Also, because XML is so general purpose, you get things like libraries allowing deserialization of arbitrary objects from XML, which is a security nightmare.

That last point isn't a clean win because sometimes the same library will handle JSON and XML, and so you have to audit the use carefully. However, if you're sure that your serialization libraries only use JSON, its simplicity means that it shouldn't have that kind of deserialization vulnerability.

P.S. If you want to rag on JSON, that's fine. It's not a great format. But "it's less secure than XML" is not the tack I'd take.

Re: It’s time to kill the web app

#56

>> We desperately need a way of conveniently distributing sandboxed, secure, auto-updating apps to desktops and laptops. What's the proposal? * App stores controlled by juggernaut companies, doing the app-screening? * Signing web apps bu an authority? * Writing in "safe" languages in java/rust/..? * Java applets? * Adobe Flash? Silverlight? * Uglified, minimized encrypted JS code? * or Win95 style self-extracting ins…

Screening apps by a large company is not bad. Users don't want to guess whether the app contains malware or not. They would prefer someone do it for them.

Re: It’s time to kill the web app

#57
post #37

the biggest security blunder of the web platform is allowing third party domains to inject code into https pages, which completely violates the trust that https is meant to establish. and it's here to stay, folks! because the entire trillion-dollar ad industry is built upon it, vacuuming up data about users across the internet. a huge amount of security and privacy issues would vanish overnight simply by requiring sa…

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.

Re: It’s time to kill the web app

#58
post #18

What about the fact that the Web platform isn't owned by any one company, but is supported (to varying degrees) by every major native platform? A shiny new app platform won't have that. That's important.

In theory indeed. In practice there's 3 vendors and the standard defining organisation represents commercial interests in the platform, not you.

3 vendors is still better than one.

Re: It’s time to kill the web app

#59
post #48

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…

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

If this was the case, it would be near-impossible to write HTML by hand. And if you're writing HTML with a tool (React, HAML etc.), the tool could be doing HTML escaping correctly instead. This isn't an issue with HTML, it's an issue with human error.

Re: It’s time to kill the web app

#60

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.

Many programs in the 90s, especially of the simple CRUD type, were written in VisualBasic and other RAD tools, as they were known at the time, and later Java.

> Is this really a common problem in web apps? Most web apps are built in languages that don't have buffer overrun problems.

It's not buffer overrun in the "undefined behavior" sense, but rather problems relating to the need to parse text data, which can be tricky and susceptible to injection attacks.

Post reply on HN