It runs some, like I had polygon mode of GLTools running, but then
AntiAlias made it 'highlight' with lines with thicker white lines and
it looked all wrong.
Thanks for clearing that up.
On 20/06/2011, at 4:19 PM, vade wrote:
This is in the application side, completely outside and has nothing
to do with Quartz Composer at all.
You load a file via NSData dataWithFile or dataWithURL presumably
from your application bundle. That file is encrypted.
You run some magic algorithm you have to decrypt the NSData to its
original state
You initialize a QCComposition from the data
You initialize a QCRenderer using the above composition
You now render.
Run the steps backwards to get an encrypted file (make a
composition, load the file as NSData, magic encrypt it algo, then
save the file)
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.
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
The machine does not isolate man from the great problems of nature but
plunges him more deeply into them.
Antoine de Saint-Exupery
_______________________________________________
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]
