DRM for Images and Text in Stacks
katir at hindu.org
Tue Mar 7 04:42:50 EST 2006
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
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
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?
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.
Himalayan Academy Publications
at Kauai's Hindu Monastery
katir at hindu.org
More information about the Use-livecode