> a meaningful number of developers are openly questioning the web platform.
And then going back to building their products. On GitHub.
Oh, wait.
It’s time to kill the web app
211–220 of 717 posts
Re: It’s time to kill the web app
#212Earlier quoted context omitted.
Yep, also on speed: it seems to me that the microsoft office suite for instance slows down every generation despite only having minor improvements and not actually being that different now than from 95. The nature of developers is that they will use whatever resources that they have. Faster computers don't necessarily mean faster applications but faster software development cycles from bigger teams with less need for…
Just imagine how slow MS Office could be as a web app.
Imagine? With wasm, I'm afraid you won't have to imagine in a few years...
Re: It’s time to kill the web app
#213Earlier quoted context omitted.
> if html used length-prefixed tags rather than open/close tags most injection attacks would go away immediately. That's not really the problem. The problem is there is no distinction between data and control leading to everything coming to you in one binary stream. If the control aspect would be out-of-band then the problem would really go away. Length prefixes will just turn into one more thing to overwrite or inte…
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…
It makes sure that all your code is yours and that no matter what stuff makes it into the data stream it will never be able to do anything because it is just meant to be rendered.
So abc would go as
where datum 1 would refer to the first datum in the data stream, being 'abc' and no matter what trickery you'd pull to try to put another tag or executable bit or other such nonsense in the datum it would never be interpreted. This blocks any and all attacks based on being able to trick the server or eventual recipient browser of the two streams to do something active with the datum, it can only be passive data by definition.
For comparison take DTMF, which is inband signalling and so easily spoofed (and with the 'bluebox' additional tones may be generated that unlock interesting capabilities in systems on the line) and compare with GSM which does all its signaling out-of-band, and so is much harder to spoof.
The web is basically like DTMF, if you can enter data into a form and that data is spit back out again in some web page to be rendered by the browser later on you have a vector to inject something malicious and it will take a very well thought out sanitation process to get rid of all the possibilities in which you might do that.
If the web were more like GSM you could sit there and inject data in to the data channel until the cows came home but it would never ever lead to a security issue.
No amount of extra encoding and checks will ever close these holes completely as long as the data stays 'in band' with the control information.
Re: It’s time to kill the web app
#214I wonder if there's a market for a WebApp store. Like a curated WebApp library - centralized billing, some form of vetting before apps can be listed, maybe even some apis for notifications or whatever. WebApps tested on a few major browsers and platforms before they're allowed to be listed. I'd probably be more willing to pay for WebApps if they were delivered that way.
Re: It’s time to kill the web app
#215Earlier 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.
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 right")
Re: It’s time to kill the web app
#216I wonder if there's a market for a WebApp store. Like a curated WebApp library - centralized billing, some form of vetting before apps can be listed, maybe even some apis for notifications or whatever. WebApps tested on a few major browsers and platforms before they're allowed to be listed. I'd probably be more willing to pay for WebApps if they were delivered that way.
Most consumers don't know the difference between a web app and a native app, so no one would care
Re: It’s time to kill the web app
#217The web app is the best we have. Please give us an alternative or else it's not actually time to kill it.
Re: It’s time to kill the web app
#218Re: It’s time to kill the web app
#219Earlier quoted context omitted.
> This isn't an issue with HTML, it's an issue with human error. All security issues are due to human error. Those are solved by building better tools. > If this was the case, it would be near-impossible to write HTML by hand. If, besides the text form, there would be a well-defined length-prefixed binary representation, we could simply compile HTML to binary-HTML, which would immediately made the web not only safer,…
One could build something similar by using a set of "conventional" canonical S-expressions: https://en.wikipedia.org/wiki/Canonical_S-expressions
Prefixes for character length? Is that a better choice than byte size or would it even matter?
Re: It’s time to kill the web app
#220I deleted Facebook from my iphone because i don’t want to give them that much access, and now only use their web app on my iphone. And it’s horrible . If Facebook can’t get it right, who can? My latest example is from 30 minutes ago, where I tried uploading s video; and almost gave up after 5 mins. The UI was hard to understand, extremely slow and never let me understand what was happening. Professionally I’m an iOS…
Facebook has decent incentive to move people from their web app to their mobile app.