"...it just occurs to me that a basic patch"... This should have read "virtual patch". Sorry.
-gt On Mon, Jun 20, 2011 at 2:49 AM, George Toledo <[email protected]> wrote: > > > On Mon, Jun 20, 2011 at 2:19 AM, vade <[email protected]> wrote: > >> >> Now, considering you are not making an app, you are almost totally out of >> luck, unless you write some custom plugins to load an encrypted composition >> within an un-encrypted one. So you'd be loading two comps, one unencrypted >> plain one which is simply a single instance of your "de-crypter" plugin. >> That plugin points to a URL of an *encrypted* composition. Now, the issue >> is, I dont think Keynote will happily run 3rd party plugins since its 'safe >> mode'. If it does, thats your solution. >> >> > A feature request for some variation of "virtual patch" or something like a > composition importer, as opposed to loader, to do that would probably be a > reasonable way of handling that, it seems like. A patch could embed the > contents of the qtz as encrypted data in the qtz, and then decrypt it, and > that should be currently possible, but wouldn't work because of safe mode, > or would work but would be non-standard API. > > This is basically the same thing you're saying, it just occurs to me that a > basic patch is sort of a black box in the qc editor, not so much in plist > editor, and there's the ability to flatten it. If it was encrypted data with > no ability to flatten, like a "locked" virtual patch, it would probably be > useful to a lot of people, for reasons other than protection even. > > > >> >> On Jun 19, 2011, at 9:19 PM, Alastair Leith wrote: >> >> Thanks Christopher >> >> Fundamentals I still don't *get* (apologies to the wise): >> >> If I was to employ someone using this QCComposition +compositionWithData >> method what do I end up with? Are we building a plugin that I incorporate >> into a standard .qtz file in the QC Editor app, or can Xcode actually build >> a .qtz file that references encrypted data so when this .qtz file is opened >> in the QCEditor most of the contents remains hidden in an encrypted file. I >> always thought a .qtz file was just a .plist describing patches and noodles >> and a bit of user data. >> >> The issue is I'm not building my own app, I *need* a .qtz (or .mov) file >> to provide the Theme user something to import onto the Keynote slides. It is >> desirable that this .qtz file only reveal user adjustable inputs and little >> else when opened in QCEditor. It doesn't want to be loading from another >> .qtz file that is a plain text .qtz file obviously, that's all I'm capable >> of today. >> >> >> On 20/06/2011, at 1:14 AM, Christopher Wright wrote: >> >> It's seems important to me that the decrypted composition resides in >> memory not written, even temporarily, to HD in plain-text. A force quit of >> hosting app like Keynote or QC Editor then search ".qtz" & sort by date will >> turn up the secret composition in plain text form otherwise (as pointed out >> by Christopher on the Kineme thread). >> >> >> In memory isn't much better than on-disk to a determined adversary. And >> to be honest this doesn't require a particularly determined adversary at all >> (more than a casual finder-only attacker, but if that's all you're trying to >> thwart then vade's "use an encrypted NSData" is more than sufficient - in >> fact, that's what the NSData API was added for. If you're wanting to >> prevent even less casual attackers, you'll need to do some leg work to find >> out how they do what they do, and then how to prevent that where possible >> and how to make it inconvenient where not possible. There's a cost/benefit >> curve between complexity and breakability, and you'll need to find where >> you're comfortable on that curve based on your constraints (how much >> complexity are you willing to write/purchase from a developer, how much >> illicit activity do you intent to prevent, etc.) >> >> >> Okay so feature request to Apple stands, as good as Apple can make it, all >> constraints considered. :-) (*Ignorance is bliss)* >> >> Casual sharing is the lesser issue, although, if a disincentive to finder >> copying is possible, great. Effortless competitor pilfering of techniques is >> the main concern. If a competitor can hire a ninja aquatinted in the >> black-arts to can-open whatever we can produce in half a day, then I guess >> I'm no better off bothering. >> >> >> >> Are you talking about writing a QC composition in Xcode that can load and >> decrypted the NSData blob from another file? Or are we talking about a >> writing a QC plugin that loads the NSData and decodes it and somehow creates >> a QCComposition object that can bind to the plugin patch's ports in QC. >> >> >> QCComposition has documented API initializers, including >> +compositionWithFile: and +compositionWithData:. you can create a mutable >> data from a file on disk, decrypt it (using any one of a variety of >> algorithms), and then feed it to +compositionWithData:. >> >> >> Your requirements aren't particularly well-defined: >> >> The encryption key remains secret from a inquisitive competitor! Where >> would it be stored or would it auto-generated at runtime and stay secret >> somehow? Or would it be stored in the Keychain at installation time thereby >> becoming safe. >> >> >> how inquisitive? Also, you're totally missing out on numerous attack >> vectors that happen _after_ decryption in memory, regardless of how locked >> down the key is. Stuff in the keychain is user-visible (via the "show >> password" check box + enter their keychain password). >> >> >> *The machine does not isolate man from the great problems of nature but >> plunges him more deeply into them.** >> **Antoine de >> Saint-Exupery*<http://www.brainyquote.com/quotes/quotes/a/antoinedes131176.html> >> * * >> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Quartzcomposer-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> >> http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com >> >> This email sent to [email protected] >> >> > > > -- > George Toledo > [email protected] > www.georgetoledo.com > > > -- George Toledo [email protected] www.georgetoledo.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
