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
_______________________________________________ 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]
