Hacker News Reader

Comment by surrealize | Hacker News Reader

pdf.js was a pretty cool hack, but I wonder if it's time to integrate pdfium.

edit: I meant "hack" in the "cool application of technology" sense.

Moving from code inside the browser sandbox to code outside the browser sandbox seems like a bad idea. (Chrome's integrated PDF support runs in a sandbox despite being native code, but Firefox doesn't have equivalent native-code sandboxes.)

Moreover, I'd take sandboxed JavaScript over sandboxed native code any day, given the complexity of modern browser IPC and how much kernel surface area tends to be exposed even to sandboxed processes on Windows and Mac.

Modern browser IPC is what backs JavaScript as well as sandboxed native code, so that's not going to save you. Windows/OSX issues aside, on Linux I'm more comfortable with seccomp-bpf than with a sandbox that's based solely on assuming an absence of security holes in a JavaScript virtual machine.

Oh, I don't want to argue that unsandboxed JavaScript—and by this I mean unsandboxed at the OS level—is more secure than sandboxed C++. (Now I think there's a reasonable case that it is when compared to the sandboxes on Windows/Mac, but that's debatable and I'm certain that people with more expertise in security than I have disagree with me.)

My point is that I prefer having the JS VM and the OS-level sandbox, as opposed to just the OS-level sandbox.

Regarding IPC, I think there's a difference in terms of surface area between being able to call the Web APIs and being able to send arbitrary bytes (and shmem, etc.) across the named pipes/file descriptors.

That would be the wrong conclusion to draw from this exploit. PDFium has had vulnerabilities too.

PDFium wins on functionality and performance; I thought pdf.js won on security but this vulnerability makes me wonder. If PDFium and pdf.js are on par (or even close) security-wise, in my view that tilts the tradeoff toward PDFium.

Do not mentally categorize software into "has never had a vulnerability" versus "has had vulnerabilities" buckets. Especially for software as widely used, and as closely scrutinized, as browsers.

> Do not mentally categorize software into "has never had a vulnerability" versus "has had vulnerabilities" buckets.

Right. Software that has never had a vulnerability is either 1) software that has never had careful scrutiny, 2) software that has no potential security implications whatsoever, or 3) software that has gone through some formal verification and proof process (exceedingly rare).

I don't think I did. Security is obviously not a black-and-white thing, and my words "on par" and "close" are entirely consistent with a shades-of-grey view.

Nonetheless, the posterior distribution shifts based on new evidence.

Are you making a claim about which one is more secure? I'm genuinely curious about how they stack up against one another. pdf.js is obviously managed code, which I'm sure helps. But it also seems like it has less person-power behind it, now and historically. Do you agree with that perception? Why or why not?

I don't know how many people work on PDFium.

But I don't think that it's particularly relevant to security whether 3 people or 30 people work on a project. Both Chrome and Firefox are fully maintained with top-notch security teams.

Reply on news.ycombinator.com