Acrobat PDF rendering engine added to Microsoft Edge | Hacker News Reader

Acrobat PDF rendering engine added to Microsoft Edge

blog.adobe.com

59 pointscpeterso69 comments

> Users who want more advanced digital document features — such as the ability to edit text and images, convert PDFs to other file formats, and combine files — can purchase an Acrobat subscription that enables access to these features anywhere, including directly inside Microsoft Edge via an extension.

Or, more plainly: "we're putting more shareware in your operating system via the preinstalled browser"

Up next, Edge App Store.

Huh, wait, remember Chrome App Stores where they had paid browser extensions? Or is that still there and I just haven't been paying attention?

Gone for at least two years now [1].

[1]: https://developer.chrome.com/docs/webstore/cws-payments-depr...

Recently I opened a government document in Acrobat Reader and was told I needed a paid version to edit it.

I assumed it was a permission issue and whoever created the doc made a mistake, but now I wonder if they're going to rug pull PDF editing and sell it back to us as a subscription. Governments should be preemptively mandating a ban on PDFs if there's even a hint of anyone making moves to charge the end-user for document viewing, filling, submitting.

Editing PDF files with Acrobat was always non free.

I'm guessing GP is referring to a PDF form that hasn't had the "allow filling out in Acrobat Reader" setting enabled.

(I don't recall the actual text of the setting).

And an awful user experience. No excuse for it at all that I could see

It’s called “Reader” for a reason.

Ban PDFs?

I see enough people in companies and privately using Adobe Acrobat. However, given the quality of the software (from Adobe in general) and all the security holes that have been exploited for Acrobat over the years, I can advise everyone not to use Adobe PDF Acrobat Reader and instead open PDF files in Firefox (pdf.js) or Chrome (pdfium).

A look at the PDF specification is enough to know that it is a hard task to parse such a complex file format without memory bugs: the file is read backwards, which is why the x-ref table is at the end of the file, actually PDF is supposed to be exclusively ASCII... except that every PDF contains binary streams and in addition functions and properties which are defined are ignored even by Adobe Reader. I wrote some PDF-fuzzers a few years ago and the whole file format is a huge mess..

that's nice except that I periodically receive PDFs created by other companies, or even gov. orgs, which I find I am unable to fill out and/or sign using anything other than Acrobat on Windows :/

> can advise everyone not to use Adobe PDF Acrobat Reader and instead open PDF files in Firefox (pdf.js) or Chrome (pdfium).

I agree that Acrobat should be avoided whenever possible but I advise everyone not to use any PDF reader that's found in a browser either because PDF is a minefield and you can expect that the most popular (default) readers will be the most heavily targeted by attackers who will inevitably find security issues. 80% of the time, users are best off downloading PDF files to disk and converting them to text or PNG before opening while resorting to a non-browser/adobe reader for any other cases excepting the ones where you're just forced to use Adobe's software because of some advanced feature.

It won't work for everybody, and it's not as if PDF converters and less common PDF readers are immune from bugs either, but if the vast majority of the time you open a PDF file all you really want is text it can be nice to know your file isn't doing things like making network connections, running JS, playing multimedia or some other bullshit PDF allows for at the same time.

>image

No. If you use Linux, the correct thing to do would be to convert the PDF into DJVU and use djview4 to read it.

Or better to xpm. Just to be sure /s

That sounds good as long as you don't mind lossy compression (which shouldn't matter for text but might for images)

Pdf2djvu (and most ghostscript/poppler/djvu based tools) have quality settings for images.

The advantage of pdf.js/pdfium is they are just web pages themselves. To exploit it you need to not only find a PDF exploit but a browser exploit - at which point it'd be many times easier to just serve the browser exploit via a normal page.

Converting PDFs to text or PNG on the machine just means you're now getting rid of the need for that 2nd level exploit by running something natively on the machine.

I see it as the other way around. Now you only need a single PDF exploit to compromise the browser and in bad cases, a single PDF can compromise the entire system.

Could you explain why a PDF exploit would bypass the need for an exploit that bypasses the web sandbox? As mentioned the pdf engines in browsers are not written in native code, I don’t see any way to bypass the need for both a pdf exploit AND a browser sandbox exploit.

Unless they changed programming language of Acrobat Reader to something memory safe, this will open a huge attack surface for drive by hacking.

There's a reason why most browsers got rid of plugins (Java Applets, Flash, Acrobat, etc.)

Yep - even though Acrobat is the standard for PDFs on the desktop, there's a world of difference between "PDFs I download may be malicious" and "links I click and frames I load may be malicious." The idea that https://nvd.nist.gov/vuln/detail/CVE-2021-28550 could have been exploited without requiring a download would have been a disaster.

(Though, I should add, memory safety is by no means a guarantee of software being free of code-execution vulnerabilities... but it certainly does help!)

I imagine they'll run it in a sandbox, plus MS may help find vulnerabilities themselves

While I don't trust Adobe to make secure software, the existing PDF viewer in Chrome/Edge is PDFium [1] which was licensed from Foxit [2] and is C++ and has had its share of exploits.

There is PDF.js [3] used in Firefox but it has performance and printing issues due to it being purely done in javascript.

Ideally the whole browser including the HTML and PDF rendered would be done in a memory safe language, but that will be awhile I suspect.

I certainly don't want to go back to the activeX days and having to install a plugin to view PDF's.

Don't really see the need for this change as its going back to a close source renderer and PDFium seemed to work well with all PDF's thrown at it unlike PDF.js

[1] https://pdfium.googlesource.com

[2] https://en.wikipedia.org/wiki/Foxit_Software#OEM_relationshi...

[3] https://mozilla.github.io/pdf.js/

As a side note: Acording to mitre.org there are 107 CVE entries issued for PDFium since it got it's first entry in 2014. In the same years Acrobat Reader got totally 1678 CVE entries.

Yeah, this is exactly what I was thinking. Why not just bring back ActiveX?

The post links to a blog and the most recent post seems to address this concern. (I haven't actually read it yet.)

https://microsoftedge.github.io/edgevr/posts/How-we-are-secu...

Edit after reading: What a joke. They are using a better allocator and doing some fuzzing. This is nowhere close to the approach that Chromium uses which is basically running the PDF viewer via WASM.

The "Adobe PDF Experience", for me, is "locks up if I try to use it for smartcard signatures", which is 98% of the reason I open a PDF outside the browser.

Add a sprinkling of "spend money to upgrade" harassment and you've really got the "experience" ready.

The prospect of adding this "experience" to a browser... No. Stop. Go away.

Am I alone in feeling... 'yikes'?

Stay tuned for vulnerabilities in 3 2 1

I had the french canadian version of that 'eurk'.

Nope, I thought "yikes, I am happy that I use Firefox".

Let me guess, this will also come with helpful features like preventing me from choosing another PDF reader? And I will always helpfully have to open every PDF in Acrobat?

I don't think they will go as far as totally preventing us to do so, but they will make sure to make it cumbersome and reset our preferences with each update.

Also, the resulting UX for a third-party PDF reader is ugly and clunky.

So it will now take PDF's five times longer to render?

Can we opt out of this feature? Or will it be just as bad as in the actual Acrobat Reader?

Being the unicorn behind the PDF format, Adobe Acrobat has become this bloatware; they just don't care enough about giving Acrobat Reader any modern rendering features such as GPU acceleration, smooth scrolling, etc. Smaller open-source software such as Samatra has far-superior experience in actually reading PDFs, this is Windows. On macOS, there is one bad PDF reader and that is Acrobat.

Because of this, I have been trying very hard to avoid Acrobat, and Edge seems to be a legit experience on Windows, and now it is killed and Acrobat will be all that we have.

So no thank you, you give me another reason I should stick to FireFox.

SumatraPDF is really nice. I use it to view service manuals at my job and it's way faster than pdf.js or Adobe Reader.

I’ve been using a Chrome Extension to replace Edge’s PDF renderer with pdf.js [1]. It’s a little outdated at this point and it does change the URL in the address bar while viewing PDFs, but overall I find it works better (especially while scrolling) than the existing built in PDF viewer for Edge.

[1]: https://chrome.google.com/webstore/detail/pdf-viewer/oemmndc...

Happy with Sumatra, thanks

I am very happy with PDF XChange viewer on windows, since it renders very quick and efficiently, while having many features for annotation/marking/etc that is usually not available. Eg highlighting text, text boxes, arrows, polygons, etc. Very fast to zoom, scroll, pan.

Since I am a tab hoarder, naturally my PDFX has a couple of pdf tabs too, so it takes a little while to open - so if I want to just quickly view a file, I drag and drop it onto firefox.

Oh boy, it is nigh time for me to dust off my Adobe ActionScript malware scanner and iCAP it off AGAIN with my transparent Squid.

ICYMI: PDF uses JavaScript and surely Adobe has a JavaScript engine that (now) needs to be watch even closer.

The things we thought were over, dead, and buried; time to start digging up this esoteric malware Adobe/PDF/JS detector of mine.

Has anyone come across any cases where the Acrobat rendering engine did a better job than the one used in Chrome and Chromium?

For some forms, but Acrobat is slow and filled with security holes so who cares?

So pdf is officially dead. R.I.P.

(Big company product only bundles with widely used product, if they are desperately longing the the descending userbase. Look for flash, when users begin no longer installing by themselves, it come to the windows.)

This is huge, not for the HN crowd, but for people who are still using acrobat to this day.

In what sense?

A lot of people are still used to the Acrobat interface and its features.

On linux I'm pretty happy with Okular, but on Windows I usually just use my web browser. What do you use?

SumatraPDF is great on Windows

This is huge for malware distributors as well as industries that rely on identifying end-users. For IT support folks it'll be less than ideal.

The Chromium PDF viewer was built from the Foxit PDF SDK.

Was Chromium Edge using that PDF viewer previously? Is this just moving to a new PDF viewer based on Acrobat SDKs?

It was PDFium which is the open source version of Foxit. So yeah looks like they are just moving to closed source Adobe just like the old days with the Active plugin in IE.

Damn, I thought Edge made the perfect PDF reader/annotator and now it’ll harass you to do ‘more’ with Adobe junk in it.

Why not pdf.js? :/ Adobe scare me...

I don't want to use Edge as a PDF viewer because of its useless UI.

Damn. I just literally removed Acrobat from every machine I have.

Isn’t there a perfectly good open source pdf viewer?

we need to publish documents in a new format. pdf is ridiculously restrictive and makes training the language models a nightmare.

Well there’s this thing called HTML that is pretty popular.

You can see an example of it here: https://motherfuckingwebsite.com/

You even have formatting options as discussed here: http://bettermotherfuckingwebsite.com/

If I send someone a PDF document, I know exactly how it will look for them on screen and on paper.

HTML, not so much.

Sure. Part of that is PDF’s restrictiveness. We either value the consistency, value the flexibility or pick the appropriate format for the application. Basic HTML gets you something readable with any HTML renderer, and you can pretty much count on it, but not to the same degree or certainty as you can with a PDF (and bad PDF renderers exist too). You can still read a book in it. HTML+other stuff is where it gets dicey, and temptations like on-demand loading and endless scrolling, or “rich” features like dictionary lookups (that my OS already natively supports in any application from any text selection including the web browser) start to make reading a book this way sound like a bad idea and PDF starts to sound a lot more appealing.

All I’m saying is when PDF starts to sound like the wrong choice, consider HTML. Not HTML plus stuff, just HTML. Maybe a very very light touch of CSS if you’re feeling fancy, but it’s really not necessary.

HTML should be used for books and stuff.

(Accessible) PDF should be used when you want to control exactly how it looks on the receiving end, but this should be a rare use case.

Outside of actual raster image formats, PDF is the only file type I can export to and be confident it will render correctly on the recipient's machine. SVGs are a mess, MS Office documents are a crapshoot unless everyone is using official Microsoft Office, and I probably don't need to even discuss HTML.

There are PDFs out there which will only render correctly in Adobe Acrobat, but unless I'm using some niche Adobe-only feature, I basically never encounter problems. I've also heard that PDFs are technically horrible under-the-hood, but for some reason they just work like nothing else does!

As sad as it is, the reason PDFs just work like nothing else does is probably because they're technically horrible under the hood.

They are so horrible that you still need to have some quirks in your reader, because some important tool still generates it incorrectly , but it is still correct. Then there are loops and some software Try to parse them. The encryption types, the security, which is bonkers… why should it be possible to disallow printing or analyzing it with another software, there are attachments, forms, JavaScript…

And then there is xfa (Especially the dynamic one), a format in a format which basically totally different than a pdf. But it is inside the pdf container and people expect that you understand it. Thank god that pdf 2.0 probably kills it.

PDF is for printing. Use text formats for everything else. Or, as a PDF alternative, DJVU.

lots of big, confident-seeming moves from Redmond—it'll be interesting to see what happens.

Has static linking gone too far?

Reply on news.ycombinator.com