Seconded -- I try to steer clear of *Nuke systems, which seem like the backend version of stupid malware-bearing "customizations" for user desktops on windows systems.
They're riddled with holes and confusions, don't have any sort of plan or logic to their growth, and the "extensions" are an example of plug-in hooks gone mad.
The whole point of good/secure coding is not anticipating attacks, but just making sure that the program can't do anything *except* what it's supposed to. "Integration" unless its done with secure clear protocols is the source of nearly every security hole for windows.
Was Uncle Buddy's Phantom Funhouse, a hypercard stack (or rather set of stacks) designed as a whole free-exploratory mystery.
Really still brilliant stuff, and a hint at the possibilities of hypertext before EastGate defined it into a certain narrow and dull scope.
Some links:
http://www.eastgate.com/catalog/Funhouse.html
http://www.kith.org/logos/wander/10.west/Buddy.htm l
http://www.iath.virginia.edu/elab/hfl0285.html
Major lock companies very often keep the "prints" of their secure keys on file by # so they can be re-ordered, etc. If its individualized and then say registered with a trusted third party, this is about as good as any physical security that can be purchased.
I absolutely agree -- but some sort of public/private key mechanism could also be put in place. Two-part unique private keys generated for each box -- one for the customer, and one to be held by the provider. Both would need to be used simultaneously against the key of the box in order to gain access.
Sure, what if the customer loses the private key? But what if the customer drops the box in a lake? You can only protect people so far.
Slashdot Mirror
Seconded -- I try to steer clear of *Nuke systems, which seem like the backend version of stupid malware-bearing "customizations" for user desktops on windows systems. They're riddled with holes and confusions, don't have any sort of plan or logic to their growth, and the "extensions" are an example of plug-in hooks gone mad.
The whole point of good/secure coding is not anticipating attacks, but just making sure that the program can't do anything *except* what it's supposed to. "Integration" unless its done with secure clear protocols is the source of nearly every security hole for windows.
Oy! This all took place when she was 14. She *wrote the book* when she was 17, and it was published when she was 18. Just to clear that up.
Those links again, done right:m l
http://www.eastgate.com/catalog/Funhouse.html
http://www.iath.virginia.edu/elab/hfl0285.html
http://www.kith.org/logos/wander/10.west/Buddy.ht
Was Uncle Buddy's Phantom Funhouse, a hypercard stack (or rather set of stacks) designed as a whole free-exploratory mystery. Really still brilliant stuff, and a hint at the possibilities of hypertext before EastGate defined it into a certain narrow and dull scope. Some links: http://www.eastgate.com/catalog/Funhouse.html http://www.kith.org/logos/wander/10.west/Buddy.htm l
http://www.iath.virginia.edu/elab/hfl0285.html
Major lock companies very often keep the "prints" of their secure keys on file by # so they can be re-ordered, etc. If its individualized and then say registered with a trusted third party, this is about as good as any physical security that can be purchased.
I absolutely agree -- but some sort of public/private key mechanism could also be put in place. Two-part unique private keys generated for each box -- one for the customer, and one to be held by the provider. Both would need to be used simultaneously against the key of the box in order to gain access. Sure, what if the customer loses the private key? But what if the customer drops the box in a lake? You can only protect people so far.
The best method for steno/spam work is still just a varient of one time pads!