4 ms·

HTML is capable of a dynamic interface, but it must be statically defined. With HTML5 we even have videos. The linked webpage including video work like a charm

by madez 9y ago

HTML is capable of a dynamic interface, but it must be statically defined. With HTML5 we even have videos. The linked webpage including video work like a charm with JavaScript disabled. Furthermore I'd welcome a HTML6 as long as it stays non-programmable, and don't see why it shouldn't be able to be a low-latency interface. The interface of the linked video feels very snappy. I agree that HTML-only GMail in the browser right now is a mess, but that's because a browser is not an e-mail client, and shouldn't be one. People are trained for certain behaviours and often don't want to change from that. On the other hand they like new shiney software and things to try out. That explains in my eyes why for example Google Docs (seriously, office editing in the browser?!) is used. Also, Google has a good reputation for software. I think most people are simply not aware of the dangers, downsides and alternatives of this approach. The behaviour was learned when people talking about a globally snooping NSA were called crackpots. On top of that, Google has no business interest in offering a standalone office solution, so people either use Google Docs in their browser, or not at all. Supply creates its own demands. How discoverability and ease of obtaining trusted code is solved, is a technical problem. I could imagine markup-only webpages which can call locally installed programs to appear in the tab, but the prorams are installed in trusted ways. That's just one spontaneous idea. Mozilla is making it easier for people to use technical solutions that are suboptimal for them. This has a network effect and shapes the web to be a worse place. That is what I accuse Mozilla of, and I stand by it.

kentonv 9y ago
> HTML is capable of a dynamic interface HTML is capable of very specific, fixed functions. Sure, video is one of them. But video is not very interactive. You press play, and then you watch. Interactivity in plain HTML is very difficult. > People are trained for certain behaviours and often don't want to change from that. On the other hand they like new shiney software and things to try out. No no. People don't use these products because they were "trained" for it. The world of installed native applications existed before the web. The web took off because it's actually way better for many people. Not having to manage installing apps is awesome. Being able to access your data from multiple devices trivially is awesome. Not having to worry about backups is awesome. Being able to collaborate in real time is awesome. People don't just like this stuff because it's "shiney", they like it because it's really, genuinely useful. > I could imagine markup-only webpages which can call locally installed programs to appear in the tab, but the prorams are installed in trusted ways. That would actually be way less secure, because those locally-installed programs are almost certainly not security reviewed to the extent that the JavaScript sandbox is. They are far more likely to have exploitable bugs than your JavaScript sandbox. It doesn't matter that you "trust" them. In practice, the vast majority of programmers do not know how to write secure code. We can't realistically fix that. The answer is to give them programming environments where they can't get it wrong, or at least they can only hurt their own app. We accomplish that with sandboxing.
- madez 9y ago
  Starting and stopping a video is an interactive action. Even a drop down menu is interactive. Arbitrary interactivity may not be possible, but I think that is totally acceptable for what we are talking about: remotly delivered, unaccounted, unreviewed and directly and automatically executed code. That the local and native programs are not as good as the browser-based abominations is no argument for that technology; there are reasons for the businesses to choose this way despite (or because) how bad it is for users. Code that comes for example from a distribution is signed and maintained by someone I can easily identify. It is looked at by more than the author. I can track the path of the code backwards, if something nefarious happens. That justifies trust in that code. The comparison of that code with the JavaScript sandbox is invalid, it's to be compared with the delivered JavaScript. There is no reason why even trustably delivered code shouldn't be sandboxed. The comparison of that sandbox with the JavaScript sandbox would be apt. I agree that sandboxing is important, even for local programs.
  - kentonv 9y ago
    OK, I'm glad we agree that native apps ought to be sandboxed too. Unfortunately no major desktop OS does a good job of this yet, which is why, realistically, today, choosing web apps over native apps actually makes your system more secure. Maybe that wouldn't be true in an ideal world where desktop apps were sandboxed as heavily as web apps. But you're still in denial about the fact that web app delivery is hugely valuable to a lot of people (yes, to users). This isn't even remotely debatable. SaaS is now a $100B/yr industry and growing rapidly. People wouldn't be rapidly replacing locally-installed apps with SaaS if they didn't really want it. You really can't just proclaim that everyone should give all that up based on your ideology about how software "should" be delivered.
    - madez 9y ago
      I think we don't contradict each other necessarily. JavaScript applications not delivered by websites but through the package manager would be okay for me. We would have the sandbox on one side and the accounting and responsibility on the other side. After all, even the JavaScript sandbox (FireFox) itself is delivered how I think software should be delivered. The size of the market is no argument. Supply drives demand. I don't simply proclaim how things should be done. I point out problems, criticize the status quo based on sound facts, and point to better solutions. What else do you suggest?
pfalcon 9y ago
Hat's off! I'm astonished that people like this still exist. I really have no idea under which rock and in which tinfoil hat they still survive. But we need more such people, so please keep your windmill-fighting. In the meantime, before they deliver "non-programmable HTML6", they deliver HTML 5.2 (or was it .3?) with DRM inside. Mozilla? They produced buggy, resource-hungry browser for decade (was less resource-hungry than competition, now the same). What to expect from them? These Xmas time, when opening a new empty browser page, they show an ad phishing me for money. And that's exactly what everyone expects from them. The stories about HTML with DRM and unsolicited adds from Mozilla were discussed here on HN. So again, no idea what tinfoil hat you wear, but godspeed with keeping it up.

by madez 9y ago

kentonv 9y ago

> HTML is capable of a dynamic interface HTML is capable of very specific, fixed functions. Sure, video is one of them. But video is not very interactive. You press play, and then you watch. Interactivity in plain HTML is very difficult. > People are trained for certain behaviours and often don't want to change from that. On the other hand they like new shiney software and things to try out. No no. People don't use these products because they were "trained" for it. The world of installed native applications existed before the web. The web took off because it's actually way better for many people. Not having to manage installing apps is awesome. Being able to access your data from multiple devices trivially is awesome. Not having to worry about backups is awesome. Being able to collaborate in real time is awesome. People don't just like this stuff because it's "shiney", they like it because it's really, genuinely useful. > I could imagine markup-only webpages which can call locally installed programs to appear in the tab, but the prorams are installed in trusted ways. That would actually be way less secure, because those locally-installed programs are almost certainly not security reviewed to the extent that the JavaScript sandbox is. They are far more likely to have exploitable bugs than your JavaScript sandbox. It doesn't matter that you "trust" them. In practice, the vast majority of programmers do not know how to write secure code. We can't realistically fix that. The answer is to give them programming environments where they can't get it wrong, or at least they can only hurt their own app. We accomplish that with sandboxing.

madez 9y ago
Starting and stopping a video is an interactive action. Even a drop down menu is interactive. Arbitrary interactivity may not be possible, but I think that is totally acceptable for what we are talking about: remotly delivered, unaccounted, unreviewed and directly and automatically executed code. That the local and native programs are not as good as the browser-based abominations is no argument for that technology; there are reasons for the businesses to choose this way despite (or because) how bad it is for users. Code that comes for example from a distribution is signed and maintained by someone I can easily identify. It is looked at by more than the author. I can track the path of the code backwards, if something nefarious happens. That justifies trust in that code. The comparison of that code with the JavaScript sandbox is invalid, it's to be compared with the delivered JavaScript. There is no reason why even trustably delivered code shouldn't be sandboxed. The comparison of that sandbox with the JavaScript sandbox would be apt. I agree that sandboxing is important, even for local programs.
- kentonv 9y ago
  OK, I'm glad we agree that native apps ought to be sandboxed too. Unfortunately no major desktop OS does a good job of this yet, which is why, realistically, today, choosing web apps over native apps actually makes your system more secure. Maybe that wouldn't be true in an ideal world where desktop apps were sandboxed as heavily as web apps. But you're still in denial about the fact that web app delivery is hugely valuable to a lot of people (yes, to users). This isn't even remotely debatable. SaaS is now a $100B/yr industry and growing rapidly. People wouldn't be rapidly replacing locally-installed apps with SaaS if they didn't really want it. You really can't just proclaim that everyone should give all that up based on your ideology about how software "should" be delivered.
  - madez 9y ago
    I think we don't contradict each other necessarily. JavaScript applications not delivered by websites but through the package manager would be okay for me. We would have the sandbox on one side and the accounting and responsibility on the other side. After all, even the JavaScript sandbox (FireFox) itself is delivered how I think software should be delivered. The size of the market is no argument. Supply drives demand. I don't simply proclaim how things should be done. I point out problems, criticize the status quo based on sound facts, and point to better solutions. What else do you suggest?

pfalcon 9y ago

Hat's off! I'm astonished that people like this still exist. I really have no idea under which rock and in which tinfoil hat they still survive. But we need more such people, so please keep your windmill-fighting. In the meantime, before they deliver "non-programmable HTML6", they deliver HTML 5.2 (or was it .3?) with DRM inside. Mozilla? They produced buggy, resource-hungry browser for decade (was less resource-hungry than competition, now the same). What to expect from them? These Xmas time, when opening a new empty browser page, they show an ad phishing me for money. And that's exactly what everyone expects from them. The stories about HTML with DRM and unsolicited adds from Mozilla were discussed here on HN. So again, no idea what tinfoil hat you wear, but godspeed with keeping it up.