I'm seeing a lot of denial here. Nobody wants to accept that Apple is moving away from this technology.
Apple championed Firewire. They gambled on it. They were the first to use this kind of high speed connection technology.
But the gamble hasn't paid off. Firewire has not spread successfully beyond Apple. PC's have nearly unanimously gone with USB2 instead.
At one time external disk drives primarily used Firewire. Today they mostly use USB2. Firewire drives are mainly targeted at Mac users. They tend to cost more, as with other Mac-specific technology, because it is a much smaller segment of the market.
The writing is on the wall for Firewire. USB2 has won. This latest move by Apple itself, champion of Firewire, just further underscores the reality of the situation.
Mac purists don't want to accept that Apple's gamble has failed. They deny the reality that is in front of them, and comfort themselves by quoting specs, just like the old Beta VCR purists did.
But all the specs in the world don't matter when the market moves away from a technology. That's what is happening with Firewire.
I just checked comodo.com and it says "starting from only $249 for a 2 year certificate". That's more than twice the $50 a year you quoted. Do they have some other cert that's cheaper?
Keep in mind that the pcHDTV card, and the Broadcast Flag in general, only works with Over-The-Air TV. It does not work with cable or satellite systems.
The last statistics I saw indicated that less than 20% of Americans don't have cable or satellite. This means that the BF will affect only that small minority who watches digital TV and receives it over the air. It doesn't affect cable viewers, and it doesn't affect satellite viewers.
As far as I know, HBO generally does not go over the air. That's because it's illegal to encrypt OTA TV. The BF is supposed to require equipment to sort of pretend that certain signals are encrypted and treat them as if they are protected. So maybe HBO could eventually use OTA broadcasts, if the BF is successful. But at this time, the BF is irrelevant to HBO.
I don't happen to live in a metropolitan area that has HDTV broadcasters. There are only a couple of TV stations even within reach of my small town, so pretty much everybody here has cable. The BF has no effect on me, and the pcHDTV card would be useless for me. Only a small percentage of people are affected.
This is really stupid. Firewire drives and CD burners are not endangered. Likewise D/A and A/D converter chips.
It's misleading and confusing to include these in the classification with technologies like Morpheus, which looks to be heading towards a loss in court with the recent admissions that it tracked individual downloads, and HDTV tuner boards which are already scheduled to be phased out this year due to the broadcast flag rules.
Re:Info on what exactly SHA-1 is ...
on
SHA-1 Broken
·
· Score: 4, Informative
I don't know about this, but when SHA (the Secure Hash Algorithm) was submitted as an approved algorithm for government use, the NSA reviewed it and suggested a minor change. That modified algorithm is what we now know as SHA-1.
Note quite right. The NSA invented SHA, but then a couple of years later discovered a weakness and made a slight change, to create SHA-1. The older version is now called SHA-0. According to Schneier's report, SHA-0 was broken even worse by the Chinese team, 2^39 work for a collision vs 2^69 for SHA-1. So the NSA's change was important and made a major increase in the strength of the algorithm.
It was a few years before public-sector cryptographers caught on to what the significance of the changes was (I wish I could explain it, but it is beyond me).
They just added a 1 bit rotate in one phase of the algorithm. Without it, SHA tends to keep the bits lined up and there is less mixing.
The three radar booms of MARSIS were initially to have been deployed in April 2004, towards the end of the Mars Express instrument commissioning phase. They consist of a pair of 20-metre hollow cylinders, each 2.5 centimetres in diameter, and a 7-metre boom. No satisfactory ground test of deployment in flight conditions was possible, so that verification of the booms' performance had to rely on computer simulation. Just prior to their scheduled release, improved computer simulations carried out by the manufacturer, Astro Aerospace (California), revealed the possibility of a whiplash effect before they locked in their final outstretched positions, so that they might hit the spacecraft.
So here's the problem. They designed this system based on computer simulations that turned out to be inadequate. It wasn't until years later that complete simulations were done which raised the possibility that deploying the radar could damage the spacecraft.
Why wasn't that discovered earlier? These kinds of issues should be raised and detected during the design phase, not once the craft is already in orbit around Mars! It's a lot easier to fix things here on Earth than forty million miles away.
I can't help thinking that they were trying to save money up front, so they could only afford a limited set of simulations. Then after the thing was launched they found money for more extensive simulation runs, which showed the problem (and led to yet even more extensive and expensive simulations, which gave them the courage to go through with the deployment anyway).
We've all seen cases like this, where there's never time and money to do it right, but then there's time and money to do it over again later. That may not be so bad in the office environment, but when you're talking about a spacecraft, it points to skewed priorities and inadequate management.
This is the best sign yet that we're winning the war on spam. This is exactly what measures like SPF were designed to induce - forcing zombies to go through the ISP rather than sending mail themselves.
Now all the ISPs have to do is to filter and detect sudden jumps in email traffic. It will be easy for them to detect systems which have been infected. This will catch the small number of users who suddenly start running high volume email lists from their home systems, but those cases will be few enough that they can be dealt with manually.
This is the beginning of the end for the zombie spam problem!
What? So they can't run lying software, so they can't do "anything"? Oh, I'm so confused!!
People can run lying software, it just won't convince anyone. It won't be credible, because it can't create fake reports signed with a validated and certified TPM key.
Now will you say that the inability to run software to create a false idea in someone else's mind means you can't run whatever software you want? Jeez, you might as well complain that you can't run software to solve the halting problem or teleport matter. It is beyond the power of software to make arbitrary changes in the universe. That's not a valid limitation on what you can do.
There are no guarantees in the world that you can lie. TPM makes it harder to lie by making it easier to verifiably tell the truth. That may be unfortunate for liars but it is not an actual constraint on their actions.
This means that the entire security of the boot process hangs on whatever data the CPU feels like sending to the chip for hashing. I could as well make a patch for GRUB that sends the "secure" version of GRUB down the SMbus and actually executes whatever nastiness I have in store.
That's a clever idea, but it doesn't work. The secret is that the trusted boot process uses a concept of "trust extension". We start off with the BIOS. That takes a hash of itself and sends it to the TPM. Then the BIOS will load and run the boot loader. But - and here is the key - before running GRUB, the BIOS take a hash of GRUB and sends it to the TPM. Then it runs GRUB.
The next step is that GRUB - or at least the TPM enabled version, performs a similar process for the OS kernel. It first takes a hash of the kernel and sends it to the TPM; then it runs the kernel. And the kernel can repeat the process with the various startup scripts and other programs that loads, a la tcgLinux or the Enforcer.
The key point is that before each component is loaded, it is "measured" (i.e. its hash is reported to the TPM). So you can create a bogus GRUB or a bad kernel, but this fact will show up in the TPM's configuration registers because your bad component got its hash reported before it ran.
The one exception is the BIOS, but TPM systems are supposed to have restricted BIOS flash capabilities so you can't re-flash the part of the BIOS which does the initial hash of itself. This is part of what they call the Core Root of Trust for Measurement (CRTM) and it is supposed to be inviolable.
I want to try to correct one of the most common and universal misconceptions about Trusted Computing: that it will only allow signed code to run. This is causing enormous confusion here, with people arguing about how that works with the GPL, who would get to sign the code, would users get to sign their own code, etc., etc.
The truth is that the TCG spec says nothing about signed code. There are no limitations in TCG that keep you from running unsigned code. There is no distinction between "secure" and "insecure" code. You can run anything you like. Signing is a complete red herring in this discussion.
I am not trying to gloss over problems or paint a false picture. The truth is that TCG does have features whose effects are somewhat like what people are worried about with signed code. The result is that TCG could be helpful for DRM, and it might make it impossible to download music from an online store without running a special application, for example. But this would not be because "you can only run signed code". Rather, it is the server that decides whether it wants to talk to you, not your computer deciding what you can and cannot run.
What's the difference? Well, if your main concern is being able to run hacked clients that will allow you to violate your user agreements, then there is no difference. You would be right to oppose Trusted Computing. It will make it harder to lie and pretend to honor an agreement, then break your word and go back on your promise.
But if your main concern is about the GPL and what software you run, there is a big difference. There are no limits on the software you can run. You can hack your Linux kernel to do whatever you want. You can disable "secure" features in the software you run. These privileges don't go away when there is a TPM chip. That should put to rest the concerns about the GPL and hopefully end the discussion about who signs what code.
If you're wondering how these two points of view can be compatible, you need to learn more about the TCG spec and the TPM chip. In a nutshell, the TPM chip, with the cooperation of the BIOS and OS software, takes a hash or fingerprint of the software configuration as the computer boots. It can then report this fingerprint to remote servers, if client software requests it. These reports are signed with an on-chip TPM key that never leaves the chip; and this chip has a certificate from the computer manufacturer, so no emulator can fake these reports (called remote attestations).
That's how it works. It's a lot more complicated than refusing to run unsigned code. What it comes down to is that software can report its configuration in a believable and, yes, trustable way. That's the real reason this is called Trusted Computing, not the lie made up by Ross Anderson. It's Trusted because you can Trust the reports from a remote system about what software it is running, and therefore what it will do.
The only argument I can see here is that you don't have to worry about some spyware sending your personal data to someone. But this only makes sense if you're running an insecure OS known for frequent vulnerabilities to spyware and viruses.
Oh, sure. Linux is perfectly secure, right? Keep on dreaming, it must be nice.
Actually, Linux security bugs are found all the time. Dan Bernstein had a bunch of undergraduates look and found 44 Linux security bugs in just a few weeks. The only reason Linux users are safe is because there are too few of them to be an attractive target. If and when Linux becomes popular for applications like banking, there will be plenty of malware stealing people's account numbers and draining accounts.
Um, no. Any trusted client system relies on keeping the client from tinkering with the TCP chip, and while this might be sufficiently complicated to keep people from copying your precious MP3s, it is not nearly secure enough for an election. I will be dead before I take part in an election where any sucker with a mod-chip can rig it!
Online Gambling
See the last comment. The financial incentive for rip-off casinos to hack the TC chips would be huge - so huge that I almost smile when I think about this use since it makes me more sure than ever that there will be modchips available. A much better system to secure against this is to play at reputable casinos and are tested by indpendents doing statistical analysis.
So what you're basically saying here is that TC is not secure enough for these applications. Two points: first, future versions will have increased security, for example by being built into the CPU. And second, we run these applications already, without any security at all. How can you possibly hold elections, for example, to such an unrealistically high standard, when elections are going on all the time that have much lower security? People vote online from overseas without any protection at all. And casinos likewise operate without any oversight or auditing whatsoever. Millions of people play these games every day. Adding security can only benefit them. Your rhetorical tactic of demanding perfect security is an obvious smokescreen designed to discourage approaches which improve the security of the system.
Financial Transactions
You've got to be kidding! I'm suppose to trust my bank to take care of my money if they cannot write a banking interface that doesn't rely on controling the client to keep it safe? You may claim Internet banking is in it's infancy, but I have been using it for five years and I cannot think of a single security threat against it caused by me being able to use Mozilla rather than IE to access the bank.
You're the one who's got to be kidding! Have you not heard of the many new forms of malware which are going after banking account numbers and infiltrating themselves into secure banking transactions? TC can stop these cold via sealed storage and remote attestation. Again, you are arguing that we should deny users access to these technologies purely for political reasons because you don't like the technology.
I won't go through the rest of your "analysis" because it's the same kind of bullshit. You are using any excuse you can think of to disparage a technology that can add security and improve reliability for millions of online users. It's obvious that you have an ulterior motive yourself. Any other technology which had all these obvious benefits would be welcomed.
My guess is that you are worried that TC will make it harder for you to pirate your favorate songs and movies. Well, if it makes you feel any better, that's probably not the case. Anything that can be observed can be recorded, TC or not. So why not focus on what you really care about rather than making up unreasonable objections that throw up a smoke screen of FUD around a technology with enormous potential for good?
Sure for most users (those with tons of spyware on their computer, or with computers that their kids have loaded with enough illegal IP that a lawsuit might come any day in the mail) trusted computing might be seen as a good thing.
I don't believe your scenario, but look at what you're saying. You want to inflict harm on the interests of most users in favor of your selfish desires. You are afraid that if this technology becomes popular, presumably because it satisfies the needs and desires of the broad mass of users, you will be inconvenienced.
Think about a horse rider who hated the new horseless carriages and foresaw that if they became popular, he would be forced off the road. He would have been right, but does that mean that we should go back to the time of the horse?
Like it or not, we should make social policy that considers the welfare of the large numbers of people over the welfare of the selfish few. In this case, all that is necessary is to stand back and let people decide for themselves what technologies they want to use. All those VHS purchasers made it hard on the die hard Beta enthusiasts, but we didn't try to forbid VHS from being used.
In the same way, TC should live or die based on how well it satisfies the needs of users. Don't use it if you don't like it, but don't try to stop other people from using it just because you are afraid it may become popular.
Your emulator will not have a certified TPM key (those stay on the chip)
That is why CSS is still not broken for DVD, heh?
CSS was a completely different case. It was implemented in software. This allowed a CSS key to be pulled out of the software, and the CSS algorithm itself to be revealed. Cryptanalysis of CSS (which was a proprietary algorithm created by a non-public process) then discovered weaknesses which allowed it to be broken even without a CSS key.
TCG is very different. It uses hardware to protect the keys, and no software implementation of TCG is necessary or will ever exist. And the cryptography being used is completely standard, based on RSA and other well known algorithms. The spec has been publicly available for review and comment for three years now, and some of the best cryptographers in the world have been involved.
Even if a TPM key does get pulled off a chip (which would require hundreds of thousands of dollars of reverse-engineering time and equipment, stripping it off layer by layer, using exotic devices like quantum interference based SQUID probes), the spec provides a feature to revoke a TPM key so that it will be of no use to people who want to produce fake, software-emulated TPMs.
The whole process of TPM design and development has been the opposite of the secrecy-shrouded CSS. The result should be exactly the opposite in terms of security.
Conversely, if the GPL allows me to sign binaries on a system where unsigned binaries don't run, then the GPL is broken
Trusted Computing doesn't work this way, never has and never will! This is a lie which has been promulgated by people who should know better. TC does allow systems to report their software configuration in a verifiable and unforgeable manner. This can allow servers to refuse service to clients which are not running specified software configurations. This is how DRM would be implemented using TC.
But there is no such prohibition as you describe, being unable to run unsigned binaries. Anyone can run anything they want. All they can't do is lie to someone else about what they are running. That's enough for DRM and many good uses of TC.
Please, stop spreading falsehoods and learn more about how the technology actually works. See my other comments in this topic where I have described it in more detail.
4. Trusted computing means that all binaries are signed with a secret key. 5. The Trusted CPU will not execute binaries that weren't signed with that key. 6. In this way, it is impossible for end-users to create modified binaries to add/remove features from the software.
This is total garbage. Where did you get this nonsense?
TC does not require binaries to be signed with a key. TC will not refuse to execute unsigned binaries. And end users can do whatever they want.
Now for the facts, in case you're interested. TC implements a secure boot. This allows the TPM chip to store a hash or fingerprint of your software configuration: the BIOS, the boot loader, the OS, and if desired, the applications that are running.
The TPM and OS can basically do two things with this information. They can implement "sealed storage" which means that a program can lock its encrypted data to the current software configuration. This means that if you boot a different OS, or if the program gets modified (either of which might happen due to virus infection), the fingerprint changes and the data will no longer be available. Likewise if another program tries to access the first program's sealed data, it won't be able to get access to it.
The second feature of the TPM is "remote attestation". This allows a program to request the TPM to issue a cryptographically signed statement about what the current software fingerprint is that is running. This signed attestation cannot be forged because the TPM generated an on-chip key at manufacture time, and the manufacturer issued a certificate on that key which the chip can use to prove to anyone that it is a legitimate TPM.
Remote attestation allows network applications to determine what software configuration the peers are running, and, if they choose, to disallow participation by software which is not running a specified set of configurations. This is the closest you will come to the idea that users can't change their own software. If they want to run a program which relies on this feature, and that program doesn't accommodate the changes the user wants to make, they would be shut out. But in practice, open source programs will probably be flexible in this regard as they will want to have as many people as possible participate. There are a number of technical measures which can be adopted to allow for considerable user flexibility.
But certainly none of this would violate the GPL or any other legal prohibitions. Everything is entirely voluntary, and Trusted Computing does not prevent you from doing what you want with your computer. You don't even have to turn it on if you don't want to!
I can already think of a workaround. Use an x86 emulator and two copies of Linux...
Emulation won't work to defeat DRM. The TPM generates an on-chip secret key at manufacture time which never leaves the chip. The manufacturer issues a certificate on the corresponding public key which certifies that this is a legit TPM key. The TPM then is able to issue attestations about the software configuration based on what is called a "secure boot" sequence, in which the TPM creates a fingerprint of the software configuration.
An emulated boot looks different from a real boot to the TPM, so the reported software configuration will be different. Your emulator won't be able to forge a TPM attestation report because it doesn't have a certified TPM key from the manufacturer. These keys stay on chip and there is no way (without spending hundreds of thousands of dollars on exotic chip-stripping equipment) to pull a TPM key off the chip.
Much cheaper to aim a video camera at the screen and put a microphone in front of the speakers.
Since the source is available for Linux, what would stop someone from sandboxing 'trusted' software by having the OS validate code before it's executed (slow, though a bit faster than emulation and without all the bugs), and then implenting the DRM hardware (or BIOS) instructions in software in a way that stores the keys (or plaintext information, if that is not doable) and allows access to any software to get the info.
This is one of the most commonly asked questions about the TPM. The answer is that the TPM implements what is called a "secure boot" sequence.
The first thing that happens in a TPM enabled computer is that the BIOS, on startup time, sends a hash of itself to the TPM. Then, when the BIOS goes to load the OS, it sends a hash of the boot loader (grub, in the case of Linux) to the TPM. The boot loader will be modified (see the Trusted Grub project) to take a hash of the OS kernel and send that to the TPM. And the OS itself will be modified (a la tcgLinux to take a hash of the various OS components, startup scripts, and programs as the computer boots.
The net result is that the TPM has a record of what OS was booted and what the software configuration is that is running. This allows it to distinguish between a "real" boot and an emulated one, because in the latter case it sees a hash of the emulator being loaded.
Software which runs in un-emulated mode and uses the TPM features can distinguish that case from when it is running emulated. If it locked some data using the TPM in the first mode, it won't be accessible in the second mode.
Once remote attestation is possible, networked applications will be able to report their software configuration to each other. This will be unforgeable because the TPM will sign an attestation of the software configuration, and the TPM itself will have a certificate from the manufacturer attesting that it is a legit TPM. Your emulator will not have a certified TPM key (those stay on the chip) and so it won't be able to come up with a credible forged attestation. Programs running on emulators won't be able to take part in network security applications that use these features.
Those who do not believe me (or those who are inclined to believe the MS shills who will respond saying that I am wrong), should read EFFs analysis of TCPA where they give a simple way that the chip could be changed to allow all uses except remote attestation intended to force people to use certain operating systems and enforce DRM over the user.
Further see this blog entry by the same author on good uses of Trusted Computingall of which rely on the supposedly evil Remote Attestation feature. EFF's proposal to allow people to override their systems' attestations would ensure that none of these applications would be possible.
The truth is that TC along with Remote Attestation is a new feature set for your computer which allows new ways for people to cooperate online. Some people oppose this because they don't believe that others should be allowed to cooperate in ways they don't approve of. They don't want you to be able to credibly commit to obeying certain rules in processing data. But they have no right to interfere in your private decision making processes.
Though the specifications detailed in the article are definately a Good Thing, they lack (at least as far as I could tell) any way of preventing unauthorized physical access to the chip.
Slashdot ran a story a few weeks ago about a new set of chips with built-in TPM features. These chips have the Trusted Computing capabilities built into the CPU. It will make it much more difficult to attack them physically since the TPM is not a separate module but is integrated into the whole system. Probably this is how all TC systems will be built eventually.
Trusted Computing Group (TCG) technology makes sense in the context of Linux. Microsoft refuses to implement it. They had their own conception, which was Palladium, then NGSCB, then was dropped. So if TCG is going to go forward at all, it has to be with Linux.
It's kind of ironic, because Ross Anderson's lying Anti-TCPA FAQ tries to claim that TC exists to kill Linux. And yet it is turning out that Linux is the salvation of Trusted Computing.
Don't believe the FUD about TC. When implemented in Linux using Open Source software, TC gives you new options for securing and expanding the capabilities of your computer.
It hasn't been called the Trusted Computing Platform Alliance, TCPA, for a couple of years now. It's now the Trusted Computing Group, TCG. Same technology, just a new name.
If USA can attack another country "Just Like That"(tm), I would consider Chinese's censorship a godsend given it's only imposed within its own country. If you decided to move there, respect its laws; if you don't agree with its laws, go somewhere else. You always have a choice.
I can't believe that people are agreeing with this sentiment. It's one thing to say that it may be unwise or unsafe to plan on breaking Chinese laws, given their lack of civil liberties, their arbitrary legal system, their authoritarian government, and their reliance on personal power rather than the rule of law. I agree that it's risky. But it's entirely another to suggest that it is morally wrong to go to China and seek to oppose or circumvent unjust laws!
The only people we should respect in this situation are those who are brave enough to oppose Chinese censorship from within the country. These people are putting their livelihoods and even their very lives on the lines! They are like the Russian refuseniks and dissidents who paid a terrible price for their opposition to their country's policies.
Any suggestion that the Chinese government deserves respect is completely misguided. Unlike in Western democracies, China has no system of accountability to the public. Its policies are purely designed to protect the entrenched power structure which runs the country. This is an evil and immoral system of government! The laws it passes have no moral force. Their system of censorship is purely intended to keep the truth from the Chinese people and keep the government in power.
We saw what happened when the Soviet Union tried their policy of perestroika and glasnost, openness, and allowed the media to operate freely. The resulting explosion of criticism and free speech brought the government to an end. The Chinese government fears this outcome. They know that if their people become able to communicate freely, they face the same danger.
So please, don't suggest that the government of China deserves "R.E.S.P.E.C.T." It deserves nothing but contempt. I'm not saying that it is a good idea to go there and break the laws, any more than doing so would be a good idea in any other authoritarian regime. But that's a matter of self preservation, not morality. The only people who deserve our respect are those who are taking chances to overcome Chinese censorship and bring the truth to the Chinese people.
The Mac was the first major computer with support for the 3 1/2 inch hard cased floppies. PCs continued to use the 5 1/4 inch soft floppies for years afterwards. I remember reading a magazine article where Jobs pulled a floppy out of his pocket and tossed it onto the table. Everyone gasped. They had learned how fragile floppy drives were and the importance of always carrying them careully and putting them promptly into the box (not only did the 5 1/4s bend, they had holes so dust could get onto the disk surfaces).
That's why everyone claps right at the beginning, he pulls the floppy out of his pocket(!) and sticks it into the computer.
People watching today might not realize that the Mac did not have a hard drive. One was later provided as an expensive extra option. But initially the Mac had only a floppy drive to boot from.
Those were the days... I loved the Mac. I bought one back in 1984, the first GUI I'd ever used. Then a year later I laboriously unsoldered the memory chips and upgraded the system from 128K to a whole half a meg of memory. I can't count how many Macs I've bought over the years since then... we've got 7 right now, counting the 2 my kids in college have.
Since the original comment was censored by right-leaning moderators, here is a recap:
I have a hunch that you were modded down because what you're saying doesn't seem sensible.
It isn't just federal funding for stem-cell research that has been banned. Federal funding for any research, related or not, bans any embryonic stem-cell research from being conducted, anywhere, by anyone associated with the organization involved. Nearly every research organization in the country receives federal funding in one form or another. If the lab across campus doing physics has a federal grant, you can't do embryonic stem-cell research (except using the existing, contaminated lines).
If that were true, it would mean for example that the California stem cell initiative would be practically worthless. None of the top California state and private universities, institutions like Berkeley and Stanford, UCLA and Cal Tech, would be able to take on any of the funding from this initiative, because they all have physics departments and other departments that receive federal grants. The only people who could receive funding under the California initiative would be small private clinics.
But that's obviously not true. California research institutions strongly supported the stem cell initiative, and if the funds weren't going to be able to be used by the top researchers, opponents of the initiative would have used that fact to kill it.
In sum, your statement flunks the plausibility test. The ban on federal funds for stem cell research can't be as extreme as you say. If you want to claim otherwise, please provide a link to the text of the regulation for us to see for ourselves. In the absence of such a response, I encourage moderators to once again mod you down.
I'm seeing a lot of denial here. Nobody wants to accept that Apple is moving away from this technology.
Apple championed Firewire. They gambled on it. They were the first to use this kind of high speed connection technology.
But the gamble hasn't paid off. Firewire has not spread successfully beyond Apple. PC's have nearly unanimously gone with USB2 instead.
At one time external disk drives primarily used Firewire. Today they mostly use USB2. Firewire drives are mainly targeted at Mac users. They tend to cost more, as with other Mac-specific technology, because it is a much smaller segment of the market.
The writing is on the wall for Firewire. USB2 has won. This latest move by Apple itself, champion of Firewire, just further underscores the reality of the situation.
Mac purists don't want to accept that Apple's gamble has failed. They deny the reality that is in front of them, and comfort themselves by quoting specs, just like the old Beta VCR purists did.
But all the specs in the world don't matter when the market moves away from a technology. That's what is happening with Firewire.
I just checked comodo.com and it says "starting from only $249 for a 2 year certificate". That's more than twice the $50 a year you quoted. Do they have some other cert that's cheaper?
Keep in mind that the pcHDTV card, and the Broadcast Flag in general, only works with Over-The-Air TV. It does not work with cable or satellite systems.
The last statistics I saw indicated that less than 20% of Americans don't have cable or satellite. This means that the BF will affect only that small minority who watches digital TV and receives it over the air. It doesn't affect cable viewers, and it doesn't affect satellite viewers.
As far as I know, HBO generally does not go over the air. That's because it's illegal to encrypt OTA TV. The BF is supposed to require equipment to sort of pretend that certain signals are encrypted and treat them as if they are protected. So maybe HBO could eventually use OTA broadcasts, if the BF is successful. But at this time, the BF is irrelevant to HBO.
I don't happen to live in a metropolitan area that has HDTV broadcasters. There are only a couple of TV stations even within reach of my small town, so pretty much everybody here has cable. The BF has no effect on me, and the pcHDTV card would be useless for me. Only a small percentage of people are affected.
This is really stupid. Firewire drives and CD burners are not endangered. Likewise D/A and A/D converter chips.
It's misleading and confusing to include these in the classification with technologies like Morpheus, which looks to be heading towards a loss in court with the recent admissions that it tracked individual downloads, and HDTV tuner boards which are already scheduled to be phased out this year due to the broadcast flag rules.
I don't know about this, but when SHA (the Secure Hash Algorithm) was submitted as an approved algorithm for government use, the NSA reviewed it and suggested a minor change. That modified algorithm is what we now know as SHA-1.
Note quite right. The NSA invented SHA, but then a couple of years later discovered a weakness and made a slight change, to create SHA-1. The older version is now called SHA-0. According to Schneier's report, SHA-0 was broken even worse by the Chinese team, 2^39 work for a collision vs 2^69 for SHA-1. So the NSA's change was important and made a major increase in the strength of the algorithm.
It was a few years before public-sector cryptographers caught on to what the significance of the changes was (I wish I could explain it, but it is beyond me).
They just added a 1 bit rotate in one phase of the algorithm. Without it, SHA tends to keep the bits lined up and there is less mixing.
The three radar booms of MARSIS were initially to have been deployed in April 2004, towards the end of the Mars Express instrument commissioning phase. They consist of a pair of 20-metre hollow cylinders, each 2.5 centimetres in diameter, and a 7-metre boom. No satisfactory ground test of deployment in flight conditions was possible, so that verification of the booms' performance had to rely on computer simulation. Just prior to their scheduled release, improved computer simulations carried out by the manufacturer, Astro Aerospace (California), revealed the possibility of a whiplash effect before they locked in their final outstretched positions, so that they might hit the spacecraft.
So here's the problem. They designed this system based on computer simulations that turned out to be inadequate. It wasn't until years later that complete simulations were done which raised the possibility that deploying the radar could damage the spacecraft.
Why wasn't that discovered earlier? These kinds of issues should be raised and detected during the design phase, not once the craft is already in orbit around Mars! It's a lot easier to fix things here on Earth than forty million miles away.
I can't help thinking that they were trying to save money up front, so they could only afford a limited set of simulations. Then after the thing was launched they found money for more extensive simulation runs, which showed the problem (and led to yet even more extensive and expensive simulations, which gave them the courage to go through with the deployment anyway).
We've all seen cases like this, where there's never time and money to do it right, but then there's time and money to do it over again later. That may not be so bad in the office environment, but when you're talking about a spacecraft, it points to skewed priorities and inadequate management.
This is the best sign yet that we're winning the war on spam. This is exactly what measures like SPF were designed to induce - forcing zombies to go through the ISP rather than sending mail themselves.
Now all the ISPs have to do is to filter and detect sudden jumps in email traffic. It will be easy for them to detect systems which have been infected. This will catch the small number of users who suddenly start running high volume email lists from their home systems, but those cases will be few enough that they can be dealt with manually.
This is the beginning of the end for the zombie spam problem!
What? So they can't run lying software, so they can't do "anything"? Oh, I'm so confused!!
People can run lying software, it just won't convince anyone. It won't be credible, because it can't create fake reports signed with a validated and certified TPM key.
Now will you say that the inability to run software to create a false idea in someone else's mind means you can't run whatever software you want? Jeez, you might as well complain that you can't run software to solve the halting problem or teleport matter. It is beyond the power of software to make arbitrary changes in the universe. That's not a valid limitation on what you can do.
There are no guarantees in the world that you can lie. TPM makes it harder to lie by making it easier to verifiably tell the truth. That may be unfortunate for liars but it is not an actual constraint on their actions.
This means that the entire security of the boot process hangs on whatever data the CPU feels like sending to the chip for hashing. I could as well make a patch for GRUB that sends the "secure" version of GRUB down the SMbus and actually executes whatever nastiness I have in store.
That's a clever idea, but it doesn't work. The secret is that the trusted boot process uses a concept of "trust extension". We start off with the BIOS. That takes a hash of itself and sends it to the TPM. Then the BIOS will load and run the boot loader. But - and here is the key - before running GRUB, the BIOS take a hash of GRUB and sends it to the TPM. Then it runs GRUB.
The next step is that GRUB - or at least the TPM enabled version, performs a similar process for the OS kernel. It first takes a hash of the kernel and sends it to the TPM; then it runs the kernel. And the kernel can repeat the process with the various startup scripts and other programs that loads, a la tcgLinux or the Enforcer.
The key point is that before each component is loaded, it is "measured" (i.e. its hash is reported to the TPM). So you can create a bogus GRUB or a bad kernel, but this fact will show up in the TPM's configuration registers because your bad component got its hash reported before it ran.
The one exception is the BIOS, but TPM systems are supposed to have restricted BIOS flash capabilities so you can't re-flash the part of the BIOS which does the initial hash of itself. This is part of what they call the Core Root of Trust for Measurement (CRTM) and it is supposed to be inviolable.
I want to try to correct one of the most common and universal misconceptions about Trusted Computing: that it will only allow signed code to run. This is causing enormous confusion here, with people arguing about how that works with the GPL, who would get to sign the code, would users get to sign their own code, etc., etc.
The truth is that the TCG spec says nothing about signed code. There are no limitations in TCG that keep you from running unsigned code. There is no distinction between "secure" and "insecure" code. You can run anything you like. Signing is a complete red herring in this discussion.
I am not trying to gloss over problems or paint a false picture. The truth is that TCG does have features whose effects are somewhat like what people are worried about with signed code. The result is that TCG could be helpful for DRM, and it might make it impossible to download music from an online store without running a special application, for example. But this would not be because "you can only run signed code". Rather, it is the server that decides whether it wants to talk to you, not your computer deciding what you can and cannot run.
What's the difference? Well, if your main concern is being able to run hacked clients that will allow you to violate your user agreements, then there is no difference. You would be right to oppose Trusted Computing. It will make it harder to lie and pretend to honor an agreement, then break your word and go back on your promise.
But if your main concern is about the GPL and what software you run, there is a big difference. There are no limits on the software you can run. You can hack your Linux kernel to do whatever you want. You can disable "secure" features in the software you run. These privileges don't go away when there is a TPM chip. That should put to rest the concerns about the GPL and hopefully end the discussion about who signs what code.
If you're wondering how these two points of view can be compatible, you need to learn more about the TCG spec and the TPM chip. In a nutshell, the TPM chip, with the cooperation of the BIOS and OS software, takes a hash or fingerprint of the software configuration as the computer boots. It can then report this fingerprint to remote servers, if client software requests it. These reports are signed with an on-chip TPM key that never leaves the chip; and this chip has a certificate from the computer manufacturer, so no emulator can fake these reports (called remote attestations).
That's how it works. It's a lot more complicated than refusing to run unsigned code. What it comes down to is that software can report its configuration in a believable and, yes, trustable way. That's the real reason this is called Trusted Computing, not the lie made up by Ross Anderson. It's Trusted because you can Trust the reports from a remote system about what software it is running, and therefore what it will do.
The only argument I can see here is that you don't have to worry about some spyware sending your personal data to someone. But this only makes sense if you're running an insecure OS known for frequent vulnerabilities to spyware and viruses.
Oh, sure. Linux is perfectly secure, right? Keep on dreaming, it must be nice.
Actually, Linux security bugs are found all the time. Dan Bernstein had a bunch of undergraduates look and found 44 Linux security bugs in just a few weeks. The only reason Linux users are safe is because there are too few of them to be an attractive target. If and when Linux becomes popular for applications like banking, there will be plenty of malware stealing people's account numbers and draining accounts.
So what you're basically saying here is that TC is not secure enough for these applications. Two points: first, future versions will have increased security, for example by being built into the CPU. And second, we run these applications already, without any security at all. How can you possibly hold elections, for example, to such an unrealistically high standard, when elections are going on all the time that have much lower security? People vote online from overseas without any protection at all. And casinos likewise operate without any oversight or auditing whatsoever. Millions of people play these games every day. Adding security can only benefit them. Your rhetorical tactic of demanding perfect security is an obvious smokescreen designed to discourage approaches which improve the security of the system.
You're the one who's got to be kidding! Have you not heard of the many new forms of malware which are going after banking account numbers and infiltrating themselves into secure banking transactions? TC can stop these cold via sealed storage and remote attestation. Again, you are arguing that we should deny users access to these technologies purely for political reasons because you don't like the technology.
I won't go through the rest of your "analysis" because it's the same kind of bullshit. You are using any excuse you can think of to disparage a technology that can add security and improve reliability for millions of online users. It's obvious that you have an ulterior motive yourself. Any other technology which had all these obvious benefits would be welcomed.
My guess is that you are worried that TC will make it harder for you to pirate your favorate songs and movies. Well, if it makes you feel any better, that's probably not the case. Anything that can be observed can be recorded, TC or not. So why not focus on what you really care about rather than making up unreasonable objections that throw up a smoke screen of FUD around a technology with enormous potential for good?
Sure for most users (those with tons of spyware on their computer, or with computers that their kids have loaded with enough illegal IP that a lawsuit might come any day in the mail) trusted computing might be seen as a good thing.
I don't believe your scenario, but look at what you're saying. You want to inflict harm on the interests of most users in favor of your selfish desires. You are afraid that if this technology becomes popular, presumably because it satisfies the needs and desires of the broad mass of users, you will be inconvenienced.
Think about a horse rider who hated the new horseless carriages and foresaw that if they became popular, he would be forced off the road. He would have been right, but does that mean that we should go back to the time of the horse?
Like it or not, we should make social policy that considers the welfare of the large numbers of people over the welfare of the selfish few. In this case, all that is necessary is to stand back and let people decide for themselves what technologies they want to use. All those VHS purchasers made it hard on the die hard Beta enthusiasts, but we didn't try to forbid VHS from being used.
In the same way, TC should live or die based on how well it satisfies the needs of users. Don't use it if you don't like it, but don't try to stop other people from using it just because you are afraid it may become popular.
Your emulator will not have a certified TPM key (those stay on the chip)
That is why CSS is still not broken for DVD, heh?
CSS was a completely different case. It was implemented in software. This allowed a CSS key to be pulled out of the software, and the CSS algorithm itself to be revealed. Cryptanalysis of CSS (which was a proprietary algorithm created by a non-public process) then discovered weaknesses which allowed it to be broken even without a CSS key.
TCG is very different. It uses hardware to protect the keys, and no software implementation of TCG is necessary or will ever exist. And the cryptography being used is completely standard, based on RSA and other well known algorithms. The spec has been publicly available for review and comment for three years now, and some of the best cryptographers in the world have been involved.
Even if a TPM key does get pulled off a chip (which would require hundreds of thousands of dollars of reverse-engineering time and equipment, stripping it off layer by layer, using exotic devices like quantum interference based SQUID probes), the spec provides a feature to revoke a TPM key so that it will be of no use to people who want to produce fake, software-emulated TPMs.
The whole process of TPM design and development has been the opposite of the secrecy-shrouded CSS. The result should be exactly the opposite in terms of security.
Conversely, if the GPL allows me to sign binaries on a system where unsigned binaries don't run, then the GPL is broken
Trusted Computing doesn't work this way, never has and never will! This is a lie which has been promulgated by people who should know better. TC does allow systems to report their software configuration in a verifiable and unforgeable manner. This can allow servers to refuse service to clients which are not running specified software configurations. This is how DRM would be implemented using TC.
But there is no such prohibition as you describe, being unable to run unsigned binaries. Anyone can run anything they want. All they can't do is lie to someone else about what they are running. That's enough for DRM and many good uses of TC.
Please, stop spreading falsehoods and learn more about how the technology actually works. See my other comments in this topic where I have described it in more detail.
4. Trusted computing means that all binaries are signed with a secret key.
5. The Trusted CPU will not execute binaries that weren't signed with that key.
6. In this way, it is impossible for end-users to create modified binaries to add/remove features from the software.
This is total garbage. Where did you get this nonsense?
TC does not require binaries to be signed with a key. TC will not refuse to execute unsigned binaries. And end users can do whatever they want.
Now for the facts, in case you're interested. TC implements a secure boot. This allows the TPM chip to store a hash or fingerprint of your software configuration: the BIOS, the boot loader, the OS, and if desired, the applications that are running.
The TPM and OS can basically do two things with this information. They can implement "sealed storage" which means that a program can lock its encrypted data to the current software configuration. This means that if you boot a different OS, or if the program gets modified (either of which might happen due to virus infection), the fingerprint changes and the data will no longer be available. Likewise if another program tries to access the first program's sealed data, it won't be able to get access to it.
The second feature of the TPM is "remote attestation". This allows a program to request the TPM to issue a cryptographically signed statement about what the current software fingerprint is that is running. This signed attestation cannot be forged because the TPM generated an on-chip key at manufacture time, and the manufacturer issued a certificate on that key which the chip can use to prove to anyone that it is a legitimate TPM.
Remote attestation allows network applications to determine what software configuration the peers are running, and, if they choose, to disallow participation by software which is not running a specified set of configurations. This is the closest you will come to the idea that users can't change their own software. If they want to run a program which relies on this feature, and that program doesn't accommodate the changes the user wants to make, they would be shut out. But in practice, open source programs will probably be flexible in this regard as they will want to have as many people as possible participate. There are a number of technical measures which can be adopted to allow for considerable user flexibility.
But certainly none of this would violate the GPL or any other legal prohibitions. Everything is entirely voluntary, and Trusted Computing does not prevent you from doing what you want with your computer. You don't even have to turn it on if you don't want to!
I can already think of a workaround. Use an x86 emulator and two copies of Linux...
Emulation won't work to defeat DRM. The TPM generates an on-chip secret key at manufacture time which never leaves the chip. The manufacturer issues a certificate on the corresponding public key which certifies that this is a legit TPM key. The TPM then is able to issue attestations about the software configuration based on what is called a "secure boot" sequence, in which the TPM creates a fingerprint of the software configuration.
An emulated boot looks different from a real boot to the TPM, so the reported software configuration will be different. Your emulator won't be able to forge a TPM attestation report because it doesn't have a certified TPM key from the manufacturer. These keys stay on chip and there is no way (without spending hundreds of thousands of dollars on exotic chip-stripping equipment) to pull a TPM key off the chip.
Much cheaper to aim a video camera at the screen and put a microphone in front of the speakers.
Since the source is available for Linux, what would stop someone from sandboxing 'trusted' software by having the OS validate code before it's executed (slow, though a bit faster than emulation and without all the bugs), and then implenting the DRM hardware (or BIOS) instructions in software in a way that stores the keys (or plaintext information, if that is not doable) and allows access to any software to get the info.
This is one of the most commonly asked questions about the TPM. The answer is that the TPM implements what is called a "secure boot" sequence.
The first thing that happens in a TPM enabled computer is that the BIOS, on startup time, sends a hash of itself to the TPM. Then, when the BIOS goes to load the OS, it sends a hash of the boot loader (grub, in the case of Linux) to the TPM. The boot loader will be modified (see the Trusted Grub project) to take a hash of the OS kernel and send that to the TPM. And the OS itself will be modified (a la tcgLinux to take a hash of the various OS components, startup scripts, and programs as the computer boots.
The net result is that the TPM has a record of what OS was booted and what the software configuration is that is running. This allows it to distinguish between a "real" boot and an emulated one, because in the latter case it sees a hash of the emulator being loaded.
Software which runs in un-emulated mode and uses the TPM features can distinguish that case from when it is running emulated. If it locked some data using the TPM in the first mode, it won't be accessible in the second mode.
Once remote attestation is possible, networked applications will be able to report their software configuration to each other. This will be unforgeable because the TPM will sign an attestation of the software configuration, and the TPM itself will have a certificate from the manufacturer attesting that it is a legit TPM. Your emulator will not have a certified TPM key (those stay on the chip) and so it won't be able to come up with a credible forged attestation. Programs running on emulators won't be able to take part in network security applications that use these features.
Those who do not believe me (or those who are inclined to believe the MS shills who will respond saying that I am wrong), should read EFFs analysis of TCPA where they give a simple way that the chip could be changed to allow all uses except remote attestation intended to force people to use certain operating systems and enforce DRM over the user.
And see this rebuttal to the EFF report.
Further see this blog entry by the same author on good uses of Trusted Computing all of which rely on the supposedly evil Remote Attestation feature. EFF's proposal to allow people to override their systems' attestations would ensure that none of these applications would be possible.
The truth is that TC along with Remote Attestation is a new feature set for your computer which allows new ways for people to cooperate online. Some people oppose this because they don't believe that others should be allowed to cooperate in ways they don't approve of. They don't want you to be able to credibly commit to obeying certain rules in processing data. But they have no right to interfere in your private decision making processes.
Though the specifications detailed in the article are definately a Good Thing, they lack (at least as far as I could tell) any way of preventing unauthorized physical access to the chip.
Slashdot ran a story a few weeks ago about a new set of chips with built-in TPM features. These chips have the Trusted Computing capabilities built into the CPU. It will make it much more difficult to attack them physically since the TPM is not a separate module but is integrated into the whole system. Probably this is how all TC systems will be built eventually.
Trusted Computing Group (TCG) technology makes sense in the context of Linux. Microsoft refuses to implement it. They had their own conception, which was Palladium, then NGSCB, then was dropped. So if TCG is going to go forward at all, it has to be with Linux.
It's kind of ironic, because Ross Anderson's lying Anti-TCPA FAQ tries to claim that TC exists to kill Linux. And yet it is turning out that Linux is the salvation of Trusted Computing.
There are a number of research projects in TC on Linux, including TPM Device Driver, Trusted GRUB and Secure GUI, tcgLinux, TCPA Open Source Platforms, Enforcer, and more. All Linux based.
Don't believe the FUD about TC. When implemented in Linux using Open Source software, TC gives you new options for securing and expanding the capabilities of your computer.
It hasn't been called the Trusted Computing Platform Alliance, TCPA, for a couple of years now. It's now the Trusted Computing Group, TCG. Same technology, just a new name.
If USA can attack another country "Just Like That"(tm), I would consider Chinese's censorship a godsend given it's only imposed within its own country. If you decided to move there, respect its laws; if you don't agree with its laws, go somewhere else. You always have a choice.
I can't believe that people are agreeing with this sentiment. It's one thing to say that it may be unwise or unsafe to plan on breaking Chinese laws, given their lack of civil liberties, their arbitrary legal system, their authoritarian government, and their reliance on personal power rather than the rule of law. I agree that it's risky. But it's entirely another to suggest that it is morally wrong to go to China and seek to oppose or circumvent unjust laws!
The only people we should respect in this situation are those who are brave enough to oppose Chinese censorship from within the country. These people are putting their livelihoods and even their very lives on the lines! They are like the Russian refuseniks and dissidents who paid a terrible price for their opposition to their country's policies.
Any suggestion that the Chinese government deserves respect is completely misguided. Unlike in Western democracies, China has no system of accountability to the public. Its policies are purely designed to protect the entrenched power structure which runs the country. This is an evil and immoral system of government! The laws it passes have no moral force. Their system of censorship is purely intended to keep the truth from the Chinese people and keep the government in power.
We saw what happened when the Soviet Union tried their policy of perestroika and glasnost, openness, and allowed the media to operate freely. The resulting explosion of criticism and free speech brought the government to an end. The Chinese government fears this outcome. They know that if their people become able to communicate freely, they face the same danger.
So please, don't suggest that the government of China deserves "R.E.S.P.E.C.T." It deserves nothing but contempt. I'm not saying that it is a good idea to go there and break the laws, any more than doing so would be a good idea in any other authoritarian regime. But that's a matter of self preservation, not morality. The only people who deserve our respect are those who are taking chances to overcome Chinese censorship and bring the truth to the Chinese people.
The Mac was the first major computer with support for the 3 1/2 inch hard cased floppies. PCs continued to use the 5 1/4 inch soft floppies for years afterwards. I remember reading a magazine article where Jobs pulled a floppy out of his pocket and tossed it onto the table. Everyone gasped. They had learned how fragile floppy drives were and the importance of always carrying them careully and putting them promptly into the box (not only did the 5 1/4s bend, they had holes so dust could get onto the disk surfaces).
That's why everyone claps right at the beginning, he pulls the floppy out of his pocket(!) and sticks it into the computer.
People watching today might not realize that the Mac did not have a hard drive. One was later provided as an expensive extra option. But initially the Mac had only a floppy drive to boot from.
Those were the days... I loved the Mac. I bought one back in 1984, the first GUI I'd ever used. Then a year later I laboriously unsoldered the memory chips and upgraded the system from 128K to a whole half a meg of memory. I can't count how many Macs I've bought over the years since then... we've got 7 right now, counting the 2 my kids in college have.
Since the original comment was censored by right-leaning moderators, here is a recap:
I have a hunch that you were modded down because what you're saying doesn't seem sensible.
It isn't just federal funding for stem-cell research that has been banned. Federal funding for any research, related or not, bans any embryonic stem-cell research from being conducted, anywhere, by anyone associated with the organization involved. Nearly every research organization in the country receives federal funding in one form or another. If the lab across campus doing physics has a federal grant, you can't do embryonic stem-cell research (except using the existing, contaminated lines).
If that were true, it would mean for example that the California stem cell initiative would be practically worthless. None of the top California state and private universities, institutions like Berkeley and Stanford, UCLA and Cal Tech, would be able to take on any of the funding from this initiative, because they all have physics departments and other departments that receive federal grants. The only people who could receive funding under the California initiative would be small private clinics.
But that's obviously not true. California research institutions strongly supported the stem cell initiative, and if the funds weren't going to be able to be used by the top researchers, opponents of the initiative would have used that fact to kill it.
In sum, your statement flunks the plausibility test. The ban on federal funds for stem cell research can't be as extreme as you say. If you want to claim otherwise, please provide a link to the text of the regulation for us to see for ourselves. In the absence of such a response, I encourage moderators to once again mod you down.