Forum

Protect patch form stealers?

Hi. Is the way for protect my patches and software from stealers, when i use it’s on standalone installation? I can’t found any info, about exporting patches to closed executables or just patches, thats nodelist can’t be viewed.

you can lookup the patch - but if anybody knows this little trick ;) maybe the easiest way is to remove the keyboard and mouse!

and no, you can’t export patches … I remember that there was somewhere written that the vvvv guys can export a patch for you … but I think that will cost money and I’m also not sure if that feature is still available.

Edit: ok, I was wrong - see here at the player license comment.

the latest release also features a -shutup command line option, which will leave all patch windows closed. obviously anybody who knows vvvv can just open your patches without the -shutup command. but anybody having a clue about vvvv will most probably guess what you are doing anyway.

Setpatch (VVVV) is quite usable to randomly shift your nodes around to make sure nobody will get an idea how your patch works. make sure to have a backup.

@m9dfukc:
player license is just a license, and not a real player:

Note that this is only a different license; not a different software with any additional features or feature limitations.

@oschatzt:
I really agree on the need of a ‘somehow’ magic way to stand alone…
hidding makes me really fear…
completely understand that you wont do a standaloner.exe that will compute patches. Ok.

next year i have a project with vvvv where the man who will tour the installation is not at all computer minded … he is part of the group so i have to find out a way on HOW there could be no catastrophic accident.

Could devvvvs propose a separate exe, that output only rendering windows, without doing the stuff of hidding patchs locking them or dispatching them randomly ?
hidding and desappearing patchs… brrrrr … too much mismatch and fear…
this could be a nice way to protect patch from epilleptic fingers and to enables to use vvvv for editing patch if needed.
lets say it could be named the_vvvv_renderer.exe ?
disabling mouse calling menu could be great also ( just an arg to launch the viewer)

I hope oschatz you will have a friendly eye on this post.
in theatre field, its rarely people who build patches that will tour it… and user and its practice are really in the heart of our preoccupations.
i hope this proposal is not a real complex work for devvvvs, but will answer to this real preoccupation…

;-)
cheers

To stop things getting messed with you can write protect your patches and subpatches, meaning that you can’t accidently break something and save it accidently, maybe good for that touring situation?
This has always been on my wishlist, but so long that I’ve stopped thinking about it!

yes Cawtweasel,
thxs for your advices.

but that should be more really convenient just to launch a kind of vvvviewer…

somehow a nasty hack but what about following:

writing a little program that encapsulates the vvvv folder and your patch - when you start the .exe the encapsulated files get extracted and start running … if now somebody changes something in the patch it’s not that fatal because the next time you start the files get extracted for a new.

hmm you get what I mean - little early in the morning to write correct sentences :)

Edit: Ok, I’m not sure if thats maybe against the vvvv license? maybe oschatz can answer that!

another way is to have a limited windows account
disable the usb for external storage…remove mouse & keyboard
lock + shutup + Setpatch your patch
and put a padlock on the pc case :)

there is also the dongle approach …see joreg post
http://vvvv.org/tiki-view_forum_thread.php?topics_offset=1&forumId=7&comments_parentId=18328

next vvvversion will have a security interface to use encrypted patches, this was also the background to implement the /shutup option. however, it will require coding for each one who wants to use it. you have to write an application to encrypt .v4p files and place a .dll into vvvv’s bin directory, which is called by vvvv to decrypt them.
if someone needs help or coding of such a thing, please contact me, thats my job: tebjan_at_gmx_de.

yes lets all encrypt our patches on vvviki so no one can steal them… :D

see joreg post:
"some call such views naiv, i call myself joreg."

… beautifull… a long time i didn t read something with so much senses…

ok, m9dfuck, your solution of zip unzip could be somehow ok…

but from all this discussion, suggestion of tonfilm is rather good and serious…

could be interresting to developp an app that enables it…

tonfilm it sounds really hard coding…
i mean we are not talking about enccrypting in 128 bits, thats right ? just s"omething impossible to alterate working patch and enabling just the use of the GUI" ?

imo, there are two scenarios here:

the casual thief who does not know too much: he will be deterred from just grabbing your patch by simple measures (e.g. /shutup)

the IT/vvvv savy guy who is determined to get your patch: he will (following experience with DRM/copy protection over the whole IT field) only be stopped by really extreme measures, which may very well impact usability/stability/experience for “regular/honest” customers. you will definitely want to avoid this!

so, my 2cents are that you should implement some mild protection scheme because anything that stops every attacker will also piss off regular customers.

@kristouf, the coding complexity depends on the requirements, a basic encrypt application/decrypt.dll is easy to implement and would protect you in most cases. and it has a second advantage: its forbidden by law to break a copy protection. but ofc its not very save against specialist, like bilderbuchi described.

coding complexity grows rapidly if you want to use things like usb-dongles and/or data management with key/user/product associations.

we are never inventing things, we are always recreating somehow things ;-)
so the idea of stealers is quite laughable, somehow.
for me, i m in care of a end user that should not be in a nightmare with a complex patch not working at one hour of the performance…

so i m just thinking of protecting patches from end user, letting it having only GUI in render window , and not being able to go from vvvv to patchs , close subpatch accidentaly, or find them and maj=ke a wrong short cut with keyboard …

just in fact protecting end user
do you think tonfilm that a dll encryption could reply to this subject ? sorry alg for this piracy act on this act

we are never inventing things, we are always recreating somehow things ;-) so the idea of stealers is quite laughable, somehow.

very true… i think the shutup is quite a cool feature but i dont like any kind of patch encription that much. poeple who encrypt their patches shouldnt be allowed to use patches/knowledge from the vvvv community in my humble opinion… of course i know that they do anyways and use stuff commercially and silently, and theres nothing you can do against it except to keep things open :)

this also leads to the question under what license poeple should publish there stuff, because for now most users leave the question open how their stuff can be used.

i really like to publish some stuff, which i spent quite some time on but im unsure under what license i should do it…

i like the gpl model but im unsure if its combatible with vvvv itself…

+1 Elektro :).

+1 Elektromeier

@Ele: maybe creative commons!?

+1 also Elektro !

why a not a www.vvvv license ? i mean all interresting stuff provided by community is included in the site and may arrive in the include files of vvvv…

rather sincerely, i think there is no use of license, than asking for people if they use hardly your patch a little thx written somewhere… ( myself i ow a beer to uncle west and uncle kalle)

good idea.
i’m going to add a
“if-you-use-his-modules-and-you-meet-him-offer-him-beer-and-singlemalt-whiskys-until-he-begs-you-to-stop”-license to all my sites.

hey ! we said a beer, not a hot and toxic mix with whiskey !
;-)

ok, if you have a turkish shop around, i will make you a true lebaneese babaranouj…