DRM for Images and Text in Stacks

[Sivakatirswami]

Dream with me for a moment:

Revolution Players of various shapes and flavors have become as  
ubiquitous as copies of Acrobat Reader. The Revolution IDE is  
deployed to the same number of seats as Acrobat Professional.

Enter new problem:  Digital Rights Management: how to protect images  
and text in fields in stacks that are *not* standalones from theft by  
others who have the IDE. If you have ever set security on an Acrobat  
file, e.g. the "cannot extract images" option, even someone with  
Acrobat professional (the "IDE" for pdf's)  will find that the option  
to extract images is dimmed. (Our managing editor who deals with  
photographers is all over this business)  Of course  Adobe  has a  
disclaimer saying that their may still be ways people can hack the  
PDF, but it certainly would not be a trivial task.

Not so for a Rev stack. If you deployed a rich media library as  
stacks that  had copyright images stored in a substack, even if one  
sets a password on a stack, any other developer could open substack  
"image library" and go through the cards with the images on them in  
the application browser. We would not be able to tell our

very-adamant-that-my-images-are-not-leaked-into-the-public-domain  
photographer or
hot-new-york-news-com-agency-with-litigious-lawyers.

that we had adequately protected their images in our product. I  
believe that even a very inexpensive "Dream Card"  IDE, or whatever  
it will be called this week or next, will open such a stack and have  
access to all cards in all substacks. So, right now we can make such  
claims fairly confidently for distribution of a rich media  
"experience" via an interactive PDF, but I would like to be able to  
do the same for a Rev stack, without having to turn each and every  
instance of a stack containing such content into a standalone.

I may be missing something, but, unlike Supercard, where, if I recall  
correctly, you could  lock up a stack such that even in the dev  
environment, it could not be opened without a password, this cannot  
be  done in Revolution. Anyone with an IDE license can open any  
stack... all that we can block is access to scripts and custom  
properties. Or, am I missing something?

Related question: Assuming we could lock up a substack image library  
(which I will put in as a feature request, if it is not  possible  
today) and then simply display those images  programatically on the  
fly, are their ways to block screen shots from within Revolution? We  
may tell the photographer "They are just 72 dpi's, don't worry" but a  
screen shot of an image  that fills the entire screen might be taken  
and output at a high enough resolution that he had reason to worry. I  
see the stunning full screen experience of  "If Monks Had Macs" (Yes  
they do.. just come visit us...) and I am immediately struck by the  
problem we would face if we used an image from our top Hinduism Today  
photographers in such a context.

This is already an issue for us: we have tons of commissioned art  
work from India that we put on the web and it is now "everywhere!"   
on literally hundreds of other web sites. Fortunately we own the  
rights to all that imagery and we really have no interest in guarding  
it and we get the occasional request to reprint in the  old ink-on- 
paper world which we grant for a small fee. But for Hinduism Today  
magazine content, it's a totally different ball game. We have "one  
time usage" for most images.. (various flavors of rights...) And I  
don't know that Keynote or Powerpoint presentations, or Quicktime  
movies (as slide shows) of such content can be "locked" up either...  
(these being the other  options we have for deploying rich media  
content)

If we *could* get some strong DRM going inside Revolution, it  would  
really open up a whole  new realm for a more professional level of  
media deployment. Our top photographer is very protective and I don't  
have good answers for him.

I suppose a plug in might also do the job? Chris... do we see another  
product from  Altuit?

"RevContentSecurityManager"

Am I the only one who ever thought about this issue? I would like to  
experiment with a kind of "Ajax" rich media experience were we  
deliver a player which then starts talking to the web server and  
delivering substacks etc. caching some onto the  user's hard drive,  
pulling live feeds off the server... the model would be fairly open  
in the sense that the stacks could be easily pulled off the web by  
anyone,  but  without  some strong DRM, we would  keep hitting walls  
where we can't deploy certain kinds of content crucial to the concept.

Insights anyone?

Sivakatirswami
Himalayan Academy Publications
at Kauai's Hindu Monastery
katir at hindu.org
www.HimalayanAcademy.com,
www.HinduismToday.com