Re: DRM of the mirror universe
On Tue, Apr 13, 2004 at 11:05:10PM +0300, Jani Nurminen wrote: > > But what content could the consumer-become-content-provider, the > ordinary person, you or me (let's call this actor the "user"), produce? > What could be interesting and rare for the corporation but found in > abundance from the user? One answer is personal data. > > Upon request by some corporation, the user decides to accept the > request. The user creates a DRM-protected file containing the personal > data the user wishes to reveal. When proper DRM technology is being used > (the same technology used to protect e.g. movies), the user can be sure > that the corporation is not able to > * use the personal data after the license period (e.g. 2 hours) has > expired > * share the personal data with third party companies without > permission > * do other non-authorized nasty stuff with the personal data DRM only works because the supplier of the content has itself certified the software used to process the content, or trusts the entity that has certified the software. Who would you trust to certify the software that some corporation will use to process your personal data? Another issue is that DRM works best to protect massive content. For example, whether you are HIV-positive is a single bit. How would you prevent me from capturing that bit from my screen with a camera? If the DRM prevents any association of your data with your identity, the data will not be worth much to me. Also, even assuming the DRM works, what prevents the user from presenting false data? The only data I can't lie about is what I generate as a side-effect of something else, for example a click-stream. But that's already available reliably to the server(s) now, without DRM. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Israeli coders, Arab testers
The fly in this ointment is that the testers (of whatever stripe) are being trusted to reveal all the flaws that they find. One way of assuring that is flaw injection, but it's imperfect, because you can never prove that failure to find the flaw was deliberate. The same problem applies to penetration tests, which is why hiring former felons to do it is not risk-free. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Wed, Oct 01, 2003 at 07:02:00PM -0700, bear wrote: > > Heh. You looked at my mail headers, didn't you? Yes, I use pine - > primarily *because* of that property. It treats all incoming messages > as text rather than live code. > > A protocol for text (as opposed to live code) requires compliant > clients (ie, clients that don't do anything other than display the > recieved messages). As such, it's at least somewhat a social issue. While I agree that text is far safer than html or a .exe, do you run Pine on a dumb terminal, or in a window? If the latter, escape sequences which most folks would class as "text" can lead to remote compromise. There have been occasional bugs in terminal emulators, in X and others. TERM=vt100 is in some sense defining an interpreted programming language, albeit a limited one. That absolute safety is impossible does not excuse software from our favorite vendor whose security model is all but impossible to fathom, so I'm not at all disagreeing with your point. I use Mutt. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Monoculture
On Wed, Oct 01, 2003 at 04:48:33PM +0100, Jill Ramonsky wrote: > > But I would like to ask you to clarify something about SSL which has > been bugging me. Allow me to present a scenario. Suppose: > (1) Alice runs a web server. > (2) Bob has a web client. > (3) Alice and Bob know each other personally, and see each other every day. > (4) Eve is the bad guy. She runs a Certificate Authority, which is > trusted by Bob's browser, but not by Bob. > Is it possible for Bob to instruct his browser to (a) refuse to trust > anything signed by Eve, and (b) to trust Alice's certificate (which she > handed to him personally)? (And if so, how?) The list of trusted certs is part of the browser config, and can be altered. It would be hard to imagine a browser so badly written as to hard-code that list. Certainly Mozilla makes it easy (Manage Certs under Privacy & Security in Edit Preferences) and I've even added a self-signed server cert under IE with no trouble or inconvenience. (Yes it did ask whether to accept the site's cert.) -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: New toy: SSLbar
On Wed, Jul 02, 2003 at 11:05:08AM -0700, James A. Donald wrote: > > In practice, if people were able to ensure they saw the same > cert every time they hit what is purportedly the same site, > this would take out most scams. What's wrong with the ssh known-hosts approach, for this? Do sites change certs more often than sshd changes host keys? Given how much crap browsers cache already, this wouldn't seem to add much. Of course it wouldn't help when using a public client host, but anybody doing that for confidential web access is wide open anyway. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
