7 ms·

And... ?

• lclarkmichalek 14y ago
  Something being closed source matters to some people. You might not be one of them, but other people might have different perspectives that cause them to value an open source option above a closed source equivalent.
  • siddhant 14y ago
    Yes but the masses don't care if it's open or closed source.
    • LeonidasXIV 14y ago
      No, but we should. For the masses that don't.
    • PavlovsCat 14y ago
      That the masses don't care about open source is reason to work really hard to educate them; not reason to not care either.
• gcb0 14y ago
  ... from there comes most infections on windows PCs running chrome.
  • heartbreak 14y ago
    Source?
  • benaiah 14y ago
    Actually, that would be Java.
    • iso-8859-1 14y ago
      Source? I don't believe this since so many levels of confirmation is required. I think the biggest source is the simple links to "KimKSexTape.jpg.exe".
      • benaiah 14y ago
        Source: http://www.kaspersky.com/about/news/virus/2012/Oracle_Java_surpasses_Adobe_Reader_as_the_most_frequently_exploited_software http://www.kaspersky.com/about/news/virus/2012/Oracle_Java_s... (Chrome uses its own PDF system, not Adobe Reader, so it's not even close to the threat level of Java). Java has had multiple drive-by exploits discovered in just the past few months, which by definition don't require confirmation. I was inaccurate, however. Java is almost certainly the cause of most exploits, but I daresay that user inexperience (to put it kindly) is probably the source of most infections. Touchè.
  • drzaiusapelord 14y ago
    This is ridiculous. The foxit plugin is fully sandboxed and I have not seen any exploits via any of the netsec lists I subscribe to.
    • simonster 14y ago
      With a couple Google queries, you can find out that the Chrome PDF viewer has had multiple vulnerabilities that allow code to be executed in the sandboxed environment, and that there have also been Chrome vulnerabilities that allow sandboxed code to escape the sandbox. Sandboxing is certainly a good thing, but it's not perfect. Sandboxed code still increases the attack surface. The rationale behind pdf.js is that, because it's almost entirely unprivileged JavaScript, it's unlikely that there's a way to exploit a browser in the presence of pdf.js that wouldn't work in the absence of pdf.js.
      • pifflesnort 14y ago
        The browsers themselves have also been subject to such vulnerabilities. I dare say the attack surface of a full browser implementation is much larger than just the sandboxing, and sandboxing ideally sits behind all I trusted operations in the browser, providing a single common last line of defense.
• jlongster 14y ago
  It's not just a matter of open/closed source. Bundling in yet another C binary is only going to widen the surface area for security vulnerabilities for millions of people, and there's really not a great reason to do so anymore. PDF.js proves that it's possible to write high-performance javascript to do this stuff, without introducing any security risks and it's completely cross-platform. Computers are only going to get faster, and js compilers are only going to get better too.
  • jonknee 14y ago
    But Chrome's works better and has been around (and useful for millions) for years. Perhaps they'll move to a JS solution in the future, but if I had to choose between the two right now I'd take the faster more complete one.
    • mehrzad 14y ago
      >But Chrome's works Citation needed, pdf.js has performed better for me personally than Chrome's viewer.
    • abrowne 14y ago
      pdf.js supports PDF indexes (or whatever that's called), but AFAICT Chrome's doesn't.
  • pifflesnort 14y ago
    JS-everywhere ideologues are always trying to buy a hamburger today and pay for it tomorrow. Someday machines will be faster. Someday the implementation will on par with the alternatives. How it works today is what matters to users. Tomorrow the native stack will just make use of more hardware features, it will still be faster, and we'll still be having the same conversation that we'be been having with JS ideologues for 10 years now. "Someday ..." This is what the XML ideologues used to say too. The problem wasn't XML, it was the libraries, or the lack of dedicated XML processing hardware. Then someone realized that if you got rid of the core complexity -- XML -- you could stop layering on piles of additional complexity while trying to work around the root of the problem. Someday...