Re: DRM of the mirror universe

2004-04-14 Thread Barney Wolff
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

2004-04-01 Thread Barney Wolff
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

2003-10-02 Thread Barney Wolff
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

2003-10-01 Thread Barney Wolff
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

2003-07-02 Thread Barney Wolff
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]