Digital Workshop

This thread is the result of my test findings from the "Launch Web Page action bug?" thread at
http://www.digitalgrapevine.info/viewtopic.php?t=548. Please refer to that thread first if you do not know the background of the problem.


Description:
I have finished authoring an instructional publication for commercial distribution on CD to a targeted market. I am ready to publish and send a master CD to duplication.

The pub includes 2 chapters.

One chapter has the overall publication's main menu page plus 8 pages of text and images showing the tools and components required to complete the project. The pages in this chapter have several image buttons with 'Launch Web Page' actions that link to the online stores of our affiliates.

The second chapter is the assembly section and has 10 pages. Each page is a step in the assembly process and includes text, images and a single mpeg1 video file that's 10-40mb in size. I an embedding the video in the publication to help deter pirates.

The final .exe file size on the CD is 175mb. To date, this pub has been tested on approximately 30 computers with processors ranging from PII-500mhz to P4-3Ghz and running on operating systems from Win98 to WinXP SP2. So far, the pub has run perfectly, without any particular problems or delays, on all machines tested except those with 3rd party software firewalls installed.
FYI: The integrated firewall in Windows XP has not been an issue.

Problem:

Popular software firewalls and internet security suites by Norton and Zone Alarm (the only 2 we've tested so far) control/restrict outgoing internet access requests made by programs on the local machine. When the Opus pub launches the default browser and requests a URL, the firewall will block the outgoing request until a permission rule is created (usually automatically); no problem. If the requesting program is on a removable media like a CD-Rom disc, the software firewalls noted above will ALWAYS scan the requesting .exe file before allowing outgoing access even if there is already an existing rule that allows that access. The scan takes approximately 1-2 minutes for a pub this size depending on the system's processor speed. Once the scan is completed, the URL will be located and the browser begins loading the page according to the machine's connection speed and any network congestion encountered. The firewall's scan of the CD is done just once per CD session but it will scan again the next time the CD (or any removable media) is inserted and the program attempts to launch the browser with an outgoing URL request.

Attempted Solutions:

1. Don't embed the video. This solves the problem because the pub is now much smaller (just 4.7MB) and the firewall's scan of the .exe file only takes a few seconds. Unfortunately, this solution leaves all of our propietary video files unprotected and so is not preferred.

2. Publish the 2 chapters as seperate but linked pubs. This also solves the problem for the same reason as #1. The chapter 1 pub contains all the 'Launch Web Page' and browser related actions and is very small so the .exe is scanned quickly. The chapter 2 pub contains all the embedded video files and no outgoing browser requests so it is not scanned by the firewall. After testing this, it becomes obvious that the opening and closing of the 2 pubs as the user navigates between them is too cumbersome to be a good option.

3. Select "Create executable and data files as below: one for each chapter" in the settings of the publishing panel. I thought this option would create an autorun to open the .exe that calls 2 seperate data files, one for each chapter, and all could reside on the CD. I had great hopes that this would make the firewall scan only the tiny .exe file and solve my problem. Either I'm not doing this correctly or creating an executable and data files does not work the way I thought. An error message " Cannot find publication file!!" is displayed when attempting to 'Test' at the end of the publication wizard.

4. Distribute the pub as an installed program instead of running it on the CD. This would run the pub from a local hard drive allowing the firewall to create a permanent rule without the repeated scanning required for removable media. This option solves my original problem but creates a new one in that I would now need to manually administer registration IDs and generate unlock codes to prevent casual piracy. The way this security option is set up in Opus, it would be fairly difficult to manage more than a handful of demos and I realize it was probably never intended for use with a commercial product.

Other Options?

Because 3rd party internet security/firewall software is becoming increasingly popular, this issue is probably going to become larger with time. If anyone can recommend other options besides ignoring the 1 to 2 minute delay in calling up web pages on these machines, please post a reply. I am currently at the end of my rope and would greatly appreciate your help.

Best,
Keith Martin
Intramedia

Keith

This "solution" may be a bit radical. Have you given consideration to convertingthe video to swf? This should get around the Firewall issue as rules for the flash player will already be established.

You will not be able to embed the swf however, and there is the question of the border in doc view. Flash player 6 or higher will be required on the target machines and lower spec machines will need testing to ensure they can cope. Flash video can be processor intensive.

Taking it further - if you have access to Flash MX2004 pro you could convert video to flv format and stream into a swf container in doc view. This would deter casual theft - you would need Flash MX or above to make any use of the file. Downside is I think Flash player 7 would be required on targets.

Its late and I'm not sure this is total joined-up thinking.

Best of luck

Ken,

Thanks for your response but converting the mpeg-1 video to Flash video will not solve the underlying problem. The firewall will still scan the CD when the publication requests internet access for the 'Launch Web Page' action. This will happen regardless of any existing program access rule because the program resides on removable media; i.e. a CD-Rom. If the publication file (.exe) is over 100MB, it will take the firewall a considerable period to scan the CD-Rom media (over a minute for Norton to scan a 175MB pub) before allowing the program link and default browser to actually find and begin loading the requested web page.

If the video, whether it's flash or mpeg is not embedded in the publication, the firewall's scan is fast enough but the video files are no longer protected. It's a simple matter to copy the files from original disc to a hard drive or another CD. Also, the video will be considerably lower quality as flash video rather than mpeg-1.

Conclusion:
Unfortunately, I'm being forced into making the decision to not embed the video at all and take my chances with casual theft of the video files so that users with systems running software firewalls will not have to hassle with long delays when launching web pages.

It's a trade off I would prefer to avoid but I have to keep an eye on the big picture. The web pages the pub is launching are stores and sponsored affiliate links that provide the major portion of the income derived from distribution of the CD. Retail sales revenues from the CD itself basically just cover the costs of producing it. Until I can come up with some type of work around, I can see no alternative.

I am fairly disappointed that DW support didn't particpate in either this thread or the previous thread at viewtopic.php?t=548. I was hoping they would at least attempt to help me find some sort workaround. After all, this issue with CD based pubs running on local computers using software firewalls is not limited to embedded video but will occur with any large pub attempting to access the internet and launch a web page

Best,
Keith Martin
Intramedia

Keith,

You could try the following:

Open a new file in notepad and paste the code below and then change the URL to your webpage.
Next save the resulting file with the name link.url. Within Opus launch the link.url file.
If your theory is correct and the delay is caused by Norton scanning the program that launches the web request this should solve the problem as the launch is being instigated by a 1k file.



[DEFAULT]
BASEURL=http://www.digitalgrapevine.info/
[InternetShortcut]
URL=http://www.digitalgrapevine.info/






The last post in that thread is from support at digitalworkshop.

That's the answer, as it will keep the executable size small whilst allowing you to protect your video. Can you tell us exactly what files you got out and maybe we can work out why it didn't work?

Brenden,

Sorry for not knowing you are a member of the DW support team. Your ID tag on posts gives no indication you are with Digital Workshop. I would have seen Digital Workshop had I checked your forum profile.

The Solution
Anyway, your solution of launching a URL link file and then using it to call the browser/URL works perfectly. I did need to type the file name "link.url" since browsing to add it in the 'Launch this file' window creates the URL name instead of the file name and then it doesn't work.

New Problem

I used the variable <SYSTEM_CD_DRIVE> to point to the link file on the publication CD which works out fine. I run into a new wrinkle on systems with more than one CD drive installed. Using the above variable, the publication disc needs to be in the correct CD drive in order for the link.url file to be found. How do I write the variable so it points to the CD drive containing the pub disc on a computer with multiple CD drives?

Thanks for your help.

Keith Martin
Intramedia

The best variable to use is <SYSTEM_PUBLICATION_DIR> this variable stores the directory information of were the publication is actualy running from so there is no chace of a problem.


Brenden Knifton
DW

Dave,

After investigating this option and the published files some more, I have stumbled onto the source of the error message. I have been naming my publication using revision numbers so it's easy to track which is which; RBFT7.0, RBFT7.5, RBFT8.0, etc..

The files being produced were:
RBFT8.0.exe
RBFT8.ilm
RBFT8_00000001.ilm
RBFT8_00000002.ilm

In this case the executable RBFT8.0.exe is probably looking for the file name RFBT8.0.ilm to launch but the publication wizard created RFBT8.ilm.

I changed the publication file name to RBFT8 and I get these files:
RBFT8.exe
RBFT8.ilm
RBFT8_00000001.ilm
RBFT8_00000002.ilm

The pub runs fine as seperate data files this way. The problem is being generated because of the extra "." in the former file name. This extra dot in the name is not a problem when publishing a single standalone executable.

Thanks,
Keith Martin
Intramedia

Problem Solved

The solutions suggested by DW support solve the internet access delay issue when running pubs from removable media using computers with a 3rd party software firewall installed (The Windows XP firewall does not scan outgoing program requests so it does not display this problem.)

The problem is caused because the firewall software requires the CD based program requesting internet access be scanned, regardless of any existing rule, before the URL can be loaded. The firewall will always scan the media once for each CD session. If the requesting program is large, say more than 100MB, this scan can take more that a minute. I have verified this behavior/issue with both Symantec (Norton Internet Security)and Zone Labs (Zone Alarm Security Suite) support over the phone.

Both the suggested solutions work by reducing the size of the program directly requesting internet access so the scan is very short.

1. Launching web pages by creating a 'Launch file' action to launch a seperate URL link file.

2. Publishing as an executable and seperate data files using the "Create executable and data files as below:" in the publishing wizard.

After testing both, I have decided on #2 as it's the easiest, most direct method.

Thanks to everyone who helped with this issue. I can now take a deep breath and move ahead

Keith Martin
Intramedia