You are correct about freezing damage. You are incorrect that cryonics uses freezing. The process used is called vitrification, which avoids the freezing damage you are talking about. Of course there's the biotoxicity of the vitrification chemicals, but one thing at a time.
TPM doesn't buy you anything in a VM - the virtualized environment has to trust the host that it's getting the correct certificates and data. The VM doesn't have direct access to the TPM, and the TPM won't export private keys. Also, that's only one set of keys per TPM, so multiple/portable VMs aren't realistic.
I'm in favor of the tools TPM offers users (vice content producers) but I don't believe this is a good fit.
What folks appear to be missing is that it's POSSIBLE for key exchanges to be routed through Skype corporate servers. Because of this Skype (the company) has the opportunity to man-in-the-middle an apparently secure communication. Breaking AES isn't involved, this would be an operational flaw.
Going back to the operating system, this would presumably be handled by ACLs.
Actually, you'll probably want to employ some type of multi-level security, something that provide mandatory access controls via security labels. This generally provides a model more robust than ACLs.
Was that not a butchered version of Do Androids Dream of Electric Sheep?
I believe it was based on Super-Toys Last All Summer Long by Brian Aldiss, though I can understand how a viewer might believe it was based on a PKD story.
Ok, here are some real facts about how this works.
Under the Common Criteria (CC), people with financial ties create the product. They (or another sponsor who wants the product evaluated) pay an independent lab (CCTL) to evaluate it. Labs are certified by NIAP, a partnership of NIST and the NSA Information Assurance directorate. (The NSA has two main parts, the other is Signals Intelligence.) The independent lab evaluation is overseen by a Validation team employed by the government, who reviews the process and results of every evaluation, including all vendor evidence, before it is certified. The Validators also oversee the labs for proper execution of the CC. Once it passes all these reviews successfully it is certified.
Certifications are tiered by Evaluation Assurance Levels (EALs), from 1 to 7. Generally, the higher the EAL, the greater confidence there is in the vendor claims. This is NOT the same as being more secure!
The way to use these certified products is to select a product family (say firewalls), and review at a minimum two documents: The Security Target (ST) and Validation Report (VR). The ST is written by the vendor or sponsor, and basically contains the security claims they're making for the product, and how they expect the product to be used. The Validation Report describes how those claims were evaluated, and what notable things the Validation team observed during the evaluation. After reading both of these documents (usually not more than 100 pages - pretty short for 1-2 years of work) you can determine if the product can be used in its certified configuration in your environment.
Check out some interesting operating systems, like Windows XP, Mac OS X, or one of the Linux's.
It's certainly not perfect, but it's better than what we had.
Good first thought, but the idea that keeps hanging in the periphery of the discussion above is that if you consolidate massive storage into a single LUN like that, it takes too long to back it up. The controllers simply can't move the data off fast enough. This is why in production systems you never see RAID LUNs maxed out. (Another reason is to distribute your transactions across multiple I/O channels.)
EMC and its smaller rivals make a fortune on clever array technology that allows you to perform "snap clones" of LUNs that can be later backed off to off line storage at a lower rate. As long as it can be done before the next "snap" window, you're OK. Otherwise, reduce the LUN size and stand up more robots.
Good suggestion. I'd go a step further and figure out a way to incorporate transactions performed (outright, not per second). So if you've got quad cores in an idle loop, and the other gal has a 1.0+ load average per CPU, she wins. I guess this could be gamed by running SETI@Home, but at least it would still be performing work.
So the plus is that it runs Linux? How about the minuses?
. No voter-verifiable receipt
. No code auditing by the general public (only by the political parties, which is a small step-up from the U.S.)
. Process flow problems allowing voter fraud or deception.
. Recounts not possible.
. Vote-stealing possible by poll-workers.
Diebold is a vendor in this system. Interesting that having the opportunity for a complete system rewrite (moving to Linux) didn't eliminate the same design flaws inherent in their other systems.
Diebold may make apparently fine ATMs, but voting is a different beast, requiring different thinking.
Because banking and voting are different problems. Banking requires accountability (non-repudiation), voting anonymity. There are solutions for both, but anonymous electronic voting that's verifiable while being untraceable is so far unimplemented.
The flexibility and usefulness of paper voting continues to be underrated in these discussions.
Yes, it's a hash and not an image. The problem is there are three generally accepted formats for capturing and storing the hash. Assuming for a moment they're equally distributed in the marketplace, losing one means it's usable by the bad guys in 33% of applications. The problem gets worse if there's standardization. The print image isn't needed, it's the hashes (templates) that are compared.
If you mean weather radar, they have it. If you mean radar to see other aircraft, they already have (available) TCAS - Traffic alert and Collision Avoidance System
As an IT Security professional, I approach the situation differently. I'm there to help the developer make a stronger system, using my experience with many possible flaws and vulnerabilities across many systems. I don't want their system to be the next one pwnd. When we're done the system will be a little more robust.
Apart from that, it's a puzzle. Someone hands me a system or process, and it's my job to see if there's an unguarded way in (or out), a way to DOS the system, etc. Sometimes I don't find them before the real enemy does. It's a race, and it's a thrilling one.
Finally, I don't haughtily tell anyone anything. These are systems that (ideally) people have put their heart and soul into. You don't go up to someone and say their baby is ugly or deformed or broken. You point out that there may be a problem, and that you're a doctor - a specialist - and you're here to help.
Um, I watched it on NBC and they actually mentioned it was a special effect when they were showing it. So apparently everyone who was watching wasn't LISTENING.
Slashdot Mirror
You are correct about freezing damage. You are incorrect that cryonics uses freezing. The process used is called vitrification, which avoids the freezing damage you are talking about. Of course there's the biotoxicity of the vitrification chemicals, but one thing at a time.
Actually cryonics has been an openly money-losing proposition for thirty years. Go invest in the airline industry.
I'll take that bet: List of oldest companies
Eight over 1000 years old, hundreds all over the world over 200 years old, tens of thousands over 100 years old.
The rest of your points are equally specious and collapse with any kind of scrutiny. Now if you don't like it, that's your own look out.
TPM doesn't buy you anything in a VM - the virtualized environment has to trust the host that it's getting the correct certificates and data. The VM doesn't have direct access to the TPM, and the TPM won't export private keys. Also, that's only one set of keys per TPM, so multiple/portable VMs aren't realistic. I'm in favor of the tools TPM offers users (vice content producers) but I don't believe this is a good fit.
What folks appear to be missing is that it's POSSIBLE for key exchanges to be routed through Skype corporate servers. Because of this Skype (the company) has the opportunity to man-in-the-middle an apparently secure communication. Breaking AES isn't involved, this would be an operational flaw.
Ha! If you're HAL 9K, I took a picture of it the other day, when I was driving behind you. Perhaps more deal is made than you're aware of?
Going back to the operating system, this would presumably be handled by ACLs.
Actually, you'll probably want to employ some type of multi-level security, something that provide mandatory access controls via security labels. This generally provides a model more robust than ACLs.
FYI, Freenet is to counter content supression. Tor supports hidden servers just fine, with much better performance.
DoubleDos
I believe it was based on Super-Toys Last All Summer Long by Brian Aldiss, though I can understand how a viewer might believe it was based on a PKD story.
You may also want to include the Security Target, which is where the vendor makes their security claims. It's at the second link.
Under the Common Criteria (CC), people with financial ties create the product. They (or another sponsor who wants the product evaluated) pay an independent lab (CCTL) to evaluate it. Labs are certified by NIAP, a partnership of NIST and the NSA Information Assurance directorate. (The NSA has two main parts, the other is Signals Intelligence.) The independent lab evaluation is overseen by a Validation team employed by the government, who reviews the process and results of every evaluation, including all vendor evidence, before it is certified. The Validators also oversee the labs for proper execution of the CC. Once it passes all these reviews successfully it is certified.
Certifications are tiered by Evaluation Assurance Levels (EALs), from 1 to 7. Generally, the higher the EAL, the greater confidence there is in the vendor claims. This is NOT the same as being more secure!
The way to use these certified products is to select a product family (say firewalls), and review at a minimum two documents: The Security Target (ST) and Validation Report (VR). The ST is written by the vendor or sponsor, and basically contains the security claims they're making for the product, and how they expect the product to be used. The Validation Report describes how those claims were evaluated, and what notable things the Validation team observed during the evaluation. After reading both of these documents (usually not more than 100 pages - pretty short for 1-2 years of work) you can determine if the product can be used in its certified configuration in your environment.
Check out some interesting operating systems, like Windows XP, Mac OS X, or one of the Linux's.
It's certainly not perfect, but it's better than what we had.
ok for christmas I get my brand new 15kw or later my 100kw laser gun.
but what can i do with that ?
You could shoot your eye out, kid.
Some amateur satellites actually USE steel tape-measure as antennas. Here's a shot of PC-SAT. (Full site article)
EMC and its smaller rivals make a fortune on clever array technology that allows you to perform "snap clones" of LUNs that can be later backed off to off line storage at a lower rate. As long as it can be done before the next "snap" window, you're OK. Otherwise, reduce the LUN size and stand up more robots.
Good suggestion. I'd go a step further and figure out a way to incorporate transactions performed (outright, not per second). So if you've got quad cores in an idle loop, and the other gal has a 1.0+ load average per CPU, she wins. I guess this could be gamed by running SETI@Home, but at least it would still be performing work.
I would like transparent, administrator controlled, versioning...
I suggest looking at how VMS did it. The 2.6 kernel already incorporates VMSs distributed lock manager (woot!)
And good luck trying to teach a jury about hash collisions.
. No voter-verifiable receipt
. No code auditing by the general public (only by the political parties, which is a small step-up from the U.S.)
. Process flow problems allowing voter fraud or deception.
. Recounts not possible.
. Vote-stealing possible by poll-workers.
Diebold is a vendor in this system. Interesting that having the opportunity for a complete system rewrite (moving to Linux) didn't eliminate the same design flaws inherent in their other systems.
Diebold may make apparently fine ATMs, but voting is a different beast, requiring different thinking.
Because banking and voting are different problems. Banking requires accountability (non-repudiation), voting anonymity. There are solutions for both, but anonymous electronic voting that's verifiable while being untraceable is so far unimplemented.
The flexibility and usefulness of paper voting continues to be underrated in these discussions.
Yes, it's a hash and not an image. The problem is there are three generally accepted formats for capturing and storing the hash. Assuming for a moment they're equally distributed in the marketplace, losing one means it's usable by the bad guys in 33% of applications. The problem gets worse if there's standardization. The print image isn't needed, it's the hashes (templates) that are compared.
If you mean weather radar, they have it. If you mean radar to see other aircraft, they already have (available) TCAS - Traffic alert and Collision Avoidance System
Apart from that, it's a puzzle. Someone hands me a system or process, and it's my job to see if there's an unguarded way in (or out), a way to DOS the system, etc. Sometimes I don't find them before the real enemy does. It's a race, and it's a thrilling one.
Finally, I don't haughtily tell anyone anything. These are systems that (ideally) people have put their heart and soul into. You don't go up to someone and say their baby is ugly or deformed or broken. You point out that there may be a problem, and that you're a doctor - a specialist - and you're here to help.
Global warming is a misnomer anyway - it should be called, "global climate instability."
I thought The Earth was just thermally-challenged.
Um, I watched it on NBC and they actually mentioned it was a special effect when they were showing it. So apparently everyone who was watching wasn't LISTENING.