4 ms·

Approximately 1% (order of magnitude) of users have JS disabled. If users wish to disable it they can, but most of the web will break. I don't particularly see

Approximately 1% (order of magnitude) of users have JS disabled. If users wish to disable it they can, but most of the web will break. I don't particularly see this as an indictment of the industry, rather, it's an indication of the risk-benefit trade-off that most people are willing to make. A little risk, a lot of functionality. Put a different way; driving is WAY more of a risk, but it doesn't seem to stop people doing it. We've mostly gotten rid of Java and Flash at this point. That seems rational. The investment in browser (and JS engine) security at this point is massive. If you've got missile launch codes on your computer or something, by all means, don't browse! (or browse with JS disabled, or use Qubes, or otherwise sandbox your browser). Realistically, at any given point in time my browser IS vulnerable - but on the other hand, my CC details and DOX aren't worth burning a reliable 0day on, so I'm cool with JS enabled.

pdkl95 11y ago
So I'll take that as yes, you insist that people must accept additional risks to red your pages. You place ease of development (or maybe unnecessary-but-shiny features) over the safety of users. > 1% That just proves my point about how widespread this disregard for safety is in this industry. Saying "but those people make broken products as well!" isn't a justification to do so yourself. > driving is off topic, and in no way comparable. I am not being forced to accept risk from driving to read document or submit a simple form. > Java and Flash Not documents. More importantly, this is another example where saying "but he did it to!" isn't a justification. > missile launch codes This is just cheap hyperbole intended to distract. > don't browse [unless you let us force risk on you] At least you admit that you agree with this ultimatum. > my browser IS vulnerable Yes, it probably is - so maybe you should start to work on fixing that situation. A good place to start would be limiting the use of the main vectors for infection... which is javascript. The paper even discusses (and I quoted) how the use of javascript enables auto-selection of attacks. > my CC details and DOX aren't worth Ahh, the "but I'm not interesting enough to be a target" fallacy, where you only consider targeted attacks.
- xyzzy123 11y ago
  I respect your opinion, but still feel that you fail to understand the fundamental nature of risk. P.S: I write browser exploits (mostly FF, I'm not pro enough to do Chrome!). Usually use-after-free. Myself and my colleagues still browse with JS on. BTW, NoScript bypass is do-able.
  - slasaus 11y ago
    Can you maybe elaborate on the main non-js vectors? I know image/video is one, is webgl/canvas maybe a big one? or webrtc? Or would you say js is by far the biggest vector? I currently browse with developer edition (daily patches) with noscript and requestpolicy to make firefox as secure as I can but I still feel using a browser, and Firefox in particular is very unsafe practice and the code is a mess. Am I right in this as far as you know?
    - xyzzy123 11y ago
      JS is by far the biggest vector. Even if you have a good bug in another component (those you listed are good candidates) you will typically need JS to massage the heap or trigger it. SVG is another good source of bugs that comes to mind. I don't think FF code quality is particularly worse than other browsers. Part of the problem is that it is simply a very large very public project. Some of the code is very old. Mainly though, they have been a bit slow to implement architectural features (e.g. privilege separation / sandboxing) which would improve resilience.

pdkl95 11y ago

So I'll take that as yes, you insist that people must accept additional risks to red your pages. You place ease of development (or maybe unnecessary-but-shiny features) over the safety of users. > 1% That just proves my point about how widespread this disregard for safety is in this industry. Saying "but those people make broken products as well!" isn't a justification to do so yourself. > driving is off topic, and in no way comparable. I am not being forced to accept risk from driving to read document or submit a simple form. > Java and Flash Not documents. More importantly, this is another example where saying "but he did it to!" isn't a justification. > missile launch codes This is just cheap hyperbole intended to distract. > don't browse [unless you let us force risk on you] At least you admit that you agree with this ultimatum. > my browser IS vulnerable Yes, it probably is - so maybe you should start to work on fixing that situation. A good place to start would be limiting the use of the main vectors for infection... which is javascript. The paper even discusses (and I quoted) how the use of javascript enables auto-selection of attacks. > my CC details and DOX aren't worth Ahh, the "but I'm not interesting enough to be a target" fallacy, where you only consider targeted attacks.

xyzzy123 11y ago
I respect your opinion, but still feel that you fail to understand the fundamental nature of risk. P.S: I write browser exploits (mostly FF, I'm not pro enough to do Chrome!). Usually use-after-free. Myself and my colleagues still browse with JS on. BTW, NoScript bypass is do-able.
- slasaus 11y ago
  Can you maybe elaborate on the main non-js vectors? I know image/video is one, is webgl/canvas maybe a big one? or webrtc? Or would you say js is by far the biggest vector? I currently browse with developer edition (daily patches) with noscript and requestpolicy to make firefox as secure as I can but I still feel using a browser, and Firefox in particular is very unsafe practice and the code is a mess. Am I right in this as far as you know?
  - xyzzy123 11y ago
    JS is by far the biggest vector. Even if you have a good bug in another component (those you listed are good candidates) you will typically need JS to massage the heap or trigger it. SVG is another good source of bugs that comes to mind. I don't think FF code quality is particularly worse than other browsers. Part of the problem is that it is simply a very large very public project. Some of the code is very old. Mainly though, they have been a bit slow to implement architectural features (e.g. privilege separation / sandboxing) which would improve resilience.