3 ms·

Yes, that's exactly my point... There will be new platforms, but they need significantly new functionality, like being able to carry around the Internet in your

by chubot 9y ago

Yes, that's exactly my point... There will be new platforms, but they need significantly new functionality, like being able to carry around the Internet in your pocket. There's a reason Steve Jobs worked hard to get Google Search, Maps and YouTube on the iPhone, and writing a completely new web browser optimized for it. The iPhone was bootstrapped off the web to some extent, and open protocols like e-mail. (It didn't have apps in the first iteration.) Or they need a proven customer base which is willing to shell out money for games. The web is the highly unusual case, because it was not developed by a big company, but by a grass roots effort. It was a distributed RFC/Usenet-type process as far as I can tell. But the web offered significantly new functionality -- at the time nobody in the world was using networked hypertext. The ideas laid out in the post seem heavy on developer pet peeves rather than user functionality / monetary incentives. As much as it pains me to say this, security is almost a developer pet peeve, in the sense that users generally don't adopt products for security reasons. I think there's evidence they use products in spite of bad security. Of course, I would very much like a more secure web. I think it would be a worthy goal to attack only that portion, while leaving out all the rest of your proposal. As far as length prefixes, it probably makes sense for the control channel like HTTP headers, but not for the data channel like HTML.

mike_hearn 9y ago
Isn't iOS a good example of my point? Steve Jobs tried the "just write web apps, we'll keep native to ourselves" line. It was rejected by developers. I think users will happily assign some value to security if it's offered in a meaningful way. The virus-resistance of iPhones (and to a lesser extent Android) is definitely seen as a selling point by many people, mostly for the iPad. A lot of developers think users don't care about security. I think what is happening is that users aren't being offered real security. Rather, developers say "can I spend X hours this week on security" but the value delivered as perceived by the boss or customer is often very unclear and is often seen as near-zero, because people don't really believe programmers can write secure software. Additionally, security is often seen as a bottomless pit into which you can empty money forever with no perceptible difference in the product. The cost is far, far too high, and the likelyhood of being "secure" in the end is far, far too low. If a platform gains a reputation for security though, as iOS has done, then people will start to trust that programmers actually mean it when they say "we can make this secure" and users will start to care more. I think it would be a worthy goal to attack only that portion, while leaving out all the rest of your proposal. It can't be done. Otherwise I'd have made such a proposal. The web is so deeply flawed, security wise, nearly nothing can be preserved. It all has to be reset. For instance, switching to binary for the HTTP headers is already done in HTTP/2, but that hasn't had any noticeable impact on the rate of security vulnerabilities in web apps. It helps a bit: perhaps HTTP/2 is invulnerable to header splitting attacks (I'd hope so!). But the rest of the stack is still seriously flawed and that's where the bulk of the attacks are.

by chubot 9y ago

mike_hearn 9y ago

Isn't iOS a good example of my point? Steve Jobs tried the "just write web apps, we'll keep native to ourselves" line. It was rejected by developers. I think users will happily assign some value to security if it's offered in a meaningful way. The virus-resistance of iPhones (and to a lesser extent Android) is definitely seen as a selling point by many people, mostly for the iPad. A lot of developers think users don't care about security. I think what is happening is that users aren't being offered real security. Rather, developers say "can I spend X hours this week on security" but the value delivered as perceived by the boss or customer is often very unclear and is often seen as near-zero, because people don't really believe programmers can write secure software. Additionally, security is often seen as a bottomless pit into which you can empty money forever with no perceptible difference in the product. The cost is far, far too high, and the likelyhood of being "secure" in the end is far, far too low. If a platform gains a reputation for security though, as iOS has done, then people will start to trust that programmers actually mean it when they say "we can make this secure" and users will start to care more. I think it would be a worthy goal to attack only that portion, while leaving out all the rest of your proposal. It can't be done. Otherwise I'd have made such a proposal. The web is so deeply flawed, security wise, nearly nothing can be preserved. It all has to be reset. For instance, switching to binary for the HTTP headers is already done in HTTP/2, but that hasn't had any noticeable impact on the rate of security vulnerabilities in web apps. It helps a bit: perhaps HTTP/2 is invulnerable to header splitting attacks (I'd hope so!). But the rest of the stack is still seriously flawed and that's where the bulk of the attacks are.