Locking files

[Lucas Krech]

Is there anyway to lock files for Q-Lab shows so that they can't be copied and ported over to a different hard drive? I'd like to protect original work from would be copyright infringers.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

Vimeo.com/LucasKrech

Twitter: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"What is to give light must endure burning"

~Viktor Frankl

[Keith Smith]

On 11 Sep 2012, at 04:36, Lucas Krech wrote:

> Is there anyway to lock files for Q-Lab shows so that they can't be copied and ported over to a different hard drive? I'd like to protect original work from would be copyright infringers.

In practice you can protect yourself from everyone except those with the password for the account QLab runs in. But there is a cost, e.g. turning on disk encryption.

Who are you trying to protect yourself from and under what scenarios would they have access to the computer?


K.

[Jeremy Lee]

Would LOVE this. I've suggested in the past that I'd love to see a way to create a QLab Monolith file that would both encrypt the audio files and tie it's use to QLab's authorization system. Reviving a show? Rent a license to use it at a rate I set as a designer, and Fig53 could even take a cut for processing the money.

I'm hopeful that we'll see something like this in a future version.

On Sep 10, 2012, at 11:36 PM, Lucas Krech wrote:

> Is there anyway to lock files for Q-Lab shows so that they can't be copied and ported over to a different hard drive? I'd like to protect original work from would be copyright infringers.
>
> -L
>

--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com

[Lucas Krech]

I leave my work on the computer when the show opens and go off to do other shows so that means weeks or months where anyone with access to the computer has access to the files. This applies to my original work worth, easily 10 million dollars a file(give or take a few ;-), but also works licensed under a limited use scenario. Would be great to protect both my and other peoples work from potential misuse or theft.

Jeremy's idea of a password lockout system for file access sounds fantastic.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

Vimeo.com/LucasKrech

Twitter: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Don't tell me the moon is shining; show me the glint of light on broken glass."  

~Anton Chekhov

[Jeremy Lee]

It also protects your work if the show moves but they want to replace you for whatever reason.  Or they spawn more companies.  And there was a thread maybe a couple of years ago about dance companies that send out CD players (or something) with the door glued shut so that you can't copy the audio...

[Paul Gotch]

Frankly if you can play it you can rip off the audio assets, locking the file to a particular Qlab license is also a bad idea because it means it's harder to switch to a backup system if the master fails.

-p

[Jeremy Lee]

The QLab license itself allows for a main and backup system both being authorized at the same time. Most time when I use QLab, there's a lot more going on than a simple playing back of audio files- lots of layers, fades, looping, etc.

On Sep 11, 2012, at 1:31 PM, Paul Gotch wrote:

> Frankly if you can play it you can rip off the audio assets, locking the file to a particular Qlab license is also a bad idea because it means it's harder to switch to a backup system if the master fails.
>
> -p
>

> --
> Change your preferences or unsubscribe here:
> http://groups.google.com/group/qlab
>
> Follow Figure 53 on Twitter: http://twitter.com/Figure53

[ra byn taylor]

On Tue, Sep 11, 2012 at 12:50 PM, Jeremy Lee <jerem...@jjlee.com> wrote:
The QLab license itself allows for a main and backup system both being authorized at the same time.  Most time when I use QLab, there's a lot more going on than a simple playing back of audio files- lots of layers, fades, looping, etc.

On Sep 11, 2012, at 1:31 PM, Paul Gotch wrote:

> Frankly if you can play it you can rip off the audio assets, locking the file to a particular Qlab license is also a bad idea because it means it's harder to switch to a backup system if the master fails.

Many years ago my Uncle created a company that sold the hardware to laser cut out things & licensed the software to control the hardware.

Each month the user had to pay their monthly license fee. No license update, no hardware use.

In the case of Qlab, maybe there could be a DESIGN function as follows.

1. designer subscribes to a Qlab designer account & receives some sort of small license generating app.
2. designer programs show & sets up the show license.
3. designer collects fee
4. designer authorizes the show for X days / X shows / etc...

If the show needs to extend, they have to contact the designer to get a new code (customized & created in the app provided by Figure 53 )
5. designer renders out new authorization code & sends

If the show needs to be moved a new computer, it doesn't matter.
Backup rig? no concern.
Put the show on 1000 Macs if you want but the clock is still ticking.

Sure anyone could copy the files & should. But in order to load the show in Qlab, the show would have to be authorized for at least that date.

Qlab could even display showing that the file authorization ends in X days with a link to contact designer for more time.

Since Qlab is already available as a timed rental, the concept should be somewhat in place. Just add in the structure to allow for the workspace authorization.

OR

Maybe Qlab allows for the following:

"Bundle show with expiration date"

If the client wants to reuse, they'll need to replace the authorization in the bundle folder first.

Along these lines, there could be an emergency authorization code that works for 3 days (weekend) but then never works again.

There could also be a log that shows how many times the show was opened, used, etc...

Best regards,

ra byn

[Keith Smith]

On 11 Sep 2012, at 17:26, Lucas Krech wrote:

I leave my work on the computer when the show opens and go off to do other shows so that means weeks or months where anyone with access to the computer has access to the files. This applies to my original work worth, easily 10 million dollars a file(give or take a few ;-), but also works licensed under a limited use scenario. Would be great to protect both my and other peoples work from potential misuse or theft.

Leaving aside the question of wether or not having so many of your shows on a computer you leave with people is a good idea - or even if this whole concept is a good idea, the *easiest* way of getting what you want is:

1. Create a separate user account for each show, give the account a unique password
2. Get yourself a password manager (you're going to need it)
3. For each show account, turn on File Vault. To do this you must be logged in as that show user, then enable it in Control Panels -> Security -> File Vault
4. Make sure that *all* media used by a show is copied to a folder within the show account's Home folder
5. Work with QLab as normal, but make sure that the cue files are saved within the account's Home folder somewhere
6. Make a file based backup from within the account
7. Give the user name and password of the relevant show account to that show's crew

Some notes:

• File Vault (account based disk encryption) is used to prevent someone booting the computer in Single User Mode (or from DVD) and getting access to the files
• If you forget the password for an account and you didn't make a backup from within the account (i.e. your backup files are not encrypted) you have lost everything in that account - you will not get it back. 
• There is both a CPU and disk performance hit doing this, make sure you take that into account if you are lobbing lots of HD video around

Regards,

Keith.

[Keith Smith]

Do you realise that you are suggesting adding a whole Rights Management system to QLab?

I'd like to go on record here and state that I think this is a Really Bad Idea.  Can you give me even a single example of a DRM system that has worked well?  Heck, can you give me an example of one that has even worked in all cases?

To say nothing of performance and resource implications.

There are more pragmatic ways of dealing with this problem.

Regards,

Keith.

[Mike P]

I'd also think Figure53 should have a long conversation with their legal advisors before taking on custodianship of someone else's intellectual property.

Mike Post
(601) 307-8657
mdp...@mac.com
http://mdpostdesign.com

[Rich Walsh]

On 12 Sep 2012, at 00:58, Keith Smith wrote:

Leaving aside the question of wether or not having so many of your shows on a computer you leave with people is a good idea - or even if this whole concept is a good idea, the *easiest* way of getting what you want is:

1. Create a separate user account for each show, give the account a unique password
2. Get yourself a password manager (you're going to need it)
3. For each show account, turn on File Vault. To do this you must be logged in as that show user, then enable it in Control Panels -> Security -> File Vault
4. Make sure that *all* media used by a show is copied to a folder within the show account's Home folder
5. Work with QLab as normal, but make sure that the cue files are saved within the account's Home folder somewhere
6. Make a file based backup from within the account
7. Give the user name and password of the relevant show account to that show's crew

Why go through all those hoops when you can just stick the show in an encrypted disk image? Not that this actually addresses the problem at all: in order to run the show people have to have read access to the show media, at which point they also have the ability to copy it – whether it's in a FileVault or on an encrypted partition (which you can also do), or whatever.

Presumably no-one other than the "show crew" who know the password are using the playback machines anyway, are they? So what, exactly, are you achieving here?

There isn't a way round it unless Chris does what Jeremy outlined: encrypt the QLab file itself. It is surprising how few people understand that they are only _renting_ a design for the run and should delete it at the end – and that they can't snaffle sound effects out of the folder and put them on their server. On the other hand, I've only had someone steal a design once – and what they stole was slightly more intangible than the media: it was the ideas of where the sound effects should go and what they should be…

A good contract rider is a start, and a quick email to your operator at the end of the run (and/or the hire company) asking them to erase the show is worth it too.

Rich

[Keith Smith]

On 12 Sep 2012, at 01:18, Rich Walsh wrote:

> Why go through all those hoops when you can just stick the show in an encrypted disk image?

Yep, that would work too.

> Not that this actually addresses the problem at all: in order to run the show people have to have read access to the show media, at which point they also have the ability to copy it – whether it's in a FileVault or on an encrypted partition (which you can also do), or whatever.

I thought the OP wanted to protect media from other shows stored on the same computer - not the current show.

> Presumably no-one other than the "show crew" who know the password are using the playback machines anyway, are they? So what, exactly, are you achieving here?

I kind of alluded to this with my comment about weather or not this was even a good idea (I actually don't think it is - I was just responding to the OP's question).

But to answer your question, you prevent the current crew from accessing other shows that are (apparently) also be stored on the computer. Although, I kind of feel that if you don't trust your crew you've got bigger problems.

> A good contract rider is a start, and a quick email to your operator at the end of the run (and/or the hire company) asking them to erase the show is worth it too.

Agreed.



Regards,
Keith.

[Jeremy Lee]

That's not usually an option in the regionals. It's fine if you own or are renting the gear. But still doesn't stop the operator from copying the files and giving them to the producers when asked. 

Jeremy Lee

- A thumb is a terrible speller. Please forgive my trespasses.

[Jeremy Lee]

You wouldn't have to use it. Kontakt Libraries are copy protected, and it works well and unobtrusively. And it took maybe 15 years for the iLok to be broken, and people had a lot more incentive to crack it.

I think it could be a useful and unique feature. And it would protect the designer. No copy protection is ever unbreakable. But it makes people go out of their way to be bad players.

Jeremy Lee

- A thumb is a terrible speller. Please forgive my trespasses.

[sam kusnetz]

i think there's a big difference between an encrypted "monolith" file and a full-blown DRM system. (can we give the file a shiny black rectangle for an icon?)

i would love to be able to create a read-only bundle, and i'm very interested in optionally giving that bundle an expiration date. i'm not particularly interested in anything more complex than that.

[insert disclaimer about how i contract for figure 53 but this is just my own opinion, blah blah...]

cheerio
sk
--
sam kusnetz, sound & projection design | USA-829
503.201.2591
s...@notquite.net

[Lucas Krech]

 It is surprising how few people understand that they are only _renting_ a design for the run and should delete it at the end 

A good contract rider is a start, and a quick email to your operator at the end of the run (and/or the hire company) asking them to erase the show is worth it too.

The renting aspect is a big part of where my question comes from. Even though my contracts clearly state I retain all rights to the design and content etc. etc. many people don't *get* or respect that. Also, there is no guarantee someone affiliated with the company, or the playback computer, down the road won't just lift something. Often the computers that I end up using for playback are owned by the venue or producing company.

Also Jeremy's concern about the actual content within QLab as proprietary design work is a good point. A password protected lock which only gives visibility to the info tab as read only and the called cues (i.e. not auto-follow/continue)  would be nice. Perhaps limiting by cue list so that one could make a cuelist of start cues that could only be seen referencing all the programming and not actually have access to the individual elements within a cue.

I'm almost considering building a video playback system in Quartz Composer and then wrapping it as a simple application. While it doesn't encrypt the data (which would have serious performance issues) it gets it to the point that someone needs some actual computer knowldge to examine the package and find the content. Which as Jeremy says "makes people go out of their way to be bad players."

Of course I'd prefer to just keep using QLab rather than build a whole thing myself.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

Vimeo.com/LucasKrech

Twitter: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"What is to give light must endure burning"

~Viktor Frankl

[Jeremy Lee]

I've been handed copies of cues from previous workshops or productions on numerous occasions. It always makes me uneasy using them, and I always ask that the producers clear it with the previous designer. I'm sure close to 100% of them have not.

Given this history, I'm sure that my work has been passed around from time to time without my knowing it. Certainly, my shows have been built from time to time to Dropbox, synced with an SMs laptop. Many people don't understand that I own the work they hear. Others just don't care. It's part of the business. I'd protect it in a heartbeat if I could.

Jeremy Lee

- A thumb is a terrible speller. Please forgive my trespasses.

--

[Lucas Krech]

It would be awesome even to have the files bundled into the QLab file when your click bundle workspace. While it would not lock them up tightly it would require someone to do some serious snooping around package contents to get at them. Which makes it more explicitly theft and thus a greater deterrant than simply copying some MP3s or MOVs which in the world of bitTorrent doesn't cause most folk to bat an eyelash.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

Vimeo.com/LucasKrech

Twitter: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Don't tell me the moon is shining; show me the glint of light on broken glass."  

~Anton Chekhov

[ra byn taylor]

On Tue, Sep 11, 2012 at 10:41 PM, Lucas Krech <des...@lucaskrech.com> wrote:
It would be awesome even to have the files bundled into the QLab file when your click bundle workspace. While it would not lock them up tightly it would require someone to do some serious snooping around package contents to get at them. Which makes it more explicitly theft and thus a greater deterrant than simply copying some MP3s or MOVs which in the world of bitTorrent doesn't cause most folk to bat an eyelash.

Seems like a simple route to take is to be able to bundle with a workspace file that expires.

This leaves the content bare & useable but it means the average person who copies it & tries to use it down to road won't get it to work.

Certainly without notes & spending a lot of time trying to recreate it.

It also means that unless someone knows this, they won't start worrying about it until it's too late.

In which case, upon trying to load the show, a "this show has expired. For an extension or to renegotiate usage, contact (insert your name & contact information here)."

For those designs that are so simple, anyone could recreate it, so be it. Recreate it if you like.  For shows that are complex enough to where it will take a Qlab wizard, I'd think that the average producer is going to call you asap once they know the show won't work out of the box.

If an EXPIRATION BUNDLE also renamed the raw audio & video files, something that doesn't make sense without a key of sorts (only available to the designer), it would be pretty difficult to recreate things.

Once a show is expired, the warning that shows on the screen when you attempt to load the show could also allow for a password to unlock the bundle (for the visiting designer).

Sort of like what we have at our disposal on DSP configuration software.

There is a designer level of security (all access to everything)
There is a user level (access to tools such as main eq, main comp, etc...)
There is a high end user level (access to features that are needed from time to time)
etc...

If someone bootlegs your show, chances are they're not going to immediately test it to see if it works. Just copy it. 6 months or 2 years later, if they go to try it, the path to the designer is clear. "Contact such & such (with an email /skype / message / link ((whatever the designer put in the contact area when setting up a "EXPIRATION BUNDLE" )).

For those who need not worry about their designs being used, just ignore the special bundle option (that is not in the same place as a standard bundle option).

For those that do, they must setup a separate area before the EXPIRATION BUNDLE even becomes available. Even then there are warnings along the way to make sure the person bundling knows that they're making a dead end bundle.

Before the bundle process is complete, maybe QLAB has to generate a file that has all the keys to opening the bundle again & also what the setup was. Maybe Qlab even has to send out an confirmation email with the information that has to be responded to before the bundle is rendered.

I wouldn't mind some inconvenience in exchange for some IP protection.

BUT if this whole concept is going to make Qlab crash or sound like crap, NO PLEASE:)

ra byn

[Lucas Krech]

Seems like a simple route to take is to be able to bundle with a workspace file that expires. 

This leaves the content bare & useable but it means the average person who copies it & tries to use it down to road won't get it to work.

I was using 'bundle' in the OSX meaning where files get tucked and hidden inside other files. Not the QLab meaning where they get copied to an open file.

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

Vimeo.com/LucasKrech

Twitter: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"More light!"

~Johann Wolfgang von Goethe

[citikid]

I found this thread via a google search and it seems like the only logical conversation about this topic anywhere.

Has there been any progress made to help designers protect their work?
I think some great suggestions have been made on this thread.
I'm using 2.3.8 pro bundle.

I was imagining something as simple as adding password protection to the lock function which would not only prevent changes to the workspace but also disable the bundle function. I know that the files would still be vulnerable but with a little intuition the files could be hidden in invisible folders which, while not perfect, would at least make a thief work for it a bit.

The ideal solution would be a bundle function which encrypts the audio and has an expiration date.
It seems figure 53 has taken the time to include time stamped authorization for the program when leasing it. Perhaps the same code could be deployed by designers for their workspaces.

Audio content producers whether for sound design or music are the easiest artists to steal from.

I work in NY and have had my work lifted at least once -  that I know of.

[Christopher Ashworth]

Hi there,

Welcome to the list, it's good to have you.

We have internally had a lot of discussion about this, informed in large part by the public discussion from this thread on the list, and others.

We have some ideas about some simple read-only file bundled file formats we may one day explore. If this happens it would of course be for QLab 3, rather than QLab 2. I agree that there are definitely some tools that we could provide to help designers encourage the proper use of their work.

That said, I am only in favor of simple and clean approaches to help "keep honest people honest". This is the same philosophy we take with our own licensing of QLab, and I stand behind it firmly. We've been contacted by multiple content companies asking us to add support for "encrypted", or DRM'd audio playback in QLab. I empathize with the goals, but strongly disagree with that approach. Every product that has gone down that road has come limping back defeated in the end.

Technology can encourage the right behavior, but it can't ultimately enforce it, and it is with a heart full of love for all the designers out there that I say: I believe it's better to take a different approach.

best,
Chris

[citikid]

Hi Christopher,
Thanks for the reply and info. I understand that for colleges and small regional theater who are programming simple ambient sounds this is a non issue.
But for those of us in larger markets where the content contains customized and complex designs the value of copy protection is important.

If you guys could add an option to password the "lock"  function and also disable file commands while the lock is enabled, most importantly "bundle" that would be a great first step.

Allowing designers to enter an expiration of a workspace under the same password would be amazing. (I can figure out how to hide audio, somewhat.)

Those are both pretty simple features that would not take much resources to implement and would not change the program for customers who do not need them.

The read only File Bundles would be super amazing!

With respect to companies limping back from encryption / DRM attempts. Please keep in mind that what I, and the others on this thread, are suggesting is not a mandated new feature like Apple did with it's early DRM. But rather an "option" for those designers who actually create content that is worth protecting.

Native Instruments,  Propellerheads & Steinberg are just a few companies that have managed to create formats to protect their content providers while maintaining functional transparency to the end user.
But I know that could get into licensing costs that could affect all Qlab users so I can understand why it wouldn't be at the top of the list.

Anyway - Thanks for a smart and fun program.

best wishes

[Andy Leviss Lang]

On Wed, Aug 7, 2013 at 12:22 PM, citikid <mypla...@yahoo.com> wrote:
> Thanks for the reply and info. I understand that for colleges and small
> regional theater who are programming simple ambient sounds this is a non
> issue.
> But for those of us in larger markets where the content contains customized
> and complex designs the value of copy protection is important.

I think you could do this by setting up an account with limited
access, so that it can't run updates, etc, and then running a few
terminal commands. You'd probably want to make it a Parental
Controlled account so you can block network access, etc, or get into
the heavier duty world of MCX management or Profiles, which is a
special world of hurt.

See this link for how to lock down USB and FireWire drives, with the
caveat that I haven't tested this at all, and that post is with an
older OS version, but it *should* work on 10.8. You'll need to disable
it when you want to use an external drive from any account, but bear
in mind that only an Administrator account will be able to
disable/enable it. If you lock down Parental Controls, you can block
access to the applet, so you'll need to log in as the Admin to
re-enable.

HTH,
Andy

[Christopher Ashworth]

On Aug 7, 2013, at 12:22 PM, citikid <mypla...@yahoo.com> wrote:

With respect to companies limping back from encryption / DRM attempts. Please keep in mind that what I, and the others on this thread, are suggesting is not a mandated new feature like Apple did with it's early DRM. But rather an "option" for those designers who actually create content that is worth protecting.

I understand, but disagree. I don't say this to be rude, just to be clear: I don't expect to ever support DRM in QLab.  I don't want to set the wrong expectation, or the wrong hopes.

As mentioned, I do think we can look in to tools to help the end goal, but DRM isn't one of them.

-C

[Craig k]

A few years ago, we almost lost a show of a major mega musical because one of the Windows machines decided that it was no longer the same machine (it hadn't changed a single thing) and we needed to call Redmond to get a new authorization ( on a sunday).

I'm all for protecting IP, but I hate when a show gets messed up.

Craig.