From bram at gawth.com Sun Feb 2 14:57:02 2003 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] p2p-hackers meeting next sunday, the 9th Message-ID: As per usual, this month's p2p-hackers meeting will be at 3pm on the second sunday of the month, the 9th, in the metreon, san francisco. This to talk about include the upcoming CodeCon and random stuff I've been working on. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From seth.johnson at RealMeasures.dyndns.org Sun Feb 2 21:14:02 2003 From: seth.johnson at RealMeasures.dyndns.org (Seth Johnson) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! Message-ID: <3E3DF862.195AEE15@RealMeasures.dyndns.org> New Yorkers for Fair Use Action Alert: -------------------------------------- Tell American Megatrends and Transmeta not to make chips that let others control your computer! Stop Palladium and TCPA Now! Okay, you folks understand this issue -- AMI and Transmeta recently announced their intention to build TCPA technology into their chips. It's time to tell them that building chips that let others control your computer, is unacceptable. 1) Please send your comments using the form provided below. Tell them not to produce their AMIBIOS8 and TM5800 chips, and that you will boycott any technology that enables TCPA and Palladium technology on your computer. Read the alert below for details. 3) Take up a role helping with this and other efforts related to information freedom in the future. Two roles you can take up are to become a Press Outreach Campaigner or a Commentator. Simply reply to this email to show your interest. 2) Please forward this alert to any other interested parties that you know of, who would understand and see the importance of this issue. New Yorkers for Fair Use Action Alert: -------------------------------------- Stop Palladium and TCPA now! Tell American Megatrends and Transmeta not to make chips that let others control your computer! Please use the following form to tell American Megatrends and Transmeta not to produce their AMIBIOS8 and TM5800 chips, and that you will boycott any technology that enables TCPA and Palladium technology on your computer: http://www.nyfairuse.org/cgi-bin/nyfu/palladium What's Going On: Last week, Intel, Microsoft, the RIAA and the MPAA announced their intention to force Palladium and TCPA into every personal computer on the planet. Palladium and TCPA are a different kind of DRM, worse than even the most invasive of previously proposed "content control" systems. Palladium and TCPA would hardwire your home computer so that these four entities and their partners would be able to run processes on your computer, entirely outside your control, indeed, without your knowledge. Below we answer some questions about DRM, Palladium, TCPA, and the boycott. New Yorkers for Fair Use What is DRM? DRM is the political, legal, contractual, economic, hardware, and software infrastructure designed and intended by a loose alliance of cartels and monopolies to take away your right to own and privately use a computer. No full DRM exists in the world today, though pieces of DRM have been successfully enacted into law and tiny bits of DRM hardware and software have been placed in some home movie playing and recording devices. Every single piece of DRM is meant to help attain the objective of the anti-ownership alliance: to get control of every personal computer in the world. Intel and Microsoft and RIAA and MPAA, by their own admission, have, to date, spent billions of dollars to force universal DRM on the entire world. Last week these four reiterated their intention to force DRM into every personal computer on the planet: http://www.nytimes.com/2003/01/15/business/15PIRA.html http://news.com.com/2100-1023-980671.html For more on DRM see: http://newsforge.com/newsforge/02/10/21/1449250.shtml?tid=19 http://www.panix.com/~jays/what.is.drm.3 What is Palladium? "Palladium" is Microsoft's name for its proposed DRM system. No implementation of Palladium exists today, indeed no complete specification of Palladium exists today, but certain hardware which a Palladiated operating system requires is about to be placed in all personal computers, unless we stop Microsoft and its hardware and vendor partners, such as Intel, American Megatrends, Transmeta, Dell, and CompUSA. What will Palladium do? Palladium will enable a few large corporations and governments to run source secret, indeed, well-encrypted, code on home users' machines in such a way that the home user cannot see, modify, or control the running code. A Palladiated system is under the complete control of Microsoft at all times. Microsoft might allow some of its partners to run code on your machine, but no code will run on a Palladiated system without Microsoft's consent. The mechanics are as follows: only code that has been signed with a special Microsoft provided key will run. Microsoft will retain at all times the power to revoke any other entity's keys. In particular, no operating system will be able to boot without a key from Microsoft. So if Palladium is forced into every home computer, there will be no more free software. Microsoft will be able to spy on each and every keystroke, and mouse movement, and send encrypted messages from your machine to Microsoft headquarters. Microsoft will also be able to examine every file on your system. Your encryption programs will not work against Microsoft, or any other entities which have full power keys from Microsoft. But surely wily crackers and freedom-loving hackers around the world will be able to defeat Palladium by breaking it? No. Whether or not a few hackers are able to get around some versions of Palladium, most people will not be able to. There are two reasons most people will not be able to escape the All Seeing Eye and Invisible Hand of Palladium. First, Palladium is not like the absurdly weak systems called "DRM" today. Palladium is both hardware and software, and the software is locked to the hardware in a manner completely different from today's weak DRM systems. The design of Palladium allows for defense in depth, and even one layer of Palladium is harder to crack than any DRM ever seen before. Second, under the Digital Millennium Copyright Act of the United States of America, it is illegal to try to see what Palladium is doing. It is also illegal to modify the hardware of a Palladiated system. And it is a felony to sell advice on how to disable Palladium or its supporting hardware. It is hard enough today to get vendors to sell computers with a free operating system already installed. Once Microsoft and Intel have forced Palladiated hardware into every personal computer, it will be impossible to run a free OS. The very act of booting a free OS will be outlawed by application of the DMCA to a Palladiated computer. But there are no Palladium systems available today. So how can you boycott Palladium? We are boycotting the hardware that Palladium needs. Before Palladium is rolled out, Palladium-enabling hardware must be placed in most of the world's personal computers. Right now such hardware is being placed in computers meant for home and business use without the buyer being told. Our boycott is aimed at stopping Palladium-enabling hardware from being secretly forced into every personal computer in world. We intend to stop Palladium before we cease to own the computers in our own houses and offices. The main Palladium-enabling hardware is called a "TPM" for Trusted Platform Module. The TPM hardware will support, in addition to Palladium, many different systems which take control of the computer away from the user and give control to large corporations and government entities. The TCPA, the Trusted Computing Platform Alliance, is the standards organization for the TPM. The founding Alliance members are Compaq, HP, IBM, Intel and Microsoft. Since 1999, the year TCPA was founded, about one hundred more companies have joined the TCPA. The Alliance has published a formal specification of the TPM. The TCPA's FAQ http://www.trustedcomputing.org/docs/Website_TCPA%20FAQ_0703021.pdf seeks to allay the natural suspicions of computer buyers about what the TPM does. Unfortunately the FAQ is inaccurate on the most important issues. For example, the claim is made that a computer with a working TPM will remain under the final, ultimate, and complete control of the user. But, as explained above, this is simply untrue. So what exactly are you doing? We refuse to buy any computer with a TPM inside and we ask you to refuse to buy any computer with a TPM inside. We use the term "TPM" to include TPM-like devices, whether in a separate chip, in the BIOS chip, or even in the cpu. This means that we ask buyers of personal computers to find out whether the computer has a TPM or a TPM-like device inside. We will shortly provide buyers of home computers with methods for telling whether or not a computer has a TPM inside. Is it possible to be more specific today? Yes. We call for a boycott of the just announced American Megatrends AMIBIOS8: http://www.ami.com/ami/showpress.cfm?PrID=118 http://www.ami.com/products/product.cfm?ProdID=127&CatID=6&SubID=14 http://interviews.slashdot.org/article.pl?sid=03/01/09/166251&tid=99 http://interviews.slashdot.org/article.pl?sid=03/01/17/1430214&mode=thread&tid=137 and the just announced Transmeta TM5800 cpu: http://siliconvalley.internet.com/news/article.php/1569201 http://slashdot.org/article.pl?sid=03/01/14/1719220&mode=thread&tid=161 Where can I find out more about Palladium, TCPA, and DMCA? For Palladium see: http://www.cl.cam.ac.uk/%7Erja14/tcpa-faq.html http://wintermute.homelinux.org/miscelanea/TCPA%20Security.txt http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0301b&L=wmtalk&T=0&O=A&P=12347 http://www.theregus.com/content/4/25378.html http://www.counterpane.com/crypto-gram-0208.html#1 http://www.ofb.biz/modules.php?name=News&file=article&sid=152 For TCPA and the TPM see: http://www.trustedcomputing.org For the DMCA see: http://www.nyfairuse.org/analysis/dmca.must.be.repealed.xhtml http://anti-dmca.org http://www.nyfairuse.org/dmca.xhtml How do I tell these folks I don't want DRM? Just click on the URL below: http://www.nyfairuse.org/cgi-bin/nyfu/palladium From lists.p2phackers at imperialviolet.org Mon Feb 3 07:39:02 2003 From: lists.p2phackers at imperialviolet.org (Adam Langley) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: <3E3DF862.195AEE15@RealMeasures.dyndns.org>; from seth.johnson@RealMeasures.dyndns.org on Mon, Feb 03, 2003 at 12:04:34AM -0500 References: <3E3DF862.195AEE15@RealMeasures.dyndns.org> Message-ID: <20030203153839.B10586@linuxpower.org> On Mon, Feb 03, 2003 at 12:04:34AM -0500, Seth Johnson wrote: > Tell American Megatrends and Transmeta not to make chips > that let others control your computer! This is sensationalist and wrong. TCPA chips do not let other people `control your computer', in fact the abilities of the TCPA chip are rather limited. It would help if you read the spec for TCPA (http://www.trustedcomputing.org/) before posting such stuff, but I will admit that the TCPA spec is a wonderful example of exactly how not to write a spec. I'm sure much of the min-understanding of TCPA is due to the poor quality of this document. Also see http://www.research.ibm.com/gsal/tcpa/ for a wonderful work about TCPA which may alay some of your fears. > Palladium and TCPA would hardwire your home computer so that > these four entities and their partners would be able to run > processes on your computer, entirely outside your control, > indeed, without your knowledge. If you are running Windows this pretty much happens already. > The mechanics are as follows: only code that has been signed > with a special Microsoft provided key will run. Microsoft > will retain at all times the power to revoke any other > entity's keys. In particular, no operating system will be > able to boot without a key from Microsoft. So if Palladium > is forced into every home computer, there will be no more > free software. Total crap. It M$ wish to implement code signing in Windows they can do that with or without TCPA . TCPA allows you to seal data and only unseal it when booted in the same configuration. It also allows you to `prove' to another party that you are running a given configuration (with a number of assumptions) "The TCPA chip doesn t execute anything. It accepts request data, and replies with response data. The TCPA chip does not and cannot control execution!" (IBM paper). *TCPA chips do not prevent free-software running on the computer* > Microsoft will be able to spy on each and every keystroke, > and mouse movement, and send encrypted messages from your > machine to Microsoft headquarters. Microsoft will also be > able to examine every file on your system. As they can (and, by some accounts, do) currently. > Your encryption > programs will not work against Microsoft, or any other > entities which have full power keys from Microsoft. Utter crap again. TCPA does not alter mathematical reality. Boot Linux and encrypt all you like. > There are two reasons most people will not be able to escape > the All Seeing Eye and Invisible Hand of Palladium. You are mixing up Palladium and TCPA. And we don't even have details on Palladium yet. > Once Microsoft and Intel have forced Palladiated hardware > into every personal computer, it will be impossible to run a > free OS. Rubbish. See above. Now, TCPA does allow some nasty things to happen. See http://www.trustedcomputing.org/docs/TCPA_first_WP.pdf for an example of `content providers' using TCPA to only trust a computer running a given OS. But, personally, I would like a TCPA system. That way I can encrypt my filesystem and store the key in the TPM; which would only decrypt it when my kernel was booted. As a crypto junkie that appeals quite a lot. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org (+44) (0)7986 296753 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 From zooko at zooko.com Mon Feb 3 11:58:02 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: Message from Adam Langley of "Mon, 03 Feb 2003 15:38:39 GMT." <20030203153839.B10586@linuxpower.org> References: <3E3DF862.195AEE15@RealMeasures.dyndns.org> <20030203153839.B10586@linuxpower.org> Message-ID: The Treacherous Computing Platform Alliance certainly *will* control what you can do with your computer, and it certainly will include preventing you from booting a free operating system. I speak not of the Trusted Computing Platform Alliance spec that Adam read, but of the strategic plan that is currently being executed by the authors of that spec. Lest you think that this is all FUD, consider that there are already millions of Xboxes in the hands of consumers, which cannot boot a free operating system without cracking open the case and installing a modchip. This level of constraint is sufficient to prevent 99% of people from ever being able to try Linux on their computers, but Microsoft is hard at work designing improvements that will significantly increase the difficulty. If your mother buys a "Microsoft PC" next Christmas to do her e-mail, it may very well be one that cannot be made to boot Linux without expensive and potentially damaging hardware surgery. Now, Adam is probably right that the Trusted Computing Platform Alliance spec doesn't say that a TCPA computer must prevent you from booting Linux, but Seth is right that the Treacherous Computing Platform Alliance *will* prevent you from booting a free operating system and *will* control everything that you do with your computer, and soon. As far as I can tell, the current TCPA spec is intended to make sure that you can't view Microsoft Media DRM'ed videos through Wine, vmware, bochs, etc. so that you can't bypass the DRM. Regards, Zooko From hal at finney.org Mon Feb 3 12:17:01 2003 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! Message-ID: <200302032016.h13KGQK05386@finney.org> Zooko writes: > Now, Adam is probably right that the Trusted Computing Platform Alliance spec > doesn't say that a TCPA computer must prevent you from booting Linux, but Seth > is right that the Treacherous Computing Platform Alliance *will* prevent you > from booting a free operating system and *will* control everything that you do > with your computer, and soon. Are you being facetious here? What is the Treacherous Computing Platform Alliance and how does it differ from the Trusted Computing Platform Alliance? Are you just calling them names? If so, where do you get your information about what the TCPA will do? Don't they all explicitly claim that they won't impose restrictions on what can boot? How do you explain IBM's release of open source software for using the TCPA hardware? > As far as I can tell, the current TCPA spec is intended to make sure that you > can't view Microsoft Media DRM'ed videos through Wine, vmware, bochs, etc. so > that you can't bypass the DRM. I believe this is correct, the idea is that the TCPA boot process stores various metrics of your boot sequence in some protected memory. Then it lets the OS lock (i.e. encrypt) data such that it can't be unlocked if a different boot sequence is used. So data could be locked under a Windows OS such that it could not be unlocked under a non-Windows OS (and vice versa, I suppose). Given this capability, why do they need to stop you from booting Linux as you claimed above? And does this constitute "control [of] everything that you do with your computer"? Or is there something worse? Hal Finney From zooko at zooko.com Mon Feb 3 12:56:01 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: Message from "Hal Finney" of "Mon, 03 Feb 2003 12:16:26 PST." <200302032016.h13KGQK05386@finney.org> References: <200302032016.h13KGQK05386@finney.org> Message-ID: Hal Finney writes: > > Are you being facetious here? No. > What is the Treacherous Computing Platform > Alliance and how does it differ from the Trusted Computing Platform > Alliance? Are you just calling them names? Yes, I'm just calling them names. It was RMS's idea AFAIK. Likewise, he expands DRM as "Digital Restrictions Management", which I believe is a much less euphemistic term than the official one. > If so, where do you get your information about what the TCPA will do? Various sources such as Microsoft job postings, interviews, press releases, etc., plus simple reasoning about what strategy profit-seeking machines (corporations) will attempt in the current situation. > Given this capability, why do they need to stop you from booting Linux > as you claimed above? That's a good point -- the TCPA hack can enforce Digital Restrictions Management without preventing you from booting a free operating system. So inasmuch as that works, it lessens the profit motive to prevent alternative OSes, by instead constraining what the alternative OSes are capable of doing. Xboxes prevent you from booting a free operating system because they are sold below cost. One final profit motive might be simple competition: if Linux or another OS were to sufficiently encroach on desktop sales of Windows then applying Xbox-like constraints to PC hardware might be worthwhile. But there might be cheaper ways to achieve the same thing (such as managing OEM relationships). But you (and Adam) make a very good point that the goal of the current TCPA spec is not to prevent booting of alternative OSes. Rather it is to prevent that an alternative OS can use certain information after booting. > And does this constitute "control [of] everything that you do with > your computer"? Or is there something worse? Well, there are two prongs here: one is that if you run Windows, then Microsoft will have de facto control of everything that you do with your computer, and will use it for various profit-making purposes such as disabling competing software, forcing you to upgrade, preventing you from sharing content, etc. The other prong is that if you *don't* run Windows, there will be less and less that you are able to do in terms of interacting with the rest of the world that does. Currently we live in an exception from the big pattern -- a bubble in history, when I can send and receive e-mail and web pages with my mom even though she runs Windows and I run Linux. This will become less and less possible in the future, as the web page that she views and the document tools that she uses (MS Word, Outlook) start emitting information which is cryptographically impossible for me to read. (For example, because the information is encrypted with a public key whose private counterpart is embedded in my computer and only available if I boot Windows.) I want to stress that this stuff is not future hypothetical stuff. Windows Media Player 9 is now released. It signals the sound card, if the sound card has the appropriate Digital Restrictions Management features built in, to prevent the user from recording the digital audio passed through it. Many soundcards currently in the hands of consumers will obey this instruction. None of them say so on the outside of the box. http://www.theregister.co.uk/content/4/27232.html Regards, Zooko From hal at finney.org Mon Feb 3 13:28:02 2003 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! Message-ID: <200302032127.h13LRNA05856@finney.org> Zooko writes: > Yes, I'm just calling them names. It was RMS's idea AFAIK. Likewise, > he expands DRM as "Digital Restrictions Management", which I believe is > a much less euphemistic term than the official one. Just as a data point, I personally have a very negative reaction to substituting name-calling for argument, and probably at least a few other people do, too. > That's a good point -- the TCPA hack can enforce Digital Restrictions > Management without preventing you from booting a free operating system. > So inasmuch as that works, it lessens the profit motive to prevent > alternative OSes, by instead constraining what the alternative OSes are > capable of doing. > ... > One final profit motive might be simple competition: if Linux or > another OS were to sufficiently encroach on desktop sales of Windows > then applying Xbox-like constraints to PC hardware might be worthwhile. > But there might be cheaper ways to achieve the same thing (such as > managing OEM relationships). I agree that the profit motive is the right place to start. The founding members of the TCPA were HP, Compaq, IBM, Intel and Microsoft. Since then HP has bought Compaq and Microsoft has somewhat disassociated it from the effort as it has gone off with Palladium. That leaves HP, IBM and Intel as the main members at present. I don't see them as benefiting by making computers that can only run one OS. IBM has been moving towards the free software camp, and both HP and Intel would benefit from making the hardware they sell more useful and versatile. > Well, there are two prongs here: one is that if you run Windows, then > Microsoft will have de facto control of everything that you do with > your computer, and will use it for various profit-making purposes such > as disabling competing software, forcing you to upgrade, preventing you > from sharing content, etc. The other prong is that if you *don't* run > Windows, there will be less and less that you are able to do in terms > of interacting with the rest of the world that does. Both of these are well along the way to coming true even without these new technologies. Windows puts many restrictions on what you can do, whether Palladium ever happens or not. And Linux users give up a lot of functionality. They can't run most of the PC games in the store, they can't run IE and access sites that require it. On the other hand they gain some advantages too. Everything in life is a tradeoff. > Currently we live in an exception from the big pattern -- a bubble in > history, when I can send and receive e-mail and web pages with my mom even > though she runs Windows and I run Linux. This will become less and less > possible in the future, as the web page that she views and the document > tools that she uses (MS Word, Outlook) start emitting information which > is cryptographically impossible for me to read. (For example, because > the information is encrypted with a public key whose private counterpart > is embedded in my computer and only available if I boot Windows.) It's very questionable whether it will be in Microsoft's interest to close its world to this extent, even ignoring anti-trust issues. Customers do need to be able to talk to users who have non-Palladium computers - Macs, Linux and Unix systems, older versions of Windows. How easy will it be for Microsoft to sell its new version of Windows if it has all these built-in incompatibilities? And if Microsoft were sure this were the right way to go, couldn't they do much of this already? Remove the "text mode" save option from Word, for example, so that you could only save in modes that Word users could read? They could FORCE everyone to buy Word! Given your model of how the world works, why hasn't Microsoft done this? Hal From ingo at fargonauten.de Mon Feb 3 14:25:02 2003 From: ingo at fargonauten.de (ingo@fargonauten.de) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: <200302032127.h13LRNA05856@finney.org> References: <200302032127.h13LRNA05856@finney.org> Message-ID: <20030203222452.GA27289@fargonauten.de> On Mon, Feb 03, 2003 at 01:27:23PM -0800, Hal Finney wrote: > Just as a data point, I personally have a very negative reaction to > substituting name-calling for argument, and probably at least a few > other people do, too. If you try to tell me that a steak is "well done", when its really still bloody on the inside and I call it "english" instead, is that calling names? I don't think so. Given what the TCPA does, do you really want say that "trusted" is a correct description? "Trusted Computing" used to mean something /entirely/ different. Even if you don't agree, discussion on the interpretation is perfectly legitimate, IMHO. Its not as if you're calling them morons or anything like that. Changing the expansion of 'TCPA' is just making it very obvious that 'trusted' isn't deemed to be really appropriate here. > And if Microsoft were sure this were the right way to go, couldn't they > do much of this already? Remove the "text mode" save option from Word, > for example, so that you could only save in modes that Word users could > read? They could FORCE everyone to buy Word! Given your model of how > the world works, why hasn't Microsoft done this? Please! Thats a nice example, but it doesn't really fit here. There's no reason at all to remove that functionality, so the removal would be seen clearly for what it is, a restriction of users freedoms. OTOH, the media industry is hard at work telling everyone that copying is immoral anyway, even for personal use. I recently attended a lecture by a well known german hypertext researcher (Dr. Rainer Kuhlen, from Konstanz) who talked about freedom of research and the value of interchanging ideas and works. After his very well reasoned and /extremely/ polite lecture was over, he was accused of trying to defend "theft" by the assembled media industry representatives. /Thats/ what I call stifling a discussion and thats why the discussion about the removal of functions from media applications is such a different matter and the 'Word' comparison not really fitting. Microsoft is just a corporation. Going the easy way is a very rational business choice, especially if litigation is lurking on the other way. If the easy way is to comply with what the media industry is asking, they will do it, irregardless of anyone elses opinions. Pointing that out is not calling Microsoft evil, its just stating the obvious. -- http://fargonauten.de/ingo PGP: 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B From hal at finney.org Mon Feb 3 15:10:02 2003 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! Message-ID: <200302032309.h13N9RA06433@finney.org> I suppose this is all off topic for this list, so I will respond briefly and then say something that is on topic. Ingo Luetkebohle writes: > If you try to tell me that a steak is "well done", when its really > still bloody on the inside and I call it "english" instead, is that > calling names? I don't think so. Zooko had written: "Yes, I'm just calling them names. It was RMS's idea AFAIK." and I was responding to that. Regarding removing clear-text saving from Word: > Thats a nice example, but it doesn't really fit here. There's no > reason at all to remove that functionality, so the removal would be > seen clearly for what it is, a restriction of users freedoms. > > OTOH, the media industry is hard at work telling everyone that copying > is immoral anyway, even for personal use. I recently attended a > lecture by a well known german hypertext researcher (Dr. Rainer > Kuhlen, from Konstanz) who talked about freedom of research and the > value of interchanging ideas and works. After his very well reasoned > and /extremely/ polite lecture was over, he was accused of trying to > defend "theft" by the assembled media industry representatives. > > /Thats/ what I call stifling a discussion and thats why the discussion > about the removal of functions from media applications is such a > different matter and the 'Word' comparison not really fitting. Zooko had written: "Currently we live in an exception from the big pattern -- a bubble in history, when I can send and receive e-mail and web pages with my mom even though she runs Windows and I run Linux. This will become less and less possible in the future, as the web page that she views and the document tools that she uses (MS Word, Outlook) start emitting information which is cryptographically impossible for me to read. (For example, because the information is encrypted with a public key whose private counterpart is embedded in my computer and only available if I boot Windows.)" Zooko was the one who raised the example of tools that only output information in a form which is impossible for non-Windows-users to read. I think my question about a version of Word which doesn't save plain-text is very appropriate in this context. But I won't belabor the point. Rather, on to the relevant context. What does "trusted computing" (or "treacherous computing" if you prefer) mean for P2P hacking? There are possible bad and possible good effects. The bad possibility is that somehow TC will prevent P2P from happening, at least without authorization of some sort. Some people claim that this technology will only run Microsoft-signed executables, for example. The first message in this thread made exactly that claim. All the evidence is that this claim is FALSE but still it floats around. FUD is hard to kill. Alternative claims are that Microsoft will become able to send out search-and-destroy messages which will take over your computer and cause it to delete all the files on certain lists. I believe this statement is in Ross Anderson's TCPA FAQ. Again, I don't know of any shred of credible evidence that Microsoft or anyone else plans to do this, or would be able to get away with it if they tried. There are also suggestions that the TCPA crypto package could be subverted from outside, so that if you relied on it, they could backdoor your crypto. Then any P2P package that relied on this possibly-future-standard crypto technology could have its crypto defeated and its users would lose their privacy and possibly freedom. I've studied the existing TCPA specs and this doesn't look possible to me, but then most claims along these lines are expressed in speculative terms and not firmly grounded in the actual implementations. We've all heard about these possible bad effects; are there any good ones? Are there ways that P2P software could benefit from TCPA technology? I think there might be, but to understand the possible benefits you would have to view TCPA objectively, as an engineer, rather than how an activist or politician sees it. It's gotten to the point where even discussing this technology calmly is quite difficult, and anyone who does so finds himself accused of being a shill for the content industry. The assumption is that the possible bad consequences of TCPA/Palladium are so awful that any discussion of good uses is counter-productive, as it makes it more likely that the terrible outcome will occur. But if you can get past that for a moment and just think objectively, there are some things that TCPA can do for you. It has a crypto package that includes at least some degree of tamper resistance for holding the keys. It's kind of like having a smart card bolted to the motherboard. So this could be a key store that would have advantages over just putting your crypto keys into memory. TCPA/Palladium also have some features for getting a hash of the software that is loaded. The details are a little vague still, but both of them provide at least in principle for securely reporting this hash in response to remote inquiries. They can also seal (encrypt) data and lock it to the hash of the currently running software, such that it can't be decrypted if some other software configuration is running. So this can provide more security for key storage; in principle your application could generate a key and encrypt some data, and no other application could decrypt the data. Also if your application were tampered with or infected with a virus, its hash would change and it would not be able to decrypt the data any more. All this can increase the security of your key management. The remote reporting of the hash is the most interesting (and perhaps threatening) aspect of the technology. It means that you can connect to another computer and get a "trustworthy" report of what software you are talking to (which is really where the name "trusted computing" comes from). Now, this trustworthyness is modulo a number of issues, like hardware compromise and chain of custody, and it's not clear if the infrastructure for all this will ever be developed. But the DRM people need it and so if it does happen, P2P could piggyback on it. Basically this remote report would let you write P2P apps where each one could trust (there's that word again) its peers to a degree impossible today. P2P apps in today's environment have to be defensive, or at least they need to grow some defenses once they get a big enough profile in the world. Anyone could send any data claiming to be participating in the P2P protocol. There has been some discussion with regard to Gnutella about the problems with "bad peers" in the net. Designing protocols which can detect and respond to misbehavior is an ongoing effort. Theoretically trusted computing would provide either a way of avoiding this requirement, or another layer of defense, depending on how you look at it. It would make it more expensive and difficult to subvert a P2P network with bad data and bad traffic. The P2P nodes could check that their peers were running the expected software and refuse to connect to them if not. This would all be based on the ability to get a remote snapshot of the running software. So these are a few possibilities for how TCPA/Palladium could actually benefit P2P, if and when these technologies become mature. They are still speculative, and more details of how trusted computing will work will be necessary before we can evaluate these ideas. But hopefully they illustrate that the basic technology of trusted computing has more uses than to take over your computer, or to treacherously take control of your system away from you. Hal From zooko at zooko.com Mon Feb 3 18:17:02 2003 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: Message from "Hal Finney" of "Mon, 03 Feb 2003 15:09:27 PST." <200302032309.h13N9RA06433@finney.org> References: <200302032309.h13N9RA06433@finney.org> Message-ID: [replying to two separate messages posted by Hal Finney] Hal Finney wrote: > > How easy will it be for Microsoft to sell its new version of Windows if > it has all these built-in incompatibilities? ... > And if Microsoft were sure this were the right way to go, couldn't they > do much of this already? Hal: You are one of the two people (along with Dave Wagner) whose posts I always read first in any thread concerning crypto or security. Your vast knowledge about the many subfields of security has always impressed me, and I have in fact commented to my wife a couple of times that there's this guy named "Hal Finney", and I don't know much about him personally, but in any good mailing list, he always shows up and contributes the most useful posts about crypto and security. (Also, you contributed useful crypto patches to Mojo Nation.) Therefore, I'm quite surprised that you evince an apparent ignorance of the history of Microsoft successfully maintaining and extending its dominance by deliberate and systematic application of strategic incompatibility, FUD, strongarm tactics, and cetera. The question is not "Couldn't Microsoft do much of this already?", but "Given that Microsoft has been doing this with great success for the last two decades, is there any reason to believe that they will stop doing it as they deploy their new crypto platform?". > What does "trusted computing" (or "treacherous computing" if you prefer) > mean for P2P hacking? ... And here Hal continues to uphold his reputation for top notch security analysis contributed gratis to the world through Internet mailing lists. I'm glad I took the time to read your whole post. Your overall point that there could be good applications of the "send signed hash of application" feature is valid. Sadly, I feel strongly that even if Microsoft, Intel and others were to allow me to use that feature for an application that they may disagree with (a censorship-resistant decentralized file store), that the good things that I could do with it would be dwarfed by the harm that the corporations and governments would do with it. (I hold, in fact, the belief that you alluded to: I consider talking about the possible good uses of the possible "send signed hash of application" feature to be counterproductive, since the certain bad uses of that possible feature, as well as the certain "only allow authorized code to use certain data" feature are far more important.) > Some people claim that this technology will > only run Microsoft-signed executables, for example. ... > All the evidence is that this > claim is FALSE but still it floats around. FUD is hard to kill. If by "this technology", you mean the technology required by the TCPA v1 specification, then you are right. If by "this technology", you mean the strategic initiative that is already being deployed to consumers in stealthy increments, then you are wrong. I point to Xbox's resistance to booting alternative operating systems, Windows XP's requirement that hardware drivers be digitally signed by Microsoft, and the Creative Labs DRM sound cards that are already in the hands of unsuspecting consumers as just three examples which are already deployed. Next year's version will be more effective and it will extend its control to more parts of the users' lives. It could also, very easily, be automatically deployed without user intervention through Windows XP's automatic update. Probably part of the disagreement that we've just witnessed on this mailing list is a terminological collision. Hal Finney and Adam Langley use "TCPA" to mean a certain operating system/machine feature described in the "TCPA specification". Seth Johnson, and I use "TCPA/Palladium" to denote a certain grand strategy to make computers incapable of performing forbidden acts even if their users want them to, and to deploy this new platform with stealth, obfuscation, and spin management so that the consumers don't realize what it is and refuse to use it. The former technical specification is one important step in the latter world- domination strategy. Regards, Zooko http://zooko.com/ From lists.p2phackers at imperialviolet.org Tue Feb 4 05:21:02 2003 From: lists.p2phackers at imperialviolet.org (Adam Langley) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: ; from zooko@zooko.com on Mon, Feb 03, 2003 at 09:16:41PM -0500 References: <200302032309.h13N9RA06433@finney.org> Message-ID: <20030204132021.A7074@linuxpower.org> On Mon, Feb 03, 2003 at 09:16:41PM -0500, Zooko wrote: > Hal: > > You are one of the two people (along with Dave Wagner) whose posts I always > read first in any thread concerning crypto or security. Your vast knowledge > about the many subfields of security has always impressed me, and I have in > fact commented to my wife a couple of times that there's this guy named "Hal > Finney", and I don't know much about him personally, but in any good mailing > list, he always shows up and contributes the most useful posts about crypto > and security. (Which is why Hal is sometimes refered to as Gandalf by Freenet developers) > Probably part of the disagreement that we've just witnessed on this mailing > list is a terminological collision. Hal Finney and Adam Langley use "TCPA" > to mean a certain operating system/machine feature described in the "TCPA > specification". Seth Johnson, and I use "TCPA/Palladium" to denote a > certain grand strategy to make computers incapable of performing forbidden > acts even if their users want them to, and to deploy this new platform with > stealth, obfuscation, and spin management so that the consumers don't > realize what it is and refuse to use it. The former technical specification > is one important step in the latter world- domination strategy. If my guardian of arguments (Jeff Darcy) were here, he would undoubtably point to http://www1.law.ucla.edu/~volokh/slippery.htm. Just because TCPAv1 *may* be a stepping stone towards something bad doesn't automattically make TCPAv1 bad. As Hal and I have pointed out, TCPAv1 has a number of interresting uses and I, for one, will not be asking people to boycot it. But if people are asking for my support in educating the world about the dangers of what we believe Palladium is, then I will be marching right alongside them. I will fight tooth and nail to stop the sealth introduction of such technologies and laws supporting them passed by corrupt governments. But by making examples of TCPAv1 we only weaken our own position. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org (+44) (0)7986 296753 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 From thorsten.strufe at tu-ilmenau.de Tue Feb 4 05:33:02 2003 From: thorsten.strufe at tu-ilmenau.de (Thorsten Strufe) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] [Fwd: RE: TCPA? - No thanks!] Message-ID: <3E3F83A5.2090108@tu-ilmenau.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: RE: Palladium? - No thanks! Date: Montag, 3. Februar 2003 15:35 From: "Umbertina E. Vezzani" Hello [...], Thank you for taking time to contact us here at AMI. We are sorry to hear of your decision to not seek out an AMI ~ solution for your next purchase. While we respect your right to ~ make that decision, we would like to underline some relevant points ~ about our announcement and the purpose of TCPA. We urge you to ~ please give us a minute of your time to fully understand what AMI ~ is offering and thus be able to make a fully informed decision It must be noted that AMI has not announced support for Microsoft's Palladium. Palladium is an initiative by an OS entity that is slated ~ for the future. To be honest, though we do know about it, AMI has ~ not begun any development related to it. At this point we have not ~ made any decisions on support either. TCPA is completely optional ~ to our customers (OEMs, ODMs, CMs and other system builders). They ~ may choose to make it available or not, depending on the needs of ~ their market. We have had requests from a number of customers for ~ this technology. Depending from the motherboard manufacturer, you will continue to ~ find motherboards enabled by AMIBIOS that do not feature TCPA. I ~ must also add that AMIBIOS is not the first to offer this feature - ~ There are already PCs featuring this technology or other BIOS ~ vendors enabling this technology or other hardware-based security ~ options based on encrypted authentication. TCPA does not equal Palladium. While certainly there is some future development overlap between the two, TCPA is being introduced by ~ OEM's as a security option to protect systems through hardware and ~ firmware. The purpose of TCPA is to implement a subsystem to ~ protect computer clients from software hackers, not DRM. It is ~ poorly suited, even from a technical point of view, for DRM. DRM ~ applications might use TCPA applications or not, and DRM can be ~ introduced without TCPA. If you are against DRM, your concerns ~ should be expressed to the organizations that promote it. On TCPA goals and functions: http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf On misconceptions in circulating papers: http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf Another common misconception is that TCPA would not allow people to ~ run Linux. It actually does not limit the ability to run Linux (or ~ any other open source solution). Linux device drivers for TCPA are ~ available as well. In addition to this, the TCPA FAQ document reports several ~ protections for those users that are concerned with their privacy: * The system owner has ultimate control and permissions over private information and must opt-in to utilize a TCPA subsystem.(...) A TCPA subsystem can be disabled permanently * The specification allows the system owner to create multiple ~ and/or anonymous identities to enhance personal security and remove ~ avenues for identity cross-correlation * Supports multiple certificate authorities to give user choice * Code, applets or drivers used on a TCPA subsystem do not need to ~ be signed, unless the Operating system used specifically requires ~ it. Please refer to: TCPA FAQ http://www.infineon.com/cmc_upload/documents/048/002/TCPA_FAQ_1.pdf As a smaller company itself, AMI has always supported innovation and creativity, as these have been our main tools in competing against ~ much larger companies in our industry. We would not do anything ~ that in our minds would damage our credibility or reputation for ~ world class BIOS solutions and will carefully evaluate this type of ~ feedback when it does come time to examine any future technologies. ~ We would also like to recommend that anyone who is opposed to a ~ Palladium-type solution in the future, please make that known to ~ OEM's and system builders. As they are our customers, we ~ definitely listen to them in terms of what they (and hopefully ~ their customers) will want in future BIOS. Thank you again for your time in contacting us and we hope that this ~ and some of the links below will shed some light on AMI's plans. LINKS Original Articles on theinquirer.net http://www.theinquirer.net/?article=7089 http://www.theinquirer.net/?article=7103 Interview with Slashdot ("real, not laundered") AMI TCPA module Whitepaper http://www.ami.com/support/doc/TCPA_whitepaper.pdf TCPA FAQ http://www.infineon.com/cmc_upload/documents/048/002/TCPA_FAQ_1.pdf TPM FAQ http://www.infineon.com/cmc_upload/documents/048/003/TPM_FAQ_1.pdf TCPA Website - -- Dipl.-Inf. Thorsten Strufe +49(0)3677-694553, CC 442 Fachgebiet Telematik Institut Praktische Informatik Technische Universit?t Ilmenau http://www-ia.tu-ilmenau.de/IPI/FGT Sartre:Begehe keine Dummheit zweimal, die Auswahl ist doch gro? genug! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+P4OlOQ9e8ojbqFYRAhD2AJ9s6zV7v/G6et1YbFmSKt370MbA+QCfQfja BaVx0mv41WmqYBfe66vM60k= =ZeD+ -----END PGP SIGNATURE----- From iluetkeb at TechFak.Uni-Bielefeld.DE Tue Feb 4 05:33:03 2003 From: iluetkeb at TechFak.Uni-Bielefeld.DE (Ingo Luetkebohle) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: <200302032309.h13N9RA06433@finney.org> References: <200302032309.h13N9RA06433@finney.org> Message-ID: <20030204111240.GA13108@kilauea.TechFak.Uni-Bielefeld.DE> Hi, sorry if this off-topic (again?). I also think that being objective on this topic is very important but likewise I'm of the opinion that there are issues about the TCPA that, though non-technical, are relevant for engineers and that, when taking a purely technical point of view, its tempting to forget crucial issues in the understandable excitement over having a crypto device in every box. On Mon, Feb 03, 2003 at 03:09:27PM -0800, Hal Finney wrote: > But if you can get past that for a moment and just think objectively, > there are some things that TCPA can do for you. [...] At last years Chaos Communication Congress, there was a big discussion on the TCPA. Almost everybody agreed it could be usefull. Likewise, almost everybody agreed that the same benefits could be had by other means. Smart cards were mentioned as one possibility, USB tokens are another, surely such a device could also be plugged in as a PCI card. So, the question becomes: Why do it this way and not another? Why, e.g., hasn't the smartcard industry gotten its act together and standardized? Of course, there are cost benefits to be had by integrating the chip directly on the mainboard and it would do wonders for ubiquity. However, its also very bad for upgrading -- there's a large installed base of machines without a TPM in use and replacing the main-board in every one of them is not feasible. So, from a purely objective engineering point of view, its not clear that this is the best solution. The idea that something other than objective, engineering reasons are behind the decision to do it this way can't be discarded offhandedly, as much as I personally would like that. The one, big difference is that a TPM can't be removed. Coupled with the information that there will be keys in the TPM that can't -- ever -- be taken out, and thats not just for high-security applications but a feature supposedly for everyday usage, it makes you wonder. So, of course, a TPM could be very cool device and I'm sure many cool apps will benefit from it. But its architecture allows other things and, after having read Lessigs "Code", I'm a little bit paranoid such things ;-) bye -- Ingo Luetkebohle / http://blank.pages.de/ Computer Science & Linguistics Student / iluetkeb@techfak.uni-bielefeld.de From ingo at fargonauten.de Tue Feb 4 06:29:02 2003 From: ingo at fargonauten.de (ingo@fargonauten.de) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: <20030204111240.GA13108@kilauea.TechFak.Uni-Bielefeld.DE> References: <200302032309.h13N9RA06433@finney.org> <20030204111240.GA13108@kilauea.TechFak.Uni-Bielefeld.DE> Message-ID: <20030204142827.GD13522@kilauea.TechFak.Uni-Bielefeld.DE> On Tue, Feb 04, 2003 at 12:12:40PM +0100, Ingo Luetkebohle wrote: > the information that there will be keys in the TPM that can't -- ever > -- be taken out, and thats not just for high-security applications but > a feature supposedly for everyday usage, it makes you wonder. It has been pointed out to me that this way of using the TPM is Palladium-specific and has nothing to do with the TCPA. It /is/ a very important functionality for some applications. Sorry for any resulting confusion. -- Ingo Luetkebohle / http://blank.pages.de/ Computer Science & Linguistics Student / iluetkeb@techfak.uni-bielefeld.de From lists.p2phackers at imperialviolet.org Tue Feb 4 08:09:02 2003 From: lists.p2phackers at imperialviolet.org (Adam Langley) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: References: <200302032309.h13N9RA06433@finney.org> <20030204132021.A7074@linuxpower.org> <20030204160720.C7074@linuxpower.org> Message-ID: <20030204160815.D7074@linuxpower.org> On Mon, Feb 03, 2003 at 09:16:41PM -0500, Zooko wrote: > Hal: > > You are one of the two people (along with Dave Wagner) whose posts I always > read first in any thread concerning crypto or security. Your vast knowledge > about the many subfields of security has always impressed me, and I have in > fact commented to my wife a couple of times that there's this guy named "Hal > Finney", and I don't know much about him personally, but in any good mailing > list, he always shows up and contributes the most useful posts about crypto > and security. (Which is why Hal is sometimes refered to as Gandalf by Freenet developers) > Probably part of the disagreement that we've just witnessed on this mailing > list is a terminological collision. Hal Finney and Adam Langley use "TCPA" > to mean a certain operating system/machine feature described in the "TCPA > specification". Seth Johnson, and I use "TCPA/Palladium" to denote a > certain grand strategy to make computers incapable of performing forbidden > acts even if their users want them to, and to deploy this new platform with > stealth, obfuscation, and spin management so that the consumers don't > realize what it is and refuse to use it. The former technical specification > is one important step in the latter world- domination strategy. If my guardian of arguments (Jeff Darcy) were here, he would undoubtably point to http://www1.law.ucla.edu/~volokh/slippery.htm. Just because TCPAv1 *may* be a stepping stone towards something bad doesn't automattically make TCPAv1 bad. As Hal and I have pointed out, TCPAv1 has a number of interresting uses and I, for one, will not be asking people to boycot it. But if people are asking for my support in educating the world about the dangers of what we believe Palladium is, then I will be marching right alongside them. I will fight tooth and nail to stop the sealth introduction of such technologies and laws supporting them passed by corrupt governments. But by making examples of TCPAv1 we only weaken our own position. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org (+44) (0)7986 296753 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 From wesley at felter.org Tue Feb 4 11:04:01 2003 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! In-Reply-To: <20030204111240.GA13108@kilauea.TechFak.Uni-Bielefeld.DE> References: <200302032309.h13N9RA06433@finney.org> <20030204111240.GA13108@kilauea.TechFak.Uni-Bielefeld.DE> Message-ID: <1044385488.2868.28.camel@arlab191.austin.ibm.com> On Tue, 2003-02-04 at 05:12, Ingo Luetkebohle wrote: > The one, big difference is that a TPM can't be removed. Coupled with > the information that there will be keys in the TPM that can't -- ever > -- be taken out, and thats not just for high-security applications but > a feature supposedly for everyday usage, it makes you wonder. In IBM's machines the TPM is on a card that can be removed; maybe we should encourage other manufacturers to do this. (This solves the "how do you know if it's *really* turned off?" problem.) My understanding is that keys stored in the TPM can be deleted; I don't know if this applies to the all-important endorsement key. -- Wes Felter - wesley@felter.org - http://felter.org/wesley/ From bram at gawth.com Tue Feb 4 20:12:02 2003 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] CodeCon schedule announced Message-ID: The CodeCon schedule is now up - http://codecon.info/2003/schedule.html Registration is closing in not too long. You should register early if you plan to come - it's $15 cheaper in advance, and buying your dinner in advance will help us guess the number of people to prepare for. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From rajesh at infoglyptic.com Wed Feb 5 07:36:01 2003 From: rajesh at infoglyptic.com (Rajesh Acharya) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] P2P Distributed Backup In-Reply-To: <20030124153535.2f7ddbfa.zainul@ee.iitb.ac.in> References: <20030123203333.3b486408.zainul@ee.iitb.ac.in> <03012412093002.12355@pc70.ig.com> <20030124153535.2f7ddbfa.zainul@ee.iitb.ac.in> Message-ID: <03020521253904.14569@pc70.ig.com> Hello Zainul, Was offline for quite sometime and hence could not take your questions. Aisland is in development stage and there is not much documentation available at present. All I can suggest is that you have to check out the code from cvs and build to see if it suits your needs. You may even get the binary from downloads section alternatively. If you need you may write to me directly so that I can zip the software and mail to you. Its around 7 MB. I think the C implementation of JXTA has taken back-stage due to recent focus on Java implementation to prove JXTA's credibility and scalabilty as a generic P2P protocol. You may get a better update on the jxta lists on C implementation. Rajesh > Thanks for the info. I went through the description and explanation. But I > think I missed the whole point. Is there some resource which explains how > AIsland works without going into details of Java classes ? I apologize for > I'm not too much of a Java hacker. > > Is the C implementation of JXTA stable for use now ? > > Zainul. > From juan.soto at Sun.com Thu Feb 6 08:32:02 2003 From: juan.soto at Sun.com (Juan Carlos Soto) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] JXTA C Information References: <20030206112856.6809.2995.Mailman@capsicum.zgp.org> Message-ID: <3E428DD4.8070109@Sun.com> Rainul, The JXTA-C code available today at http://jxta-c.jxta.org implements the original JXTA protocols and is fully interoperable with the latest releases of Java2SE (for servers, desktops, larger PDAs, etc.) and Java2ME (for cell phones, small PDAs, pagers, etc.) implementations of JXTA. The main effort at the core level over the past 6 months has been on a Java 2 SE implementation of enhancements to the JXTA protocols which I call version 2. The next stable release of the JXTA for J2SE platform implementing the protocol changes is due any day now. Note that this release will break backwards compatibility. Once that release is complete, work will speed up again on the C (http://jxta-c.jxta.org) and J2ME (http://jxme.jxta.org) versions to implement the latest protocol changes. hth, -Juan Carlos Soto. p2p-hackers-request@zgp.org wrote: > > Message: 1 > From: Rajesh Acharya > To: p2p-hackers@zgp.org > Subject: Re: [p2p-hackers] P2P Distributed Backup > Date: Wed, 5 Feb 2003 21:25:39 +0530 > Reply-To: p2p-hackers@zgp.org > > Hello Zainul, > Was offline for quite sometime and hence could not take your questions. > Aisland is in development stage and there is not much documentation available > at present. > All I can suggest is that you have to check out the code from cvs and build > to see if it suits your needs. You may even get the binary from downloads > section alternatively. If you need you may write to me directly so that I can > zip the software and mail to you. Its around 7 MB. > > I think the C implementation of JXTA has taken back-stage due to recent focus > on Java implementation to prove JXTA's credibility and scalabilty as a > generic P2P protocol. You may get a better update on the jxta lists on C > implementation. > > > Rajesh > > > >>Thanks for the info. I went through the description and explanation. But I >>think I missed the whole point. Is there some resource which explains how >>AIsland works without going into details of Java classes ? I apologize for >>I'm not too much of a Java hacker. >> >>Is the C implementation of JXTA stable for use now ? >> >>Zainul. >> > > > > --__--__-- > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > > > End of p2p-hackers Digest -- Juan Carlos Soto juan.soto@Sun.com Project JXTA 415.762.2734 From hal at finney.org Thu Feb 6 11:57:02 2003 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:12:05 2006 Subject: [p2p-hackers] Stop Palladium and TCPA Now! Message-ID: <200302061956.h16Juej22070@finney.org> Just thought I'd make a final comment on the TCPA/Palladium issue... I know my opinion is somewhat out of step with most views in the security community. I think the differences are more political than technical, though. Opponents of the technology are generally extrapolating possibilities which I agree would be genuinely harmful. The worst case would be for trusted computing (TC) to be mandated by legislation, with only government-approved software allowed to run. If we can avoid such a disaster, I generally support the exploration of new technologies like TC, even when they are used to implement digital rights management. It may seem paradoxical to work on Freenet and anonymity while also supporting DRM technologies, but to me they are all part of the same picture. My politics are libertarian, which means I don't take sides in the marketplace. I want people to make informed decisions, but I don't want to take away their options. But enough philosophy. As a final technical point, I think the community is in danger of making a mistake in evaluating TCPA vs Palladium. There is a growing current that says TCPA=good (or at least OK), Palladium=bad. I think in fact the proposals are much more similar in their goals and their effects than this distinction suggests. However the point may be moot, as Microsoft's effective abandonment of TCPA in favor of Palladium suggests that TCPA doesn't have much of a future. Hal From levine at vinecorp.com Thu Feb 6 17:08:02 2003 From: levine at vinecorp.com (James D. Levine) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] [Silicon Valley] PeerPunks reminder - next Tuesday Feb 11 Message-ID: It's that time again...see you there! James ----- Where: Dana Street Roasting Company 744 W Dana St, Mountain View,CA 94041 Phone: (650) 390-9638 This is just 1/2 block off Castro St. When: 7:00 pm onward From bram at gawth.com Sat Feb 8 17:53:02 2003 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] p2p-hackers meeting tommorow Message-ID: Remember everyone, p2p-hackers meeting tomorrow, 3pm, the metrion, san francisco, planet earth. Unrelated to anything p2p (but kinda distributed) I just released this new version control system - http://bitconjurer.org/codeville/ -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From arma at mit.edu Mon Feb 10 10:46:02 2003 From: arma at mit.edu (Roger Dingledine) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] PET2003 (Mar 26-28) accepted papers Message-ID: <20030210134523.A4668@moria.mit.edu> The following papers have been accepted for presentation and publication at the 3rd Privacy Enhancing Technologies workshop, in Dresden Mar 26-28 this year. In addition, there will be several invited talks and/or panels. Please forward this mail to other relevant lists. See http://petworkshop.org/ for more details, including the rapidly approaching deadlines for stipends (February 16 -- available to non-authors too!) and registration (February 20). "Mix-networks with Restricted Routes" George Danezis "Generalising Mixes" Claudia Diaz, Andrei Serjantov "Modelling Unlinkability" Sandra Steinbrecher and Stefan K\"opsell "Metrics for Traffic Analysis Prevention" Richard E. Newman, Ira S. Moskowitz, Paul Syverson, Andrei Serjantov "Breaking and Mending Resilient Mix-nets" Lan Nguyen, Rei Safavi-Naini "Improving Onion Notation" Richard Clayton "Engineering Privacy in Public: Confounding Face Recognition" James Alexander and Jonathan Smith "From Privacy Legislation to Interface Design: Implementing Information Privacy in Human-Computer Interactions" Andrew S. Patrick, Stephen Kenny "Defeating Web Censorship with Untrusted Messenger Discovery" Nick Feamster, Magdalena Balazinska, Winston Wang, Hari Balakrishnan, David Karger "GAP -- Practical anonymous networking" Krista Bennett, Christian Grothoff "An Analysis of GNUnet and the Implications for Anonymous, Censorship-Resistant Networks" Dennis K\"ugler "A Component Architecture for Dynamically Managing Privacy Constraints in Personalized Web-based Systems" Alfred Kobsa "Privacy in Enterprise Identity Federation: Policies for Liberty Single Signon" Birgit Pfitzmann "From P3P to Data Licenses" Yuh-Jzer Joung From levine at vinecorp.com Mon Feb 10 23:34:02 2003 From: levine at vinecorp.com (James D. Levine) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] [Silicon Valley] PeerPunks meeting Tuesday at 7pm Message-ID: See you there... James -------- Where: Dana Street Roasting Company 744 W Dana St, Mountain View,CA 94041 Phone: (650) 390-9638 This is just 1/2 block off Castro St. When: 7:00 pm onward ----- PeerPunks is just my clever name for the Silicon Valley contingent of p2p enthusiasts, hackers, well-wishers, etc. Any and all are welcome, so please come and join in... -- From levine at vinecorp.com Tue Feb 11 15:39:02 2003 From: levine at vinecorp.com (James D. Levine) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] [Silicon Valley] PeerPunks TONIGHT in Mountain View Message-ID: See everyone tonight... James -- Where: Dana Street Roasting Company 744 W Dana St, Mountain View,CA 94041 Phone: (650) 390-9638 This is just 1/2 block off Castro St. When: 7:00 pm onward ----- PeerPunks is just my clever name for the Silicon Valley contingent of p2p enthusiasts, hackers, well-wishers, etc. Any and all are welcome, so please come and join in... -- From bram at gawth.com Wed Feb 12 13:51:02 2003 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] CodeCon pre-registration closing soon Message-ID: CodeCon pre-registration, which is cheaper than at the door, is going to end on the 15th. http://codecon.info/ Everyone should come, we've got a great program this year. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From rabbi at abditum.com Wed Feb 12 15:48:02 2003 From: rabbi at abditum.com (Len Sassaman) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] CodeCon Registration Deadline Approaching Message-ID: CodeCon is fast approaching, and there are only three days left to register online for CodeCon at the reduced rate. CodeCon 2.0 is the premier event in 2003 for the P2P, Cypherpunk, and network/security application developer community. It is a workshop for developers of real-world applications with working code and active development projects. Last year, presentations at CodeCon included the Peek-A-Booty anti-censorship application, the Invisible IRC Project, the CryptoMail web-based email encryption project, and the file-distribution application BitTorrent. Some of this year's highlights include Mixminion, a next-generation anonymous remailer; Alluvium, Internet Radio software exempt from current RIAA webcasting royalties; and GNU Radio, an open source software defined radio application. CodeCon registration is $95; a $15 discount is available for attendees who register online prior to February 15th. CodeCon 2.0 will be held February 22-24, noon-6pm, at Club NV (525 Howard Street) in San Francisco. For more information, please visit http://www.codecon.info. From mfreed at cs.nyu.edu Thu Feb 13 06:31:02 2003 From: mfreed at cs.nyu.edu (Michael J. Freedman) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] IPTPS03 papers now available In-Reply-To: <20030213112746.29036.94080.Mailman@capsicum.zgp.org> Message-ID: Hi all, All the papers from the 2nd International Workshop on Peer-to-Peer Systems (IPTPS '03) are now publicly available on the web: http://iptps03.cs.berkeley.edu/ http://iptps03.cs.berkeley.edu/program.html Many of these papers are probably quite relevant to the p2p-hackers community as well! Enjoy, --mike From aloeser at cs.tu-berlin.de Fri Feb 14 05:25:02 2003 From: aloeser at cs.tu-berlin.de (Alexander =?iso-8859-1?Q?L=F6ser?=) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] "Access Control" in P2P and CDN References: <3E2E3867.7060901@neurogrid.com> Message-ID: <3E4CEE43.553D33A9@cs.tu-berlin.de> Hey Sam, I'am currently working on how to bring structure into a peer-to-peer network using access controls. To get entrance to the network, peers have to register at super peers. Each super peer provides its own policy, e.g. which peer may join or not. Each policy consists of several rules. Here is an example: ON (Event) Enter IF ( (Peer.Advertisement.Property metadata_schema="Dublin Core") AND (Peer.Advertisement.Property peer_name INCLUDE "cs.tu-berlin.de") ) DO (Action) Approve(Peer) ELSE (Action) Reject(Peer) Such rules are formulated by the super-peer administrator. Finally the network is structured in several subject specific clusters, each one represented by one super peer. Further details can be taken from http://cis.cs.tu-berlin.de/~aloeser/gk/publications/Caise03_submission_Loeser_Nejdl_Wolpers_Siberski.PDF Cheers Alex Sam Joseph wrote: > Hi Everyone, > > I've got to give a talk soon on content distribution networks and p2p > systems, particularly as regards the presence of "access control". > > So far I'm going to include YouServ, and probably mention the primitive > access control in NeuroGrid. If I remember correctly, some Gnutella > clones can be set up to provide private sub-networks. > > However, I wondered if any of you thought there were any other good > examples of "access control" being used in distributed network > environments. > > In more concrete terms, the use of "Access Policies" within the > distributed network environment to restrict access to certain types of > content to different subsets of users ... > > Thanks in advance. > > CHEERS> SAM > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers -- ______________________________________ Alexander L?ser Technische Universitaet Berlin Fakultaet IV - CIS bmb+f-Projekt: "NewEconomy" "Neue Medien in der Bildung" email: aloeser@cs.tu-berlin.de office: +49- 30-314-25555 fax : +49- 30-314-21601 ______________________________________ From justin at chapweske.com Fri Feb 14 07:24:02 2003 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] IPTPS03 papers now available In-Reply-To: References: Message-ID: <3E4D09D5.30405@chapweske.com> Oh, btw. I like your use of multiple increasing diameter DHTs to exploit network locality. Its a nice, clean approach. Michael J. Freedman wrote: > Hi all, > > All the papers from the 2nd International Workshop on Peer-to-Peer Systems > (IPTPS '03) are now publicly available on the web: > > http://iptps03.cs.berkeley.edu/ > http://iptps03.cs.berkeley.edu/program.html > > Many of these papers are probably quite relevant to the p2p-hackers > community as well! > > Enjoy, > --mike > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From mfreed at cs.nyu.edu Fri Feb 14 10:04:01 2003 From: mfreed at cs.nyu.edu (Michael J. Freedman) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] IPTPS03 papers now available In-Reply-To: <3E4D09D5.30405@chapweske.com> Message-ID: Thanks Justin, I've have some performance numbers within the next month. I'll let you know what it looks... --mike On Fri, 14 Feb 2003, Justin Chapweske wrote: > Date: Fri, 14 Feb 2003 09:23:01 -0600 > From: Justin Chapweske > Reply-To: p2p-hackers@zgp.org > To: p2p-hackers@zgp.org > Subject: Re: [p2p-hackers] IPTPS03 papers now available > > Oh, btw. I like your use of multiple increasing diameter DHTs to > exploit network locality. Its a nice, clean approach. > > > Michael J. Freedman wrote: > > Hi all, > > > > All the papers from the 2nd International Workshop on Peer-to-Peer Systems > > (IPTPS '03) are now publicly available on the web: > > > > http://iptps03.cs.berkeley.edu/ > > http://iptps03.cs.berkeley.edu/program.html > > > > Many of these papers are probably quite relevant to the p2p-hackers > > community as well! > > > > Enjoy, > > --mike > > > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > > -- > Justin Chapweske, Onion Networks > http://onionnetworks.com/ > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > ----- "Not all those who wander are lost." www.michaelfreedman.org From cooperb at Stanford.edu Fri Feb 14 11:36:03 2003 From: cooperb at Stanford.edu (Brian Frank Cooper) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] Thesis defense - 2/28/2003, 9am Message-ID: ====================================================================== Special University Oral Examination Information Preservation in Networks of Autonomous Archives Brian Frank Cooper PhD Candidate Computer Science Department Stanford University Friday, Feb 28, 9:00 - 10:00 am Room 104, Gates Computer Science (Refreshments will be served at 8:45 am) ====================================================================== An ever increasing amount of information is being stored digitally, and people are becoming more and more dependent on it. However, very little is understood about how to preserve digital information for long time periods. Media failures, natural disasters and bankruptcy all conspire to cause information loss over decades or centuries. Such failures rob future generations of vital scientific and cultural artifacts. To deal with these problems, we have developed a distributed digital archive that is based on the concept of multiple autonomous archives cooperating to provide preservation. For such a system to effectively preserve data for the long term, it must be as self-supervising as possible. Moreover, the system should be structured so that autonomous archives have an incentive to collaborate and share resources. Replication in our system is based on archives trading data under the principle of "I'll preserve your data if you preserve mine." These trades result in an archive network that self-organizes into a reliable system, self-tunes to improve efficiency, and self-heals after a failure. I'll discuss the architecture of the system, and techniques for making trades to achieve the highest reliability. Once data is replicated, there must be an efficient and robust mechanism to allow users to find important documents. Using a simple model of peer-to-peer search networks, we have discovered new and interesting network topologies, and also developed techniques for ad hoc networks, where a network can self-organize and self-tune to produce an efficient topology without external supervision. -- Brian Cooper PhD Candidate, Department of Computer Science, Stanford University cooperb@stanford.edu http://www-db.stanford.edu/~cooperb/ +----------------------------------------------------------------------------+ | This message was sent via the Stanford Computer Science Department | | colloquium mailing list. To be added to this list send an arbitrary | | message to colloq-subscribe@cs.stanford.edu. To be removed from this list,| | send a message to colloq-unsubscribe@cs.stanford.edu. For more information,| | send an arbitrary message to colloq-request@cs.stanford.edu. For directions| | to Stanford, check out http://www-forum.stanford.edu | +-------------------------------------------------------------------------xcl+ From decapita at ing.unibs.it Sun Feb 16 07:18:02 2003 From: decapita at ing.unibs.it (Sabrina De Capitani di Vimercati) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] CFP: 8th European Symposium on Research in Computer Security Message-ID: [Apologies if you receive multiple copies of this message] CALL FOR PAPERS 8TH EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY Gj?vik, Norway - October 13-15, 2003 Organized by Gj?vik University College Held in conjunction with Nordsec 2003 http://www.hig.no/esorics2003/ ---------------------------------------------------------------------- Papers offering novel research contributions in any aspect of computer security are solicited for submission to the Eighth European Symposium on Research in Computer Security (ESORICS 2003). Organized in a series of European countries, ESORICS is confirmed as the European research event in computer security. The symposium started in 1990 and has been held on alternate years in different European countries and attracts an international audience from both the academic and industrial communities. From 2002 it will be held yearly. The Symposium has established itself as one of the premiere, international gatherings on Information Assurance. Papers may present theory, technique, applications, or practical experience on topics including: - access control - network security - accountability - non-interference - anonymity - privacy-enhancing technology - applied cryptography - pseudonymity - authentication - security as quality of service - covert channels - secure electronic commerce - cryptographic protocols - security administration - cybercrime - security evaluation - data integrity - security management - denial of service attacks - security models - dependability - security metrics - firewalls - security requirements engineering - formal methods in security - security verification - inference control - smartcards - information flow control - steganography - information warfare - subliminal channels - intellectual property protection - survivability - intrusion detection - system security - intrusion tolerance - transaction management - language-based security - trustworthy user devices The primary focus is on high-quality original unpublished research, case studies and implementation experiences. We encourage submissions of papers discussing industrial research and development. Proceedings will be published by Springer-Verlag in the Lecture Notes in Computer Science series. INSTRUCTIONS FOR PAPER SUBMISSIONS Submissions must not substantially duplicate work that any of the authors has published elsewhere or has submitted in parallel to any other conference or workshop with proceedings. The paper must list all authors and their affiliates; in case of multiple authors, the contact author must be indicated (note that ESORICS does not require anonymized submissions). It should begin with a title, a short abstract, and a list of key words, and its introduction should summarize the contributions of the paper at a level appropriate for a non-specialist reader. The paper should be at most 15 pages excluding the bibliography and clearly marked appendices, and at most 24 pages in total, using at least 11-point font, reasonable margins, and page numbers on each page. Committee members are not required to read appendices; the paper should be intelligible without them. The document must be in either PostScript or Acrobat PDF format, and must be legible after printing on standard gray-scale printers, both those that use A4 and those that use 8-1/2x11" paper. Submissions not meeting these guidelines risk rejection without consideration of their merits. Authors are invited to submit their papers electronically. A detailed description of the electronic submission procedure will appear in FEBRUARY 2003 on the ESORICS 2003 submission page (http://www.hig.no/esorics2003/submit.html). Submissions must conform to this procedure and be received by APRIL 11, 2003 in order to be considered. Notification of acceptance or rejection will be sent to authors by JUNE 27, 2003. Authors of accepted papers must be prepared to sign a copyright statement and must guarantee that their paper will be presented at the conference. Authors of accepted papers must follow the Springer Information for Authors' guidelines for the preparation of the manuscript and use the templates provided there. The final copy of the paper may be no longer than sixteen (16) pages (which corresponds to approx. 8000 words in Springer LNCS style), unless otherwise arranged with the Program Chair. Last day for receipt of camera-ready copy for the proceedings is JULY 27, 2003. GENERAL CHAIR J?rn Wroldsen (Gj?vik University College, N) PROGRAM CHAIR Einar Snekkenes (Gj?vik University College, N) PROGRAM COCHAIR Pierangela Samarati (University of Milan, I) PUBLICATION CHAIR Dieter Gollmann (Microsoft Research, UK) PROGRAM COMMITTEE Tuomas Aura, Microsoft Research, UK Joachim Biskup, University of Dortmund, D T?nnes Brekne, Telenor, N Fr?d?ric Cuppens,IRIT, F Marc Dacier,EURECOM, F Herve Debar, France Telecom R&D, F Sabrina De Capitani di Vimercati, University of Milan, I Yves Deswarte,LAAS-CNRS, F Simon Foley, University College Cork, IE Dieter Gollmann, Microsoft Research, UK Trent Jaeger, IBM Research, USA Kaoru Kurosawa, Ibaraki University, J Heiko Mantel, DFKI, D John McHugh, CERT, USA Ken Moody, University of Cambridge, UK Stefano Paraboschi, University of Bergamo, I Birgit Pfitzmann, IBM Research, CH Avi Rubin, Johns Hopkins University, USA Peter Ryan, University of Newcastle upon Tyne, UK Pierangela Samarati, University of Milan, I Tomas Sander, HP, USA Einar Snekkenes, Gj?vik University College, N Michael Steiner, IBM Research, USA Paul Syverson, NRL, USA Michael Waidner, IBM Research, CH FOR MORE INFORMATION For details: http://www.hig.no/esorics2003 On-site arrangements: esorics2003info@hig.no General program information: esorics2003prog@hig.no From Ross.Anderson at cl.cam.ac.uk Thu Feb 20 07:01:02 2003 From: Ross.Anderson at cl.cam.ac.uk (Ross Anderson) Date: Sat Dec 9 22:12:20 2006 Subject: [p2p-hackers] Econmics and Information Security 2003 - Final Call for Papers Message-ID: Economics and Information Security Second Annual Workshop May 29-30, University of Maryland http://www.cpppe.umd.edu/rhsmith3/index.html Do we spend enough on keeping `hackers' out of our computer systems? Do we not spend enough? Or do we spend too much? For that matter, do we spend too little on the police and the army, or too much? And do we spend our security budgets on the right things? The economics of security is a rapidly growing field of research. More and more people are coming to realise that security failures are often due to perverse incentives rather than to the lack of suitable technical protection mechanisms. (Indeed, the former often explain the latter.) While much recent research has been on `cyberspace' security issues - from hacking through fraud to copyright policy - the field is expanding to throw light on `everyday' security issues at one end, and to provide new insights and new problems for theoretical computer scientists and `normal' economists at the other. In the commercial world, as in the world of diplomacy, there can be complex linkages between security arguments and economic ends. Program committee: Ross Anderson (program co-chair) (Cambridge University) Larry Gordon (program co-chair) (University of Maryland) Marty Loeb (general chair) (University of Maryland) Bruce Schneier (Counterpane) Jean Camp (Harvard) Doug Tygar (UC Berkeley) Li Gong (Sun Microsystems) Andrew Odlyzko (University of Minnesota) Hal Varian (UC Berkeley) If you would like to present a paper at the Workshop, please submit a detailed abstract (PDF format perferred) to Dr. Martin P. Loeb, General Chair by e-mail at mloeb@rhsmith.umd.edu by March 15, 2003. Last year's proceedings are available at: http://www.sims.berkeley.edu/resources/affiliates/workshops/econsecurity/ More information at: http://www.cl.cam.ac.uk/~rja14/econsec.html