This is getting to be a real annoyance. I don't want to have to download (7x650) 4.550 GB of data just to try out the latest linux distro. Some people aren't even able because they're either on a modem or have capped broadband. Personally, I'd like to see all distros cut down to three:
1 CD to install the OS. This would be the only cd necessary to install the operating system. With just this one cd, the user would be able to install their chosen distro of GNU/Linux and get a graphical desktop with some very basic apps (I'm picturing basically everything on the accessories menu on windows).
Up to 2 cds of apps - an office suite, dev tools, games, whatever. After using the single OS install disc, the user would then be able to pop an apps cd into the system and choose what they want.
No source cds. I'm not saying that distro makers shouldn't provide source code to the binaries that they distribute (they should!) and I'm certainly not saying that source is useless (it's not!). I'm just saying that making ISOs of source packages available for download is a great way to waste bandwidth for users and mirror sites that don't bother to mark them as non-essential to the process of 'getting something working'. Windows doesn't have a loop device to check out isos before they're burned, so newbies from windows can't help but be confused. (Yes, I know about Daemon Tools. Does everyone else?)
It would eliminate bloated 2GB default installs and cd swapping. Sure, there wouldn't be a (start|hat|k|foot|swirl) menu that takes up 10MB of space on disk just for the items it contains, but that's probably a good thing.
I'm not bashing suse or RH or any of the other GNU/Linux distros. I'm just saying that the default install/CD bloat is way out of hand and this would be an easy way to solve it. The way I see it, it's a no-brainer like replacing "scary" printk's during kernel startup with a booting progress bar (by default).
Those aren't instructions. Learn braille! It says:
Warning: You are currently standing in front of a drive-up atm. Please move out of the way before you are run over by a careless driver intent on withdrawing $20.00.
Imagine if your video board and sound board or their integrated chipset equivalents used encrypted data formats instead of unencrypted - it wouldn't matter that you put a logic probe in the line, because you couldn't read the bits. It wouldn't even require much extra CPU - the RC4 encryption algorithm is strong enough, fast enough, and uses very little memory. Key exchange is requires some CPU, but it would be pretty simple to build a public-private keypair into the adapter, where the public key is retrievable by the CPU but the private key is only accessible to the adapter, and require a setup message (either at boot time, or perhaps on a per-application basis) that creates a session key, pk-encrypts it, and hands it to the adapter.
I think this is the eventual plan, but as far as I know it's not implemented yet, nor is it in the works. However, I remember reading in an article about HDTV that the DVI interface currently supports almost exactly this scheme. Scary, no?
But the TCPA / Palladium / Fritz Hollings view of DRM basically requires the system to give root access to any program that wants to use the security, and that's blazingly unsafe. It's not clear to me that you can get away with much less than that and still get real application security, but the stuff's obviously Not Ready For Prime Time even on a requirements basis, much less a design or implementation basis.
I actually took the time to start reading through the "general" and "PC-specific" TCPA specs and, while it's certainly a bad idea, it doesn't require as much of a security sacrifice as you suggest. Individual applications that need to make use of "security functions" have two resources at their disposal.
The first is a crypto coprocessor soldered onto the motherboard. If that crypto chip is satisfied with the state of the system (signed OS, signed drivers, encrypted display connection) then it releases certain private and public keys to signed applications on request. In order to be signed, executable code (in the OS, drivers, or software package) must not at any time disclose those keys to other applications, store them unencrypted on disk, or do anything else that could lead to exposure of those keys to an untrusted entity.
The second resource all programs have access to is the a small program running in what I guess could be called "ring -1" (in palladium it's called "the nub"). By making requests to this program, an application can allocate "secure" memory for itself that neither the OS nor any other program can access. This could be used to store unencrypted uncompressed video frames, for example, before they are sent to the video card.
In other words, individual programs that make use of TCPA "security" functions don't gain root access to the system - they access a limited TCPA API to perform a few functions that execute at a privilege level above that of the OS. The TCPA effectively eliminates the rights of the end user, but it does so in a tidy way.
I believe you're referring to my post that contains video overlay. I'm aware that video overlays can be captured quite easily with the right software or when video acceleration is turned off - I was using WMP as an example to show that 'printscreen' by itself isn't a magic answer to everything. Most slashdotters (in my opinion) are aware that if something can be seen it can be copied. However, too many (again in my opinion) believe that if it can be seen, it can be copied easily (i.e. with printscreen). I see this fallacy as dangerous as it encourages people to feel secure in the false belief that DRM cannot be implemented in a way that interferes with their lives and is not worth worrying about.
Thank you for your comment, though. I did neglect to mention in my original post that directshow overlay can easily be defeated...I hope nobody got the wrong impression.:)
The author hit the nail on the head - copy protection is impossible. However, the example he used (capturing data with the printscreen key) is a weak illustration of this fact, especially considering the recent speculation about palladium. For example, think about clips played using video overlay in windows media player. Pressing print screen while playing one would yield an off-black rectangle where you would expect a video frame to be. The real reason copy protection is not possible is a little more complicated than "print screen".
I think it's pretty well understood that now, in the pre-palladium/TCPA universe, copy prevention is impossible. If you can read a CD, you can copy it. Perhaps your specific cd burner's firmware isn't robust enough to write specific "strange" bit patterns, but bit-for-bit cd-duplicating machines cannot be fooled. If you can watch a movie contained in a file, you can send it to a friend. Even if that file is encrypted, the player program must decrypt it in order to play it and that decrypted data can be grabbed and written to disk.
At first glance, it seems like palladium will put a stop to this with its careful use of encryption and digital signatures. This is not true. Information physics didn't just fly out the window. All that Palladium accomplishes in connection with modified PC hardware is a separation of user and computer into two entities. Currently, users have complete control over their systems. Any OS can be run and no information is hidden from it by the hardware. The system, all by itself, is incapable of protecting its own private keys from the user. It is incapable of preventing the user from assuming its identity. A palladium OS running on TCPA-compliant PC hardware changes this. A TPM, or Trusted Platform Module, charged with the responsibility of certifying that a DRM-aware OS is running on the hardware is included on the motherboard and has its own sets of private and public keys. The critical difference between a TCPA-compliant computer and a PC of today is that the TCPA PC has its own "identity" separate from its user as defined by its ability to keep its keys confidental and process information using them.
It is well known that the only way to be sure a secret is kept is to make sure that all entities who know that secret agree to keep it a secret. If even one entity "in the know" decides to divulge it to an outside party, that information can no longer be controlled. Palladium/TCPA tries to implement copy protection by ensuring that the only entities that get access to that information agree to keep it a secret - namely the TPMs. In other words, if you were to enter your credit card information into a web site in order do download a palladium-protected movie, you didn't purchase the video for yourself. As it would be transmitted as data encrypted using the TPM's public key, you actually be purchasing the video for another entity, your TPM. The idea is that TPMs will obtain various metrics of the system on boot (is the OS signed or unsigned? the drivers? etc...) and only perform cryptographic operations at the request of the system if everything checks out. In addition, a special "trusted" cpu mode that has the same kind of power over kernel mode that kernel mode has over user mode (an inexact description but good analogy) is used to provide for allocating memeory that is only readable by a trusted application through calls to the program running in trusted mode. That's Palladium/TCPA in a nutshell. The reason that everyone seems to be so upset about it is that, in a bug-free environment, there are no software attacks on the system. The are many hardware attacks, such as special memory that can be used by the system and read by another device, soldering capture devices into output cards, or physically opening the TPM and extracting its cryptographics keys. The list goes on. Also, as information only has to be liberated from the "circle of friends", including all TPMs in all computers and the ??AA, once a single hardware mod would create an unpluggable leak through which an infinite amount of infomation could flow.
Critical and unrepairable holes in Palladium have been found before it has been deployed.
This brings me to the reason I'm writing this post: slashdot is permeated with ignorant fear. People believe that their ability to get copies of music, movies, and software without paying a cent is going to be in jeopardy. While this creates a great deal of support for anti-palladium initiatives (which is good), ignorant advocates can seriously hurt the fight for sensible treatment of information and universal recognition of the truth of information physics by providing passionate but incorrect and empty arguments against palladium and the TCPA (which is bad). So, if you'll still be able to get free entertainment in a palladium world (albeit with much more difficulty and a soldering gun), why is palladium bad? A number of very serious reasons:
Palladium will work reasonably well as attacks, though possible, are difficult. Over time, the majority of computer users would be convinced to believe the dangerous fallacy that copy protection is possible with the support of sufficient laws and technology. This belief (whether fostered by ignorance or campaign contributions) in our elected representatives what spawned the DMCA. In other words, your freedoms are in jeopardy as well as your friday night movie-and-popcorn party.
Palladium claims that it is capable of protecting your personal information - your name, address, credit card number, etc... - and puts you in a position of total control over how that information is used. Users that are bamboozled by the tantalizing promise of "trusted computing" will place their important personal information into the care of an unreliable system under the control of an entity that has profit rather than the users' best interests at heart. That is, they will forego the only true way to make sure personal information is kept confidential - not giving it to the computer. This may become incredibly difficult when the latest version of windows kindly demands it during the install process to activate the user's initial one-year license term.
In order to work, palladium-enabled service providers must be able to verify whether or not the cryptographically signed message coming from the client computer saying "This computer is running DRM-aware software," was signed by a TPM which is reporting accurate system metrics. In order to make sure those messages are unspoofable (by emulating the TPM in software) a central registry of all TPMs and their individual public keys must be maintained and made accessible. In other words, all palladium computers will have unique indelible ID tags and will report them over the internet to whoever asks. I don't have to explain to slashdot the privacy implications of this kind of system.
Hopefully I've managed to replace some ignorant fear with some informed fear. If you're not a member of the EFF, ask yourself why. Right now.
In line with what they other posts said, non-blocking I/O can be accomplished by letting the DMA controller take over transfers while the CPU does other things. However, I think the advantage that SCSI has over IDE that you're thinking of is that SCSI can have multiple outstanding transactions on a bus at once while IDE cannot. In other words, you can send a read request to one SCSI disk and, while it's being processed, send out another one to another SCSI disk on the same bus. With IDE, you have to wait to send a request to a new device on a channel until the last one finishes.
I'm not 100% sure about this, so if you need to make decisions based on this information I suggest you do some research elsewhere. You might want to check out the online pc guide.
How does the gnutella client start to build a host cache without connecting to a well-known source? Or rather, how does it connect to this source without making it possible for the ISP to MITM.
Some clients connect to a server operated by the client maintainer the first time they're installed. Others use a web-based host caching mechanism to get started. Some have regularly updated host cache files that come with the software. Once a client gets connected for the first time, it sends out a ping packet over gnet (not ICMP ping, gnet ping). Any hosts that need more entries in their host caches respond to the ping with a pong packet containing their IP address and listening port. From that point on, the host has (or can get) as many other ip:port pairs as it wants.
Anyway, I'd love an URL or two with more information about the future direction of gnutella.
Sadly, there's not a great deal of direction in terms of the future of the gnutella network; however, there are a couple of sites worth visiting. The Gnucleus home page has a forum component that's usually pretty lively. It's not exactly developers only, though, so expect to see a lot of posts from people who have "Great Ideas!" about what the developer should do next but don't know anything about programming or gnet. There's also the RFC-Gnutella project on sourceforge that aims to (obviously) produce an RFC on the gnutella protocol, or at least get it standardized to the point where all developers can agree on how servents should pass around data.
"... a copyright owner shall not be liable in any criminal or civil action for disabling, interfering with, blocking, diverting, or otherwise impairing the unauthorized distribution, display, performance, or reproduction of his or her copyrighted work on a publicly accessible peer-to-peer file trading network, if such impairment does not, without authorization, alter, delete, or otherwise impair the integrity of any computer file or data residing on the computer of a file trader."
It's a get out of jail free card for tampering with the network for stopping copyright infringement, but it does not cover tampering with files on your computer.
Oops, I goofed. I fell for the slash-hype and REposted it without REsearching. Thanks for pointing this out!:)
It a user downloads the entire file from them, the client program, upon completion of the download, will report an error since the hash that the file should have does not match the hash of the downloaded data. Not too serious - just some wasted downstream bandwidth on the part of the user. This kind of attack also costs the ??AA mega$ as they are the only source for the file:
Simple chaffent:
Collect a list of (filename, filesize, hash) we want to fake. Reply when someone is searching (both name search and hash search). Allow connect from clients and start serving bogus data. Disconnect the transmition after a little while. Add the client IP to a ~30min blacklist (maybe shared by all chaffents). Don't answer any reconnect requests from that IP as long as it is on the blacklist.
For the user, this should look just like someone that was online for a while and then disconnected. The user will try to resume the download from other sources, but the file is already broken.
If the servent can't download from the ??AA junk server, the user will eventually become impatient with the download and try another source. Tiger-tree hashing (which I described lower down) provides the means for servents to intelligently and automatically cull garbage data from the download. When all of the data has been downloaded (the 30 minutes of garbage data + the rest of the legit file) and 5% of the file doesn't fit with the other 95%, the servent can just re-download that 5% from random servers until it gets one that fits. The only attack on this would be for the ??AA to feed data to the client faster than the rest of the p2p network, eventually filling 51% of the file with garbage. The servent would then fruitlessly seek the other 49% of the garbage file (the real data being the suspect minority) and would not complete the download. However, in order for the ??AA to execute this attack, they would have to serve up 51% of the bits on p2p networks - in other words, out-bandwidth the rest of the p2p community.
In other words, the ??AA won't be able to corrupt your downloads unless they out-bandwidth the rest of the p2p community.;)
Or rather - out-search-request-answer if done as above.
See above, although yes, query hit flooding is also a problem.;)
The problem, essentially, is that you don't know if the metadata reported about the file (title, resolution, length, etc...) is accurate.
[snip explanation]
Sounds like a good approach for ensuring metadata integrity.
Anyway, I get this image of FBI busting someone and discovering the private key of a notorius release group on his computer. This could actually make it easier to track down the really big copyright infringers.;-D
Well, it could make it easier to _prosecute_ copyright infringers, except that private keys are encrypted using a symmetric cypher and a passphrase in the secret keyring . The longer, the better - long enough to stop FBI crackers and long enough to forget during questioning.
Considering that P2P traffic is something like 80% of the total Internet traffic at the moment, ISPs wanting to do bandwidth throttling is not exactly surprising.:)
In many situations you actually want to do bandwidth shaping in order to keep the network running smoothly. You don't want your P2P traffic to hog so much bandwith that the responsiveness of your interactive SSH sessions go south.
I heartily agree.:) Maintaining network responsiveness is a high priority; however, it shouldn't be done by throttling the collective p2p bandwith usage for an entire campus to 64kbps. (Yes, I did read the link in the latest story and I know UCI is throtling to 10mbps. I'm thinking of a different campus.) Making p2p traffic undifferentiable from other traffic to automated throttling programs is one way to "persuading" ISPs and UCs to rethink their packet shaping device configurations and perhaps offer to simply de-prioritize p2p traffic rather than throttle it outright, in exchange for the use of servents that have identifiable traffic which can then be de-prioritized by automated methods.
If all communications on p2p networks started with a raw exchange of public keys, the first (for example) 2048 bits of p2p connections would be different from client to client.
Smells like overkill to me, but anyway.
This kind of extreme undetectability might be necessary in some cases. Very few protocols other than the one I describe (in my limited estimation) have the first 2048 bits set to the same value for every outbound connection. A static per-client public key could be a dead giveaway for traffic shapers.
Ports used for (at least gnutella) p2p are already random, btw.
At least the initial connect is to a well-known port, no?
No. Initial connects and file transfers now use random ports on the gnutella network as long as the user is running a client that supports it. Gnucleus, for example, does. (Yay open source!)
If your ISP really wants to spend a lot of time and resources to track you, they could play man-in-the-middle from the initial connect with the gnutella network. Not that it would ever be worth the effort, but anyway.
Read the very last paragraph I wrote in my original post. ISPs couldn't reliably execute MITM attacks without borking all non-p2p traffic. ISPs couldn't execute MITM attacks at all without borking a significant amount of non-p2p traffic.
Now what do I do? Well, at least in my opinion, the first thing you should do is recognise that UCI is doing the second best thing they could possibly do in this situation. The only better option would be to give p2p third priority after web traffic (first) and general traffic (second) but not restrict it to a max of 10mbps (out of 60) no matter what else is going on. Congratulate them for being honest and openly allowing p2p to boot.
What can you do? Well, from a networking point of view, not much. The UC controls your connection and can throttle it as much as they want. Currently, your system sorts traffic into three categories: Favored (packets get priority): HTTP for web access Neutral (packes are routed as usual): General traffic, e.g. games, ftp, telnet, etc... Unfavored (packets are throttled regardless of available bandwidth): p2p
If your goal is to speed up file transfers, your only easy and immediate option is to start trading ftp logins with others, as ftp traffic falls into the second (mostly unrestricted) category, or use some other File Transfer Protocol. There is another solution to the throttling/snooping problem that would prevent ISPs and universities from being able to single out p2p traffic, but it would require reworking the protocol used by the p2p network of your choice. As it happens, I just posted more info on this exact topic earlier today in another story. You may find some of it informative if you're interested in the future/development of p2p.
What should you do? Well, it's obvious that UCI cares more about bandwidth than legal threats from the abusive and overbearing ??AA. Try starting up a LAN-only file sharing network. You won't be subject to any throtling, the speeds will be _much_ better than downloading off of some ADSL user with 128kbps of upstream bandwidth, and there's a p2p client that's already written and available for download that meets your exact needs. It's also stable, fast, spy/ad/crapware-free, and GPL'd to boot. In case you're struck with a craving to learn more, you can find the program author's site here.
The confusing thing is that I'm hard pressed to think about any attacks on P2P networks that:
1) Is not already legal today (For example, filling the network with bogus Britney mp3s), or 2) Impacts only illegal sharing of copyrighted material instead of killing the whole - or parts of the P2P network itself.
The purpose of the bill is to create a safe harbour for 'content owners' that use technology to impair the sharing of copyrighted content on P2P networks.
Given this, I think it is arguable that an effective way to stop the sharing of copyrighted content on p2p networks without imparing sharing of uncopyrighted works (or copyrighted by those who do not restrict the distribution of their works) is to delete the files containing copyrighted works from computers participating in the p2p network. Since the Berman bill gives them a (somewhat) blank check to break "hacking" laws in pursuit of this goal as long as they notify the gov't first, I think they will end up doing exactly that. However, I really should have been more specific in my first post. I should have said:
Media companies have legal permission to crack into your computer and delete files that contain copyrighted content as long as they tell the gov't about it first.
-------------
What if the RIAAntiKazaa chaffing servent simply lies about the hash. You can't check that the hash is correct before you have downloaded the file anyway. Besides, with segmented downloading you only need to download one segment of a file from the chaff servent to destroy the file.
If you do SHA (or similar secure hashes) on segments of the file, it would be possible to discard only the bad segments instead of the whole file.
My knowledge of what's going on in p2p is limited to the gnutella network, but here's what's happening right now:
Files are can be searched for by their SHA1 hashes and almost all major servents support this. Currently, the only thing that the ??AA could do to inhibit downloading (beyond what I noted in my first post re: bad files & user laziness) would be to find out the hash of a good file, and report that they have the file whenever they receive a search request for it. It a user downloads the entire file from them, the client program, upon completion of the download, will report an error since the hash that the file should have does not match the hash of the downloaded data. Not too serious - just some wasted downstream bandwidth on the part of the user. This kind of attack also costs the ??AA mega$ as they are the only source for the file: non-SHA1-aware clients won't be able to propagate the false hash reporting and SHA1-aware clients will dump the file as soon as it's done downloading. In other words, the only thing the ??AA has going for them right now is user laziness.
Here's what's going to happen in the near future:
The ??AA isn't faking hashes because they (probably) followed the same line of reasoning. However, faking hashes can cause other problems. Since SHA1 hashes hash all the data in the file to produce the output hash, even a small chunk of changed data in the file will affect whether or not the downloading servent thinks the download is "good". If the RIAA were to report that they had the "good" file corresponding to the "good" hash, but send "bad" data when the "good" file is requested, they could wreak havoc on servents that support multisource downloading. If a servent downloads even one byte from one of the ??AA's destructive interloper nodes, trying to download the file a bit faster by downloading from another source, the SHA1 hash calculated after the download finishes would be incorrect, killing an otherwise successful download as you mentioned above.
As luck would have it, P2P developers have been trying to enable partial file sharing (sharing available [downloaded] parts of unfinished downloads) for quite some time. It turns out that implementing this technology will render the above attack useless.
Soon, servents will support "bitprint" hashes. A bitprint hash is a concatenation of the SHA1 hash of a file, and a hash obtained by using the tiger-tree method. The tiger tree method: 1. Break the file up into equal size chunks. (say, 1MB) 2. Hash each chunk. 3. Concatenate adjacent chunks to make new chunks. 4. Go to step 2. All of these hashes, done using the Tiger algorithm, form a tree where each node has two leaves - hence Tiger-Tree. The original idea was that servents could use this tree of hashes to ensure data integrity when downloading pieces of a file from multiple hosts. Since ??AA-trashed data will not hash to what it should, just like corrupted data, those blocks will be thrown out and re-downloaded until a good block is obtained from a non-??AA host.
In other words, the ??AA won't be able to corrupt your downloads unless they out-bandwidth the rest of the p2p community.;)
There are still two (technical) issues threatening p2p and oddly enough I think they can both be solved by strong public key cryptography. The first is fake files - that is files containing garbage data from the ??AA and misnamed files. The problem, essentially, is that you don't know if the metadata reported about the file (title, resolution, length, etc...) is accurate. However, one of the things I've noticed about online file trading is that files that appear there, especially movies, are tagged with short prefixes identifying the ripping/encoding team. "[smr]", for instance, stands for "shadow movie realm". While rips of apps and games don't generally have these filename tags, they are generally distributed as archives containing, along with the program, an info file of some sort crediting the crackers. The common thread is that most content is introduced into the network by a small number of dedicated, talented "teams" that want credit for their work. To me, this seems like a perfect application of digital signatures. If, upon release of new content, the block of metadata describing that content (title, resolution, length, etc, and bitprint hash) were signed by the release team, then downloaders with the release team's public key could verify which rips are genuinely what they say they are, or more to the point, which hashes point to good files. Is it vulnerable to other people posing as the release team and signing data with their own keys? Sure, but over time one public key would develop more "cred" than all of the spoofs and since the release teams would only sign their own releases, that "best key" would be accepted as theirs. The best thing is, this whole process can be automated. Servents can even keep track of key validity (cred) by themselves simply by asking the user "Is this signed file what it says it is?" upon completion of a download.
The second issue is eavesdropping and bandwidth throttling by ISPs (especially universities). This problem can easily be solved by recognising that an ISP can only safely throttle what it can identify. If all communications on p2p networks started with a raw exchange of public keys, the first (for example) 2048 bits of p2p connections would be different from client to client. For extreme undetectability, servents could generate new public/private key pairs for each new connection. All following bits would be encrypted and unavailable to the ISP. It would seem that this technique would be vulnerable to a man in the middle attack by the ISP; however, consider what it would take to execute that kind of attack. The ISP would have to modify the first (again, for example) 2048 bits of a connection that it knows nothing about because it just initialized. While this would gain them access to the unencrypted data stream of a p2p connection, it would horribly confuse any other software trying to communicate over the internet. In other words, they can only check for p2p communications by killing all non-p2p communications. Ports used for (at least gnutella) p2p are already random, btw.
Most slashbots are too lazy to write (as in with a pen, paper, a hand, and an informed mind, not as in forward email with a computer) their congresscritters let alone hit refresh in a browser once every minute for...how long? In any case, I think DDoSing wouldn't even be all that effective in promoting social change which is what we really need. What I find interesting is that they've already spelled out that the CTO must come up with a plan to engage in P2P warfare. I mean, I realize that job descriptions are all about...well...describing jobs, but it seems like they're saying, "You have complete freedom....to find a way to do what we've already decided is the best thing to do even though that's a decision the CTO should make." Isn't it the Chief Technology Officer's responsibility to say things like, "Hmm, maybe our company's current position with respect to technology, that is using the public's ignorance against them to push oppressive DRM into all digital devices, isn't working. Why don't we evaluate some other plans?" Again, I realize that they probably don't want someone who would make that statement as their CTO, but it still seems odd.
------------ Also:
Slightly OT, but there are actually two things going on here:
1. Media companies have legal permission to crack into your computer and delete files as long as they tell the gov't about it first. This doesn't give them the legal right to distribute fake files, but that activity wasn't illegal in the first place as cracking into someone else's computer and deleting their files was. I don't know if they've actually done this yet.
2. They distribute fake files on p2p networks with names that suggest they're not fake. The idea is that the fakes are released before real content, fakes spread all over the network, and real content gets hard to find because nobody bothers to delete their downloads that turn out to be fakes.
They can't fake the _hashes_ on files. If they have a rogue p2p client online, they can respond to searhes for a certain hash and try to get clients to download from them, but when legitimate p2p clients see that the bytes coming from the rogue client don't hash to what they're supposed to, those bytes won't be included in the file. The only way they could "fake the hash" is by finding another file that has exactly the same length and hash as the original file but contains different data. I don't know what fastrack/winmx/others use, but gnutella uses SHA1 hashes (or bitprint hashes which incorporate SHA1) which are designed to resist that kind of attack. In other words, if you have file (A), it is easy to find its hash (B), but it is near impossible to find another file (C) with the same hash (B) as the first file (A). Of course, as long as p2p users remain lazy and ignorant and p2p software developers don't develop features that prompt the user to identify and delete bad files, media companies won't have to fake the hash in order to frustrate users.
This is really cool. If Apple added ogg support to their iPod I would chuck my very old 32MB flash mp3 player and buy one of these in an instant. However, this kind of notice, "First program to do task X under linux!" kinda frightens me. I mean, it's good that it's being done and I'm sure a lot of people would get a lot of use out of it, but what happens when the second program comes out, and the third?
In an open market where physical goods are being sold, competition is good and improves consumer choice. Don't like product A? Try substitute product B. Think B is too expensive? Try product C. And so on... Same thing to a lesser extent with commercial software, except there might not be two packages that do *exactly* the same thing but could still be substituted for eachother. Example: Dreamweaver and GoLive. Both are site design tools, but they don't have exactly the same function sets. (PLEASE no flames to the effect of "How DARE you compare Dreamweaver and GoLive?! ABC is OBVIOUSLY superior to XYZ! They're not even in the same class of products!" It's just an example.)
However, with open source software, <sweeping generalization>multiple "substitute" goods can hurt choice and the end user's experience.</sweeping generalization> Why? Well, many times, like this one, a piece of OSS doesn't perform a complete function that the average user can take advantage of. A backend is great, but unless you love the command line to death and can't get enough of long technical manuals, readmes, and errata, and don't really care if it takes you an hour or mode just to get started, you're going to want a frontend. It may be a textual one with a nice menu system. Undoubtedly someone will produce one of those (not everyone likes mice;) ). It may be an app that uses qt widgets and integrates really well with konqueror. I can see KPod coming now. It may be one based on gtk2 that snuggles up next to nautilus. That would be GPod. Let's say that there are two backends: backend1 and backend2. Let's further say that the designers of the textual and gtk2 frontends decided to build on backend1 because that's the one that they could get to work on their home boxes. The KDE designer is using backend2 because it's easier to write on top of.
At first glance it seems like the user has a lot of choice - two backends and three frontends are available to let him access his iPod under linux. Except he's a KDE user and he can't get backend2 to work. Or he's got his GNOME desktop all set up the way he likes it but the only way he can get the feature he needs from backend1 (which he has to use because there's no GNOME frontend for backend2) is by using the latest alpha build of backend1 which tends to crash when doing large file transfers. He could try using the console frontend or reading up on the backend, but the last time he tried that he borked his iPod when he tried to convert its built-in HFS+ partition to FAT32. The "simple" task of getting his linux box to talk to his iPod is turning into a headache. "Hmm," he thinks, "I heard Windows DRM 2005 has a nice iPod app that just works...maybe I should try that out."
Ok, ok, I'm aware that this is an obviously constructed scenario, but I think it illustrates my point. Wouldn't we be better off with ONE backend that WORKS rather than two that are lacking? Just like closed source software development has its strengths and weaknesses, so does open source. I've just described one of the weaknesses - the tendency to have multiple projects that try to do the same thing and end up splintering the user base. Take advantage of the corresponding strength of OSS: that you can work together on a SINGLE project with another developer even if she's halfway around the world (as long as you speak the same [programming] language). Please, developers, please - if you despise the way a particular backend works, don't just start your own. Unless the first one goes away, you'll only end up hurting users. Find out if there's a way you can contribute to the backend - fix the bug that's really bothering you or add the feature you desperately need to a project that's already started. Work together with other developers - it's better for everyone involved.
As I see it, the question that's being asked is: "Does the retroactive extension of copyright promote the progress of science and useful arts?" I think the obvious answer to that question is no - there's no sense in securing income for dead people, but the copyright clause in the constitution just says what congress can do, not what they have to do or even are fobidden to doing the opposite of. From this perspective, it doesn't seem like it's very likely that Eldred v. Ashcroft will turn out well for consumers.
But there's another way to look at it. Congress is not specifically bound not to inhibit the progress of science and useful arts; however, if congress passes legislation repealing a law that inhibits the progress of science and useful arts, they are promoting the progress of science and useful arts. Isn't congress inhibiting the progress of science and useful arts when they extend the term of copyright to 70 years beyond the death of the original work's creator? If a company can sit around and get fat on old copyrights then they have a greatly reduced incentive to produce anything new. Wouldn't congress be promoting the progress of science and useful arts if they were to repeal the CTEA?
You're thinking of the Voodoo Graphics and Voodoo 2 from 3Dfx, and you're correct - they were replaced by more popular all-in-one cards such as the voodoo 3. However, the reason that all-in-one cards were preferable at that time was that the connectors between the 2d and 3d cards were analogue. Everyone using a VG or V2 had to run a short vga cable out of their 2d card and into their 3d card. Their monitor then plugged into the 3d card, which operated as a pass-through device when not in use. Needless to say, this kind of setup wasn't the best for signal quality. Also, since it was outside the case, it was prone to being kicked or knocked out of place during an energetic gaming session.
Making the interface digital, placing it inside the case, and supporting resolutions that the inevitable hardware-game performance leapfrogging will never let us approach would, in my non-hardware-developer opinion, be enough to solve those old problems and make that kind of setup popular.
On a side note, the all-in-one card that directly followed the pass-through cards in 3Dfx's line-up, the Voodoo Banshee, developed an absolutely awful reputation for performance and stability. It was so bad, in fact, that its successor which should have been called the Banshee II as it was, essentially, a bug and performance fix on the original, was renamed and marketed to great success as the Voodoo 3.
Beowulf, a fictional Scandanavian warrior from the sixth century, is the subject of the oldest known english epic poem. Read it here . Naturally (?), geeks working on clustering computers together to combine their number crunching power decided to name their work after it. I think this may have to do with Beowulf having the combined strength of 50 men.
I don't understand how you could have trouble figuring this out. The FIRST link that came up when I did a search for Beowulf on google explaned what beowulf means in a clustering context. Elsewhere on the FIRST page there was a link to the translation I linked above. Learn to use google.
That would certainly be acceptable. However, I would tend to think that the cost of making those components modular would mostly negate the benefits of not having to buy a new pcb every time you upgrade. Personally, I'm all for separation of function into three separate devices (output, input, and rendering).
1. A 2D display card with DVI/VGA and TV output. Possibly multiple sets of outputs depending on how "fancy" you want the card to be and how much you're willing to spend.
2. A video input card with coax, firewire, DVI, RCA, etc... input connectors.
3. A card designed solely for 3D rending with a GPU, fast ram, and, most importantly, a standard digital interface to the RAMDAC on the 2D card.
That would allow for the optimum modularity and consumer benefit. Need support for a new kind of output device, or more output devices? Buy a new output card. Want real-time hardware support for a new video compression codec? Buy a new video input card. Want to play the lastest game at reasonable frame-rates? Buy a new 3D card. There wouldn't be any worries about forward compatibility as the video input component isn't really an integral part of the system - it's just been bundled with video cards in recent years. There's the interface between the 2D card's frame buffer and the 3D card's output, but all you need is a one-time digital interface capable of supporting, say, 2048x1536 at 32bpp. Most gamers would be willing to accept that graphics card technology will never be far enough ahead of game software to play at resolutions/bit depths greater than 2048x1536x32 at any kind of reasonable frame-rate (unless of coures you're playing GLQuake on your "GeForce 5 Palladium 400"). Given that, the bandwidth of the bus can stay constant while the memory bandwidth and core clocks on successive models of 3D cards could grow.
I'm sure that graphics card manufacturers want to provide us with as few upgrade options as possible for the simple reason that it would mean more money for them. However, I don't think memory slots on cards would be all that useful. Usually, the bottleneck that triggers an upgrade for most consumers is a killer app that pushes more polygons and requires a faster GPU with more rendering pipelines and faster graphics memory. More sticks of DDR SGRAM isn't going to do you any good there.
What is wrong if they are to offer 256Kb/128Kb DSL or Cable for like $15/month for those who doesn't need huge broadband for Pr0n downloads and online gaming?
I'd totally agree with you - most people don't need the speed that broadband provides today, except I'd also argue that unless you're sending and receiving large volumes of data (music, movies, etc...), 256/128 would do just fine for about everything, including online gaming and porn. Only the greediest online games (network-wise) even begin to touch data rates of 16KB/s (128kbps). Sure, you can configure them to use more than that, but the difference between 32KB/s and 16KB/s dedicated to a game is incredibly small compared to the difference between 5KB/s (a modem) and 16KB/s (limited DSL/cable). Also, packet latency is a much greater contributing factor to a positive gaming experience than data rate. Considering that low pings cost _nothing_ to provide as they are mostly a result of the technology bridging the last mile and not the ISPs backbone connection which, for most providers, are very very very low latency. Besides, I find (and I think most people would agree with me) that the most useful part of "broadband" is that it's always on (yeah yeah, I know, only when your computer is) and it doesn't tie up your phone line or stop you from watching cable tv at the same time (depending on service type). I'm a "power user", and I'd be more than happy to "downgrade" to a 256/128 for $10-$15/month compared to the $50 I pay now for 2000/256 if I get to keep the always on and low latency parts.
I have to take the side of Clean Flicks on this one - there's no reason anyone should be restricted from buying bits, modifying them, and selling them. However, it makes me wonder why the directors even care. They can't be worried about their "vision being corrupted" as they don't complain about the TV versions of movies. The issue can't be money either - Clean Flicks buys a copy of the movie for every edited copy they sell. The directors, not to mention the MPAA, are making more money because the market for their products is broadened by Clean Flicks. I'm rather bewildered as to why they're so upset.
This story makes me think about that DVDSynth article slashdot had a few days ago. While the software is currently for geeks only, it doesn't seem like all that much effort would be required to implement a similar capability in set-top DVD players. If Clean Flicks were to distribute "mod cards" containing rom chips with info to patch the.ifo and.bup files on the DVD, the copyright gestapo wouldn't have a leg to stand on - Clean Flicks wouldn't be distributing copyrighted content, and they wouldn't have to buy a copy of the movie for every mod they sold. The directors and the MPAA would make just as much money as consumers would need to buy a copy of the original DVD for the mod roms to patch against.
This kind of technology isn't really meant for home use - you'd have to buy a special reader device just to input your "number". Also, any transaction would probably only check a few places on the card and send that data (maybe a few KB). If they kept the entire contents of your card in a database, they would have to maintain 125GB of space on their servers per customer.
Of course, at some point, the decrypted data is visible internally to the computer.
Yup. True for any system. However, I don't think using them as individual keys on a per-media basis would fly. That would mean the data on the dvd would have to be encrypted individually with whatever key was attached to it, which means that stamping out large numbers of dvds from the same master would become impossible. Considering that it would be way too slow to burn dvds one by one at manufacturing plants, I don't think the media companies would go for it.
This story has a misleading title. Basically, the article says that they've found a cheap way to implement a hashing function in hardware. Unlike a software hashing function that takes data to be hashed as input and produces the hash as output, the physical mechanism accepts a certain pattern of lasers as input and produces a speckled light pattern that can be observed from any angle as output. Since the position of the glass beads in the epoxy will be different for all cards, each glass and epoxy smear will have a different hash function that can be used to tell them apart.
There's no encryption/decryption going on here, just hashing, but that is an important concept in the field of cryptography.
The main application of this is to replace magnetic stripes on credit cards. Currently, the machine-readable part of a credit card produces a small amount of static output (16 or so decimal digits) and is easy to copy with readily available equipment. By switching to these new chips, the number and complexity of possible outputs that the card can produce would be increased and the output-producing device would be more difficult to duplicate.
For example, right now your electronics-geek waiter could slip your credit card through her palm pilot with home-made magnetic reader attachment on her way back to the register. Later, she could take a used or invalid credit card, and write your magnetic pattern onto the bar. Credit card machines wouldn't be able to tell the difference between the original and the duplicate, so she effectively stole your credit card and you wouldn't know until the bill came.
If you were using a glass and epoxy chip, there would be several problems with duplicating this kind of attack.
1. The waiter would have to read 125 gigabytes (1Tb=1TB/8=~125GB) of data into her intermediate storage device in a few seconds. That's a lot of fast memory to pack into a small space. Copying only a few possible outputs wouldn't work, as only the credit card company would know exactly which (laser position, card output) data pairs it had on file for use in a challenge-response protocol.
2. Assuming the waiter could read out the entire card before handing it back to you, she would have a hard time duplicating it later. She would have to construct a physical object taking laser position as input and producing specific light patterns as output. While hooking up a credit card shaped I/O device to a laptop with the 125GB database would be possible, chances are somebody would notice a suspicious person plugging their laptop into an ATM. Also, considering that the laptop would have to sift through 125GB of data before it could tell the I/O device to output a certain light pattern, whereas the true card would produce the "right answer" at the speed of light, a timeout function on the card reader would be effective in preventing this kind of attack.
Slashdot Mirror
This is getting to be a real annoyance. I don't want to have to download (7x650) 4.550 GB of data just to try out the latest linux distro. Some people aren't even able because they're either on a modem or have capped broadband. Personally, I'd like to see all distros cut down to three:
1 CD to install the OS. This would be the only cd necessary to install the operating system. With just this one cd, the user would be able to install their chosen distro of GNU/Linux and get a graphical desktop with some very basic apps (I'm picturing basically everything on the accessories menu on windows).
Up to 2 cds of apps - an office suite, dev tools, games, whatever. After using the single OS install disc, the user would then be able to pop an apps cd into the system and choose what they want.
No source cds. I'm not saying that distro makers shouldn't provide source code to the binaries that they distribute (they should!) and I'm certainly not saying that source is useless (it's not!). I'm just saying that making ISOs of source packages available for download is a great way to waste bandwidth for users and mirror sites that don't bother to mark them as non-essential to the process of 'getting something working'. Windows doesn't have a loop device to check out isos before they're burned, so newbies from windows can't help but be confused. (Yes, I know about Daemon Tools. Does everyone else?)
It would eliminate bloated 2GB default installs and cd swapping. Sure, there wouldn't be a (start|hat|k|foot|swirl) menu that takes up 10MB of space on disk just for the items it contains, but that's probably a good thing.
I'm not bashing suse or RH or any of the other GNU/Linux distros. I'm just saying that the default install/CD bloat is way out of hand and this would be an easy way to solve it. The way I see it, it's a no-brainer like replacing "scary" printk's during kernel startup with a booting progress bar (by default).
It seems like it might be. It's (relatively) cheap, handheld, uses flash for storage, has usb ports, and runs linux.
Those aren't instructions. Learn braille! It says:
Warning: You are currently standing in front of a drive-up atm. Please move out of the way before you are run over by a careless driver intent on withdrawing $20.00.
Imagine if your video board and sound board or their integrated chipset equivalents used encrypted data formats instead of unencrypted - it wouldn't matter that you put a logic probe in the line, because you couldn't read the bits. It wouldn't even require much extra CPU - the RC4 encryption algorithm is strong enough, fast enough, and uses very little memory. Key exchange is requires some CPU, but it would be pretty simple to build a public-private keypair into the adapter, where the public key is retrievable by the CPU but the private key is only accessible to the adapter, and require a setup message (either at boot time, or perhaps on a per-application basis) that creates a session key, pk-encrypts it, and hands it to the adapter.
I think this is the eventual plan, but as far as I know it's not implemented yet, nor is it in the works. However, I remember reading in an article about HDTV that the DVI interface currently supports almost exactly this scheme. Scary, no?
But the TCPA / Palladium / Fritz Hollings view of DRM basically requires the system to give root access to any program that wants to use the security, and that's blazingly unsafe. It's not clear to me that you can get away with much less than that and still get real application security, but the stuff's obviously Not Ready For Prime Time even on a requirements basis, much less a design or implementation basis.
I actually took the time to start reading through the "general" and "PC-specific" TCPA specs and, while it's certainly a bad idea, it doesn't require as much of a security sacrifice as you suggest. Individual applications that need to make use of "security functions" have two resources at their disposal.
The first is a crypto coprocessor soldered onto the motherboard. If that crypto chip is satisfied with the state of the system (signed OS, signed drivers, encrypted display connection) then it releases certain private and public keys to signed applications on request. In order to be signed, executable code (in the OS, drivers, or software package) must not at any time disclose those keys to other applications, store them unencrypted on disk, or do anything else that could lead to exposure of those keys to an untrusted entity.
The second resource all programs have access to is the a small program running in what I guess could be called "ring -1" (in palladium it's called "the nub"). By making requests to this program, an application can allocate "secure" memory for itself that neither the OS nor any other program can access. This could be used to store unencrypted uncompressed video frames, for example, before they are sent to the video card.
In other words, individual programs that make use of TCPA "security" functions don't gain root access to the system - they access a limited TCPA API to perform a few functions that execute at a privilege level above that of the OS. The TCPA effectively eliminates the rights of the end user, but it does so in a tidy way.
I believe you're referring to my post that contains video overlay. I'm aware that video overlays can be captured quite easily with the right software or when video acceleration is turned off - I was using WMP as an example to show that 'printscreen' by itself isn't a magic answer to everything. Most slashdotters (in my opinion) are aware that if something can be seen it can be copied. However, too many (again in my opinion) believe that if it can be seen, it can be copied easily (i.e. with printscreen). I see this fallacy as dangerous as it encourages people to feel secure in the false belief that DRM cannot be implemented in a way that interferes with their lives and is not worth worrying about.
:)
Thank you for your comment, though. I did neglect to mention in my original post that directshow overlay can easily be defeated...I hope nobody got the wrong impression.
The author hit the nail on the head - copy protection is impossible. However, the example he used (capturing data with the printscreen key) is a weak illustration of this fact, especially considering the recent speculation about palladium. For example, think about clips played using video overlay in windows media player. Pressing print screen while playing one would yield an off-black rectangle where you would expect a video frame to be. The real reason copy protection is not possible is a little more complicated than "print screen".
I think it's pretty well understood that now, in the pre-palladium/TCPA universe, copy prevention is impossible. If you can read a CD, you can copy it. Perhaps your specific cd burner's firmware isn't robust enough to write specific "strange" bit patterns, but bit-for-bit cd-duplicating machines cannot be fooled. If you can watch a movie contained in a file, you can send it to a friend. Even if that file is encrypted, the player program must decrypt it in order to play it and that decrypted data can be grabbed and written to disk.
At first glance, it seems like palladium will put a stop to this with its careful use of encryption and digital signatures. This is not true. Information physics didn't just fly out the window. All that Palladium accomplishes in connection with modified PC hardware is a separation of user and computer into two entities. Currently, users have complete control over their systems. Any OS can be run and no information is hidden from it by the hardware. The system, all by itself, is incapable of protecting its own private keys from the user. It is incapable of preventing the user from assuming its identity. A palladium OS running on TCPA-compliant PC hardware changes this. A TPM, or Trusted Platform Module, charged with the responsibility of certifying that a DRM-aware OS is running on the hardware is included on the motherboard and has its own sets of private and public keys. The critical difference between a TCPA-compliant computer and a PC of today is that the TCPA PC has its own "identity" separate from its user as defined by its ability to keep its keys confidental and process information using them.
It is well known that the only way to be sure a secret is kept is to make sure that all entities who know that secret agree to keep it a secret. If even one entity "in the know" decides to divulge it to an outside party, that information can no longer be controlled. Palladium/TCPA tries to implement copy protection by ensuring that the only entities that get access to that information agree to keep it a secret - namely the TPMs. In other words, if you were to enter your credit card information into a web site in order do download a palladium-protected movie, you didn't purchase the video for yourself. As it would be transmitted as data encrypted using the TPM's public key, you actually be purchasing the video for another entity, your TPM. The idea is that TPMs will obtain various metrics of the system on boot (is the OS signed or unsigned? the drivers? etc...) and only perform cryptographic operations at the request of the system if everything checks out. In addition, a special "trusted" cpu mode that has the same kind of power over kernel mode that kernel mode has over user mode (an inexact description but good analogy) is used to provide for allocating memeory that is only readable by a trusted application through calls to the program running in trusted mode. That's Palladium/TCPA in a nutshell. The reason that everyone seems to be so upset about it is that, in a bug-free environment, there are no software attacks on the system. The are many hardware attacks, such as special memory that can be used by the system and read by another device, soldering capture devices into output cards, or physically opening the TPM and extracting its cryptographics keys. The list goes on. Also, as information only has to be liberated from the "circle of friends", including all TPMs in all computers and the ??AA, once a single hardware mod would create an unpluggable leak through which an infinite amount of infomation could flow.
Critical and unrepairable holes in Palladium have been found before it has been deployed.
This brings me to the reason I'm writing this post: slashdot is permeated with ignorant fear. People believe that their ability to get copies of music, movies, and software without paying a cent is going to be in jeopardy. While this creates a great deal of support for anti-palladium initiatives (which is good), ignorant advocates can seriously hurt the fight for sensible treatment of information and universal recognition of the truth of information physics by providing passionate but incorrect and empty arguments against palladium and the TCPA (which is bad). So, if you'll still be able to get free entertainment in a palladium world (albeit with much more difficulty and a soldering gun), why is palladium bad? A number of very serious reasons:
Palladium will work reasonably well as attacks, though possible, are difficult. Over time, the majority of computer users would be convinced to believe the dangerous fallacy that copy protection is possible with the support of sufficient laws and technology. This belief (whether fostered by ignorance or campaign contributions) in our elected representatives what spawned the DMCA. In other words, your freedoms are in jeopardy as well as your friday night movie-and-popcorn party.
Palladium claims that it is capable of protecting your personal information - your name, address, credit card number, etc... - and puts you in a position of total control over how that information is used. Users that are bamboozled by the tantalizing promise of "trusted computing" will place their important personal information into the care of an unreliable system under the control of an entity that has profit rather than the users' best interests at heart. That is, they will forego the only true way to make sure personal information is kept confidential - not giving it to the computer. This may become incredibly difficult when the latest version of windows kindly demands it during the install process to activate the user's initial one-year license term.
In order to work, palladium-enabled service providers must be able to verify whether or not the cryptographically signed message coming from the client computer saying "This computer is running DRM-aware software," was signed by a TPM which is reporting accurate system metrics. In order to make sure those messages are unspoofable (by emulating the TPM in software) a central registry of all TPMs and their individual public keys must be maintained and made accessible. In other words, all palladium computers will have unique indelible ID tags and will report them over the internet to whoever asks. I don't have to explain to slashdot the privacy implications of this kind of system.
Hopefully I've managed to replace some ignorant fear with some informed fear. If you're not a member of the EFF, ask yourself why. Right now.
In line with what they other posts said, non-blocking I/O can be accomplished by letting the DMA controller take over transfers while the CPU does other things. However, I think the advantage that SCSI has over IDE that you're thinking of is that SCSI can have multiple outstanding transactions on a bus at once while IDE cannot. In other words, you can send a read request to one SCSI disk and, while it's being processed, send out another one to another SCSI disk on the same bus. With IDE, you have to wait to send a request to a new device on a channel until the last one finishes.
I'm not 100% sure about this, so if you need to make decisions based on this information I suggest you do some research elsewhere. You might want to check out the online pc guide.
How does the gnutella client start to build a host cache without connecting to a well-known source? Or rather, how does it connect to this source without making it possible for the ISP to MITM.
Some clients connect to a server operated by the client maintainer the first time they're installed. Others use a web-based host caching mechanism to get started. Some have regularly updated host cache files that come with the software. Once a client gets connected for the first time, it sends out a ping packet over gnet (not ICMP ping, gnet ping). Any hosts that need more entries in their host caches respond to the ping with a pong packet containing their IP address and listening port. From that point on, the host has (or can get) as many other ip:port pairs as it wants.
Anyway, I'd love an URL or two with more information about the future direction of gnutella.
Sadly, there's not a great deal of direction in terms of the future of the gnutella network; however, there are a couple of sites worth visiting. The Gnucleus home page has a forum component that's usually pretty lively. It's not exactly developers only, though, so expect to see a lot of posts from people who have "Great Ideas!" about what the developer should do next but don't know anything about programming or gnet. There's also the RFC-Gnutella project on sourceforge that aims to (obviously) produce an RFC on the gnutella protocol, or at least get it standardized to the point where all developers can agree on how servents should pass around data.
According to the Berman bill: [politechbot.com]
:)
;)
;)
;-D
:)
:) Maintaining network responsiveness is a high priority; however, it shouldn't be done by throttling the collective p2p bandwith usage for an entire campus to 64kbps. (Yes, I did read the link in the latest story and I know UCI is throtling to 10mbps. I'm thinking of a different campus.) Making p2p traffic undifferentiable from other traffic to automated throttling programs is one way to "persuading" ISPs and UCs to rethink their packet shaping device configurations and perhaps offer to simply de-prioritize p2p traffic rather than throttle it outright, in exchange for the use of servents that have identifiable traffic which can then be de-prioritized by automated methods.
"... a copyright owner shall not be liable in any criminal or civil action for disabling, interfering with, blocking, diverting, or otherwise impairing the unauthorized distribution, display, performance, or reproduction of his or her copyrighted work on a publicly accessible peer-to-peer file trading network, if such impairment does not, without authorization, alter, delete, or otherwise impair the integrity of any computer file or data residing on the computer of a file trader."
It's a get out of jail free card for tampering with the network for stopping copyright infringement, but it does not cover tampering with files on your computer.
Oops, I goofed. I fell for the slash-hype and REposted it without REsearching. Thanks for pointing this out!
It a user downloads the entire file from them,
the client program, upon completion of the download, will report an error since the hash that the file should have does not match the hash of the downloaded data. Not too serious - just some wasted
downstream bandwidth on the part of the user. This kind of attack also costs the ??AA mega$ as they are the only source for the file:
Simple chaffent:
Collect a list of (filename, filesize, hash) we want to fake.
Reply when someone is searching (both name search and hash search).
Allow connect from clients and start serving bogus data.
Disconnect the transmition after a little while.
Add the client IP to a ~30min blacklist (maybe shared by all chaffents).
Don't answer any reconnect requests from that IP as long as it is on the blacklist.
For the user, this should look just like someone that was online for a while and then disconnected. The user will try to resume the download from other sources, but the file is already broken.
If the servent can't download from the ??AA junk server, the user will eventually become impatient with the download and try another source. Tiger-tree hashing (which I described lower down) provides the means for servents to intelligently and automatically cull garbage data from the download. When all of the data has been downloaded (the 30 minutes of garbage data + the rest of the legit file) and 5% of the file doesn't fit with the other 95%, the servent can just re-download that 5% from random servers until it gets one that fits. The only attack on this would be for the ??AA to feed data to the client faster than the rest of the p2p network, eventually filling 51% of the file with garbage. The servent would then fruitlessly seek the other 49% of the garbage file (the real data being the suspect minority) and would not complete the download. However, in order for the ??AA to execute this attack, they would have to serve up 51% of the bits on p2p networks - in other words, out-bandwidth the rest of the p2p community.
In other words, the ??AA won't be able to corrupt your downloads
unless they out-bandwidth the rest of the p2p community.
Or rather - out-search-request-answer if done as above.
See above, although yes, query hit flooding is also a problem.
The problem, essentially, is that you don't know if the metadata reported about the file (title, resolution, length, etc...) is accurate.
[snip explanation]
Sounds like a good approach for ensuring metadata integrity.
Anyway, I get this image of FBI busting someone and discovering the private key of a notorius release group on his computer. This could actually make it easier to track down the really big copyright infringers.
Well, it could make it easier to _prosecute_ copyright infringers, except that private keys are encrypted using a symmetric cypher and a passphrase in the secret keyring . The longer, the better - long enough to stop FBI crackers and long enough to forget during questioning.
Considering that P2P traffic is something like 80% of the total Internet traffic at the moment, ISPs wanting to do bandwidth throttling is not exactly surprising.
In many situations you actually want to do bandwidth shaping in order to keep the network running smoothly. You don't want your P2P traffic to hog so much bandwith that the responsiveness of your interactive SSH sessions go south.
I heartily agree.
If all communications on p2p networks started with a raw exchange of public keys, the first (for example) 2048 bits of p2p connections would be different from client to client.
Smells like overkill to me, but anyway.
This kind of extreme undetectability might be necessary in some cases. Very few protocols other than the one I describe (in my limited estimation) have the first 2048 bits set to the same value for every outbound connection. A static per-client public key could be a dead giveaway for traffic shapers.
Ports used for (at least gnutella) p2p are already random, btw.
At least the initial connect is to a well-known port, no?
No. Initial connects and file transfers now use random ports on the gnutella network as long as the user is running a client that supports it. Gnucleus, for example, does. (Yay open source!)
If your ISP really wants to spend a lot of time and resources to track you, they could play man-in-the-middle from the initial connect with the gnutella network. Not that it would ever be worth the effort, but anyway.
Read the very last paragraph I wrote in my original post. ISPs couldn't reliably execute MITM attacks without borking all non-p2p traffic. ISPs couldn't execute MITM attacks at all without borking a significant amount of non-p2p traffic.
Now what do I do?
Well, at least in my opinion, the first thing you should do is recognise that UCI is doing the second best thing they could possibly do in this situation. The only better option would be to give p2p third priority after web traffic (first) and general traffic (second) but not restrict it to a max of 10mbps (out of 60) no matter what else is going on. Congratulate them for being honest and openly allowing p2p to boot.
What can you do?
Well, from a networking point of view, not much. The UC controls your connection and can throttle it as much as they want. Currently, your system sorts traffic into three categories:
Favored (packets get priority): HTTP for web access
Neutral (packes are routed as usual): General traffic, e.g. games, ftp, telnet, etc...
Unfavored (packets are throttled regardless of available bandwidth): p2p
If your goal is to speed up file transfers, your only easy and immediate option is to start trading ftp logins with others, as ftp traffic falls into the second (mostly unrestricted) category, or use some other File Transfer Protocol. There is another solution to the throttling/snooping problem that would prevent ISPs and universities from being able to single out p2p traffic, but it would require reworking the protocol used by the p2p network of your choice. As it happens, I just posted more info on this exact topic earlier today in another story. You may find some of it informative if you're interested in the future/development of p2p.
What should you do?
Well, it's obvious that UCI cares more about bandwidth than legal threats from the abusive and overbearing ??AA. Try starting up a LAN-only file sharing network. You won't be subject to any throtling, the speeds will be _much_ better than downloading off of some ADSL user with 128kbps of upstream bandwidth, and there's a p2p client that's already written and available for download that meets your exact needs. It's also stable, fast, spy/ad/crapware-free, and GPL'd to boot. In case you're struck with a craving to learn more, you can find the program author's site here.
Happy trading.
The confusing thing is that I'm hard pressed to think about any
;)
attacks on P2P networks that:
1) Is not already legal today (For example, filling the network with
bogus Britney mp3s), or
2) Impacts only illegal sharing of copyrighted material instead of
killing the whole - or parts of the P2P network itself.
The purpose of the bill is to create a safe harbour for 'content
owners' that use technology to impair the sharing of copyrighted
content on P2P networks.
Given this, I think it is arguable that an effective way to stop the
sharing of copyrighted content on p2p networks without imparing
sharing of uncopyrighted works (or copyrighted by those who do not
restrict the distribution of their works) is to delete the files
containing copyrighted works from computers participating in the p2p
network. Since the Berman bill gives them a (somewhat) blank check to
break "hacking" laws in pursuit of this goal as long as they notify
the gov't first, I think they will end up doing exactly that.
However, I really should have been more specific in my first post. I
should have said:
Media companies have legal permission to crack into your computer and
delete files that contain copyrighted content as long as they
tell the gov't about it first.
-------------
What if the RIAAntiKazaa chaffing servent simply lies about the
hash. You can't check that the hash is correct before you have
downloaded the file anyway. Besides, with segmented downloading you
only need to download one segment of a file from the chaff servent to
destroy the file.
If you do SHA (or similar secure hashes) on segments of the file, it
would be possible to discard only the bad segments instead of the
whole file.
My knowledge of what's going on in p2p is limited to the gnutella
network, but here's what's happening right now:
Files are can be searched for by their SHA1 hashes and almost all
major servents support this. Currently, the only thing that the ??AA
could do to inhibit downloading (beyond what I noted in my first post
re: bad files & user laziness) would be to find out the hash of a
good file, and report that they have the file whenever they receive a
search request for it. It a user downloads the entire file from them,
the client program, upon completion of the download, will report an
error since the hash that the file should have does not match the
hash of the downloaded data. Not too serious - just some wasted
downstream bandwidth on the part of the user. This kind of attack
also costs the ??AA mega$ as they are the only source for the file:
non-SHA1-aware clients won't be able to propagate the false hash
reporting and SHA1-aware clients will dump the file as soon as it's
done downloading. In other words, the only thing the ??AA has going
for them right now is user laziness.
Here's what's going to happen in the near future:
The ??AA isn't faking hashes because they (probably) followed the
same line of reasoning. However, faking hashes can cause other
problems. Since SHA1 hashes hash all the data in the file to produce
the output hash, even a small chunk of changed data in the file will
affect whether or not the downloading servent thinks the download is
"good". If the RIAA were to report that they had the "good" file
corresponding to the "good" hash, but send "bad" data when the "good"
file is requested, they could wreak havoc on servents that support
multisource downloading. If a servent downloads even one byte from
one of the ??AA's destructive interloper nodes, trying to download
the file a bit faster by downloading from another source, the SHA1
hash calculated after the download finishes would be incorrect,
killing an otherwise successful download as you mentioned above.
As luck would have it, P2P developers have been trying to enable
partial file sharing (sharing available [downloaded] parts of
unfinished downloads) for quite some time. It turns out that
implementing this technology will render the above attack useless.
Soon, servents will support "bitprint" hashes. A bitprint hash is a
concatenation of the SHA1 hash of a file, and a hash obtained by
using the tiger-tree method. The tiger tree method:
1. Break the file up into equal size chunks. (say, 1MB)
2. Hash each chunk.
3. Concatenate adjacent chunks to make new chunks.
4. Go to step 2.
All of these hashes, done using the Tiger algorithm, form a tree
where each node has two leaves - hence Tiger-Tree. The original idea
was that servents could use this tree of hashes to ensure data
integrity when downloading pieces of a file from multiple hosts.
Since ??AA-trashed data will not hash to what it should, just like
corrupted data, those blocks will be thrown out and re-downloaded
until a good block is obtained from a non-??AA host.
In other words, the ??AA won't be able to corrupt your downloads
unless they out-bandwidth the rest of the p2p community.
There are still two (technical) issues threatening p2p and oddly
enough I think they can both be solved by strong public key
cryptography. The first is fake files - that is files containing
garbage data from the ??AA and misnamed files. The problem,
essentially, is that you don't know if the metadata reported about
the file (title, resolution, length, etc...) is accurate. However,
one of the things I've noticed about online file trading is that
files that appear there, especially movies, are tagged with short
prefixes identifying the ripping/encoding team. "[smr]", for
instance, stands for "shadow movie realm". While rips of apps and
games don't generally have these filename tags, they are generally
distributed as archives containing, along with the program, an info
file of some sort crediting the crackers. The common thread is that
most content is introduced into the network by a small number of
dedicated, talented "teams" that want credit for their work. To me,
this seems like a perfect application of digital signatures. If, upon
release of new content, the block of metadata describing that content
(title, resolution, length, etc, and bitprint hash) were
signed by the release team, then downloaders with the release team's
public key could verify which rips are genuinely what they say they
are, or more to the point, which hashes point to good files. Is it
vulnerable to other people posing as the release team and signing
data with their own keys? Sure, but over time one public key would
develop more "cred" than all of the spoofs and since the release
teams would only sign their own releases, that "best key" would be
accepted as theirs. The best thing is, this whole process can be
automated. Servents can even keep track of key validity (cred) by
themselves simply by asking the user "Is this signed file what it
says it is?" upon completion of a download.
The second issue is eavesdropping and bandwidth throttling by ISPs
(especially universities). This problem can easily be solved by
recognising that an ISP can only safely throttle what it can
identify. If all communications on p2p networks started with a raw
exchange of public keys, the first (for example) 2048 bits of p2p
connections would be different from client to client. For extreme
undetectability, servents could generate new public/private key pairs
for each new connection. All following bits would be encrypted and
unavailable to the ISP. It would seem that this technique would be
vulnerable to a man in the middle attack by the ISP; however,
consider what it would take to execute that kind of attack. The ISP
would have to modify the first (again, for example) 2048 bits of a
connection that it knows nothing about because it just initialized.
While this would gain them access to the unencrypted data stream of a
p2p connection, it would horribly confuse any other software trying
to communicate over the internet. In other words, they can only check
for p2p communications by killing all non-p2p communications. Ports
used for (at least gnutella) p2p are already random, btw.
Anyway, those are my thoughts.
Most slashbots are too lazy to write (as in with a pen, paper, a hand, and an informed mind, not as in forward email with a computer) their congresscritters let alone hit refresh in a browser once every minute for...how long? In any case, I think DDoSing wouldn't even be all that effective in promoting social change which is what we really need. What I find interesting is that they've already spelled out that the CTO must come up with a plan to engage in P2P warfare. I mean, I realize that job descriptions are all about...well...describing jobs, but it seems like they're saying, "You have complete freedom....to find a way to do what we've already decided is the best thing to do even though that's a decision the CTO should make." Isn't it the Chief Technology Officer's responsibility to say things like, "Hmm, maybe our company's current position with respect to technology, that is using the public's ignorance against them to push oppressive DRM into all digital devices, isn't working. Why don't we evaluate some other plans?" Again, I realize that they probably don't want someone who would make that statement as their CTO, but it still seems odd.
------------
Also:
Slightly OT, but there are actually two things going on here:
1. Media companies have legal permission to crack into your computer and delete files as long as they tell the gov't about it first. This doesn't give them the legal right to distribute fake files, but that activity wasn't illegal in the first place as cracking into someone else's computer and deleting their files was. I don't know if they've actually done this yet.
2. They distribute fake files on p2p networks with names that suggest they're not fake. The idea is that the fakes are released before real content, fakes spread all over the network, and real content gets hard to find because nobody bothers to delete their downloads that turn out to be fakes.
They can't fake the _hashes_ on files. If they have a rogue p2p client online, they can respond to searhes for a certain hash and try to get clients to download from them, but when legitimate p2p clients see that the bytes coming from the rogue client don't hash to what they're supposed to, those bytes won't be included in the file. The only way they could "fake the hash" is by finding another file that has exactly the same length and hash as the original file but contains different data. I don't know what fastrack/winmx/others use, but gnutella uses SHA1 hashes (or bitprint hashes which incorporate SHA1) which are designed to resist that kind of attack. In other words, if you have file (A), it is easy to find its hash (B), but it is near impossible to find another file (C) with the same hash (B) as the first file (A). Of course, as long as p2p users remain lazy and ignorant and p2p software developers don't develop features that prompt the user to identify and delete bad files, media companies won't have to fake the hash in order to frustrate users.
This is really cool. If Apple added ogg support to their iPod I would chuck my very old 32MB flash mp3 player and buy one of these in an instant. However, this kind of notice, "First program to do task X under linux!" kinda frightens me. I mean, it's good that it's being done and I'm sure a lot of people would get a lot of use out of it, but what happens when the second program comes out, and the third?
;) ). It may be an app that uses qt widgets and integrates really well with konqueror. I can see KPod coming now. It may be one based on gtk2 that snuggles up next to nautilus. That would be GPod. Let's say that there are two backends: backend1 and backend2. Let's further say that the designers of the textual and gtk2 frontends decided to build on backend1 because that's the one that they could get to work on their home boxes. The KDE designer is using backend2 because it's easier to write on top of.
In an open market where physical goods are being sold, competition is good and improves consumer choice.
Don't like product A? Try substitute product B.
Think B is too expensive? Try product C.
And so on...
Same thing to a lesser extent with commercial software, except there might not be two packages that do *exactly* the same thing but could still be substituted for eachother. Example: Dreamweaver and GoLive. Both are site design tools, but they don't have exactly the same function sets. (PLEASE no flames to the effect of "How DARE you compare Dreamweaver and GoLive?! ABC is OBVIOUSLY superior to XYZ! They're not even in the same class of products!" It's just an example.)
However, with open source software, <sweeping generalization>multiple "substitute" goods can hurt choice and the end user's experience.</sweeping generalization> Why? Well, many times, like this one, a piece of OSS doesn't perform a complete function that the average user can take advantage of. A backend is great, but unless you love the command line to death and can't get enough of long technical manuals, readmes, and errata, and don't really care if it takes you an hour or mode just to get started, you're going to want a frontend. It may be a textual one with a nice menu system. Undoubtedly someone will produce one of those (not everyone likes mice
At first glance it seems like the user has a lot of choice - two backends and three frontends are available to let him access his iPod under linux. Except he's a KDE user and he can't get backend2 to work. Or he's got his GNOME desktop all set up the way he likes it but the only way he can get the feature he needs from backend1 (which he has to use because there's no GNOME frontend for backend2) is by using the latest alpha build of backend1 which tends to crash when doing large file transfers. He could try using the console frontend or reading up on the backend, but the last time he tried that he borked his iPod when he tried to convert its built-in HFS+ partition to FAT32. The "simple" task of getting his linux box to talk to his iPod is turning into a headache. "Hmm," he thinks, "I heard Windows DRM 2005 has a nice iPod app that just works...maybe I should try that out."
Ok, ok, I'm aware that this is an obviously constructed scenario, but I think it illustrates my point. Wouldn't we be better off with ONE backend that WORKS rather than two that are lacking? Just like closed source software development has its strengths and weaknesses, so does open source. I've just described one of the weaknesses - the tendency to have multiple projects that try to do the same thing and end up splintering the user base. Take advantage of the corresponding strength of OSS: that you can work together on a SINGLE project with another developer even if she's halfway around the world (as long as you speak the same [programming] language). Please, developers, please - if you despise the way a particular backend works, don't just start your own. Unless the first one goes away, you'll only end up hurting users. Find out if there's a way you can contribute to the backend - fix the bug that's really bothering you or add the feature you desperately need to a project that's already started. Work together with other developers - it's better for everyone involved.
elastic clause
As I see it, the question that's being asked is: "Does the retroactive extension of copyright promote the progress of science and useful arts?" I think the obvious answer to that question is no - there's no sense in securing income for dead people, but the copyright clause in the constitution just says what congress can do, not what they have to do or even are fobidden to doing the opposite of. From this perspective, it doesn't seem like it's very likely that Eldred v. Ashcroft will turn out well for consumers.
But there's another way to look at it. Congress is not specifically bound not to inhibit the progress of science and useful arts; however, if congress passes legislation repealing a law that inhibits the progress of science and useful arts, they are promoting the progress of science and useful arts. Isn't congress inhibiting the progress of science and useful arts when they extend the term of copyright to 70 years beyond the death of the original work's creator? If a company can sit around and get fat on old copyrights then they have a greatly reduced incentive to produce anything new. Wouldn't congress be promoting the progress of science and useful arts if they were to repeal the CTEA?
You're thinking of the Voodoo Graphics and Voodoo 2 from 3Dfx, and you're correct - they were replaced by more popular all-in-one cards such as the voodoo 3. However, the reason that all-in-one cards were preferable at that time was that the connectors between the 2d and 3d cards were analogue. Everyone using a VG or V2 had to run a short vga cable out of their 2d card and into their 3d card. Their monitor then plugged into the 3d card, which operated as a pass-through device when not in use. Needless to say, this kind of setup wasn't the best for signal quality. Also, since it was outside the case, it was prone to being kicked or knocked out of place during an energetic gaming session.
Making the interface digital, placing it inside the case, and supporting resolutions that the inevitable hardware-game performance leapfrogging will never let us approach would, in my non-hardware-developer opinion, be enough to solve those old problems and make that kind of setup popular.
On a side note, the all-in-one card that directly followed the pass-through cards in 3Dfx's line-up, the Voodoo Banshee, developed an absolutely awful reputation for performance and stability. It was so bad, in fact, that its successor which should have been called the Banshee II as it was, essentially, a bug and performance fix on the original, was renamed and marketed to great success as the Voodoo 3.
Beowulf, a fictional Scandanavian warrior from the sixth century, is the subject of the oldest known english epic poem. Read it here . Naturally (?), geeks working on clustering computers together to combine their number crunching power decided to name their work after it. I think this may have to do with Beowulf having the combined strength of 50 men.
I don't understand how you could have trouble figuring this out. The FIRST link that came up when I did a search for Beowulf on google explaned what beowulf means in a clustering context. Elsewhere on the FIRST page there was a link to the translation I linked above. Learn to use google.
That would certainly be acceptable. However, I would tend to think that the cost of making those components modular would mostly negate the benefits of not having to buy a new pcb every time you upgrade. Personally, I'm all for separation of function into three separate devices (output, input, and rendering).
1. A 2D display card with DVI/VGA and TV output. Possibly multiple sets of outputs depending on how "fancy" you want the card to be and how much you're willing to spend.
2. A video input card with coax, firewire, DVI, RCA, etc... input connectors.
3. A card designed solely for 3D rending with a GPU, fast ram, and, most importantly, a standard digital interface to the RAMDAC on the 2D card.
That would allow for the optimum modularity and consumer benefit. Need support for a new kind of output device, or more output devices? Buy a new output card. Want real-time hardware support for a new video compression codec? Buy a new video input card. Want to play the lastest game at reasonable frame-rates? Buy a new 3D card. There wouldn't be any worries about forward compatibility as the video input component isn't really an integral part of the system - it's just been bundled with video cards in recent years. There's the interface between the 2D card's frame buffer and the 3D card's output, but all you need is a one-time digital interface capable of supporting, say, 2048x1536 at 32bpp. Most gamers would be willing to accept that graphics card technology will never be far enough ahead of game software to play at resolutions/bit depths greater than 2048x1536x32 at any kind of reasonable frame-rate (unless of coures you're playing GLQuake on your "GeForce 5 Palladium 400"). Given that, the bandwidth of the bus can stay constant while the memory bandwidth and core clocks on successive models of 3D cards could grow.
I'm sure that graphics card manufacturers want to provide us with as few upgrade options as possible for the simple reason that it would mean more money for them. However, I don't think memory slots on cards would be all that useful. Usually, the bottleneck that triggers an upgrade for most consumers is a killer app that pushes more polygons and requires a faster GPU with more rendering pipelines and faster graphics memory. More sticks of DDR SGRAM isn't going to do you any good there.
What is wrong if they are to offer 256Kb/128Kb DSL or Cable for like $15/month for those who doesn't need huge broadband for Pr0n downloads and online gaming?
I'd totally agree with you - most people don't need the speed that broadband provides today, except I'd also argue that unless you're sending and receiving large volumes of data (music, movies, etc...), 256/128 would do just fine for about everything, including online gaming and porn. Only the greediest online games (network-wise) even begin to touch data rates of 16KB/s (128kbps). Sure, you can configure them to use more than that, but the difference between 32KB/s and 16KB/s dedicated to a game is incredibly small compared to the difference between 5KB/s (a modem) and 16KB/s (limited DSL/cable). Also, packet latency is a much greater contributing factor to a positive gaming experience than data rate. Considering that low pings cost _nothing_ to provide as they are mostly a result of the technology bridging the last mile and not the ISPs backbone connection which, for most providers, are very very very low latency. Besides, I find (and I think most people would agree with me) that the most useful part of "broadband" is that it's always on (yeah yeah, I know, only when your computer is) and it doesn't tie up your phone line or stop you from watching cable tv at the same time (depending on service type). I'm a "power user", and I'd be more than happy to "downgrade" to a 256/128 for $10-$15/month compared to the $50 I pay now for 2000/256 if I get to keep the always on and low latency parts.
Then who will administrate the software administrator?
I have to take the side of Clean Flicks on this one - there's no reason anyone should be restricted from buying bits, modifying them, and selling them. However, it makes me wonder why the directors even care. They can't be worried about their "vision being corrupted" as they don't complain about the TV versions of movies. The issue can't be money either - Clean Flicks buys a copy of the movie for every edited copy they sell. The directors, not to mention the MPAA, are making more money because the market for their products is broadened by Clean Flicks. I'm rather bewildered as to why they're so upset.
.ifo and .bup files on the DVD, the copyright gestapo wouldn't have a leg to stand on - Clean Flicks wouldn't be distributing copyrighted content, and they wouldn't have to buy a copy of the movie for every mod they sold. The directors and the MPAA would make just as much money as consumers would need to buy a copy of the original DVD for the mod roms to patch against.
This story makes me think about that DVDSynth article slashdot had a few days ago. While the software is currently for geeks only, it doesn't seem like all that much effort would be required to implement a similar capability in set-top DVD players. If Clean Flicks were to distribute "mod cards" containing rom chips with info to patch the
This kind of technology isn't really meant for home use - you'd have to buy a special reader device just to input your "number". Also, any transaction would probably only check a few places on the card and send that data (maybe a few KB). If they kept the entire contents of your card in a database, they would have to maintain 125GB of space on their servers per customer.
Of course, at some point, the decrypted data is visible internally to the computer.
Yup. True for any system. However, I don't think using them as individual keys on a per-media basis would fly. That would mean the data on the dvd would have to be encrypted individually with whatever key was attached to it, which means that stamping out large numbers of dvds from the same master would become impossible. Considering that it would be way too slow to burn dvds one by one at manufacturing plants, I don't think the media companies would go for it.
This story has a misleading title. Basically, the article says that they've found a cheap way to implement a hashing function in hardware. Unlike a software hashing function that takes data to be hashed as input and produces the hash as output, the physical mechanism accepts a certain pattern of lasers as input and produces a speckled light pattern that can be observed from any angle as output. Since the position of the glass beads in the epoxy will be different for all cards, each glass and epoxy smear will have a different hash function that can be used to tell them apart.
There's no encryption/decryption going on here, just hashing, but that is an important concept in the field of cryptography.
The main application of this is to replace magnetic stripes on credit cards. Currently, the machine-readable part of a credit card produces a small amount of static output (16 or so decimal digits) and is easy to copy with readily available equipment. By switching to these new chips, the number and complexity of possible outputs that the card can produce would be increased and the output-producing device would be more difficult to duplicate.
For example, right now your electronics-geek waiter could slip your credit card through her palm pilot with home-made magnetic reader attachment on her way back to the register. Later, she could take a used or invalid credit card, and write your magnetic pattern onto the bar. Credit card machines wouldn't be able to tell the difference between the original and the duplicate, so she effectively stole your credit card and you wouldn't know until the bill came.
If you were using a glass and epoxy chip, there would be several problems with duplicating this kind of attack.
1. The waiter would have to read 125 gigabytes (1Tb=1TB/8=~125GB) of data into her intermediate storage device in a few seconds. That's a lot of fast memory to pack into a small space. Copying only a few possible outputs wouldn't work, as only the credit card company would know exactly which (laser position, card output) data pairs it had on file for use in a challenge-response protocol.
2. Assuming the waiter could read out the entire card before handing it back to you, she would have a hard time duplicating it later. She would have to construct a physical object taking laser position as input and producing specific light patterns as output. While hooking up a credit card shaped I/O device to a laptop with the 125GB database would be possible, chances are somebody would notice a suspicious person plugging their laptop into an ATM. Also, considering that the laptop would have to sift through 125GB of data before it could tell the I/O device to output a certain light pattern, whereas the true card would produce the "right answer" at the speed of light, a timeout function on the card reader would be effective in preventing this kind of attack.