It's interesting that this came, seemingly out of the blue, a little after it was made widely known (from the mozhacks article [1]) that Opera developers were working towards integrating pdf.js into their Chromium fork.
PDFium: Chrome’s PDF rendering engine is now open-source
81–90 of 106 posts
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#82I found it interesting that it seems to use Antigrain by Maxim Shemanarev in https://pdfium.googlesource.com/pdfium/+/master/core/src/fxg... (Chrome uses Skia). Unfortunately the author of Antigrain died: http://beta.slashdot.org/submission/3154635/rip-maxim-sheman... It's nice to see the fascinating Antigrain code to be used for PDF viewing every day!
Nice to hear that AGG lives on. I remember exploring it in around 2002 and being mighty impressed with it.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#83Earlier quoted context omitted.
Your arguments aren't supported by the facts: 1. It's not tied to V8. It uses V8 currently, but: - The vast majority of the code has nothing to do with JS. - Almost all of the JS-related PDF code is independent of V8. - The use of V8 is abstracted out sufficiently via IFXJS_Runtime etc that with a bit more work, a different JS runtime could be easily integrated. 2. You note that C/C++ can be sandboxed, but then claim…
> You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't. Adding more C++ to the browser certainly does increase the attack area. Sandboxes that expose enough functionality to run a modern browser engine commonly end up with holes here and there (e.g. the Pwnium vulnerabilities) and it's best to not use them as the only layer of defense; moreover,…
The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice.
Creating yet another sandbox seems silly, and NaCl hasn't been hit by pwnium, it's only been a stepping stone to the renderer (I'll let comex dive into details here!)
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#84Earlier quoted context omitted.
What about this one ? https://pdfium.googlesource.com/pdfium/+/master/core/src/fxg... "/ \ * * Copyright (c) 1998-2000, Microsoft Corp. All Rights Reserved. * * Module Name: * * Gdiplus.h * * Abstract: * * GDI+ Native C++ public header file * \ / "
Part of the Windows SDK.
Correct me if I am wrong.
I saw no evidence in the project showing that this file has BSD-style license.And since it is part of the windows SDK, it is nearly impossible to be BSD-style licensed.
Maybe it was included from foxit's code or other codebase but it is better to be put into the thirdparties directory due to the license issue.
Edited:
Thanks for pointing out my misconception about Windows SDK.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#85Earlier quoted context omitted.
> You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't. Adding more C++ to the browser certainly does increase the attack area. Sandboxes that expose enough functionality to run a modern browser engine commonly end up with holes here and there (e.g. the Pwnium vulnerabilities) and it's best to not use them as the only layer of defense; moreover,…
The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice. Creating yet another sandbox seems silly, and NaCl hasn't been hit by pwnium, it's only been a stepping stone to the renderer (I'll let comex dive into details here!)
Well, the DRM sandbox has very few exposed APIs, in contrast to the Web sandbox or Pepper.
I don't like the DRM sandbox anyhow; it's unfortunate that DRM was added to the Web, forcing a DRM module at all (speaking for myself, not my employer).
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#86Earlier quoted context omitted.
Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p I like the concept of pdf.js, but it's still significantly slower, and thus provides a worse experience to the user, than native viewers.
A large part of why PDF.js is slow is because it doesn't have text coalescing. http://www.NotablePDF.com/ is based on PDF.js and has a coalescing code in production which has improved performance substantially. It's been a significant effort on our part, and we'll be contributing it back to the PDFjs code base. Opera also has a similar coalescing effort underway by Christian Krebs.
Would you mind explaining what text coalescing is in this context?
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#87Earlier quoted context omitted.
Part of the Windows SDK.
Correct me if I am wrong. I saw no evidence in the project showing that this file has BSD-style license.And since it is part of the windows SDK, it is nearly impossible to be BSD-style licensed. Maybe it was included from foxit's code or other codebase but it is better to be put into the thirdparties directory due to the license issue. Edited: Thanks for pointing out my misconception about Windows SDK.
The SDK has a very permissive license (including redistribution), since it's obviously designed to be used, and it's convenient to developers to be able to redistribute parts of it to ease development.
Agreed it is always nice to have these things in a thirdparty directory, though, but the larger Chromium project actually does appear to have all of pdfium in third_party, which helps keep that clear.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#88Earlier quoted context omitted.
Read the description of the project. It's hosted here: https://pdfium.googlesource.com/
Except there is no description there... Not even a README. Nothing in the wiki either https://code.google.com/p/pdfium/w/list
Click on the OP's link and use your browser to find "PDFium is an open-source PDF rendering engine." Read the next line.
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#89Earlier quoted context omitted.
> You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't. Adding more C++ to the browser certainly does increase the attack area. Sandboxes that expose enough functionality to run a modern browser engine commonly end up with holes here and there (e.g. the Pwnium vulnerabilities) and it's best to not use them as the only layer of defense; moreover,…
The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice. Creating yet another sandbox seems silly, and NaCl hasn't been hit by pwnium, it's only been a stepping stone to the renderer (I'll let comex dive into details here!)
Hey, side question: I assume pdfium runs in the NaCl sandbox - how does that work with v8?
Re: PDFium: Chrome’s PDF rendering engine is now open-source
#90Earlier quoted context omitted.
Well, it wouldn't make sense for Firefox to adopt this: 1. It is tied to v8 (PDFs can run JS, this PDF viewer uses v8 do so - see CJS_Context::RunScript etc), so it would mean bundling 2 JS engines, with all the security downsides of that. 2. This is written in C++. You can sandbox C++ in various ways, but that would still increase the surface area of the browser, compared to pdf.js which only uses things normal web…
Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p I like the concept of pdf.js, but it's still significantly slower, and thus provides a worse experience to the user, than native viewers.
> Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p
AIUI from the NaCl guys, it already does.