password protection option for Locked VIs (read-only VIs)

[Nate_Moehring]

Currently the Protection options are Unlocked, Locked, and Password-protected.  I'd like to add a sub option to Locked, or perhaps a new option altogether that still allows you to view the diagram but not edit the VI unless you have the password.

I want to allow people to run and view all parts of the VI, but not allow them to make any changes to the VI unless they have the password.  This is one step above Locked and one step below password-protected which does not allow the user to view the diagram.

This is useful in an internal environment where you have many LabVIEW-savy users who want to look at how things work, but you still need some level of configuration management and you don't want to allow them to modify VIs.

To make this idea work and meet our needs NI would need to add support for two passwords:  One that prevents the user from modifying the VI and seeing the diagram (the current password-protected option), and a new password that prevents the user from modifying the VI but allows them to see the diagram and VI settings.  This is because we like to be able to debug problems even on a released application so we don't remove diagrams, we just password protect them.  Our release process would utilize both password options.  We would provide the read-only password to users as needed but never give out the modification password.

[Darin.K]

> Hostility? That's overstating it. I just see it as a complete waste of R&D time for a feature that serves no useful purpose.

Outside of ad hominem attacks, that is about as hostile as one could get toward an idea.  It is a valid judgment to make, but I find it easier to accept "I understand what you are asking for and think it is a waste of time" instead of "I do not understand what you are asking for but think it is a complete waste of time". 

> On desktop, I cannot see any reason whatsoever why it is critical to look at the actual code that is running on the actual deployed machine such that a copy or picture of "that which was deployed" is not sufficient.

As a scientist I can see very valid reasons to look at the actual code on the actual machine.  You immediately rule out all issues of provenance.  And until such time as it becomes impossible, or at least hard, to obfuscate code then images just don't cut it.  Plus you get immediate cause and effect, you can see a subVI ran and now your voltmeter is screwed up.

> When an EXE is running, you can't look at the "running C++" code, except as a separate file on disk.

I am under the impression that LV costs $$$ because it is better than working in C++, I would count this as another opportunity to do something that cannot be done in C++.  (Aside:  I think the constant analogies to C++ are detrimental and the goal should be to maximize the effective of graphical programming, not simply create a graphical analog to C++). 

> If you post some large hierarchy, why force me to duplicate all your libraries/VIs by hand just so I can edit it? If LV had this feature, we'd have to have some sort of "Save As a duplicate hierarchy, stripping the password even though you don't have the password" in order to make it useful

Why?  Because I care about helping people figure out how to do something much more than helping people get something done.  And no I would not allow Save As... without a password either.  It is like a photographer giving you any size print you want, but not the digital image.  If you or anybody else is not satisfied with being shown how to do something, but actually want the work done for them I would be happy to quote a reasonable hourly rate.  And I do not need security measures that make it impossible to get the code, just enough to make it easier to do it yourself.

So no, there may be nothing here for the large industrial clients, nor the large developer groups, but there most certainly is something there for those of us who still put the "Lab" in LabVIEW, or is it still put LabVIEW in the Lab.

[Intaris]

I wrote a utillity years ago which took the HTML documentation of a VI and inserted links into is so that one could move up and down the hierarchy and view the images (only the icon in the sub-VI list was linked, not the icon in the BD itself).  Would that be an option instead ofa ctually allowing the users to view the running code?

[Darin.K]

I have something along those lines, but as the saying on the forums goes, you can not debug a picture.  It can be very helpful to sit and observe the execution of the code in situ and even drop a probe or three, or just monitor a subVI. 

[AristosQueue (NI)]

> It is a valid judgment to make, but I find it easier to accept "I understand what

> you are asking for and think it is a waste of time" instead of "I do not

> understand what you are asking for but think it is a complete waste of time". 

I do understand what you're asking for. I just don't understand why. 😉

If it helps, I wouldn't spend this much time replying to the idea if I wasn't trying to get a better understanding.

[Darin.K]

> I do understand what you're asking for. I just don't understand why. 😉

Short answer.  Because for a group of us it is a real solution to a real problem we have which is why we use LV in the first place.  Not all problems are hardware and software, some are sociological (people are much more inclined to poke around a picture of code than touch a piece of text code).  [As a poor text programmer you may not realize that in LV the entire compile process is a run button click away.  So easy even a theorist could do it, and they will.]  This option seems simple to implement (PW protection exists, Run Mode exists, just gives us the option to move the bar a little bit as to what is allowed in a PW protected VI). 

Let's try a different analogy. Something is making a funny sound (intermittenly) in my car and as a clever engineer you figure it must be easy to fix.  My solution, when it acts up:  you can pop the hood, you can connect a diagnostic code reader, and you can start it up and listen and look.  You CANNOT under any circumstance use a wrench, hammer or screwdriver unless I hand it to you.

Or, I could hand you a picture of my car and prevent you from popping the hood.

Is it a perfect solution, no I would probably drive around with my mechanic 24/7 until it happens since it never happens at the shop.  But it is pretty good, and much better than a picture.  (Of course you could suggest my driver simply goes to the corporate motor pool and picks out a new one, or however it is the industrial world lives...)

Finding problems is usually much easier than fixing them.  This method lets me empower users to find the problems but leaves the fixing to trained professionals.

(I like good holy wars when it is something that effects everyone, like say forcing terminals to be viewed as icons, but here those who do not see the need or point can simply ignore it like so many other features).

[Intaris]

>Finding problems is usually much easier than fixing them<

Not in my experience it's not.

[Darin.K]

> Not in my experience it's not.

I am so glad that is your experience, it was very easy for me to find I have a memory leak in my 3D pictures.  Now that I have done the hard part you can tell me what to fix... 

[AristosQueue (NI)]

> You CANNOT under any circumstance use a wrench, hammer or screwdriver unless I hand it to you.

And that's what has me bugged. Edits to the config file are as big a threat to your system's correct function as any VI edit. Changes to the data files that drive your tests are also a threat. It isn't just the VIs you have to worry about. Even if LV locks out the edits, if the file system is still open, they can still change stuff. If you don't want them changing stuff, you have to make the files read-only and take away their admin access. If you do that, leave the diagrams not password protected and turn on Treat Read-Only VIs As Locked in the config file (which should also be read-only and restricted).

If you are in an industrial environment, problem solved, and solved far better than this not-really-a-password idea. 

If you are in a lab environment, there's no amount of restrictions that you can add because those people are in charge of their own machines. They're free to monkey around, so they probably will. Put the VIs in Run Mode to lock out any accidental edits and tell them not to change things. You can't do any better than that if you don't trust your users anyway. And if you do trust your users, then you don't need the password.

> (I like good holy wars when it is something that effects everyone, like

> say forcing terminals to be viewed as icons, but here those who do

> not see the need or point can simply ignore it like so many other features).

You're missing the category of users who should ignore it but don't. When R&D puts a new feature in, some user far away from these forums sees it and thinks, "Oh, this is how I should solve that problem." So they use it, even though it is actually a poor solution to actually locking the file system or getting a "compare directories" script that you can use to check for monkeying. That's exactly what happens with passwords on block diagrams today for people who have IP to protect, when what they should be doing is distributing without block diagrams entirely (for most users that I know of, they don't have to worry about recompiles or supporting multiple platforms, so this solution is actually right).

You have to convince me not only that *you* have a use for it but also that it doesn't pollute the LabVIEW environment or mislead other users.

[Darin.K]

> Edits to the config file are as big a threat to your system's correct function as any VI edit.

Your critical config files may be human readable and editable.  Mine are not.  They are created and validated with a GUI and encrypted.

> Changes to the data files that drive your tests are also a threat.

This is where your perspective is very different than mine.  The program is a contract that certain inputs give certain outputs.  Touching the code violates that contract.  Bad data is simply garbage in gives garbage out.  Not a concern for me, well-written code should handle this.

> If you are in a lab environment, there's no amount of restrictions that you can add because those people are in charge of their own machines. They're free to monkey around, so they probably will. Put the VIs in Run Mode to lock out any accidental edits and tell them not to change things. You can't do any better than that if you don't trust your users anyway. And if you do trust your users, then you don't need the password.

So much to learn of the ways of grad students.  I expect them to monkey around and be quite clever about it.  The uncurious ones are the bigger concern.  It is nice to set a few boundaries, nothing to do with trust, per se.  It is a way to keep unqualified hands off, qualified ones get the password.  It is not to protect IP, this is using passwords as the weak protection they really are, not trying to oversell their protection. 

> You have to convince me not only that *you* have a use for it but also that it doesn't pollute the LabVIEW environment

In twenty some odd years I have lost track of how many miles, yes miles, my wrist has had to travel skipping over things that I have skipped over every single time for twenty some odd years.  I somehow doubt an added checkbox in a vi property menu I'll wager gets very little traffic to begin with really rises to that level.  If you would like ten or even twenty things to remove from the environment to make room I have plenty of suggestions.  I really would like to believe that pollution is a concern and not an excuse to rule out certain changes, but then I open a new install of LV and get slapped in the face with the Express palette.

[Intaris]

>

I am so glad that is your experience, it was very easy for me to find I have a memory leak in my 3D pictures.  Now that I have done the hard part you can tell me what to fix...  <

I can actually.  But it seems out definitions of "Finding the problems" is different.  I would list "memory leak" as a symptom, not the problem.  Not closing references in the 3D Graph, that's the actual problem.  Armed with that knowledge, the solution is rather simple.

But back to the point on hand.  If your code is a contract, then why on earth should others have the ability to change it at ALL.  Surely you need to lock down your version so that the contract cannot be invalidated by third parties and then provide parallel access to the system which can be marked as "dirty" and not covered by the contract.  You can't view a program as a contract that certain inputs give outputs AND give third-party access to the code (even via password).  That just doesn't work.  As such I have a hard time reconciling your reasoning with the request made.  I don't see the idea you posted as being a proper solution to what you say you want to implement.  Your contract only covers the original code without any modifications whatsoever.  This can be fulfilled only by removing the diagrams.