Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

A serious blow for innovation

None of what follows affects the Actor Framework that will ship in LV 2012. It does affect the next version of the AF after that that was planned.

It has long been my goal to push as much power into the hands of LV users as possible without opening up problems for the fundamentals of LabVIEW. Certain functions are stable and usable under circumstances X but not under circumstances Y. Certain operations that generally would undermine the guarantees that LabVIEW provides about correct functionality can be used in limited situations. There has generally been a balance to be struck using those features. There have always been users that can get around the shields that National Instruments raises to try to protect that power, but historically, such users have kept the workarounds to themselves. That has changed in the last year, and it has forced National Instruments to be more conservative with what we release early.

I have been preparing to put out a pair of XNodes at NI Week that would significantly advance the power of the Actor Framework and multiple other architectures in LabVIEW. Under the hood, those functions did some things that allowed one VI to significantly interfere with other VIs, using a particular trick I had puzzled out... one of those "this is not something we want generally available" functions. However, as the password protection systems are not sufficient, I was asked to distribute those nodes with their block diagrams removed. That made creating a distribution system significantly harder, but I said ok. But this week, someone demonstrated that even with the diagrams stripped, the nature of the operation could still be recovered from the VIs. I have racked my brain but can come up with no workaround. As such, I'm not going to be able to distribute those XNodes. The functionality will have to wait until I (or someone) can build new primitives into LabVIEW, something that could not happen until at least the LV 2013 release... and since I am on temporary loan to another group and since the 2013 feature set is already well planned out, it will probably have to wait until an even later release than that. I'll spare you knowing what the new functionality actually was so you can pretend it was a feature you never would have used anyway.

This makes me unhappy. I have spent months getting these ready for release, and it was a major piece of new functionality. I would guess that this policy of more conservative feature release will affect all of LabVIEW going forward. As LabVIEW is used in more and more high profile systems, we just can't risk the ecosystem by having potentially destructive pieces of code floating around. I myself have already caused enough of a headache with the early generic VIs release.

So, going forward, I'm going to be building using only the tools that are officially documented and supported. That will narrow the power of the tools I can bring to the community, but for the stability of the community, I have to agree that it is the better choice.

=== Aristos Queue

-= LabVIEW R&D =-

0 Kudos
Message 1 of 13
(10,743 Views)
Under the hood, those functions did some things that allowed one VI to significantly interfere with other VIs, using a particular trick I had puzzled out... one of those "this is not something we want generally available" functions.

From the sound of it, the decision is based on trying to prevent the knowledge of how to do whatever it is you were doing, not to prevent access to tools/code that aren't ready for release.  I understand why management would decide that but it sounds an awful lot like security through obscurity, which rarely turns out well.

I admit I'm curious about the nature of the "significant interference" and why you needed to do it, but I guess I'll have to wait at least another 2 years to find out.

Message 2 of 13
(4,572 Views)

To me it sounds much more like a hacky workaround to get some specific functionality that because of it's hacky nature is highly dangerous to anyone messing with it. Dangerous to the extend that NI simply does not want to risk the potential support burdon by people who have find out about that hack from looking at the secret but because of less than 100% knowledge about LabVIEW can not possibly employ it safely, but will try so anyhow.

Security through obscurity maybe in the sense that the hack could most likely not be invented by someone without inside knowledge into LabVIEW internas, but not so much to lock out people from something exciting. That the password protection was bound to crumble sooner or later was to be expected but that even the no diagram case seems to be not enough to hide such techniques starts to worry me.

Rolf Kalbermatter
My Blog
Message 3 of 13
(4,572 Views)

rolfk wrote:

That the password protection was bound to crumble sooner or later was to be expected but that even the no diagram case seems to be not enough to hide such techniques starts to worry me.

I agree with this statement. Is this a known issue that will be fixed in future version of LV ?


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 4 of 13
(4,572 Views)

I'm not sure there is anything to be fixed really. If you think about it, the situtation that you could get at the code anyhow if you were determined enough, was very easily there for any compiled code. Disassembling DLLs is a trivial exercise, understanding the result only a slightly more complicated one. LabVIEW was special here since the file format as well as the internal memory format are undocumented and therefore not as easy to locate. Once you know to find them you can put them through disassembly just as much and get at the code.

"Fixing" would imply there is anything to fix about this. There isn't if you want to make the result executable. If the CPU can find the instructions someone else can too, and if the CPU can't find it, well it's just a bunch of random numbers anyhow .

If you are worried about your top secret algorithme being stolen, the best bet is legal protection, albeit that tends to get very expensive nowadays. If you insist on technical means to protect your ideas there is only one possible solution that is really close to 100% safe, although bad luck still could play you foul. Save everything on a memory stick, lock it in a steel safe and dump it above the Mariana Trench. Of course you have to destroy any other copies of it too!

But claiming that the possibility to get at your code is a valid reason to change from LabVIEW to something else, is simply useless. There is no other programming environment that can produce significantly more secure code, unless you have the full control over hardware, OS, programming environment and that includes a computer hardware case that is locked and only you having access to its inside. But any such attempt has been broken so far such as XBox, Playstation and who else.

Rolf Kalbermatter
My Blog
Message 5 of 13
(4,572 Views)

@rolfk

Thank you for your answer. I never thought about it before. Just one more question, what is worrying you if you know that code could be retrieve ? for what purpose do you use remove diagram feature ?

Thanks,

Olivier


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 6 of 13
(4,572 Views)

It's not so much the fact that information can't be hidden, than that there seem to be people with enough time at their hands to actually reverse engineer this. Maybe it's jealousy too .

I haven't really created code so far where I felt that more than password protection would be needed. And in fact quite a bit of my code is out in the open in forms of postings in fora, or as OpenG library.

Rolf Kalbermatter
My Blog
Message 7 of 13
(4,572 Views)

Rolfk: Consider, as an analogy, a lock and a key. Everyone can see the key and the lock. But the lock is 20' tall and the key is scaled to match, made of solid lead, and although everyone can see it and knows exactly what needs to be done, they don't own the only earthmover ever built that can lift that key. And earthmovers are really expensive to build, well, no one is opening that unless they steal the earthmover. And the drivers of the earthmover work in pairs, one awake while the other sleeps, and they're both armed and vicious.

We have such an earthmover. I'm investigating the price of lead. I'll leave you to figure out what parts of LabVIEW correspond to the parts of this analogy. 🙂

Message 8 of 13
(4,572 Views)

Olivier Jourdan wrote:

I agree with this statement. Is this a known issue that will be fixed in future version of LV ?

It is not something that would affect VIs using any released feature of LabVIEW. It is not a problem that generally exists.

0 Kudos
Message 9 of 13
(4,572 Views)

AristosQueue wrote:

Rolfk: Consider, as an analogy, a lock and a key. Everyone can see the key and the lock. But the lock is 20' tall and the key is scaled to match, made of solid lead, and although everyone can see it and knows exactly what needs to be done, they don't own the only earthmover ever built that can lift that key. And earthmovers are really expensive to build, well, no one is opening that unless they steal the earthmover. And the drivers of the earthmover work in pairs, one awake while the other sleeps, and they're both armed and vicious.

We have such an earthmover. I'm investigating the price of lead. I'll leave you to figure out what parts of LabVIEW correspond to the parts of this analogy. 🙂

Sounds like symmetric encryption to me. With 1024 bit or more encryption key, except that NI then needs to apply for an export permit for LabVIEW, or let someone in one of the overseas offices "implement" that feature.

Never understood that export limitation anyhow. As if mathematics could be owned by a goverment.

Rolf Kalbermatter
My Blog
Message 10 of 13
(4,572 Views)