June 2002 - cypherpunks-legacy

Re: maximize best case, worst case, or average case? (TCPA)
by lynn.wheeler＠firstdata.com 30 Jun '02

30 Jun '02

"security modules" are also inside the swipe & pin-entry boxes that you see at check-out counters. effectively both smartcards and dongles are forms of hardware tokens .... the issue would be whether a smartcard form factor might be utilized in a copy protection scheme similar to TCPA paradigm .... a single hardware chip that you register for all you applications .... or in the dongle paradigm .... you get a different smartcard for each application (with the downside of the floppy copy protection scenario where a user with a half dozen active copy protected applications all wanted "their" smartcard crammed into the same smartcard reader simultaneously). many of the current chipcards .... i believe are used in the magnetic stripe "swipe" mode for authenticating specific transactions .... most of the rest are used for password substitute at login type events. Many of the chipcards following the straight payment card model result in end-user having large number of different institutional tokens (similar to the floppy copy protect paradigm). Following the institutional-specific and/or application-specific token paradigm starts to become difficult to manage as the number of tokens increase and the probability that multiple are required simultaneously increases. That eventually leads into some sort of person-centric or device-centric paradigm .... not so much an issue of the form factor (floppy, chipcard, dongle, etc) .... but an issue of whether there are potentially large numbers of institutional/application specific objects or small numbers of person/device specific objects. So a simple issue is the trade-off between the institutional/application specific objects .... which seem to have some amount of acceptance (payment cards, chip cards, various "dongle" forms, etc) but in many instances can scale poorly ... especially if multiple different such objects have to be available concurrently .... vis-a-vis switching to a person/device specific object paradigm (chipcard, dongles, etc, potentially exactly same formfactor but different paradigm) ryan(a)havenco.com on 6/30/2002 12:39 pm wrote: I think dongles (and non-copyable floppies) have been around since the early 80s at least...maybe the 70s. Tamper-resistant CPU modules have been around since the ATM network, I believe, in the form of PIN processors stored inside safes) The fundamental difference between a "dongle" and a full "trusted module" containing the critical application code is that with a dongle, you can just patch the application to skip over the checks (although they can be repeated, and relatively arcane). If the whole application, or at least the non-cloneable parts of the application, exist in a sealed module, the rest of the application can't be patched to just skip over this code. Another option for this is a client server or oracle model where the really sensitive pieces (say, a magic algorithm for finding oil from GIS data, or a good natural language processor) are stored on vendor-controlled hardware centrally located, with only the UI executing on the end user's machine. What I'd really like is a design which accomplishes the "good" parts of TCPA, ensuring that when code claims to be executing in a certain form, it really is, and providing a way to guarantee this remotely -- without making it easy to implement restrictions on content copying. It would be nice to have the good parts of TCPA, and given the resistance to DRM, if security and TCPA have their fates bound, they'll probably both die an extended and painful death. I suppose the real difference between a crypto-specific module and a general purpose module is how much of the UI is within the trusted platform envelope. If the module is only used for handling cryptographic keys, as an addition to an insecure general purpose CPU, with no user I/O, it seems unlikely to be useful for DRM. If the entire machine is inside the envelope, it seems obviously useful for DRM, and DRM would likely be the dominant application. If only a limited user IO is included in the envelope, sufficient for user authentication and keying, and to allow the user to load initially-trusted code onto the general purpose CPU, but where the user can fully use whatever general purpose code on the general purpose CPU, even uncertified code, with the certified module, it's not really useful for DRM, but still useful for the non-DRM security applications which are the alleged purpose behind TCPA. (given that text piracy doesn't seem to be a serious commercial concern, simply keeping video and audio playback and network communications outside the TCPA envelope entirely is good enough, in practice...this way, both authentication and keying can be done in text mode, and document distribution control, privacy of records, etc. can be accomplished, provided there is ALSO the ability to do arbitrary text processing and computing outside the trusted envelope, .) If it's the user's own data being protected, you don't need to worry about the user intentionally circumventing the protections. Any design which removes control from the 'superuser' of the machine is fundamentally about protecting someone other than the user. This, I think, is the difference between TCPA and smartcards. Notice which one has in its short lifetime attracted far more enmity :) Quoting lynn.wheeler(a)firstdata.com <lynn.wheeler(a)firstdata.com>: > > > I remember looking at possibility at adding tamper resisistent hardware > chip to PCs back in 83 or 84 time frame (aka the TCPA idea for PCs is going > on at least 20 years old now). It was the first time I ran into embedding > chip in a metal case that would create electrical discharge frying the chip > if the container was breached. > > Remember when applications came with their own copy-protection floppy > disks? .... it was possible to build up a library of such disks .... > requiring all sorts of remove, search, insert ... when switching from one > application to another. They eventually disappeared ... but imagine if they > had survived into the multitasking era .... when it would have been > necessary to have multiple different copy protection floppy disks crammed > into the same drive at the same time. The chip was suppose to provide an > analog to the CPU serial number used for licensing software on mainframes > .... dating at least from the original IBM 370s (store cpuid hardware > instruction). > > Some of the higher-end applications still do that with some form of dongle > (originally in the serial port) that comes with the application .... it > doesn't quite have the downside of trying to cram multiple floppies into > the same drive concurrently; the serial port dongles allow for them to be > inline cascaded ... and in theory still be able to use the serial port for > other use at the same time. > > i believe that there is some statistic some place about the UK and the US > are really great .... that in those two countries the copyright piracy is > estimated to only be 50 percent. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan(a)havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

2 1

RE:
by yongdong＠earthlink.net 30 Jun '02

30 Jun '02

<HTML> These teens are so incredibly luscious your monitor will start smoking. Best of all NO CREDIT CARD NEEDED! <A HREF="http://rd.yahoo.com/dir/?http://www.evolveporn.com/abc123">Click Here</A> To be removed from further mailings <A HREF="mailto:browneyedqt28@aol.com">Click Here</A></HTML> Below is the result of your feedback form. It was submitted by hung (yongdong(a)earthlink.net) on Sunday, June 30, 2002 at 07:53:06 --------------------------------------------------------------------------- x: i ---------------------------------------------------------------------------

1 0

Re: maximize best case, worst case, or average case? (TCPA)
by Ryan Lackey 30 Jun '02

30 Jun '02

I think dongles (and non-copyable floppies) have been around since the early 80s at least...maybe the 70s. Tamper-resistant CPU modules have been around since the ATM network, I believe, in the form of PIN processors stored inside safes) The fundamental difference between a "dongle" and a full "trusted module" containing the critical application code is that with a dongle, you can just patch the application to skip over the checks (although they can be repeated, and relatively arcane). If the whole application, or at least the non-cloneable parts of the application, exist in a sealed module, the rest of the application can't be patched to just skip over this code. Another option for this is a client server or oracle model where the really sensitive pieces (say, a magic algorithm for finding oil from GIS data, or a good natural language processor) are stored on vendor-controlled hardware centrally located, with only the UI executing on the end user's machine. What I'd really like is a design which accomplishes the "good" parts of TCPA, ensuring that when code claims to be executing in a certain form, it really is, and providing a way to guarantee this remotely -- without making it easy to implement restrictions on content copying. It would be nice to have the good parts of TCPA, and given the resistance to DRM, if security and TCPA have their fates bound, they'll probably both die an extended and painful death. I suppose the real difference between a crypto-specific module and a general purpose module is how much of the UI is within the trusted platform envelope. If the module is only used for handling cryptographic keys, as an addition to an insecure general purpose CPU, with no user I/O, it seems unlikely to be useful for DRM. If the entire machine is inside the envelope, it seems obviously useful for DRM, and DRM would likely be the dominant application. If only a limited user IO is included in the envelope, sufficient for user authentication and keying, and to allow the user to load initially-trusted code onto the general purpose CPU, but where the user can fully use whatever general purpose code on the general purpose CPU, even uncertified code, with the certified module, it's not really useful for DRM, but still useful for the non-DRM security applications which are the alleged purpose behind TCPA. (given that text piracy doesn't seem to be a serious commercial concern, simply keeping video and audio playback and network communications outside the TCPA envelope entirely is good enough, in practice...this way, both authentication and keying can be done in text mode, and document distribution control, privacy of records, etc. can be accomplished, provided there is ALSO the ability to do arbitrary text processing and computing outside the trusted envelope, .) If it's the user's own data being protected, you don't need to worry about the user intentionally circumventing the protections. Any design which removes control from the 'superuser' of the machine is fundamentally about protecting someone other than the user. This, I think, is the difference between TCPA and smartcards. Notice which one has in its short lifetime attracted far more enmity :) Quoting lynn.wheeler(a)firstdata.com <lynn.wheeler(a)firstdata.com>: > > > I remember looking at possibility at adding tamper resisistent hardware > chip to PCs back in 83 or 84 time frame (aka the TCPA idea for PCs is going > on at least 20 years old now). It was the first time I ran into embedding > chip in a metal case that would create electrical discharge frying the chip > if the container was breached. > > Remember when applications came with their own copy-protection floppy > disks? .... it was possible to build up a library of such disks .... > requiring all sorts of remove, search, insert ... when switching from one > application to another. They eventually disappeared ... but imagine if they > had survived into the multitasking era .... when it would have been > necessary to have multiple different copy protection floppy disks crammed > into the same drive at the same time. The chip was suppose to provide an > analog to the CPU serial number used for licensing software on mainframes > .... dating at least from the original IBM 370s (store cpuid hardware > instruction). > > Some of the higher-end applications still do that with some form of dongle > (originally in the serial port) that comes with the application .... it > doesn't quite have the downside of trying to cram multiple floppies into > the same drive concurrently; the serial port dongles allow for them to be > inline cascaded ... and in theory still be able to use the serial port for > other use at the same time. > > i believe that there is some statistic some place about the UK and the US > are really great .... that in those two countries the copyright piracy is > estimated to only be 50 percent. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan(a)havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

TCPA/MS
by Dave Howe 30 Jun '02

30 Jun '02

Phil Youngblood posted the following to the securecomp server - thought it might interest people here, given the recent discussion of M$'s DRM stuff... -------------------------------------------------- This from the Eula for the latest Windows Media Player patch. * Digital Rights Management (Security). You agree that in order to protect the integrity of content and software protected by digital rights management ("Secure Content"), Microsoft may provide security related updates to the OS Components that will be automatically downloaded onto your computer. These security related updates may disable your ability to copy and/or play Secure Content and use other software on your computer. If we provide such a security update, we will use reasonable efforts to post notices on a web site explaining the update.

1 0

videotaping = liar & cheat?
by Major Variola (ret) 30 Jun '02

30 Jun '02

At 08:16 PM 6/29/02 +0200, Anonymous wrote: >When an artist releases a song or some other creative product to the >world, they typically put some conditions on it. If you want to listen >to and enjoy the song, you are obligated to agree to those conditions. >If you can't accept the conditions, you shouldn't take the creative work. > >The artist is under no obligation to release their work. It is like a >gift to the world. They are free to put whatever conditions they like >on that gift, and you are free to accept them or not. > >If you take the gift, you are agreeing to the conditions. If you then >violate the stated conditions, such as by sharing the song with others, >you are breaking your agreement. You become a liar and a cheat. First, What's your point? This list does not require that participants agree with anyone else's sense of ethics. This list often considers the effect of tech on civilization, but you are not required to endorse (or recognize, or scorn) civilization. This list often discusses certain ethics by themselves, but nothing is taken for granted, and the timid/naif may be a little frightened by this. Second, it is quite clear, even to contract-law/laissez-faire types like myself, that some DRM-interested companies are attempting to use the law to remove some rights from consumers (about gadgets and bits and RF). Many of us have a maniacally dim view of such manipulation. Third, if you don't get understand why some people are driven to understand technology, you should probably go back to your TV. > When someone makes you an offer and you don't find the terms >acceptable, you simply refuse. You don't take advantage by taking what >they provide and refusing to do your part. And you don't sue someone for what users of their product do.

1 0

Re: Ross's TCPA paper
by Barney Wolff 30 Jun '02

30 Jun '02

Do you really mean that if I'm a business, you can force me to deal with you even though you refuse to supply your real name? Not acceptable. I won't give up the right NOT to do business with anonymous customers, or anyone else with whom I choose not to do business. The point about DRM, if I understand it, is that you could disclose your information to me for certain purposes without my being able to make use of it in ways you have not agreed to. At least in theory. But this debate appears largely to ignore differences in the number of bits involved. To violate your privacy I can always take a picture of my screen with an old camera, or just read it into a tape-recorder. I can't do that effectively with your new DVD without significant loss of quality. I don't see any technical solution that would enable Alice to reveal something to Bob that Bob could not then reveal to Eve. If that's true, then DRM must stand on its own dubious merits. On Wed, Jun 26, 2002 at 10:01:00AM -0700, bear wrote: > ... > > Privacy without DRM means being able to keep and > do whatever you want with the records your business > creates -- but not being able to force someone to > use their real name or linkable identity information > to do business with you if that person wants that > information to remain private. -- Barney Wolff I never met a computer I didn't like.

3 5

Re: Uplifting Brin
by R. A. Hettinga 30 Jun '02

30 Jun '02

--- begin forwarded text

1 0

FREE Adult Passes
by seung-wo＠hotmail.com 30 Jun '02

30 Jun '02

<HTML> I found this site that has the ultimate XXX pics that are FREE! They change every 60 minutes with totally NEW PICs. This site is so awesome I had to tell you! <A HREF="http://rd.yahoo.com/dir/?http://www.evolveporn.com/123blue">Click Here</A> To be removed from further mailings <A HREF="mailto:browneyedqt28@aol.com">Click Here</A></HTML> Below is the result of your feedback form. It was submitted by hugh (seung-wo(a)hotmail.com) on Sunday, June 30, 2002 at 06:49:13 --------------------------------------------------------------------------- x: i ---------------------------------------------------------------------------

1 0

maximize best case, worst case, or average case? (TCPA)
by Ryan Lackey 30 Jun '02

30 Jun '02

[summary: "TCPA is a tool which even if not necessarily always used for DRM applications, and other far more evil applications, is dangerous enough that it must be killed to prevent the introduction of, and legal mandate for, these DRM and other more evil applications. People should be prepared to make some sacrifices to accomplish this goal."] (long rambling exposition follows: overview, possible worlds, possible means of resistance, my suggested integrated course of action) I-I. The current TCPA argument is, I believe, the beginning of a three staged war, with the ultimate potential loss being all freedom. It is much bigger than the issues of security for applications or of copyright. A conspiracy does not need to have conscious participation by all parties; those with knowledge of the entire situation can do enough simply by failing to act at key points, rather than taking affirmative action. Completely valid agendas can be piggybacked in order to get other aims accomplished. I-II. Yet, as much as I hate the idea of TCPA, the concept behind it has a few legitimately useful security applications I can see, and has been something I've thought about for years in a specific area. While there's a good debate about TCPA with respect to general purpose computing, that kind of "the secure hardware module IS the company" computing is a useful model for some specialized tasks. Hardware crypto modules which allow general purpose computation already operate in this mode, and as long as the architecture is open (device certified by one authority, code published and signed, secure and deterministic/duplicable toolchain, certain device functionality like "publish hash of executing program" available, users choose which hardware modules, software vendors, etc. they trust), it can be a tool for good. Admittedly a tool which can be easily perverted for evil. Being able to secure the entire platform on which a given piece of code is executing, and to publish guarantees about that security to users at a distance who will have reason to trust those guarantees, is undeniably useful for a certain class of applications. Ironically, some of these applications themselves are key to liberty. I-III. DRM systems are obviously something a lot of media execs lust after, even out of proportion to the commercial realities, since they inherently like control and hard ownership. I'm sure most content creators at the direct creation level would rather see more users for the same profit; non-creative people in the industry of creation would prefer to see the same revenue from a smaller population, as it leaves a larger potential untapped marketplace. DRM systems embedded in general purpose computers, especially if mandated, especially if implemented in the most secure practical manner (running the system in system-high DRM mode and not allowing raw hardware access to anything at any time on the platform, rather than trying to allow concurrent open and closed operation a la CMW), and in a closed manner for revenue protection purposes (only rich people get to sign the code, or at least only the keys of rich people are widely distributed by default, and anything else requires special operations by the user), are evil. (There's the whole debate about the role of copyright, piracy, content ownership, etc., which I doubt will be resolved any time soon, and I think tying it too closely to the TCPA/DRM/etc. debate is dangerous, as the intermediate results might suck a lot -- hopefully the copyright and general economic restructuring debate will take a lot longer than this particular issue of hardware restrictions) I-IV. Aside from the issues of legitimate security, and DRM, there's a third hidden agenda behind the restriction of general purpose computing hardware -- the removal of a very powerful tool from the public at large. While not stated even by the paranoids :) who claim TCPA is obviously a wedge for DRM, it seems the logical conclusion. Large commercial enterprises, governments, and the like have a fear of everyone in the world having tools of the same power; for the most part, a single laptop computer is effectively the same as the sum of all other machines in the world, for many critical applications. Auto companies would certainly be displeased by a $5 trivially distributed tool to create cars, just add water, at basically zero marginal cost; without means of protecting their franchise from limitless competition, commoditization, and decentralization, companies need to compete based on speed and agility of innovation. There is no economy of scale in that, indeed, massive diseconomies of scale. General purpose computers are the equivalent of "just add water" (or beer, or chemical of choice) and produce products and services. As such, they should rightly terrorize any organization which does not compete purely by being the best, most dynamic, most innovative competitor, any organization which uses its current position in the world to try to maintain control over the future, in a static way. That would seem to be the very definition of a government, or of large commercial or non-commercial organizations. All of the "evil" applications of computers, like anonymous communications, could easily be eliminated by requiring a true-name identity for all code, and optionally only certifying Approved applications at some future date. A more practical way of accomplishing roughly the same thing is requiring that all communications have true names attached, or some kind of potential tracing, built in at the low level, rather than requiring every high-level application to be certified; the key escrow battle of years ago can be retroactively lost in this manner -- just make identity info be included on all transactions, and then have a master key to break the crypto on the processor) II. Five possible worlds II-I. 1. As I see it, the best outcome would be for TCPA to just go away right now, after some kind of mass public rejection, similar in motivation to the marketplace rejection of intel processor serial numbers, etc. However, if it just disappears without being soundly defeated and the territory sown with salt, it will come back in a couple years. 2. A moderately tolerable case would be if TCPA is implemented in a completely open way, and simply not used except by highly specialized applications (not even commercial rights-management, but user-specified actions like operating a "wallet agent" or whatever). If it is simply so crude and annoying to use as to be commercially unviable, but still distributed and used occassionally for a while, that would be this case. This would be TCPA as the HP/etc. people claim it is intended, although there are strong arguments that this is not the real motivation. DivX (old version) would fall somewhere between this and #3; a failure in the marketplace vs. unencumbered technologies. 3. What would suck, but not completely, is if it is used extensively for rights management on commercial content, such that third-party media can be manipulated in compliance with a (possibly broken, but not en masse) DRM scheme, but user-created, or Free content, can also be processed easily, and in parallel. The system can be used with the equivalent of "self signed keys" or whatever fairly easily, without requriing reboots, and a viable distribution strategy exists for such content. Pirated/liberated versions of formerly closed content could be redistributed effectively, and it's up to pricing/market/users/etc. whether to use a pirated copy or a DRM licensed copy. (defense against piracy would be focused solely on preventing legitimate copies from being used illegitimately, not on preventing post-liberation content being distributed/used). This is effectively how DVDs work today, given that CSS and RPC are widely defeated, and DivXes are available. 4. A bit worse would be if TCPA can only be used by rebooting the system, or even requiring completely independent hardware (but still sold through mainstream channels, and not a black market). The inconvenience of this would make using any non-DRM-managed media (either user-created, or products of cracking the DRM system by a few technically elite users, and then distributed to less informed users) basically impractical; it would be an all or nothing, DRM or Open, option. The best case form of this is the DRM system being constrained to a set top box, and the "media convergence" dying; it's really just going back to 1980 and staying there. In this case, DRM is used by default on most systems, and affirmative and complex user action is required to turn it off temporarily. All-or-nothing. Liberated copies of licensed content are enough of a pain to use to force licensed content for most users, but DRM is also applied of necessity to even legitimate-source content, lowering overall functionality. This is "defense in depth" for preventing media piracy; preventing liberated versions of content from being used effectively. This is basically the same as distributing DivX if RPC 2 becomes highly effective in the future. 5. The worst case would be TCPA mandated everywhere, in the most restrictive way, with a fairly impotent resistance to this, and basically no trusted secure computational devices in the wild (#5). There are issues far more important than copyright at stake when the right to own a general purpose computing device fully under the user's control is lost. The DRM can be used to enforce other restrictions later, unrelated to copyright -- only identity-linked document creation is permitted, just like with high quality photocopiers or CD duplication; only those with government licenses can use certain kinds of tools, etc. This is the dystopia of Gibson. People would smuggle in illicit pre-ban CPUs just like they do with firearms today; instead of automatic weapons buried in the back yard, parents could pass on to their children a hermetically sealed case of Intel Pentium IIIs. About the best outcome of this is that criminals would pay for the services of hardware hackers, and hacking on hardware would be as cool as cooking drugs is today, which might over time draw the right kind of people into electrical engineering programs. (and imagine protest songs, 60s style or ghetto gangsta rap style, extolling the virtue of a particular kind of logic gate or op amp) II-II. As I see it, we could put all efforts into maximizing the chances of #1, even though it may increase the odds of (4,5) vs. (1,2,3). Or, we could put all effort into preventing #5, even if that increases the chances of (2,3,4) vs. (1). What I'm genuinely in terror of is #5. I'd be fairly comfortable with (1,2) from philsophical grounds (and actually, some of the uses in #2 are things which interest me). 1,2,3 are probably tolerable even from a wanting-widespread-piracy standpoint, and really, anything but #5 (and to some extent, #4) is tolerable in terms of protecting computers for anti-government use. Also, this is by no means a one-time challenge. If we get #2 to start, it seems likely there will be an eventual slide toward #5, unless there is some kind of great line in the sand beyond which they cannot cross. As we've seen with the continual erosion of explicitly protected liberties over the past century or two, this seems ultimately futile unless there are powerful and commercial interests constantly defending these liberties. (This is why religion, and to a lesser extent press freedoms, have won out over gun rights) Unfortunately the powerful commercial entities may be on the wrong side of this one, unless everyday business views this as a loss of control over critical IT infrastructure. II-III. As for actual approaches which could accomplish various strategies: A) A public protest to "shun" TCPA as evil seems most likely to accomplish 1 or 2, although if it fails, 3, 4, 5 are of unchanged likelyhood (perhaps 5 would be a bit harder). Focusing on the "they want to take certain powers away from the user of the computer" argument is sufficient for individuals, but TCPA could co-opt businesses by claiming some of that power will be put into the hands of MIS; a different argument would need to be made for corporate users. B) Simply making the tools for DRM be inconvenient will mostly confine it to #1 or #2, but UIs improve over time, so this is impermanent. C) Focusing on killing the Hollings bill, etc. would reduce chances of 5, but would seem to leave the other options as unchanged. D) Good DRM technical circumvention measures can make 1, 2, 3 pretty much isomorphic. (analog: the drug war, with draconian regulations circumvented by brave Men of Commerce and Chemistry). This is betting on the difficulty of the DRM problem, and the incompetence of the implementing teams; maybe a good bet for a while, but by the time they get to 3.0, it would be a difficult challenge. E) Good open-source and open-content can make 1, 2, 3, 4 the same as 1, by ensuring users turn off TCPA and simply refuse to use anything protected by TCPA. Truly effective piracy technology can do the same thing for licensed content, but it would need to be so good that all content is created by third parties, not by the licensed owners, much like mp3 and divx today for most users.) A world where #4 is tempered only by the strength of piracy isn't all that satisfying since some people have a moral need to obey the law. F) Some kind of agreement by the majority of users to simply obey basic anti-piracy anti-circumvention anti-encryption etc. practices, in exchange for no technical restrictions. This seems unlikely; ultimately people like getting free media, a lot, and it can become a tragedy of the commons. Also, this battle is initially about security, then about DRM, but then, I believe, ultimately about getting the most powerful weapon in the modern world, general purpose computing hardware, out of the hands of the populace. This would eliminate the demand for DRM on the part of the copyright holders G) Elimination of copyright as a legal concept, obviating the issue of legal protection for copyright. This would eliminate option #5, and make #1-3 highly likely; it becomes a pure technical battle, and that is one the free world can win. However, this does nothing to address the non-DRM reasons for wanting this technology; preventing "evil" applications on general purpose hardware. H) Option 5 is probably so distasteful as to make it impermanent; if it passed, any responsible citizen would resort to the canonical soap, ballot, jury, ammo progression (although, given temperaments, not necessarily in that order.) The mass of distributed hardware and information would make resistance most effective immediately after passage of legislation; once secure hardware is taken away, secure communications will wither, which makes organizing effective resistance difficult. One might question the sanity of being willing to escalate to the barricades to defend one's right to secure, anonymous, private, communications, but I think it is a legal and ethical obligation, once all other avenues are exhausted, of every citizen of a free country. III. III-I. So, I think my take on all of this is that it's worth doing the following: * Trying to kill TCPA/DRM right away, through public protest, shunning everyone involved with to any degree (boycott of all products which include it, at least when viable alternatives exist, products of companies which are involved with it or have other products which implement it, etc. Promotion in the press of all the potential evil of scenario #5, and focusing the debate on #1 vs. #2,3,4,#5 as much as a binary choice as possible) * Promote and publicize failures of TCPA/DRM systems to the extent possible; emphasize any serious losses of security, privacy, control, etc. Try to come up with byzantine failures specifically to shake public confidence in the systems. The WTC-aftermath Windows XP lockouts are a good example. "Why we don't have automobiles with speed governors centrally set to <max speed limit> -- because sometimes there are overriding legitimate reasons to break the law". People have an inherent revulsion to having power taken away from them, even if they never used that power in the past, and would be unlikely to do so in the future; this should be marketed. * Technical circumvention of all DRM mechanisms to render them impotent, and make them as intrustive/annoying as possible to be effective, so as to be commercially unviable. Ideally people wouldn't even watch DRM-protected movies, but I think as long as no revenue is received by the offenders, it should be ok (if there's a war, you don't engage in commerce with the enemy, but stealing all their resources is a good in and of itself) This mitigates the actual harm done if TCPA/DRM are adopted by vendors, without compromising the TCPA vs. no-TCPA debate. This also shakes vendor faith in DRM/TCPA systems. * Shadow distribution networks for original and "liberated" content to the extent possible, such that it is EASIER to get warezed versions of all content, make use of them, etc., than to use the legitimate option. DRM actually helps with this, to the extent that it makes full use of legitimately purchased media as difficult as possible. The risk is of course good circumvention and distribution networks can be used as arguments for TCPA/DRM by the enemy; however, this shifts the argument into #1,2,3,4 vs. #5 space, which is good. * Vigorous protest, with unlimited escalation potential, against the Hollings bill and any future bills, using all required means. Preventing world #5 is my absolute highest goal, so as to keep the battle in the technical arena where better software can solve the problem, and where general purpose hardware is retained as a tool for other, more important wars as well. * A social agreement among all reasonable people to not make use of TCPA or DRM in their applications; to not require links to real-world identity to operate their systems; to allow anonymity, security, privacy, etc. wherever possible. The sacrifice is not using general DRM-capable security technologies even if for non-DRM applications, to make those DRM-capable systems ineffective in the marketplace. This is *WAY* more evil than using MS IE-specific HTML tags, or requiring SSNs for database keys, but the short-term benefits are probably greater...this will be difficult. * Obviously, don't work for companies or organizations which intend to develop TCPA or DRM applications, or which advocate their legal enforcement. * Stockpile effective munitions, cryptographic and otherwise, against the worst case option #5. * Develop ways to do the few good things TCPA could do with technologies not so easily perverted for evil. Distributed, decentralized systems; security-specific coprocessors, simply minimizing the amount of private information required and collected at the original point of interaction, rather than trying to protect it once collected, etc. * The ultimate copyright and intellectual propery debate, which will likely not be resolved for decades. III-II. However, I'm not sure of a few things: * Is it worth making applications actively hostile to TCPA? Doing this risks making your application less widely used, and might make the legitimate TCPA version win. I think the best compromise is to allow the user to do what he wants, but to ensure no revenue or other advantage goes to the TCPA/DRM deploying organization...maybe if the damage is greater than the payment it would be acceptable too. Maybe DRM cds should be playable, but by ripping the DRM cd and distributing unencumbered mp3s at the same time. This is probably an individual question based on the market position of the official vs. resistance application. * To what extent does having a viable technical circumvention system in place both reduce the intensity with which people will fight the imposition of controls (since they don't matter in practice), and support arguments by the enemy for harsher DRM systems and legal mandates * To what extent is the loss of efficiency/security/etc. to large companies not affiliated with DRM/TCPA/restriction of computing by having those technologies deployed outweighed by the advantages to the enemy organizations? A slight improvement for major powerful organizations, at the cost of the destruction of some relatively powerless organizations, is probably going to go ahead; whereas castrating some important but not dominant organizations may not be acceptable, even if it results in a slighr improvement for more powerful organizations. However, I think big companies will all fall into the "use regulation to prevent competition" camp, and thus support the technology, even if they don't benefit from DRM. Plus, political lobbying is non-linear; if people care less than a certain amount, they have no voice at all. * Just how dead do you need to kill this idea to make sure "Never Again"? At a minimum I want the glowing wasteland left to be so bad that people won't even think about going near similar ideas for a long time, and that anything even remotely comparable will have as one of the first debates "why this isn't like TCPA". * Some of the steps suggested can make it impossible for anything like TCPA/DRM/neutered computing from being effective in the future, if implemented. What additional steps can be undertaken to make sure even if a similar thing passes in the future, it will have no effect? This would seem to require removing whatever powers would be used to implement these restrictions; SCOTUS rulings or constitutional ammendments would be sufficient, as would be some kind of "arsenal of democracy" to defend against such things. Clearly the Traditional Cypherpunk Applications are needed now, more than ever, as a check against the powers of evil. -- Ryan Lackey [RL7618 RL5931-RIPE] ryan(a)havenco.com CTO and Co-founder, HavenCo Ltd. +44 7970 633 277 the free world just milliseconds away http://www.havenco.com/ OpenPGP 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F

1 0

Mortgage Rates At An All Time Low
by jasminechick＠desertmail.com 30 Jun '02

30 Jun '02

1 0