Live data from Hacker News

It’s time to kill the web app

blog.plan99.net

651–660 of 717 posts

Re: It’s time to kill the web app

#651

Earlier quoted context omitted.

I'm not sure what the argument you're putting forth is. All of the HTML-generating tools I'm aware of (barring dumb string templating tools) work sufficiently well and prevent human error. My point is that there's nothing wrong with HTML. HTML isn't a tool, it's a format for storing and transmitting hypertext. If you're using React or HAML or any of the other HTML-generating tools, you're effectively immune from XSS.…

The prevalence of XSS suggest that the web ecosystem has failed to produce the sort of tools you suggest. If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation. However, no such tool exists. I think there's a deeper issue here: the sheer number of ways you can generate XSS alone, even ignoring the other exploit types, is far beyond wha…

> If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation.

I think you're missing another two obvious explanations:

1. Lack of education when picking a tool (copy paste from bad SO answers is a frequent source of bad code).

2. Developers don't care. If it works, why bother wrapping your head the rest of the way around to understand why it works or whether it's secure?

> By itself, it is not an XSS. But if the backend is/was running Ruby on Rails (presumably some old version by now) then it could turn into an XSS due to a combination of features that all look superficially harmless.

Sure, ERB before RoR essentially had security turned off by default (as I noted). And this issue could happen with any other non-web system, turning into any other kind of vulnerability. This isn't a web problem, it's a system security problem. Bad inputs in a "native" app could lead to security issues in the output of apps on other devices. Badly implemented binary data decoders in a desktop application could do far worse than a XSS in the browser.

This problem is misattributed as a "web problem" because there are far more complete systems on the web than there are on nearly any other platform. It's like the tired argument that Mac is more secure than Windows, but Windows has historically had an overwhelmingly outsized market share, making OS X issues far less valuable to attackers.

> When I argue that the web is unsafe by design, it's because cases like that aren't rare, they're common.

I don't disagree that these issues are common, but I disagree that the web is unsafe by design. The web is a platform. If everyone wrote their Python APIs without a framework, I can guarantee they would be littered with security holes. If everyone wrote their own text renderer in C++, just displaying strings on the screen would be a dangerous task.

There are good tools that make it really hard to fuck up on the web. Seriously, try to accidentally have a XSS vulnerability in an isorendered React app with Apollo. The problem is folks that want to jQuery-jockey their way across the finish line and don't understand that they are making terrible mistakes.

Re: It’s time to kill the web app

#652

Earlier quoted context omitted.

Agreed. And yes, that needs some attention, but most people doing responsive web do not account for most of that either. What does changing fonts mean? You design something for a font and then change it afterwards or? When I click on some languages (I am not native English and my native language, Dutch, is not very high on the list of priorities for most companies) in some of the biggest companies in the world, you n…

I used to write Petzold-style Win32 apps. I've also written native Cocoa apps as recently as last month, and I've used Qt and GTK+. Having experience with all of these, my preference is still for Web apps, because of the ease of portability and the fact that TypeScript beats C++ for ergonomics, safety, and ecosystem (just having a package manager is huge, even if NPM leaves something to be desired). I find it fun to…

When I started coding for Win16, my first option was Turbo Pascal with OWL, eventually I started to use Turbo C++ with OWL.

With the switch to Win32, the tools became VB, Delphi, Smalltalk and Visual C++ with MFC.

Like every Windows developer I also own the Petzold book, bought for Window 3.0 development, and other good one from Sybex, probalby the one book that ever explained how to properly use STRICT and Message Crackers introduced with WIndows 3.1 SDK.

However I might have written about five applications in pure Win32 API instead of using one of the former language/frameworks, as requirement for university projects.

In general, I think many developers only have the bare bones native experience without making use of proper RAD tooling, or the UNIX way, which has always been pretty bad in tooling for native GUIs versus Mac and Windows or even OS/2.

Re: It’s time to kill the web app

#653

Earlier quoted context omitted.

> it has basically zero understanding of flexible layouts. That's largely a non-issue to me. If I need anything fancy, I'll draw it myself. The simple stuff ought to be simple. > As a result, things break as soon as you try to make an easily resizable window Au contraire! It is much easier to make a resizable window when you are in full control of how nested widgets are resized along with it. That being said, some au…

Again, "anything fancy" here includes something as simple as a localized dialog. In most commercial apps, this means pretty much everything would require "drawing it yourself". At which point you can basically throw the designer away, since you'll be writing code to manage layout for all widgets anyway.

Even Windows Forms has a layout manager with data binding, but devs have to explicit take advantage of it, there is no need for "drawing it yourself".

Re: It’s time to kill the web app

#654

Earlier quoted context omitted.

True, assuming that programmers don't compute code (HTML,SQL, etc) from user input and miscompute the length of a fragment. It would be interesting to see if this idea could work in practice.

This isn't some theoretical design. Any native application that uses a binary protocol framework like protobufs over TCP to communicate with the backend will benefit from this approach.

> protobufs over TCP

I guess it would have to be protobufs over TLS, and abuse port 443, to get through firewalls from hell.

Re: It’s time to kill the web app

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

> 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. No that's only half the solution, the other (much harder) half is to ensure you have no XSS. The GP's point was if they hadn't allowed cross-origin scripting it would have had big security benefits.

Set the Content-Security-Policy in the HTTP response.

Re: It’s time to kill the web app

#657

Earlier quoted context omitted.

IntelliJ has multiple IDEs for web development, or programming text editors like VS Code and Sublime. Even Chrome allows for a very fluid editing and debugging experience. Half the time I write my code directly in the browser.

I had in mind IDE with visual layout in a live environment such as Chrome's dev tools.

The live environment is the page. You can tweak any CSS value and have it update live, or save to a file. You can run breakpoints to examine code execution, examine call stacks and use the console for input and output.

It's really no different from developing in IntelliJ or similar. The only difference is you don't need to hit "compile" first.

Re: It’s time to kill the web app

#658

Earlier quoted context omitted.

Very few web apps actually use the same HTML for desktop and mobile. It's more common for WordPress templates and other document-like things, but the UI constraints on a phone are so different that it's better to create a dedicated UI for them. So I'm not sure judging VB6 by that metric is valuable.

It's not just mobile though - it's different dpi (4k screens are getting more popular), window sizes and zoom levels. Mobile is probably not a target for the forms apps the OP is talking about, but tablets may be, and different generations of various laptops and PCs are. Web works across everything with little to no extra effort, whereas native app built with WYSIWYG UI builder is going to be constrained to certain h…

HiDPI was pioneered by Apple whose UI toolkits aren't particularly responsive at all.

You can certainly handle different window sizes with traditional UI layout managers. The only thing they don't do much of is totally changing the entire UI layout based on window size, and that's only because it's so rare to have a single app that's actually identical between tiny and huge screens.

Re: It’s time to kill the web app

#659
"So unless you work at Google or Microsoft you can’t meaningfully impact the technical direction of the web"

If this is truly what you believe. You are the problem. Killing the current system does not solve anything, proposing a solution and building it does.

Re: It’s time to kill the web app

#660
post #345
post #177

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 m…

You seem to be conflating the web with webapps.

nope.
Post reply on HN