Problems with legacy media in Reader 9.3 update

To answer your last point first, yes - legacy MM is strongly discouraged as we cannot guarantee it's secure (relying on external applications means a malicious PDF can exploit methods which are beyond the control of Adobe) which is why the 9.3 updates disable legacy MM by default. You can still open it, but you have to jump through lots of scary warnings to get there; plus the JS blacklist feature allows enterprises to completely block access.

Assuming you haven't run the blacklist installer (in which case you'd be seeing a yellow bar saying JavaScript was blocked, not one asking if you want to trust the document) then legacy MM should still be working, however if it's collecting an externally-hosted FLV it may be hitting a sandbox rule. The dot releases of Reader also update the embedded Flash Player, so you're now using FP10 (in 9.0 it was FP9). Can you give some details on what the SWF is doing and if it throws any errors, or just shows an empty screen? Does the same SWF work in other places (on a webpage etc.)?

Hi UVSAR,

Thanks for the quick reply.

The PDF in question still works fine in 9.2 and on a webpage.

The Flash (SWF) file has a video component (Flash 8) in it that calls a URL of a FLV clip that is streamed into the SWF. In 9.3 once it has been given permission the FLV clip is just absent - no warning or indications that it has been stopped.

I guess the JS blacklist has made life pretty tough for anyone who relied on JS in PDFs that are outside a corporate firewall. I cant help think that Adobe, when faced with this latest security problem, decided that fixing the locks on the doors and windows of the PDF house was too difficult and instead have settled for digging a huge moat around the whole thing. Yes it fixes the immediate problem - but for anyone who is trying to create interactive and compelling PDFs for general use the jobs just got so much harder - again.

I'll take a peek under the hood and see if there's any reason why your media shouldn't work since the .3 update, but it might take a few as it's a busy week.

The reason for the enterprise blacklist is precisely to deal with the all-or-nothing problem, as it allows individual JS functions to be turned on and off in response to security bulletins. The functions disabled in the last patch are only related to legacy MM, and it's basically because the exploit relied on a fault within an external player that the vendor of that player wouldn't fix quickly enough. Every time software spawns a third-party app to do something it can't, you're open to all the shortcomings of that app. Same with web browsers.

Hi,

I've just arrived. Hello everyone!

I've been embedding vids too.

A file I produced last year with a couple of MPG video files embedded had the following issue:

If the PDF does anything external (in this case it sent a form) before running the vid file, it issued a data sharing warning before starting the video, but only on a PC (not on a Mac, for some reason).

Tested the old file again today in Reader 9.3. I got the following message box instead:

"The document is trying to connect to
[local temporary file address]
If you trust this site, choose Allow..."

Then the video played fine. (Does the Reader rely on an external MPG player? Is MPG an exploitable format? I'm wondering why the warning appears.)

If I remember rightly, I used MPG instead of FLV, which my original source files were in, for maximum x-compatability, as Macs didn't like FLV. I never tried embedding video in a Flash file. If you can put your vids into MPGs, then that might avoid the issue for future files.


Cheers

Tony B

Tony:

Playback of legacy video (anything other than FLV/SWF content created via the Video button in Acrobat 9) is handled by whatever external video players you happen to have installed (Windows Media Player, Quicktime, etc.), and these are all potentially open to exploit - so converting a FLV into a MPG is going entirely the wrong way.

Prior to Acrobat 9, even FLV was a legacy format - and there's still a checkbox to allow you to fall back to that when you're creating video annotations in Acrobat 9, so forcing it to be played through an external app - but people should be moving to native Acro9 Flash annotations wherever possible. I wouldn't be surprised if the legacy video handler is killed off someday, as we're never going to be able to make it 100% secure when we're relying on talking to code from other vendors.

Many thanks for info, UVSAR

Tony

Hi UVSAR (or anyone else),

Please excuse me asking what's probably a very obvious question (because it's important I get it right)

For generating future PDFs with embedded video, are you saying the only format I should use is SWF?

Tony

Not necessarily SWF (though you can if you want to, using the Insert Flash tool instead of the Insert Video tool), but what we mean is if you use the Video tool in Acrobat 9 you must ensure the "create legacy" checkbox is turned off, so it uses the internal Flash video player component.

In Acrobat Pro, this means you can only embed FLV or H.264 videos.

In Acrobat Pro Extended, you can convert other formats (MPG, WMV, etc) into FLV automatically as part of the creation of the annotation.

Of course you can also stream FLV or H.264 content directly in from an external URL; it doesn't have to be embedded in the PDF itself. What matters is that the PDF doesn't try to launch an external video player program such as Quicktime.

Thanks v. much USVAR!

Tony

Impossible, since legacy multimedia handler is part of the ISO-32000 standart…

ISO standards are subject to periodic revision, and we're looking at a number of aspects of the current specification that it may not be advisable to retain long-term, given the security issues they can present to users. It won't happen tomorrow, but a PDF in ten years time will be a very different beast.

Dear USVAR,

I'm confused.

In an earlier message you said "Prior to Acrobat 9, even FLV was a legacy format," and later I can use FLV, SWF, and H.265 (?) I'm not familiar with the latter, but as a consequence of this dialogue have done some work with the first two.

When I embed an SWF file as a Screen Annot (using code that worked satisfactorily with other video formats pre Reader 9.3) this happens:

I click on the picture connected with the file...

I get the yellow bar (arrggghh!)

I click "Options", "Trust this document once."

The bar goes away but nothing else happens. My first reaction - as a professional programmer - is that it hasn't worked. My end customers are certainly going to think that.

I click on the image again and the SWF file plays.

Going from recent experience with problems submitting forms, and others' comments in forums, I'm assuming Reader's here reloading the file, and thus any password required would need to be re-entered and any JS fired on opening the file would be fired again? (None of which is desirable.)

I'm not sure why any of this is happening if SWF is a safe format?

I tried creating a PDF file with an FLV embedded instead of an SWF. Reader responded by seeking the media player over the internet, which failed.

OK, I'll stick to SWF. However, I want to avoid the issues mentioned above. Please advise, alternatively, if you have a PDF file that plays an embedded video in the simplest way possible, please share it with me / us so we can reverse engineer it.

Tony

The concept to understand is that when you create content (Flash, Video) using the multimedia tools or menus in Acrobat 9 Pro/Extended, by default it will create a version that uses the internal copy of Flash Player. This is what we call "non-legacy" or "internal" content, and will *not* be limited by trust settings. You'll still get a popup message if the SWF wants to connect to the Internet, but that's all.

However, if during the creation process you click the "create legacy multimedia" link on the SWF annotation popup window, it will change completely, and rather than using the internal Player it simply inserts your file along with a reference to open it via whatever software your operating system normally uses for that type of file. Even if that's also Flash Player, it will use the copy installed on your computer, NOT the copy built into Acrobat or Reader 9. As a result, you get the trust messages.

This internal copy of Player was first added in Acrobat 9.0 / Reader 9.0 (and was Flash Player 9). Since the dot updates, it's now Flash Player 10 - but any content created in, or opened in, a version of Acrobat or Reader before 9.0 will be using the legacy method. Once it's been embedded, there's no simple way to convert it to and from legacy mode.

Your question over "if SWF is a safe format" is only half true - SWF playing in the internal copy of Flash Player *is* safe, as that copy has been crippled to prevent some of the at-issue ActionScript calls (for example being able to access both the Internet and your local drive, and copy data between the two). If the SWF is playing in legacy mode, through your normal copy of Flash Player that handles content in your browsers, etc., then we can't consider it safe as those functions remain accessible.

By the sound of your last reply, you're not using the tool buttons in Acrobat 9 to embed your SWF files - and as a result they seem to be going in as legacy mode content. If you can explain your workflow, we can work out why.

Many thanks again for the information / clarifications, USVAR

I'm embedding vids using code. Initially I worked with PDF Ref 1.6; have checked 1.7 for changes and Supplements to ISO 32000 (0 and 1). I couldn't find anything relevant but obviously we're talking about big documents and I may easily have missed something.

Basically I use Annot, SubType Screen. I hope I can tweak this into a secure version. I worked on RichMedia also last year but couldn't succeed with it.

If there's a tweak I can add to Annot / Screen please let me know, or failing that perhaps you have a sample file that I can use alongside the refs?

Tony

Sorry but Annot.Screen streams are by definition legacy format, so will always trigger the external player.

The non-legacy rich media objects are part of the Adobe extension level 3 spec (PDF1.7 supplement zero) - see section 9.6.1 for the details, and page 94 onwards for a complete code example with both video, SWF and 3D content streams. They're not as easy to implement as there's a lot of dictionaries that have to be there before anything happens, even for a basic embed.

Hi UVSAR,

That's great... Thanks so much for your help!!

Tony B