I thought this was a relatively poor article and was not well thought out.
First of all, it starts off listing various events where planes were diverted or passengers forced to disembark. This means to imply that it is an overreaction to the bombing threat. However what it ignores is the media tendency to report on stories that have a news hook. Remember a few years back all we heard about was shark attacks, when in fact shark attacks were not any worse than at other times. In the same way, airline disruptions due to security threats are routine and happen all the time. It was just that they were being reported that week when otherwise they tend to get ignored. So right off the bat we are exposed to a false premise in this article.
Then we have his claim that by adding scrutiny at airports we are helping terrorists to win. Others here have debunked that well. The idea that a terrorist would think he is pleasing Allah by making Westerners take off their shoes unnecessarily is not only ludicrous, but actually insulting to terrorists.
This leads to this utterly bizarre claim:
Imagine for a moment what would have happened if they had blown up ten planes. There would be canceled flights, chaos at airports, bans on carry-on luggage, world leaders talking tough new security measures, political posturing and all sorts of false alarms as jittery people panicked. To a lesser degree, that's basically what's happening right now.
To compare what is happening now to what would be happening if ten planes had been blown up is beyond comprehension. If that attack had happened we would see a reaction commensurate with what happened after 9/11. The disruption and effects would be 10 or 100 times worse than what we see today. People would be rounded up and arrested all over the world. New legislation would be passed that would make the Patriot act look like it was sponsored by the ACLU. President Bush would get his secret prisons, his torture laws, his secret police, his NSA surveillance. The world would be unrecognizably different from what it is today, just as much as things changed after 9/11. Suggesting that basically the same thing is happening now shows a total lack of appreciation of the magnitude of such an attack.
I'll mention one other issue. He says it's "doubtful their plan would have succeeded." But in the very next essay, he writes, "However, the threat was real. And it seems pretty clear that it would have bypassed all existing airport security systems." So which is it? Was it a real threat that would have bypassed airport security? Or is it doubtful that the plan would have succeeded? It seems that he shifts his position as needed to make his political points.
A few years ago when.name came out I registered my name, John.Doe.name or whatever. I did the whole family, it was pretty cheap. But then we never used them and there didn't seem to be much point. Still it seems like if you want a name space for people's names, it already exists. And it's only $10/year.
I'm commenting late and this will probably not be seen with 200+ comments already here, but I think it is important to clear up one fact:
According to our current understanding of physics, THE LHC WILL NOT MAKE BLACK HOLES!
Not Mini black holes, not Macro black holes, not Fuzzy black holes, no black holes of any kind.
The only theories that predict that it could happen are speculative musings about how physics might turn out to be if our current theories were all wrong. Maybe there are extra dimensions and gravity reacts specially with these extra dimensions. There is ZERO evidence for this, and if one of these theories turned out to be true it would be one of the most astonishing discoveries in the history of physics, right up there with the discovery of QM or relativity.
So at this point, the odds have to be said to be overwhelmingly against the possibility that this collider will make black holes. That is the reality, and all the other speculation about what will happen with the black holes is based on a false premise. There will be no black holes. That is the key point based on our understanding of physics. Everything else is built on fantasy and speculation.
However AFAIK there is no solid proof that human activity is a major or even significant factor in the changes over the last 200 years.
I think you're on the wrong page. Global warming skeptics don't deny that the CO2 rise is due to people, they deny that the *temperature increase* is due to the human-caused CO2 rise.
No one doubts that the increase in CO2 levels is due to human activity. People have been cutting down trees for centuries, and burning coal, oil and natural gas for over 100 years. All this releases large quantities of carbon that goes into the atmosphere as CO2.
Now, much of it comes back out of the atmosphere, taken up by plants, dissolved in the ocean, etc. The carbon cycle is complex. But there can be no doubt that human activity is adding more carbon to the atmosphere.
They are pictures and not movies, and kind of 2 1/2 dimensional, but I really like the artwork of Scripps Institute professor David Goodsell. See some examples of the interiors of cells here:
These give a much better idea of how crowded it is inside cells. Even though Goodsell only shows the macromolecules and leaves out the water and ions, everything is just packed together.
For example, the picture on that page shows a bit of the cell membrane of a bacterium. A flagellum is curving away - the bacterium spins this for propulsion. The external surface is coated with sugar-protein molecules to make it slimy. Just inside is a meshwork of protein filaments (shown just as a green line of molecules here). Inside the body of the bacterium are lots of ribosomes, shown in purple, emitting whitish squiggles of newly synthesized proteins. And just inside that, taking up much of the body, is the bacterium's DNA, wrapped around its spools to keep it neat, shown in yellow. A bacterium doesn't have a nucleus so the DNA is right out there with everything else. And they're really small so much of the cell is taken up with DNA.
This kind of picture gives a more accurate impression of what it is really like inside cells, but it would not lend itself to 3D visualization because you wouldn't be able to see far enough through the cell. It's just too crowded.
One thing the movie is not completely consistent about is speed. This is a slowed-down view of life within the cell, but the slow-down factors are not always the same.
The "keep on truckin'" kinesis molecule towing the blobby vessicle along the microtubule will take in real life about 100 steps per second. We see it taking about 1 step per second so this is a slowdown by a factor of 100.
The translation of mRNA to protein by a ribosome occurs at a rate of about 60 steps per second, each step adding a single amino acid to the protein. If we slowed that down by a factor of 100 we'd see (add an amino acid) pause, pause, pause... (add another one) and so on. Instead, the protein is squirting out of the ribosome like frosting from a pastry press. It's slowed down by more like a factor of 10 or so.
Another example is microtubule assembly. This is the large tube that closes with a kind of zipper effect. These grow in cells at about 7 microns per minute, and have a diameter of about 25 nm, corresponding to a rate of about 5 tubule-diameters per second. The animation shows growth at a rate of about 1 diameter per second, for a slowdown of about 5.
This inconsistency paints a somewhat false picture of how these different processes relate to each other. Another point is that the interior of the cell is not empty or just full of water as these pictures might suggest, rather it is crammed full of all kinds of molecules: proteins, ATP (energy molecules), ions and other small molecules, etc. These molecules don't just appear when needed as the animation suggests, they are everywhere, a thick soup of them, and all these processes rely on this background store of raw materials being present when needed.
I can tell you a little bit about what's going on here. I should warn you, I'm not a biologist, just a fan.
We start off of course seeing white blood cells moving through a capillary blood vessel. Then a close up showing cilia from the white blood cell interacting with the cells lining the capillary wall.
We then cut to a confusing looking picture of a "platform" with some large molecules floating on a fluctuating surface. The surface is the cell membrane of the WBC, I'm not sure if this is the inside or the outside. Probably the inside. The molecules moving together are what they all a macro-molecular complex.
We then pull back and see a meshwork or net-looking arrangement. This is a structure just inside the WBC wall. These protein fibers give the WBC its semi-rigid shape, and by tugging on them it is able to change its shape and move around. Much of the interior of a cell is criss-crossed by these fibers, of various sizes. By building and disassembling them, the cell is able to control its shape.
We see some shots of these fibers and larger micro-tubules self-assembling. As noted above this is a little too "choreographed" and it is a more random process. We then see one being cleaved and beginning to disassemble, and some more disassembly.
One of the more striking sequences seems to show a big blob being towed along by a sort of foot that walks along. This is a vessicle being transported along a microtubule. It is destined to merge with the cell wall and dump its contents outside the cell. We don't see the fusion process, but near the end we see the completion of this, as a deep well in the membrane surface flattens out, and its contents are dispersed into the intracellular medium.
The "walking" process is again a little too regular. It is thought to be much floppier than this. The front end of the "foot" flops around until it hits the right spot, where it sticks. At that point an ATP molecule must bind (this is not shown) which drives the rear foot free of the tubule. It will then flop around itself until it sticks up front. This is a "brownian motor (or ratchet)" which is used in many places in cells.
We see a bunch of squiggly things shooting out of holes in some surface. I believe these are messenger RNA molecules coming out of the nucleus. The nucleus creates these molecules based on the genes which are inside the nucleus, and they go out into the cells where they serve as a guide to construct proteins.
That's what we see next, a greenish blob, the ribosome, slides along the mRNA and out the side of it comes a squiggly, new protein. What is not shown here is that there are millions of interactions with amino acids that are used to build the protein.
Many ribosomes are free floating as shown here but many are also attached to what is called the endoplasmic reticulum, a membrane within the cell that has a complicated shape. That's what we see next, a ribosome going down and attaching to the ER where it continues to work, producing a protein, then it detaches and separates into its two constituent pieces.
Next we see our friend the vessicle being towed along, and then a blobby, somewhat cylindrical object comes into view. Look close and you will see free-floating blobs moving through it. This big thing is a Golgi body, and its purpose is to prepare protein products for excretion from the cell. The vessicles move through it and some kind of last minute chemical processing is done (this is not shown, I'm not sure it is understood very well what happens there).
Back to a brief shot of the towed vessicle and then suddenly we see the end of its merging process, the volcanic upwelling as the vessicle completes its attachment to the cell membrane and finishes disgorging its contents.
Presumably this is some kind of signal the WBC is sending to neighboring cells, perhaps to prepare them for its entry.
We are back on the surface now, and see some molecules on the WBC link up to molecules on the adjacent cells. This is meant to represent the first steps by which the WBC "grabs hold" and is able to pull itself into the gap between the cells. That's how the movie ends, with the WBC disappearing into the body.
Without DRM, information goods are what economists call "public goods". Public goods are non-excludable, which means that if you supply them to one person you are effectively supplying them to everyone. And they are non-rival, meaning that if you give them away, you still have them.
Public goods sound nice, but unfortunately they cause big economic problems. It is a classic theorem of economics that public goods are under-produced. There is no effective way to get paid for the investment needed to produce them because there is no way to charge for them. A canonical public good is clean air. Pretty hard to get people to pay money to clean the air, because clean air benefits everyone and cannot be limited to just certain people.
DRM turns information goods into private goods. Now they can be sold and owned. They become excludable. The investment needed to produce them can be recovered by charging for their sale.
Further, it is a theorem of economics that in the long run, competition will force prices to the level of manufacturing costs. As goods become popular, the investment needed to produce them will dwindle in proportion to the number of goods produced, and their prices will fall. In a DRM system, popular information goods will be inexpensive, and well supplied. There will be no shortages.
DRM is an optimal way to manage information goods.
I was outside our building once watching one of the rare lightning storms we get in this area, when a bolt struck the flagpole in front of our building, about 50 feet away. It was the largest explosion I've ever heard, not at all like regular thunder, just a sudden BOOM!!! that was incredibly loud. I felt deaf for a few seconds but as that faded away I heard constant ringing. Every fire alarm in the building was going off. And a number of our computers were damaged. My computer's serial port stopped working, and when I pulled off the cable I saw scorch and burn marks where the cable had been attached to the computer.
Apparently this was all due to the incredibly intense EM field associated with such a nearby lightning strike. I could well imagine that the Shuttle's electronics could have been damaged by such an event. IMO they should take it down and do a thorough inspection rather than rushing to stay on schedule.
No SHA-1 collisions have ever been found. The first person or group to find one will achieve considerable fame. I say this as an attendee of both last week's Crypto conference and the immediately following hash function workshop.
The work factor estimated for a SHA-1 collision is something over 2^60 cycles. That would put it on par with the biggest calculations that have ever been done (publicly anyway). So far nobody has put together a sufficient effort to achieve a collision.
At the hash function workshop, cryptographer Antoine Joux published a set of recommendations for how such a hash collision effort should be mounted, in order to minimize the damaged from a published collision. The main goal is to make it difficult to take a published collision and use it to create harmful effects in various ways. Hopefully Joux's guidelines will be followed if and when a SHA-1 collision finding project gets started.
Does anyone else think that these terrorists' true purpose is not to kill the passengers on a few planes but to inconvenience travellers for years to come?
No, that's one of the stupidest things I've heard in quite a while. The notion that a terrorist would think that Allah would be pleased by forcing infidels to take their shoes off when they fly is absurd. What kind of a god would be impressed by such a humdrum inconvenience to his enemies? The very idea turns Allah into a laughingstock and verges on heresy.
I used an OS back in the 70s, Twenex from Digital Equipment Corp, that had file versioning. Every time you wrote out a file it kept the previous N versions, typically 5. It wasn't oriented towards deletion so much as recovering old versions after you screwed one up. It was a pretty nice feature, although it tended to fill up disk space which was in short supply in those days.
Today, I thought undeleting was what the trash can was for. With today's big disks you shouldn't have to Empty Trash very often.
It's the day when my computer says, "I'm sorry, but you can't run this program" that I fear.
I guess this will be my last posting to this old thread. I go over this and over this, to no avail. It's pretty frustrating.
Your scenario is not going to happen. What could happen instead is that Microsoft, or Apple, or whoever, could say, "I'm sorry, but I'm not going to talk to you because you're not running my software." And you say, "Yes, I am." And they say, "Prove it," and you can't.
Today, nobody can prove it, so nobody asks you to. TC would let you prove it, so this kind of thing could happen. That's the real "horror" of trusted computing, that people might refuse to talk to you unless you prove you're running certain software.
To me, this is nowhere near as bad as what you describe, where you can't run software, or can only run signed software. You can run whatever you like. But you can't force anyone else to interact with you, and with TC you can't successfully lie about what software you're running.
That's the real impact of TC: you can't lie in certain ways that you can today. It's a threat only to liars. And judging from the near-universality of the opposition even when people understand how it truly works instead of the falsehoods they've been told about it, apparently most slashdotters fall into that category.
Unless a method is available to verify the current state against "what it should be" then the chip itself provides no security.
That's not true. One of the capabilities of the TPM is to encrypt data and lock it to the current software configuration. Then if you boot a different OS, the software configuration will be different and it will be impossible to decrypt the data. You will only be able to decrypt the data if you are running the original configuration. This lets a high-security OS lock up its data and be assured that if a low-security OS is booted instead, it won't be able to access the data. That's good security without any concept of "what the state should be".
Also, systems can report their state securely to remote computers on the net. The TPM signs the status report using a key embedded in the chip, that never leaves the chip and is known to be a valid TPM key. This lets remote computers decide whether they want to trust the local system, based on its software state as reported in this way.
And if the hashes can be modified then any given system can backcheck to see that it was loaded "properly" provided it can accurately compare the hashed results, but it cannot do a forward look to ensure that it will be loading the correct software.
Well, even without a TPM you could modify software (say, the Grub boot loader) with a list of known good hashes and only let them load the next step if it matched an expected hash. This kind of thing is always possible and is pretty much independent of what Trusted Computing aims to achieve.
TC lets you boot and run whatever software you want. (Claims to the contrary are probably the biggest TC related lies.) But as I have described above, its goal is to reliably detect what the system configuration is, and to then be able to lock data to that configuration, or report it to remote peers. This lets remote systems know, for example, that not only will data they send you be treated according to certain rules (which they know because they know what software you are running), but that your system can lock up that data so if you booted into software that wouldn't follow those rules, it couldn't access the data.
That's how it really works, despite the lies to the contrary. You can boot and run any software you like, yet data can be protected with high security. It's really an amazing architectural achievement.
I am very glad to see that Linus is standing up against the GPL and their misguided attempts to oppose trusted computing technology. It means that Linux will continue to be available as a basis for trusted computing research and development.
When you get past the misinformation, errors and outright lies, trusted computing is not as bad as people think it is. It is a technology for enhancing security in a variety of environments. See the TPM thread a few postings down on the slashdot main page for some commentary there.
Here's an example of what I was wondering about. Suppose a DoD employee has one of these Trusted Computer systems, and he wants to download some GPLv3 software. Maybe a future version of Firefox or something. Then the website he downloads it from is "Conveying" him the software in the meaning of GPLv3. And part of the requirement of that "Conveyance" is that the user can alter the software and remote systems can't tell the difference. But maybe on a Trusted Computer that is impossible. So, someone has violated the license. But who? Is it the user who downloaded the software? The DoD that made him get this computer (or gave it to him)? Seems to me it is the web site which is bound by the license and is limited in who it is allowed to "Convey" the software to.
If the TPM chip is as passive as you say then all it can do is answer the following question: "What is the last hash you were fed?"
That's not quite how it works. When I said that these hashes get fed to the TPM, I didn't say how it digests them.
The TPM has several 20-byte registers called Platform Configuration Registers (PCRs). They are initialized to zero. When it receives a hash it gets folded into one of the PCRs. It does this by computing PCRn = SHA1 (PCRn || NewHash), where || means concatenation. In other words it takes its current hash value, concatenates the new hash value, SHA1 hashes this 40-byte buffer to get a new 20-byte hash, and stores that.
This provides an update function that cannot be rolled back. If, during the boot sequence, any component deviates from a standard configuration, the PCR register will be changed irrevocably. It will be impossible for any later software action to feed anything to the TPM that would get the PCRs back to what they were supposed to be.
if you exercise your rights under the GPL by modifying and rebuilding the software, it's no longer "Trusted" because it's not signed.
You've been posting a lot on this, and it's not right.
First of all, there's no such thing as a distinction between "Trusted" and "Untrusted" software in absolute terms. Second, software does not have to be signed.
What actually happens is that TC systems can be designed to keep track of the hashes of all the software that runs, and load those hashes into the TPM chip. THe chip can basically do two things with them. It can encrypt data and lock it to the hashes, such that the data can't be decrypted unless the machine is in exactly the same software state. Or it can report the current hash values, signed by the on-chip, unspoofable crypto key.
That's the true functionality. Now, from this, you can get features that work similarly to what you say, but not exactly.
If you change software, especially your OS software, and reboot, the TPM chip will get a different set of hashes loaded into it during the boot process. If you had previously locked (encrypted) data to the old system configuration, you won't be able to decrypt it now. You'd have to reboot back into the old configuration. If your old OS was high-security, say a SELinux configuration, and the new OS is a live CD you inserted to bypass the security, you won't be able to do so.
But it's not like the old OS was "Trusted" and the new OS is "Untrusted". It's just that they have different hashes and produce different software configurations. Data locked to the new configuration can't be decrypted in the old one, and vice versa.
The other thing the chip can do is to optionally report out to remote systems what your software configuration is. Maybe someone will only talk to you if you are running a certain configuration. Then, FROM HIS POINT OF VIEW, that configuration is "Trusted", and he won't trust any other. But it's not true in absolute terms that your computer is in a "Trusted" state or not. It's just that party's opinion about which software configurations he chooses to trust. And you could even imagine a system in which party A only "Trusts" one configuration while party B only "Trusts" an incompatible configuration. I'm sure this kind of conflict is likely to happen in the early days of TC, if it ever gets to this point.
And keep in mind that you can turn this around, too. You could connect to remote systems, say e-commerce sites or other servers, and they could use TC to report their software configuration to you. Then you might choose to trust only certain software versions, maybe systems with the most recent patches for example. Or you could have a P2P network and each computer could check that the others are running good versions of the software, to prevent people patching their systems to allow leeching or flooding attacks. There are a lot of other uses for this technology beyond DRM.
Note though that a P2P network like this would apparently be illegal under GPLv3. It would not be allowed to have software that queries the state of the peers and only connects to them if they are the same software, because this would prevent people from patching their software and continuing to participate in the P2P net (they'd have to start a new subnet of their own). So this potentially useful security tool is being shut off from the world of GPLv3. Luckily, people can continue to use GPLv2, which I expect to happen.
Furthermore, it implies that all one need do is supply their own BIOS and bootloader code that uploads the hashes from the original BIOS and bootloader and the OS underneath will be none the wiser because the message it gets back from the TPM will be exactly what it's expecting to see.
Good question. The way the system works is kind of subtle. This is perhaps why so many people prefer to believe the falsehoods that our out there, about how the system will only run signed code and keep you from changing your own software.
The TPM chip is completely passive in a TC system. It relies entirely on the BIOS, bootloader and OS to feed it data. Yet the system is designed to be secure. Here is how it works.
The first part of the BIOS is non-flashable in a TC system. It is hard-coded to hash the whole rest of the BIOS and feed that data to the TPM, first thing.
Then the BIOS, before transferring control to the boot loader, hashes it and sends the hash to the TPM.
And the boot loader similarly hashes the OS and some config files, sending that data to the TPM, before transferring control. The Linux Trusted Grub project has a patched boot loader that does this.
The TPM can later report these hash values, signed with an on-chip crypto key that can't be spoofed.
People would need to know what these values are supposed to be on an untampered system. Then there's no way to alter a system and let it boot such that the TPM gets the same values and so you could fool people about what you are running. For example, you could try patching Trusted Grub to send a fake OS hash to the TPM so you could lie about what OS version you were booting. But recall that the BIOS hashes the boot loader before executing it. If you've changed Trusted Grub, it will have a different hash, and this will be reported to the TPM. (Keep in mind that the TPM does not check these hashes for "correctness", it just remembers them and can report them later.)
So yes, you can patch your boot loader to lie, but you still won't end up with the same system configuration "fingerprint" because the boot loader got hashed and the TPM told about it before it got control. In this way the system achieves the ability to security report its boot sequence and configuration, even though people can change the software involved.
And how does the TPM chip know that the information that the bios/os loader/os itself sends to it is actually the real information about the bios/os loader/os and not faked information from an unmodified version?
This happens via a staged-boot process.
The BIOS itself in a TPM computer has a non-flashable portion that runs at startup. This takes a hash of the rest of the BIOS and feeds it into the TPM. The BIOS then hashes the boot loader into the TPM (Grub, in the case of Linux) before transferring control to it. The boot loader can hash the OS before switching control to that. The Trusted Grub project on Linux has been enhanced to do this. Then you could have the OS hash application data into the TPM as it loads; so far only a few experimental projects do that, like Enforcer.
Now, the BIOS is hard-wired to tell the truth. But the later components could lie. You could have a patched boot loader (it's open source!) which does not send truthful data about the OS kernel and configuration to the TPM.
But you couldn't get away with this fraud. Recall that the BIOS hashes the boot loader and sends the data to the TPM before running it. If you patch Trusted Grub to lie, it will have a different hash, and the TPM will be told about it. (Note, the TPM doesn't have any "expectations" regarding what these hashes are supposed to be, it just remembers what it was told and can report it later, signed with a crypto key.) So with this concept, if someone knows what the system "fingerprint" is supposed to be of a secure BIOS + Trusted Grub + Enforcer Linux boot sequence, it's impossible for you to patch it and end up with that same exact pattern.
Actually, Trusted in this context means "the people in control can trust my computer to be secure against me," where "the people in control" refers to those who hold the private key to the TPM.
No one holds the private key of the TPM. The key is generated on-chip at manufacture time and never leaves the chip.
Are you are saying that if I connect to a web server running some sort of trusted computing, I will be able to trust it to not serve me malware?
You could get a degree of trust in it, yes. It could publish its software configuration, signed by a crypto key embedded in the TPM chip. This way you could verify that it was running the latest patched version of Apache and other software, and had no intentional malware insertion features.
Slashdot Mirror
I thought this was a relatively poor article and was not well thought out.
First of all, it starts off listing various events where planes were diverted or passengers forced to disembark. This means to imply that it is an overreaction to the bombing threat. However what it ignores is the media tendency to report on stories that have a news hook. Remember a few years back all we heard about was shark attacks, when in fact shark attacks were not any worse than at other times. In the same way, airline disruptions due to security threats are routine and happen all the time. It was just that they were being reported that week when otherwise they tend to get ignored. So right off the bat we are exposed to a false premise in this article.
Then we have his claim that by adding scrutiny at airports we are helping terrorists to win. Others here have debunked that well. The idea that a terrorist would think he is pleasing Allah by making Westerners take off their shoes unnecessarily is not only ludicrous, but actually insulting to terrorists.
This leads to this utterly bizarre claim:
Imagine for a moment what would have happened if they had blown up ten planes. There would be canceled flights, chaos at airports, bans on carry-on luggage, world leaders talking tough new security measures, political posturing and all sorts of false alarms as jittery people panicked. To a lesser degree, that's basically what's happening right now.
To compare what is happening now to what would be happening if ten planes had been blown up is beyond comprehension. If that attack had happened we would see a reaction commensurate with what happened after 9/11. The disruption and effects would be 10 or 100 times worse than what we see today. People would be rounded up and arrested all over the world. New legislation would be passed that would make the Patriot act look like it was sponsored by the ACLU. President Bush would get his secret prisons, his torture laws, his secret police, his NSA surveillance. The world would be unrecognizably different from what it is today, just as much as things changed after 9/11. Suggesting that basically the same thing is happening now shows a total lack of appreciation of the magnitude of such an attack.
I'll mention one other issue. He says it's "doubtful their plan would have succeeded." But in the very next essay, he writes, "However, the threat was real. And it seems pretty clear that it would have bypassed all existing airport security systems." So which is it? Was it a real threat that would have bypassed airport security? Or is it doubtful that the plan would have succeeded? It seems that he shifts his position as needed to make his political points.
A few years ago when .name came out I registered my name, John.Doe.name or whatever. I did the whole family, it was pretty cheap. But then we never used them and there didn't seem to be much point. Still it seems like if you want a name space for people's names, it already exists. And it's only $10/year.
I'm commenting late and this will probably not be seen with 200+ comments already here, but I think it is important to clear up one fact:
According to our current understanding of physics, THE LHC WILL NOT MAKE BLACK HOLES!
Not Mini black holes, not Macro black holes, not Fuzzy black holes, no black holes of any kind.
The only theories that predict that it could happen are speculative musings about how physics might turn out to be if our current theories were all wrong. Maybe there are extra dimensions and gravity reacts specially with these extra dimensions. There is ZERO evidence for this, and if one of these theories turned out to be true it would be one of the most astonishing discoveries in the history of physics, right up there with the discovery of QM or relativity.
So at this point, the odds have to be said to be overwhelmingly against the possibility that this collider will make black holes. That is the reality, and all the other speculation about what will happen with the black holes is based on a false premise. There will be no black holes. That is the key point based on our understanding of physics. Everything else is built on fantasy and speculation.
However AFAIK there is no solid proof that human activity is a major or even significant factor in the changes over the last 200 years.
I think you're on the wrong page. Global warming skeptics don't deny that the CO2 rise is due to people, they deny that the *temperature increase* is due to the human-caused CO2 rise.
No one doubts that the increase in CO2 levels is due to human activity. People have been cutting down trees for centuries, and burning coal, oil and natural gas for over 100 years. All this releases large quantities of carbon that goes into the atmosphere as CO2.
Now, much of it comes back out of the atmosphere, taken up by plants, dissolved in the ocean, etc. The carbon cycle is complex. But there can be no doubt that human activity is adding more carbon to the atmosphere.
They are pictures and not movies, and kind of 2 1/2 dimensional, but I really like the artwork of Scripps Institute professor David Goodsell. See some examples of the interiors of cells here:
e ll/
http://www.scripps.edu/mb/goodsell/illustration/c
These give a much better idea of how crowded it is inside cells. Even though Goodsell only shows the macromolecules and leaves out the water and ions, everything is just packed together.
For example, the picture on that page shows a bit of the cell membrane of a bacterium. A flagellum is curving away - the bacterium spins this for propulsion. The external surface is coated with sugar-protein molecules to make it slimy. Just inside is a meshwork of protein filaments (shown just as a green line of molecules here). Inside the body of the bacterium are lots of ribosomes, shown in purple, emitting whitish squiggles of newly synthesized proteins. And just inside that, taking up much of the body, is the bacterium's DNA, wrapped around its spools to keep it neat, shown in yellow. A bacterium doesn't have a nucleus so the DNA is right out there with everything else. And they're really small so much of the cell is taken up with DNA.
This kind of picture gives a more accurate impression of what it is really like inside cells, but it would not lend itself to 3D visualization because you wouldn't be able to see far enough through the cell. It's just too crowded.
One thing the movie is not completely consistent about is speed. This is a slowed-down view of life within the cell, but the slow-down factors are not always the same.
The "keep on truckin'" kinesis molecule towing the blobby vessicle along the microtubule will take in real life about 100 steps per second. We see it taking about 1 step per second so this is a slowdown by a factor of 100.
The translation of mRNA to protein by a ribosome occurs at a rate of about 60 steps per second, each step adding a single amino acid to the protein. If we slowed that down by a factor of 100 we'd see (add an amino acid) pause, pause, pause... (add another one) and so on. Instead, the protein is squirting out of the ribosome like frosting from a pastry press. It's slowed down by more like a factor of 10 or so.
Another example is microtubule assembly. This is the large tube that closes with a kind of zipper effect. These grow in cells at about 7 microns per minute, and have a diameter of about 25 nm, corresponding to a rate of about 5 tubule-diameters per second. The animation shows growth at a rate of about 1 diameter per second, for a slowdown of about 5.
This inconsistency paints a somewhat false picture of how these different processes relate to each other. Another point is that the interior of the cell is not empty or just full of water as these pictures might suggest, rather it is crammed full of all kinds of molecules: proteins, ATP (energy molecules), ions and other small molecules, etc. These molecules don't just appear when needed as the animation suggests, they are everywhere, a thick soup of them, and all these processes rely on this background store of raw materials being present when needed.
I can tell you a little bit about what's going on here. I should warn you, I'm not a biologist, just a fan.
We start off of course seeing white blood cells moving through a capillary blood vessel. Then a close up showing cilia from the white blood cell interacting with the cells lining the capillary wall.
We then cut to a confusing looking picture of a "platform" with some large molecules floating on a fluctuating surface. The surface is the cell membrane of the WBC, I'm not sure if this is the inside or the outside. Probably the inside. The molecules moving together are what they all a macro-molecular complex.
We then pull back and see a meshwork or net-looking arrangement. This is a structure just inside the WBC wall. These protein fibers give the WBC its semi-rigid shape, and by tugging on them it is able to change its shape and move around. Much of the interior of a cell is criss-crossed by these fibers, of various sizes. By building and disassembling them, the cell is able to control its shape.
We see some shots of these fibers and larger micro-tubules self-assembling. As noted above this is a little too "choreographed" and it is a more random process. We then see one being cleaved and beginning to disassemble, and some more disassembly.
One of the more striking sequences seems to show a big blob being towed along by a sort of foot that walks along. This is a vessicle being transported along a microtubule. It is destined to merge with the cell wall and dump its contents outside the cell. We don't see the fusion process, but near the end we see the completion of this, as a deep well in the membrane surface flattens out, and its contents are dispersed into the intracellular medium.
The "walking" process is again a little too regular. It is thought to be much floppier than this. The front end of the "foot" flops around until it hits the right spot, where it sticks. At that point an ATP molecule must bind (this is not shown) which drives the rear foot free of the tubule. It will then flop around itself until it sticks up front. This is a "brownian motor (or ratchet)" which is used in many places in cells.
We see a bunch of squiggly things shooting out of holes in some surface. I believe these are messenger RNA molecules coming out of the nucleus. The nucleus creates these molecules based on the genes which are inside the nucleus, and they go out into the cells where they serve as a guide to construct proteins.
That's what we see next, a greenish blob, the ribosome, slides along the mRNA and out the side of it comes a squiggly, new protein. What is not shown here is that there are millions of interactions with amino acids that are used to build the protein.
Many ribosomes are free floating as shown here but many are also attached to what is called the endoplasmic reticulum, a membrane within the cell that has a complicated shape. That's what we see next, a ribosome going down and attaching to the ER where it continues to work, producing a protein, then it detaches and separates into its two constituent pieces.
Next we see our friend the vessicle being towed along, and then a blobby, somewhat cylindrical object comes into view. Look close and you will see free-floating blobs moving through it. This big thing is a Golgi body, and its purpose is to prepare protein products for excretion from the cell. The vessicles move through it and some kind of last minute chemical processing is done (this is not shown, I'm not sure it is understood very well what happens there).
Back to a brief shot of the towed vessicle and then suddenly we see the end of its merging process, the volcanic upwelling as the vessicle completes its attachment to the cell membrane and finishes disgorging its contents.
Presumably this is some kind of signal the WBC is sending to neighboring cells, perhaps to prepare them for its entry.
We are back on the surface now, and see some molecules on the WBC link up to molecules on the adjacent cells. This is meant to represent the first steps by which the WBC "grabs hold" and is able to pull itself into the gap between the cells. That's how the movie ends, with the WBC disappearing into the body.
Come on, Doofus, get off your lazy ass and start making some sensible suggestions... But nothing, he just sits there...
And then, when there's nothing more to say, then PASS, dammit!
I don't know how people can stand this. I started yelling at the computer after my second loser partner. It's like going on a speed date from hell.
Without DRM, information goods are what economists call "public goods". Public goods are non-excludable, which means that if you supply them to one person you are effectively supplying them to everyone. And they are non-rival, meaning that if you give them away, you still have them.
Public goods sound nice, but unfortunately they cause big economic problems. It is a classic theorem of economics that public goods are under-produced. There is no effective way to get paid for the investment needed to produce them because there is no way to charge for them. A canonical public good is clean air. Pretty hard to get people to pay money to clean the air, because clean air benefits everyone and cannot be limited to just certain people.
DRM turns information goods into private goods. Now they can be sold and owned. They become excludable. The investment needed to produce them can be recovered by charging for their sale.
Further, it is a theorem of economics that in the long run, competition will force prices to the level of manufacturing costs. As goods become popular, the investment needed to produce them will dwindle in proportion to the number of goods produced, and their prices will fall. In a DRM system, popular information goods will be inexpensive, and well supplied. There will be no shortages.
DRM is an optimal way to manage information goods.
I was outside our building once watching one of the rare lightning storms we get in this area, when a bolt struck the flagpole in front of our building, about 50 feet away. It was the largest explosion I've ever heard, not at all like regular thunder, just a sudden BOOM!!! that was incredibly loud. I felt deaf for a few seconds but as that faded away I heard constant ringing. Every fire alarm in the building was going off. And a number of our computers were damaged. My computer's serial port stopped working, and when I pulled off the cable I saw scorch and burn marks where the cable had been attached to the computer.
Apparently this was all due to the incredibly intense EM field associated with such a nearby lightning strike. I could well imagine that the Shuttle's electronics could have been damaged by such an event. IMO they should take it down and do a thorough inspection rather than rushing to stay on schedule.
NO SHA-1 COLLISIONS HAVE EVER BEEN FOUND!
Ahem.
Sorry, my caps lock key got stuck there.
No SHA-1 collisions have ever been found. The first person or group to find one will achieve considerable fame. I say this as an attendee of both last week's Crypto conference and the immediately following hash function workshop.
The work factor estimated for a SHA-1 collision is something over 2^60 cycles. That would put it on par with the biggest calculations that have ever been done (publicly anyway). So far nobody has put together a sufficient effort to achieve a collision.
At the hash function workshop, cryptographer Antoine Joux published a set of recommendations for how such a hash collision effort should be mounted, in order to minimize the damaged from a published collision. The main goal is to make it difficult to take a published collision and use it to create harmful effects in various ways. Hopefully Joux's guidelines will be followed if and when a SHA-1 collision finding project gets started.
I understand that this is the method your husband is currently using?
p g?v=0
http://static.flickr.com/14/89383054_29028960aa.j
I don't see any problems with it, that's exactly how I do it...
Does anyone else think that these terrorists' true purpose is not to kill the passengers on a few planes but to inconvenience travellers for years to come?
No, that's one of the stupidest things I've heard in quite a while. The notion that a terrorist would think that Allah would be pleased by forcing infidels to take their shoes off when they fly is absurd. What kind of a god would be impressed by such a humdrum inconvenience to his enemies? The very idea turns Allah into a laughingstock and verges on heresy.
Yeah, right a tree falls on a power line so we better move to the friggin moon? Live in a bio-vault? What's he smoking?
I used an OS back in the 70s, Twenex from Digital Equipment Corp, that had file versioning. Every time you wrote out a file it kept the previous N versions, typically 5. It wasn't oriented towards deletion so much as recovering old versions after you screwed one up. It was a pretty nice feature, although it tended to fill up disk space which was in short supply in those days.
Today, I thought undeleting was what the trash can was for. With today's big disks you shouldn't have to Empty Trash very often.
It's the day when my computer says, "I'm sorry, but you can't run this program" that I fear.
I guess this will be my last posting to this old thread. I go over this and over this, to no avail. It's pretty frustrating.
Your scenario is not going to happen. What could happen instead is that Microsoft, or Apple, or whoever, could say, "I'm sorry, but I'm not going to talk to you because you're not running my software." And you say, "Yes, I am." And they say, "Prove it," and you can't.
Today, nobody can prove it, so nobody asks you to. TC would let you prove it, so this kind of thing could happen. That's the real "horror" of trusted computing, that people might refuse to talk to you unless you prove you're running certain software.
To me, this is nowhere near as bad as what you describe, where you can't run software, or can only run signed software. You can run whatever you like. But you can't force anyone else to interact with you, and with TC you can't successfully lie about what software you're running.
That's the real impact of TC: you can't lie in certain ways that you can today. It's a threat only to liars. And judging from the near-universality of the opposition even when people understand how it truly works instead of the falsehoods they've been told about it, apparently most slashdotters fall into that category.
Unless a method is available to verify the current state against "what it should be" then the chip itself provides no security.
That's not true. One of the capabilities of the TPM is to encrypt data and lock it to the current software configuration. Then if you boot a different OS, the software configuration will be different and it will be impossible to decrypt the data. You will only be able to decrypt the data if you are running the original configuration. This lets a high-security OS lock up its data and be assured that if a low-security OS is booted instead, it won't be able to access the data. That's good security without any concept of "what the state should be".
Also, systems can report their state securely to remote computers on the net. The TPM signs the status report using a key embedded in the chip, that never leaves the chip and is known to be a valid TPM key. This lets remote computers decide whether they want to trust the local system, based on its software state as reported in this way.
And if the hashes can be modified then any given system can backcheck to see that it was loaded "properly" provided it can accurately compare the hashed results, but it cannot do a forward look to ensure that it will be loading the correct software.
Well, even without a TPM you could modify software (say, the Grub boot loader) with a list of known good hashes and only let them load the next step if it matched an expected hash. This kind of thing is always possible and is pretty much independent of what Trusted Computing aims to achieve.
TC lets you boot and run whatever software you want. (Claims to the contrary are probably the biggest TC related lies.) But as I have described above, its goal is to reliably detect what the system configuration is, and to then be able to lock data to that configuration, or report it to remote peers. This lets remote systems know, for example, that not only will data they send you be treated according to certain rules (which they know because they know what software you are running), but that your system can lock up that data so if you booted into software that wouldn't follow those rules, it couldn't access the data.
That's how it really works, despite the lies to the contrary. You can boot and run any software you like, yet data can be protected with high security. It's really an amazing architectural achievement.
I am very glad to see that Linus is standing up against the GPL and their misguided attempts to oppose trusted computing technology. It means that Linux will continue to be available as a basis for trusted computing research and development.
When you get past the misinformation, errors and outright lies, trusted computing is not as bad as people think it is. It is a technology for enhancing security in a variety of environments. See the TPM thread a few postings down on the slashdot main page for some commentary there.
Here's an example of what I was wondering about. Suppose a DoD employee has one of these Trusted Computer systems, and he wants to download some GPLv3 software. Maybe a future version of Firefox or something. Then the website he downloads it from is "Conveying" him the software in the meaning of GPLv3. And part of the requirement of that "Conveyance" is that the user can alter the software and remote systems can't tell the difference. But maybe on a Trusted Computer that is impossible. So, someone has violated the license. But who? Is it the user who downloaded the software? The DoD that made him get this computer (or gave it to him)? Seems to me it is the web site which is bound by the license and is limited in who it is allowed to "Convey" the software to.
If the TPM chip is as passive as you say then all it can do is answer the following question: "What is the last hash you were fed?"
That's not quite how it works. When I said that these hashes get fed to the TPM, I didn't say how it digests them.
The TPM has several 20-byte registers called Platform Configuration Registers (PCRs). They are initialized to zero. When it receives a hash it gets folded into one of the PCRs. It does this by computing PCRn = SHA1 (PCRn || NewHash), where || means concatenation. In other words it takes its current hash value, concatenates the new hash value, SHA1 hashes this 40-byte buffer to get a new 20-byte hash, and stores that.
This provides an update function that cannot be rolled back. If, during the boot sequence, any component deviates from a standard configuration, the PCR register will be changed irrevocably. It will be impossible for any later software action to feed anything to the TPM that would get the PCRs back to what they were supposed to be.
if you exercise your rights under the GPL by modifying and rebuilding the software, it's no longer "Trusted" because it's not signed.
You've been posting a lot on this, and it's not right.
First of all, there's no such thing as a distinction between "Trusted" and "Untrusted" software in absolute terms. Second, software does not have to be signed.
What actually happens is that TC systems can be designed to keep track of the hashes of all the software that runs, and load those hashes into the TPM chip. THe chip can basically do two things with them. It can encrypt data and lock it to the hashes, such that the data can't be decrypted unless the machine is in exactly the same software state. Or it can report the current hash values, signed by the on-chip, unspoofable crypto key.
That's the true functionality. Now, from this, you can get features that work similarly to what you say, but not exactly.
If you change software, especially your OS software, and reboot, the TPM chip will get a different set of hashes loaded into it during the boot process. If you had previously locked (encrypted) data to the old system configuration, you won't be able to decrypt it now. You'd have to reboot back into the old configuration. If your old OS was high-security, say a SELinux configuration, and the new OS is a live CD you inserted to bypass the security, you won't be able to do so.
But it's not like the old OS was "Trusted" and the new OS is "Untrusted". It's just that they have different hashes and produce different software configurations. Data locked to the new configuration can't be decrypted in the old one, and vice versa.
The other thing the chip can do is to optionally report out to remote systems what your software configuration is. Maybe someone will only talk to you if you are running a certain configuration. Then, FROM HIS POINT OF VIEW, that configuration is "Trusted", and he won't trust any other. But it's not true in absolute terms that your computer is in a "Trusted" state or not. It's just that party's opinion about which software configurations he chooses to trust. And you could even imagine a system in which party A only "Trusts" one configuration while party B only "Trusts" an incompatible configuration. I'm sure this kind of conflict is likely to happen in the early days of TC, if it ever gets to this point.
And keep in mind that you can turn this around, too. You could connect to remote systems, say e-commerce sites or other servers, and they could use TC to report their software configuration to you. Then you might choose to trust only certain software versions, maybe systems with the most recent patches for example. Or you could have a P2P network and each computer could check that the others are running good versions of the software, to prevent people patching their systems to allow leeching or flooding attacks. There are a lot of other uses for this technology beyond DRM.
Note though that a P2P network like this would apparently be illegal under GPLv3. It would not be allowed to have software that queries the state of the peers and only connects to them if they are the same software, because this would prevent people from patching their software and continuing to participate in the P2P net (they'd have to start a new subnet of their own). So this potentially useful security tool is being shut off from the world of GPLv3. Luckily, people can continue to use GPLv2, which I expect to happen.
Furthermore, it implies that all one need do is supply their own BIOS and bootloader code that uploads the hashes from the original BIOS and bootloader and the OS underneath will be none the wiser because the message it gets back from the TPM will be exactly what it's expecting to see.
Good question. The way the system works is kind of subtle. This is perhaps why so many people prefer to believe the falsehoods that our out there, about how the system will only run signed code and keep you from changing your own software.
The TPM chip is completely passive in a TC system. It relies entirely on the BIOS, bootloader and OS to feed it data. Yet the system is designed to be secure. Here is how it works.
The first part of the BIOS is non-flashable in a TC system. It is hard-coded to hash the whole rest of the BIOS and feed that data to the TPM, first thing.
Then the BIOS, before transferring control to the boot loader, hashes it and sends the hash to the TPM.
And the boot loader similarly hashes the OS and some config files, sending that data to the TPM, before transferring control. The Linux Trusted Grub project has a patched boot loader that does this.
The TPM can later report these hash values, signed with an on-chip crypto key that can't be spoofed.
People would need to know what these values are supposed to be on an untampered system. Then there's no way to alter a system and let it boot such that the TPM gets the same values and so you could fool people about what you are running. For example, you could try patching Trusted Grub to send a fake OS hash to the TPM so you could lie about what OS version you were booting. But recall that the BIOS hashes the boot loader before executing it. If you've changed Trusted Grub, it will have a different hash, and this will be reported to the TPM. (Keep in mind that the TPM does not check these hashes for "correctness", it just remembers them and can report them later.)
So yes, you can patch your boot loader to lie, but you still won't end up with the same system configuration "fingerprint" because the boot loader got hashed and the TPM told about it before it got control. In this way the system achieves the ability to security report its boot sequence and configuration, even though people can change the software involved.
And how does the TPM chip know that the information that the bios/os loader/os itself sends to it is actually the real information about the bios/os loader/os and not faked information from an unmodified version?
This happens via a staged-boot process.
The BIOS itself in a TPM computer has a non-flashable portion that runs at startup. This takes a hash of the rest of the BIOS and feeds it into the TPM. The BIOS then hashes the boot loader into the TPM (Grub, in the case of Linux) before transferring control to it. The boot loader can hash the OS before switching control to that. The Trusted Grub project on Linux has been enhanced to do this. Then you could have the OS hash application data into the TPM as it loads; so far only a few experimental projects do that, like Enforcer.
Now, the BIOS is hard-wired to tell the truth. But the later components could lie. You could have a patched boot loader (it's open source!) which does not send truthful data about the OS kernel and configuration to the TPM.
But you couldn't get away with this fraud. Recall that the BIOS hashes the boot loader and sends the data to the TPM before running it. If you patch Trusted Grub to lie, it will have a different hash, and the TPM will be told about it. (Note, the TPM doesn't have any "expectations" regarding what these hashes are supposed to be, it just remembers what it was told and can report it later, signed with a crypto key.) So with this concept, if someone knows what the system "fingerprint" is supposed to be of a secure BIOS + Trusted Grub + Enforcer Linux boot sequence, it's impossible for you to patch it and end up with that same exact pattern.
Actually, Trusted in this context means "the people in control can trust my computer to be secure against me," where "the people in control" refers to those who hold the private key to the TPM.
No one holds the private key of the TPM. The key is generated on-chip at manufacture time and never leaves the chip.
Are you are saying that if I connect to a web server running some sort of trusted computing, I will be able to trust it to not serve me malware?
You could get a degree of trust in it, yes. It could publish its software configuration, signed by a crypto key embedded in the TPM chip. This way you could verify that it was running the latest patched version of Apache and other software, and had no intentional malware insertion features.