Re: DRM for Images and Text in Stacks
On Mar 21, 2006, at 10:13 AM, Richard Gaskin wrote: So while it keeps people who don't have Rev from extracting data, it still leaves data vulnerable to those who do. Exactly the problem... Scott wrote: but I would guess the likelihood of your users owning a copy of Rev is lower than folks' ability to snoop around file contents. true now and confirmed, both custom props and fields are encrypted contains on disk but our assumption that the possibilities of such extraction are low is based on the less than enthusiastic ontology that the number of rev developers in the world of manifest being is small i.e. the statistical chances of theft are low relative to the number of users using the product (or who might try to hack it in BBedit or whatever...) without the IDE... but: remember the Dream World I proposed initially on this thread posits a different ontology: Rev becomes very popular and the number of IDEs in the universe approaches infinity, (excuse the word fun) suddenly the chances for theft jump Isn't there a BZ request for SC-style password protection? In SC setting the password prevents the stack from being opened in the IDE. If there isn't already a request for this maybe someone should post one, with recommendations on what that password property should be called. I just put that feature request in...I didn't know SC had this (I haven't used SC in years) I'm sorry to say I did not exercise due diligence to determine if said enhancement was already there... anyway, enhancement 3404 is now there and was assigned to the engine team. I'm not competent to recommend a password property name. But to get the ball rolling -- at the risk of using metaphorical terms (but why not? we use anchor in html, wizard for a small tool and firewall in net admin, and Tiger for and OS) Would terms related to lock work?: (opening my thesaurus) adjectives for the state of such a stack: (where the property is true or false) Where the propery being true means you cannot open the stack: bolted # like the door to a house lockout # those inside preventing entry to those outside sealed cryptic taboo kapu (taboo in Hawaiian) Prosaic: secure # as in an SSL transaction: completely opaque and unextractable closed # as in a meeting in a room with the door shut restricted blocked Nouns for a stack in such a state: crypt vault strongbox Where the property being true is the default and if set to false, means you cannot open the stack penetrable reveal accessible Sivakatirswami ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
OK further testing I finally settled on a compromise taking Key Ray's suggestion but not using compressed imageData, I don't see any advantage (I could be missing something) to using compressed imageData over simple jpg storage. Either format would be equally hackable... I think this comes close to making the images at least some what obscurely stored. --create a substack --import images into custom props as jpegs, --One could put these props in something a available as a card property or something very obscure, like a transparent invisible graphic. --set the uStuff1 of btn obscureObject to (url (binfile:/somePath/ foo.jpg)) --scripts then can call the images for display: put the uStuff of btn obscureObject into img DisplayImageNow -- then encrypt the stack with a password. (all this does is prevent another developer from seeing the scripts that display the custom prop) That's about as good as it gets, I think...some developer who was really, really intent on stealing your images might dig through every object in the stack, find the object with custom props, surmise these were image data and extract them from the msg box... but this is a highly unlikely scenario... as our managing editor pointed out today in a staff meeting, discussing this very issue of how much energy we need to put into protecting images, he said that all these years, anyone could make some hi-res scans of our printed magazine and get a pretty decent image. But, no one has actually done this. Still, on principle, I think we need a strong DRM option and I have put in a feature request into bugzilla for simple option to block access to a substack from inside the IDE... I still need to be able to say for example, to NewsCom photo agency (who we use a lot of photos from), or Thomas Kelly (world famous photographer who does shoots for us in India, Sri Lanka and Nepal) with a honest face: No, people cannot extract the images, not even another revolution developer...you are welcome to test it yourself if you wish. --right now I cannot do thatif our managing editor asks are the images locked up, I have to say well, almost...but not quite Sivakatirswami Himalayan Academy Publications www.HinduismToday.com On Mar 20, 2006, at 10:46 AM, Mark Talluto wrote: mmm. I'm reviewing all the memos to date on this and see you already mentioned this. OK yes, I think this is doable I will try it. I wonder how hackable this could be from inside the IDE if one were to place that line into just the script of the substack library This will not work as all one has to do is lock the messages before opening the stack. Mark Talluto -- CANELA Software http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
Sivakatirswami wrote: OK further testing I finally settled on a compromise taking Key Ray's suggestion but not using compressed imageData, I don't see any advantage (I could be missing something) to using compressed imageData over simple jpg storage. Either format would be equally hackable... If your security needs are modest, the fwPack and fwUnpack functions may be handy: http://www.revjournal.com/tutorials/handy-handlers-005.html -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
Recently, Sivakatirswami wrote: I think this comes close to making the images at least some what obscurely stored. --create a substack --import images into custom props as jpegs, --One could put these props in something a available as a card property or something very obscure, like a transparent invisible graphic. --set the uStuff1 of btn obscureObject to (url (binfile:/somePath/ foo.jpg)) --scripts then can call the images for display: put the uStuff of btn obscureObject into img DisplayImageNow -- then encrypt the stack with a password. (all this does is prevent another developer from seeing the scripts that display the custom prop) One thing you might want to consider is putting the image data into fields as opposed to custom properties, the reason being that field contents are encrypted along with the rest of the stack data when a stack is password protected, while custom props are not. You can still display images from the fields' contents, and the fields themselves cannot be cut and pasted. I don't know who you audience is but I would guess the likelihood of your users owning a copy of Rev is lower than folks' ability to snoop around file contents. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
Recently, I wrote: field contents are encrypted along with the rest of the stack data when a stack is password protected, while custom props are not ...or maybe custom props *are* encrypted. That's weird, I could have sworn that custom props were visible when viewing stack data in a text editor, but now (Rev 2.6) it doesn't seem so. Perhaps this used to be the case with older versions of Rev. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
Scott Rossi wrote: Recently, I wrote: field contents are encrypted along with the rest of the stack data when a stack is password protected, while custom props are not ...or maybe custom props *are* encrypted. That's weird, I could have sworn that custom props were visible when viewing stack data in a text editor, but now (Rev 2.6) it doesn't seem so. Perhaps this used to be the case with older versions of Rev. As I recall, when the possibilty of encrypting custom props along with scripts was brought up on the improve-rev list, it was shot down because it would kill access to those properties. Fortunately a quick test here confirms what you've found: custom props are indeed encrypted when the password is set, but only on disk -- you can still view and edit the data from scripts, such as the IDE's. So while it keeps people who don't have Rev from extracting data, it still leaves data vulnerable to those who do. Isn't there a BZ request for SC-style password protection? In SC setting the password prevents the stack from being opened in the IDE. If there isn't already a request for this maybe someone should post one, with recommendations on what that password property should be called. -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
On Mar 18, 2006, at 2:39 AM Mar 18, 2006, Sivakatirswami wrote: if the environment is development then quit does that not prevent someone from opening it up in the IDE? mmm. I'm reviewing all the memos to date on this and see you already mentioned this. OK yes, I think this is doable I will try it. I wonder how hackable this could be from inside the IDE if one were to place that line into just the script of the substack library This will not work as all one has to do is lock the messages before opening the stack. Mark Talluto -- CANELA Software http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
1) The bad guys are in my dream world are other owners of the Rev IDE, which has in this future world, become as ubiquitous as Acrobat Professional. It implies that Rev actually does become wildly popular... In that world, not all will be as scrupulous as our current obviously rapidly growing group of Rev users. The bad guys are people in need of content for their projects or web sites who use our content. It's already happening... with images from our web sites now, which is fine because we own it all. Within 72 hours of going live with http://www.himalayanacademy.com/resources/books/dws/; the site was indexed by Google, hit on by users to browse and others took images which started appearing on other servers, which was fine in this case because we owned it all. Bad implies that these people are criminals but actually we don't think like that at all, we tend to deploy stuff rather freely and it looks that way to everyone and so they take it and re use it and we never do much about it... share with the world model.. It save an enormous amount of mental reestate that would other wise be invested in protection and yet still be able to draw some lines inside the media itself where users see can't go there... 2) Yes, all the options for encryption and storing the media externally are all there. But I would still a) like to be able to have the media in the stack and b) see a drop dead simple option to block viewing of substacks in the IDE... because i) encrypt, decrypt and display is sluggish, of course you script around even that by unpacking media in advance of display.. but then ii) CMS starts to get complicated if you separate the media from the stack. it gets back to use of mental re-estate invested in the protection business. It's just so neat to have it all in the stack. This makes it very portable, and, side benefit: scripting the presentation to an amazingly baby simple set of Go Next Card handlers with a few transitions. Or, if one is in a do it all on one card mood.., then hide and show handlers... Anyway, thanks for all the solutions.. I've put in my feature request, something as brainless as set security in the IDE, check that box for the substack and that's the beginning and end of time and effort in the protection business. 'til then all your good ideas are in my tool box... I'll try some. Sivakatirswami Himalayan Academy Publications www.HimalayanAcademy.com, www.HinduismToday.com On Mar 17, 2006, at 8:28 AM, Mark Talluto wrote: On Mar 17, 2006, at 8:57 AM, Stephen Barncard wrote: Why can't you protect the access online to the files on a secure server rather than try to protect the media? Who or what are the 'bad guys'?? sqb Can the files be outside the application in a data folder perhaps? If so, you could just encrypt them with a setup app. Your player or media app would then import the encrypted file, decrypt it, and then show it. All the while, the download media is encrypted and safe. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
At 11:40 PM -1000 3/17/06, Sivakatirswami wrote: see a drop dead simple option to block viewing of substacks in the IDE... If you place in the stack script of one of these files you are sending 'out into the world' (iow - not an in-house production file that you might use later for working on) the following script: if the environment is development then quit does that not prevent someone from opening it up in the IDE? ciao, sims ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
On Mar 18, 2006, at 12:27 AM, sims wrote: At 11:40 PM -1000 3/17/06, Sivakatirswami wrote: see a drop dead simple option to block viewing of substacks in the IDE... If you place in the stack script of one of these files you are sending 'out into the world' (iow - not an in-house production file that you might use later for working on) the following script: if the environment is development then quit does that not prevent someone from opening it up in the IDE? mmm. I'm reviewing all the memos to date on this and see you already mentioned this. OK yes, I think this is doable I will try it. I wonder how hackable this could be from inside the IDE if one were to place that line into just the script of the substack library ciao, sims ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
On Mar 18, 2006, at 12:27 AM, sims wrote: At 11:40 PM -1000 3/17/06, Sivakatirswami wrote: see a drop dead simple option to block viewing of substacks in the IDE... If you place in the stack script of one of these files you are sending 'out into the world' (iow - not an in-house production file that you might use later for working on) the following script: if the environment is development then quit does that not prevent someone from opening it up in the IDE? mmm. I'm reviewing all the memos to date on this and see you already mentioned this. OK yes, I think this is doable I will try it. I wonder how hackable this could be from inside the IDE if one were to place that line into just the script of the substack library ciao, sims ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
At 12:39 AM -1000 3/18/06, Sivakatirswami wrote: if the environment is development then quit With one app I... placed QuickTime videos into a userprop inside of individual files that had the above script. I then had an app open that file, grab the userprop, and create a QT video as a temporary file. Then the appropriate player object played that video and when it was finished playing the app would then delete that temp file. Seemed to keep everything well hidden, maybe not 100% foolproof but what is?;-) ciao, sims European Rev Conference 2006 www.techietours.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
In a message dated 3/18/06 7:20:17 AM, sims [EMAIL PROTECTED] writes: At 11:40 PM -1000 3/17/06, Sivakatirswami wrote: see a drop dead simple option to block viewing of substacks in the IDE... If you place in the stack script of one of these files you are sending 'out into the world' (iow - not an in-house production file that you might use later for working on) the following script: if the environment is development then quit does that not prevent someone from opening it up in the IDE? Maybe. Try typing this into the message box and see what happens: edit script of stack MyProtectedProject ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
In a message dated 3/18/06 7:20:17 AM, sims [EMAIL PROTECTED] writes: At 11:40 PM -1000 3/17/06, Sivakatirswami wrote: see a drop dead simple option to block viewing of substacks in the IDE... If you place in the stack script of one of these files you are sending 'out into the world' (iow - not an in-house production file that you might use later for working on) the following script: if the environment is development then quit does that not prevent someone from opening it up in the IDE? Maybe. Try typing this into the message box and see what happens: edit script of stack MyProtectedProject Not much... Message execution error: Error description: Chunk: can't find stack ciao, sims European Rev Conference 2006 www.techietours.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
At 9:10 PM +0100 3/18/06, sims wrote: oes that not prevent someone from opening it up in the IDE? Maybe. Try typing this into the message box and see what happens: edit script of stack MyProtectedProject Ummm...oh, I see what you mean. Back to the drawing board. ciao, sims ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
FYI, setting a customProp with the compressed image data actually increases the size of the stack if those images were resized to larger than their original incoming size (that's expected behavior) This presents somewhat of a conundrum. Since the import of a 3 X 5 jpeg whose original resolution was 72 DPI (all that is needed for the screen) and if is scaled up, storing it as image data (even compressed) bloats the stack. Since the quest is internet delivery, one is looking for the opposite effect: smaller stack sizes. So, one gets caught between a rock and a hard place: you want to deliver media efficiently but protect them from theft but then to protect them from theft you have to make a stack that is so big that delivery is difficult. hmmm... I would still opt for a new feature to protect stacks in the IDE. Then you simply store images in a substack which are obviously unavailable if driven from a standalone player. Another developer then tries to open your substack in the IDE and he can't, without a password. You shouldn't need push the image data around thru hoops to get your DRM. Without this, we are stuck with PDF's as a container for delivery of content where DRM is mission critical. We're not talking little gif graphics here but high end photos with strict copyright-usage issues. Musings: PDF's are very efficient and one can set security on the images to block another Acrobat Professional user from accessing the extract images menu item (it will be dimmed), but this act of protection does not impact the size of the container...(the PDF still has the images stored in lo-quality jpg form). So I'm looking to see how that model can be implemented in Rev, but efficiently in terms of the final stack file size. The name of the game is getting from the vertical rect of the old print world to the horizontal rect of the digital revolution. It's actually a very hard nut to crack. We recently exported some Key notes with embedded media to Power Point: file sizes were so large that internet delivery was unthinkable. one would have to put them on DVD disk and sell them to cover costs. We are just interested in deploying content, not making money on most of this content, and would rather avoid the whole burn it, package it, warehouse it, catalog it, sell it, cycle. We're looking into recording the screen thru a whole presentation and turning these into movies, but for a full 600X800 rect the resulting.mov file will also be enormous, even as an MPEG or h.264... It means burning disks again, and packaged-postal delivery. No matter how well you do this, that paradigm dramatically decreases distribution compared to a web download. I'm sitting there knowing full well that the same content deployed as a revolution stack could be packaged in 1/20 the space...or incrementally delivered in a few separate stacks...and the media wants to in the stack (at least photos) and come very, very close to the equivalent files sizes for the same content packaged as PDF's. (if not smaller) Besides-- the compress and decompress thing was very sluggish... So secure PDF's of printed pages with vertical orientation still rules... and users must scroll and zoom and scroll and zoom and scroll and zoom.there is a lot of resistance to this among a certain strata of users... InDesign has some great export to XML options and with a little standardization on templates in Rev, it would not be hard parse a print magazine article-page file and get it all repackaged into a horizontal rect. But it comes back to DRM- security on the images or substack. Without that, the exercise is pointless. OK , 'nuf said... I'm copying this to support at Rev as a feature request. Oh... and text wrap around photos would also be dynamite! Sivakatirswami Himalayan Academy Publications at Kauai's Hindu Monastery [EMAIL PROTECTED] www.HimalayanAcademy.com, www.HinduismToday.com www.Gurudeva.org www.Hindu.org On Mar 07, 2006, at 9:05 AM, Sivakatirswami wrote: Here's a simple example using compress/decompress: SETUP: set the uStuff of this card to compress(the imageData of img 1) put into img 1 PLAYBACK: set the imageData of img 1 to decompress(the uStuff of this card) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
Why can't you protect the access online to the files on a secure server rather than try to protect the media? Who or what are the 'bad guys'?? sqb FYI, setting a customProp with the compressed image data actually increases the size of the stack if those images were resized to larger than their original incoming size (that's expected behavior) This presents somewhat of a conundrum. Since the import of a 3 X 5 jpeg whose original resolution was 72 DPI (all that is needed for the screen) and if is scaled up, storing it as image data (even compressed) bloats the stack. Since the quest is internet delivery, one is looking for the opposite effect: smaller stack sizes. So, one gets caught between a rock and a hard place: you want to deliver media efficiently but protect them from theft but then to protect them from theft you have to make a stack that is so big that delivery is difficult. hmmm... I would still opt for a new feature to protect stacks in the IDE. Then you Sivakatirswami -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
On Mar 17, 2006, at 8:57 AM, Stephen Barncard wrote: Why can't you protect the access online to the files on a secure server rather than try to protect the media? Who or what are the 'bad guys'?? sqb Can the files be outside the application in a data folder perhaps? If so, you could just encrypt them with a setup app. Your player or media app would then import the encrypted file, decrypt it, and then show it. All the while, the download media is encrypted and safe. Mark Talluto -- CANELA Software http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
DRM for Images and Text in Stacks
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 [EMAIL PROTECTED] www.HimalayanAcademy.com, www.HinduismToday.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription
Re: DRM for Images and Text in Stacks
Hi Sivakatirswami, On 07 Mar 2006, at 10:42, Sivakatirswami wrote: Dream with me for a moment: -snip- Insights anyone? A possibility to protect your images is to encrypt them using a blowfish or another algo (included in the enterprise version) and put the result into fields or custom props (or whatever container of your choice). The code to deencrypt this pictures and place them in their respective image containers is kept in the password protected stack. The necessary key to deencrypt when loading a encrypted pict stack: - may be burried somewhere in the stack (or somewhere else) - must be supplied (dialog box or internet connection) The last system will need the most time to crack. So there is no real need for a special plugin. Sivakatirswami Greetings, Wouter ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
On 3/7/06 3:42 AM, Sivakatirswami [EMAIL PROTECTED] wrote: 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. You could do this: for each image that needs to be displayed on the card in the substack, put the imageData of the image(s) into custom properties of the card, encrypted with 'base64encode' or compressed with 'compress' (or use a custom algorithm of your own), and then set the imageData of the image objects themselves to empty. Then, only when running in your standalone, unencrypt/decompress and pipe the imagedata from the custom props back into the image objects on preOpenCard. Make sure the custom property name and the actual object to which it is associated have different names or identifiers. Then encrypt the stacks. This way, the image data is safe from prying eyes (people would only see the raw image data when looking at it with the Rev IDE's inspector), and since the stack is encrypted and the custom prop and image objects have no obvious connection, it would be difficult to figure out which image data goes with which object and even if they could, the data is encrypted or compressed so it's not a simple act of set the imageData of img 1 to prop. Here's a simple example using compress/decompress: SETUP: set the uStuff of this card to compress(the imageData of img 1) put into img 1 PLAYBACK: set the imageData of img 1 to decompress(the uStuff of this card) Hope this helps, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
well, the point is to protect it *also* when looking in the REv's IDE inspector. If you put the images into customProps and then put a password on the stack... will that prevent uses who have the IDE from getting at them? (I'll try it.) Sivakatirswami On Mar 07, 2006, at 5:40 AM, Ken Ray wrote: This way, the image data is safe from prying eyes (people would only see the raw image data when looking at it with the Rev IDE's inspector), and since the stack is encrypted and the custom prop and image objects have no obvious connection, it would be difficult to figure out which image data goes with which object and even if they could, the data is encrypted or compressed so it's not a simple act of set the imageData of img 1 to prop. Here's a simple example using compress/decompress: SETUP: set the uStuff of this card to compress(the imageData of img 1) put into img 1 PLAYBACK: set the imageData of img 1 to decompress(the uStuff of this card) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
On 3/7/06 1:05 PM, Sivakatirswami [EMAIL PROTECTED] wrote: well, the point is to protect it *also* when looking in the REv's IDE inspector. If you put the images into customProps and then put a password on the stack... will that prevent uses who have the IDE from getting at them? (I'll try it.) No, they can get to them, but they won't know what how to decipher the binary data you put in there. Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
At 1:53 PM -0600 3/7/06, Ken Ray wrote: On 3/7/06 1:05 PM, Sivakatirswami [EMAIL PROTECTED] wrote: well, the point is to protect it *also* when looking in the REv's IDE inspector. If you put the images into customProps and then put a password on the stack... will that prevent uses who have the IDE from getting at them? (I'll try it.) No, they can get to them, but they won't know what how to decipher the binary data you put in there. Would this solve your problem... Make copies of all the stacks which contain the media. Take the second batch which will be given out with the application, place in the stack script - if the environment is development then quit. Wouldn't the file be accessible to your standalone but not in the IDE? If you need to modify those files, use your backup copy which does not have that stack script. Is there anything wrong with this strategy? ciao, sims European Rev Conference 2006 www.techietours.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: DRM for Images and Text in Stacks
On 3/8/06, Ken Ray [EMAIL PROTECTED] wrote: No, they can get to them, but they won't know what how to decipher the binary data you put in there. Of course everyone has only mentioned the images, although the same can apply to the text in your text fields. This all seems very complex to me. In Sivakatirswami Dreamworld the answer would seem to be DreamCard - as it can be used as a database front end. With all images and text stored securely in an encrypted database when anyone with the Rev IDE opens a front end all they get is 'empty' fields, etc. Pity DreamCard is on the way out, so I guess you'll have to go with a standalone DB frontend; which means you don't have to worry about when your dream of everyone having a stack player will come true. I have no idea if this would work but as for the problem of screenshots, could you capture key strokes (is it CMD-OPT-3 on the Mac?) and put 'empty' into the fields so they appear blank? Of course anyone can work around this by starting 'Grab' (on Mac) and using the Menus to do a screenshot. Could you blank the fields anytime your app is no longer front most? Just some thoughts. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
