Re: Photographer Arrested For Taking Pictures Of Vice President'S Hotel
Declan McCullagh wrote: Also epic.org (not a cypherpunk-friendly organization, but it does try to limit law enforcement surveillance) [...] Is the cypherpunks movement truly so radicalized that it is not willing to count even EPIC among its friends?
Re: Transparent drive encryption now in FreeBSD
Tyler Durden wrote: Sorry, I'm new, but does this refer to the notion of splitting up a document holographically, and placing the various pieces of numerous servers throughout the 'Net? No. It is referring to conventional encryption of your local hard disk.
Re: Cryptogram: Palladium Only for DRM
AARG! Anonymous wrote: Lucky Green wrote: In the interest of clarity, it probably should be mentioned that any claims Microsoft may make stating that Microsoft will not encrypt their software or software components when used with Palladium of course only applies to Microsoft [...] First, it is understood that Palladium hashes the secure portions of the applications that run. [...] With that architecture, it would not work to do as some have proposed: the program loads data into secure memory, decrypts it and jumps to it. The hash would change depending on the data and the program would no longer be running what it was supposed to. I think Lucky is right: Palladium does support encrypted programs. Imagine an interpreter interpreting data, where the data lives in the secure encrypted vault area. This has all the properties of encrypted code. In particular, the owner of the machine might not be able to inspect the code the machine is running. If you want a more concrete example, think of a JVM executing encrypted bytecodes, or a Perl interpreter running encrypted Perl scripts. For all practical purposes, this is encrypted software. Whether this scenario will become common is something we can only speculate on, but Palladium does support this scenario.
Re: Seth on TCPA at Defcon/Usenix
AARG! Anonymous wrote: His description of how the Document Revocation List could work is interesting as well. Basically you would have to connect to a server every time you wanted to read a document, in order to download a key to unlock it. Then if someone decided that the document needed to un-exist, they would arrange for the server no longer to download that key, and the document would effectively be deleted, everywhere. Well, sure. It's certainly how I had always envisioned one might build a secure Document Revocation List using TCPA or Palladium. I didn't realize this sort of thing would need explaining; I assumed it would be obvious to cypherpunk types. But I'm glad this risk is now clear. Note also that Document Revocation List functionality could arise without any intent to create it. Application developers might implement this connect to a server feature to enforce some seemingly innocuous function, like enforcing software licenses and preventing piracy. Then, after the application has been deployed with this innocuous feature, someone else might eventually notice that it could also be used for document revocation. Thus, Document Revocation List functionality could easily become widespread without anyone realizing it or intending it. This is a risk we should make think about now, rather than after it is too late.
Re: Thanks, Lucky, for helping to kill gnutella (fwd)
R. A. Hettinga wrote: [Ob Cypherpunks: Seriously, folks. How clueful can someone be who clearly doesn't know how to use more than one remailer hop, as proven by the fact that he's always coming out of the *same* remailer all the time? I hope I don't need to point out that always using the same exit remailer does *not* prove that he is using just one hop. One can hold the exit remailer fixed while varying other hops in the path. Your question seems to be based on a mistaken assumption about how remailers work.
Re: responding to claims about TCPA
AARG! Anonymous wrote: In fact, you are perfectly correct that Microsoft architectures would make it easy at any time to implement DRL's or SNRL's. They could do that tomorrow! They don't need TCPA. So why blame TCPA for this feature? The relevance should be obvious. Without TCPA/Palladium, application developers can try to build a Document Revocation List, but it will be easily circumvented by anyone with a clue. With TCPA/Palladium, application developers could build a Document Revocation List that could not be easily circumvented. Whether or not you think any application developer would ever create such a feature, I hope you can see how TCPA/Palladium increases the risks here. It enables Document Revocation Lists that can't be bypassed. That's a new development not feasible in today's world. To respond to your remark about bias: No, bringing up Document Revocation Lists has nothing to do with bias. It is only right to seek to understand the risks in advance. I don't understand why you seem to insinuate that bringing up the topic of Document Revocation Lists is an indication of bias. I sincerely hope that I misunderstood you.
Re: Challenge to David Wagner on TCPA
James A. Donald wrote: According to Microsoft, the end user can turn the palladium hardware off, and the computer will still boot. As long as that is true, it is an end user option and no one can object. Your point is taken. That said, even if you could turn off TCPA Palladium and run some outdated version of Windows, whether users would object is not entirely obvious. For instance, suppose that, thanks to TCPA/Palladium, Microsoft could design Office 2005 so that it is impossible for StarOffice and other clones to read files created in Office 2005. Would some users object? I don't know. For many users, being unable to read documents created in a recent version of Office is simply not an option. However, in any case we should consider in advance the possible implications of this technology.
Re: DRM will not be legislated
AARG! Anonymous wrote: David Wagner wrote: The Hollings bill was interesting not for its success or failure, but for what it reveals the content companies' agenda. The CBDTPA, available in text form at http://www.politechbot.com/docs/cbdtpa/hollings.s2048.032102.html, does not explicitly call for legislating DRM. What's your point? If you think the CBDTPA wasn't about legislating DRM or something like it, we must be from different planets. I'll elaborate. CBDTPA delegated power to the FCC to specify standards that all digital devices would have to implement. It is not at all surprising that CBDTPA was drafted to allow the FCC great freedom in choosing the technical details as necessary to achieve the bill's objectives. It is equally clear that supporters of the bill were pushing for some mandatory Fritz chip, do-not-copy bit, Macrovision protection, copy protection, or other DRM-like technical measure. This issue is not going away quietly.
Re: DRM will not be legislated
Anonymous wrote: Legislation of DRM is not in the cards, [...] Care to support this claim? (the Hollings bill and the DMCA requirement for Macrovision in every VCR come to mind as evidence to the contrary)
Re: Piracy is wrong
Anonymous wrote: Piracy - unauthorized copying of copyrighted material - is wrong. http://www.gnu.org/philosophy/words-to-avoid.html When an artist releases a song or some other creative product to the world, they typically put some conditions on it. Don't overlook the fact that when the government gives an artist a limited monopoly through copyright, the government retains some rights (e.g., fair use) to the public, whether the artist likes it or not.
Re: Ross's TCPA paper
Scott Guthery wrote: Perhaps somebody can describe a non-DRM privacy management system. Uhh, anonymous remailers? I never disclose my identity, hence there is no need for parties I don't trust to manage it. Come on, folks. This ought to be cypherpunks 101. DRM might be one way to achieve privacy, but it is not the only way. One simple way for me to ensure my privacy is simply never to disclose my personal information. There's no DRM here. Sure, maybe we could envision some alternate world where I disclose my personal information in return for some promise from Big Brother to protect my personal information with DRM, but this doesn't mean that DRM is the only way to achieve privacy!
