3 ms·

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 f

by 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.

by pdkl95 11y ago

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.