A certain greenish guy is pissed off (as usual) because of this (business as usual).


Bro, you may want to try pdf.js...
Just please, if some comic book of yours comes out garbled and unreadable (can you read, BTW?), don't get mad at me, OK?

6 Responses to “HULK WANT PDF.JS”

  1. #1 Mysterious Andy says:

    I'm only posting this comment because one of the reCAPTCHA words I got on your comment form is, I kid you not, "security".

    The other is "ofindsh", which (as I understand it) is the noise securityhulk makes when he hears about overrun exploits.

  2. #2 Tom T. says:

    I see that the Slashdot thread linked pointed out that Sumatra pdf reader was 1/100 the size of the bloated Adobe reader. I've been saying for a long time, to anyone who will listen, that Foxit reader is also about the same size: 4 MB vs 400 MB for Abloate. Size = attack surface.

    I still don't understand why a pdf add-on for Firefox is needed, when Fx, without any action on my part, detected my desktop install of Foxit, and automatically uses it for web .pdfs, either to "Open" or to "Save To Disk". "Open" still allows all actions: Zoom, Print, etc.

    The add-on just adds one more possible conflict, plus more attack surface.

    I obtained an older version of Foxit that doesn't even have any support at all for JS or any other executable content.

    This was discussed at this NoScript support forum thread:

    P.S: @ Giorgio: I couldn't get the reCaptcha to show. Fx 3.6.24, NS 2.2.4rc2 on Win XP, allowed script Hackademix and api.recaptcha.net.
    In RequestPolicy, allowed requests from here to recaptcha.net, akamaihd.net, infomaction.com, and noscript.net. Session cookie allowed.

    I can see it by viewing Page Info > Media, but the box to enter it never did show on the page.

    Finally, in desperation, I allowed script and requests to my least favorite place, Google. Is this absolutely necessary?

  3. #3 Ted Mielczarek says:

    @Tom T:

    Presumably Giorgio likes pdf.js because it's written in JavaScript, and despite the fact that he wrote NoScript, that makes it more resistant to things like buffer overruns because the language simply does not allow unchecked memory access. You would be limited to trying to find exploits in the JS engine, but since the website doesn't even control the script being executed directly in this case, you're much better off.

  4. #4 Tom T. says:

    @ Ted Mielczarek:

    Thank you for the reply. In the thread linked in my previous post, one of the chief objections was that the devs were trying to promote this as the *only* pdf reader one needs, which amounts to running an app on a browser to read a pdf on the OS/HD, instead of just running an app on the OS directly.

    I'm not sure if it's the same pdf reader mentioned. I see that this one is still highly experimental, and that some pdfs may not render properly. There have been very few exploits of the non-bloated pdf desktop apps mentioned, and disabling executable support for the reader reduces attack opportunities considerably. So I would prefer to stick with the present solution for now.

    Thanks again for presenting your insights.

  5. #5 Thrawn says:

    @Tom T: When one encounters PDFs online, I think it makes sense to view them in the browser, and that's probably what the devs were assuming. For PDFs on the hard drive, yeah, something else like Foxit or Sumatra makes sense. Although I still like the idea of opening PDFs exclusively in the browser...JavaScript at least *has* a sandbox, even if it's imperfect.

    Maybe, instead of suggesting that pdf.js can replace all PDF readers, the devs should have said that it can replace all PDF add-ons?

    Also, kudos on using RequestPolicy! However, in my experience, yes, you have to allow requests to Google in order to use Recaptcha. I think Google runs it, so that makes sense.

  6. #6 Tom T. says:

    @ Thrawn:

    "Maybe, instead of suggesting that pdf.js can replace all PDF readers, the devs should have said that it can replace all PDF add-ons?"

    That suggestion would have sat much better with this writer, definitely.

    "However, in my experience, yes, you have to allow requests to Google in order to use Recaptcha. I think Google runs it, so that makes sense."

    Yes, Google owns recaptcha as of some time ago. Originally, it was a project of Carnegie-Mellon University. And I don't mind allowing recaptcha.net. You always had to anyway, even when CMU ran it.

    But Google makes you TA Google.com, something that I avoid as much as possible. One reason that I avoid it is precisely this -- everything that they get their mitts on, they have to inject their own scripting. And their geolocation is waay more precise than Firefox's; even with geo.enabled set to False, the Google script + their huge database will nail you. Wardriving, proxies... whatever happened to the original motto, "It is possible to make money without doing evil"? Down the drain...

    Anyway, surely there must be less evil Captcha services out there, or roll-your-own that can still defeat spammers. Whatever good is done by transcribing books is way overdone by the violation of users' privacy. ... and the one that changes from black b/g to white halfway through is almost impossible to read.

Bad Behavior has blocked 966 access attempts in the last 7 days.