4 ms·
> [...] My point is that to execute randomly downloaded code is realistically impossible to secure, practically used to deliver malware and usually used against
by afuchs 9y ago
> [...] My point is that to execute randomly downloaded code is realistically impossible to secure, practically used to deliver malware and usually used against the interests of the user of the computer. [...]
This argument has been rehashed over and over again. Some of the mass appeal of the web, as a platform, is that random arbitrary code can be downloaded and run inside a sandbox. It appears that these web technologies will continue to be used regardless of any security implications.
If users demand something like JavaScript or WebAssembly, do you have an alternative proposal to satisfy them?
- madez 9y agoRehashing an argument does not make it wrong, and continuing doing so is still important if it's valid and not considered accordingly. Users don't demand JavaScript nor WebAssembly, some developers do. Users want to easily discover new programs/games/whatever. If they were presented those equally easy and convenient in another form, they wouldn't even care. Those developers that demand JavaScript and WebAssembly have mostly interests that go against the interests of the users. The developers might want to hide parts of their code or underlying data from the user, or force presentation in a certain form (ads), or avoid the orderly way of delivering software through proven ways like distributions, possibly to achieve the former two goals. Now, where does Mozilla stand in this conflict? I realize they don't stand where I thought they would stand. I want the web, but without random drive-by code execution. Code must be delivered by other, more accounted for ways.
- userbinator 9y agoUsers don't demand JavaScript nor WebAssembly, some developers do. Exactly. One of the biggest use-cases I see for JS/Wasm is in implementing DRM obfuscation and more insidious advertising/tracking code.
- kentonv 9y ago> Those developers that demand JavaScript and WebAssembly have mostly interests that go against the interests of the users. This is stating the obvious, but... For anything even mildly interactive, JavaScript is absolutely essential to creating a good (or even bearable) user experience. With purely static HTML, every interaction requires a page reload, which is painful. Users absolutely do want modern, low-latency UX. Moreover, you literally cannot build things like Slack or Google Docs without JavaScript. Users want these products. HTML-only GMail is barely possible but it's really painful to use. Users want GMail with JavaScript. Maybe you don't want these things. Maybe you are happy with pure-HTML interfaces, or doing anything interactive through dedicated native apps. But there are very few people who prefer it that way. Please don't presume to speak for all users, or accuse Mozilla of working against users, when it's your specific needs that are unusual.
- madez 9y agoHTML 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.