6 ms·

I think it's reasonable to consider that we should stop adding new features to the web until it's at a point where we could have at least one www that doesn't l

by nfoz 12y ago

I think it's reasonable to consider that we should stop adding new features to the web until it's at a point where we could have at least one www that doesn't leave users vulnerable. Literally every browser is unsafe, and has always been unsafe. There's zero reason this should be the case. Transferring documents online is not that hard a problem. Perhaps blinging out all the latest features for all the latest ad companies is not worth the cost to users' system security.

samspot 12y ago
Add operating systems, servers, and languages to your list for completeness. The reason they are unsafe is because they are created by humans, who make mistakes. You are basically proposing that all technology innovation should cease until these things are 100% secure.
- whichfawkes 12y ago
  We just have to accept the trade-offs of functionality. Things like airplane autopilot systems and medical equipment are probably pretty close to perfect, but that level of correctness in your browser, much less your operating system, much less your hardware - would be very costly. Even if every computer was running an operating system that was developed as carefully as equipment in charge of people's lives, I'm sure there'd still be vulnerabilities. The low hanging fruit is relative, and there'll always be people cracking computers.
- deleted 12y ago
  [deleted]
- mike_hearn 12y ago
  I think it's more like saying maybe before massively increasing the browser attack surface we should consider if it's really the right thing to do. A lot of sandbox escapes in recent years have been in very rarely used features like WebGL and Native Client. Cool tech for sure, but also big new exploit zones. The main problem is that what used to be called "mobile code" before smartphones were a thing is really convenient. That's why Java tried it too. Sandboxed code helps a lot, so there's this constant tension between trying to make the sandbox less restrictive and keeping it secure. Sometimes I think that despite poor execution the JVM guys had the right idea. Sandbox code from the net, but also have code signing to fall back on.
  - greggman 12y ago
    Care to back that up? Please list this "lot" of WebGL and Native Client exploits. AFAIK there's been < 5 total over 5 years. Compared to the total number of exploits that's certainly doesn't seem like WebGL nor Native Client are an issue. As for rarely used, I'd guess Google Maps is a pretty well used site that uses WebGL.
    - mike_hearn 12y ago
      Well, just search for "webgl cve", there seem to be quite a few. It exposes 3D drivers to untrusted code, and they can run to millions of lines of code. You're right, Google Maps is a good example of WebGL use. But it could also just be a regular desktop app. People would download it just fine.
tptacek 12y ago
That would put us at least 20 years from any new HTML features.
- whichfawkes 12y ago
  Not to mention the fact that somebody would just go ahead and implement them (security be damned), defeating the whole purpose.
- peterwwillis 12y ago
  Remind me why we need new HTML features? The web looks and works pretty much how it did 10 years ago. Almost every new feature is just a replacement for an old feature that did the same thing but not as well. We've gone from plugins to add features to building the features right into the browser. We've gone from tens of megabytes to hundreds of megabytes just to render some text and images. There is literally too much code to audit. I think even kernel hackers would have trouble understanding the complexity of modern browsers. In 20 years, do you expect the web will be significantly different than it is now? The interface might change, but you can't really innovate on text and pictures.
  - swypych 12y ago
    Can't tell if serious or joking. Although the length of your post worries me that you might actually believe what you are saying. Please check out the Bananabread example on mozilla's developer page (just search it on your favorite search engine). Please do not post such comments again, there are people on here that will not realize you're joking.
    - Dewie 12y ago
      > Although the length of your post worries me that you might actually believe what you are saying. > Please do not post such comments again, there are people on here that will not realize you're joking. What is so dangerous about someone having the opinion that HTML shouldn't get more features? This "be careful what you say"-tone is so weird to me, on this topic. > Bananabread A 3D shooter in the browser. So what? Yes there are advantages to having this power, but not everyone is going to agree that it is worth it.
ikeboy 12y ago
>Transferring documents online is not that hard a problem. Here's an idea: make your own browser that competes with Chrome for usability, offer a huge prize for anyone that hacks it. It's easy, right?
smackfu 12y ago
>Transferring documents online is not that hard a problem. Transferring is the easy part. Rendering them is the hard part.
SixSigma 12y ago
That would mean: "every program that processes user supplied data should be invulnerable to hostile input". Suddenly it doesn't sound so reasonable.
- graycat 12y ago
  For a first cut point, CP67 permitted running any code at all, including CP67, safely. At least once CP67 ran on CP67, ..., on CP67, 7 levels deep, on the IBM 360/67. CP67 was an abbreviation for control program 67 for the IBM 360/67 computer of, right, about 1967 and was developed by the IBM Cambridge Scientific Center as a means of interactive, time-sharing development of operating systems. Later commercial time-sharing services used CP67. So, could have a few dozen users, each writing whatever code they wanted, e.g., assembler since it was a good environment to make developing assembler code easy, with, as far as I know, no user ever hurting the CP67 code or the work of any other user. So, right, CP67 was the first or one of the first cases of virtual machine. Its security provisions appeared to be absolute -- run any code at all, including privileged code, e.g., including operating systems, including CP67 itself, with full safety and security. Two years or so later there was Multics from MIT Project MAC. It featured capabilities and attribute control lists (still with us). As far as I know, they worked fine. For some years there was a Multics in the basement of the Pentagon and regarded as secure computing. Later Prime Computer did something quite similar and claimed that they had a prize for anyone who could break their security. Later IBM revised CP67 and called it VM, and since then it has been from common to standard for the IBM mainframe operating systems to run on VM instead of on the bare metal. There have been decades of high end production systems running on VM. I haven't heard about any security holes. As of a few years ago, a list from Microsoft of security holes fixed included at least one based on a "buffer overflow" bug. Gads: If as recently as a few years ago Microsoft still had buffer overflow bugs, one has to question if by then they much cared about computer security at all. Buffer overflow bugs -- that's Programming 101 for middle school. I just checked Firefox 35.0.1 and couldn't find where to turn off JavaScript. For the Web pages at my Web site, I have so far not written a single line or character of JavaScript and hope never to, although Microsoft's ASP.NET does write some for me -- and I do wish I knew what ASP.NET classes or options I used to cause Microsoft to write any JavaScript for me. The old first rule of computer security was to separate code and data, and never but never let data from an untrusted source run as data. Never. Not once. For any reason. So, in light of this first rule, we have JavaScript downloaded with the HTML text and markup of a Web page and executed. So, I want a very, very, very clear, careful, rock solid, expertly reviewed, as close as possible to proofs of correctness evidence that it is impossible, absolutely, positively totally, without any possibly of exception, for code, any code at all that could possibly exist, in JavaScript that could cause my computer any problems at all, and otherwise just block it. Nothing to do with it. Dump it. Computer viruses have cost me about half my time so far this year, and I want nothing to do with more computer viruses. JavaScript? Totally glad to junk it. As I recall, not so long ago, Firefox had Java enabled by default! Outrageous. And at times in Microsoft's Internet Explorer had to be careful to disable Active X, which could run any code at all. JavaScript? I want nothing to do with pull downs, pop-ups, roll-overs, the screen jumping around for no good reason, etc. Just HTML and CSS -- fine with me. HTML was just a word-whacking mark-up language -- fine. But, yes, for user input it has text boxes, multi-line text boxes, check boxes, and radio buttons. Okay. Should be able to implement those safely enough. Can we start to take computer security seriously? When are we going to start? E.g., Microsoft has gone from Windows NT to 2000, XP, Vista, 8, 8.1 etc., but where in there is the solid security? They have the Start button, remove it, put it back, the Metro interface, tablets, phones, etc., but what about computer security? I don't give even one weak little hollow hoot about touch screens, but I care a lot about computer security.

by nfoz 12y ago

samspot 12y ago

Add operating systems, servers, and languages to your list for completeness. The reason they are unsafe is because they are created by humans, who make mistakes. You are basically proposing that all technology innovation should cease until these things are 100% secure.

whichfawkes 12y ago
We just have to accept the trade-offs of functionality. Things like airplane autopilot systems and medical equipment are probably pretty close to perfect, but that level of correctness in your browser, much less your operating system, much less your hardware - would be very costly. Even if every computer was running an operating system that was developed as carefully as equipment in charge of people's lives, I'm sure there'd still be vulnerabilities. The low hanging fruit is relative, and there'll always be people cracking computers.
deleted 12y ago
[deleted]
mike_hearn 12y ago
I think it's more like saying maybe before massively increasing the browser attack surface we should consider if it's really the right thing to do. A lot of sandbox escapes in recent years have been in very rarely used features like WebGL and Native Client. Cool tech for sure, but also big new exploit zones. The main problem is that what used to be called "mobile code" before smartphones were a thing is really convenient. That's why Java tried it too. Sandboxed code helps a lot, so there's this constant tension between trying to make the sandbox less restrictive and keeping it secure. Sometimes I think that despite poor execution the JVM guys had the right idea. Sandbox code from the net, but also have code signing to fall back on.
- greggman 12y ago
  Care to back that up? Please list this "lot" of WebGL and Native Client exploits. AFAIK there's been < 5 total over 5 years. Compared to the total number of exploits that's certainly doesn't seem like WebGL nor Native Client are an issue. As for rarely used, I'd guess Google Maps is a pretty well used site that uses WebGL.
  - mike_hearn 12y ago
    Well, just search for "webgl cve", there seem to be quite a few. It exposes 3D drivers to untrusted code, and they can run to millions of lines of code. You're right, Google Maps is a good example of WebGL use. But it could also just be a regular desktop app. People would download it just fine.

tptacek 12y ago

That would put us at least 20 years from any new HTML features.

whichfawkes 12y ago
Not to mention the fact that somebody would just go ahead and implement them (security be damned), defeating the whole purpose.
peterwwillis 12y ago
Remind me why we need new HTML features? The web looks and works pretty much how it did 10 years ago. Almost every new feature is just a replacement for an old feature that did the same thing but not as well. We've gone from plugins to add features to building the features right into the browser. We've gone from tens of megabytes to hundreds of megabytes just to render some text and images. There is literally too much code to audit. I think even kernel hackers would have trouble understanding the complexity of modern browsers. In 20 years, do you expect the web will be significantly different than it is now? The interface might change, but you can't really innovate on text and pictures.
- swypych 12y ago
  Can't tell if serious or joking. Although the length of your post worries me that you might actually believe what you are saying. Please check out the Bananabread example on mozilla's developer page (just search it on your favorite search engine). Please do not post such comments again, there are people on here that will not realize you're joking.
  - Dewie 12y ago
    > Although the length of your post worries me that you might actually believe what you are saying. > Please do not post such comments again, there are people on here that will not realize you're joking. What is so dangerous about someone having the opinion that HTML shouldn't get more features? This "be careful what you say"-tone is so weird to me, on this topic. > Bananabread A 3D shooter in the browser. So what? Yes there are advantages to having this power, but not everyone is going to agree that it is worth it.

ikeboy 12y ago

>Transferring documents online is not that hard a problem. Here's an idea: make your own browser that competes with Chrome for usability, offer a huge prize for anyone that hacks it. It's easy, right?

smackfu 12y ago

>Transferring documents online is not that hard a problem. Transferring is the easy part. Rendering them is the hard part.

SixSigma 12y ago

That would mean: "every program that processes user supplied data should be invulnerable to hostile input". Suddenly it doesn't sound so reasonable.

graycat 12y ago
For a first cut point, CP67 permitted running any code at all, including CP67, safely. At least once CP67 ran on CP67, ..., on CP67, 7 levels deep, on the IBM 360/67. CP67 was an abbreviation for control program 67 for the IBM 360/67 computer of, right, about 1967 and was developed by the IBM Cambridge Scientific Center as a means of interactive, time-sharing development of operating systems. Later commercial time-sharing services used CP67. So, could have a few dozen users, each writing whatever code they wanted, e.g., assembler since it was a good environment to make developing assembler code easy, with, as far as I know, no user ever hurting the CP67 code or the work of any other user. So, right, CP67 was the first or one of the first cases of virtual machine. Its security provisions appeared to be absolute -- run any code at all, including privileged code, e.g., including operating systems, including CP67 itself, with full safety and security. Two years or so later there was Multics from MIT Project MAC. It featured capabilities and attribute control lists (still with us). As far as I know, they worked fine. For some years there was a Multics in the basement of the Pentagon and regarded as secure computing. Later Prime Computer did something quite similar and claimed that they had a prize for anyone who could break their security. Later IBM revised CP67 and called it VM, and since then it has been from common to standard for the IBM mainframe operating systems to run on VM instead of on the bare metal. There have been decades of high end production systems running on VM. I haven't heard about any security holes. As of a few years ago, a list from Microsoft of security holes fixed included at least one based on a "buffer overflow" bug. Gads: If as recently as a few years ago Microsoft still had buffer overflow bugs, one has to question if by then they much cared about computer security at all. Buffer overflow bugs -- that's Programming 101 for middle school. I just checked Firefox 35.0.1 and couldn't find where to turn off JavaScript. For the Web pages at my Web site, I have so far not written a single line or character of JavaScript and hope never to, although Microsoft's ASP.NET does write some for me -- and I do wish I knew what ASP.NET classes or options I used to cause Microsoft to write any JavaScript for me. The old first rule of computer security was to separate code and data, and never but never let data from an untrusted source run as data. Never. Not once. For any reason. So, in light of this first rule, we have JavaScript downloaded with the HTML text and markup of a Web page and executed. So, I want a very, very, very clear, careful, rock solid, expertly reviewed, as close as possible to proofs of correctness evidence that it is impossible, absolutely, positively totally, without any possibly of exception, for code, any code at all that could possibly exist, in JavaScript that could cause my computer any problems at all, and otherwise just block it. Nothing to do with it. Dump it. Computer viruses have cost me about half my time so far this year, and I want nothing to do with more computer viruses. JavaScript? Totally glad to junk it. As I recall, not so long ago, Firefox had Java enabled by default! Outrageous. And at times in Microsoft's Internet Explorer had to be careful to disable Active X, which could run any code at all. JavaScript? I want nothing to do with pull downs, pop-ups, roll-overs, the screen jumping around for no good reason, etc. Just HTML and CSS -- fine with me. HTML was just a word-whacking mark-up language -- fine. But, yes, for user input it has text boxes, multi-line text boxes, check boxes, and radio buttons. Okay. Should be able to implement those safely enough. Can we start to take computer security seriously? When are we going to start? E.g., Microsoft has gone from Windows NT to 2000, XP, Vista, 8, 8.1 etc., but where in there is the solid security? They have the Start button, remove it, put it back, the Metro interface, tablets, phones, etc., but what about computer security? I don't give even one weak little hollow hoot about touch screens, but I care a lot about computer security.