On Wed, Apr 28, 2010 at 11:00 AM, Daniel Salazar - 3Developer.com <zan...@gmail.com> wrote:

As I was mentioning with Daniel on IRC, I completely agree. These 'security' additions have always caused me more trouble than benefit and I have had the same experiences at my studio in the past. For example:

* People loading up files, animating and keying not knowing that python constraints etc had decided to switch themselves off, meaning that when they were enabled again, the animation was screwed

* Problems with render nodes on farms not enabling drivers/constraints that you only notice once you get a several hour long render back from the farm

This stuff is unnecessary in a studio environment, and costs money directly in wasted time. To paraphrase what I said in IRC, the problem is that this system is trying to solve a problem that a) hasn't existed and b) doesn't actually solve anyway, while at the same time it causing considerable trouble for people who are actually using blender - the cost/benefit equation is way out of whack. There are security risks for any kind of unverified file that you download - it could be a python tool that you download, or for example look at the amount of people who blindly download builds from graphicall.org which could contain anything, or any other files from the internet either.

But now we have this current situation designed to satisfy theoretical concerns by people who may not have to deal with the practical consequences. It won't really stop people from getting into trouble, but instead *stops your own work in your own files from functioning*. This is very frustrating and I think something has to change here.

Matt