No privacy with DigiCash

One of the reasons we want http redirectors is so we could buy things
anonymously.  There is not much point in anonymous digital cash when your
web connections advertise who you are.

But, the current ecash implementation from DigiCash doesn't allow this
to work!  When you buy something, the vendor has to know your machine
name because he wants to connect back to your ecash wallet process.
So even if you did connect via a redirector, your anonymity would be
destroyed (or at least badly hurt) when you tell it your machine
name so it can connect to you.

This is a really bad way of doing it IMO because it seems to defeat
one of the big selling points of DigiCash.  Is there something I am
overlooking, some way to buy things privately with DigiCash?

Hal

> This is a really bad way of doing it IMO because it seems to defeat
> one of the big selling points of DigiCash.  Is there something I am
> overlooking, some way to buy things privately with DigiCash?

   I don't think so.  It appears that the initial implementation of 
DigiCash works exactly that way [based on what I've read on their W3 
server].  Of course, I could tell you more exactly had they replied to 
any of my four separate attempts to try it out ..

-jon
( --------[ Jonathan D. Cooper ]--------[ entropy@intnet.net ]-------- )
( PGP 2.6.2 keyprint: 31 50 8F 82 B9 79 ED C4  5B 12 A0 35 E0 9B C0 01 )
( home page: http://hyperreal.com/~entropy/ ]-------[ Key-ID: 4082CCB5 )

-----BEGIN PGP SIGNED MESSAGE-----

> When you buy something, the vendor has to know your machine
> name because he wants to connect back to your ecash wallet process.
> So even if you did connect via a redirector, your anonymity would be
> destroyed (or at least badly hurt) when you tell it your machine
> name so it can connect to you.
> 
> Is there something I am overlooking, some way to buy things
> privately with DigiCash?

Yes... at least one TCP/IP proxy system (socks) lets the client
receive incoming connections (the client makes a second connection to
the socks server, and the socks server informs it of the addr/port
that it's listening on; when a connection comes in to that port, the
two incoming connections are gatewayed to each other); that's how
socksified FTP works, by the way.

Things could get sticky if the server needs to make multiple
connections to the wallet at the same address (in sequence or in
series), but I'd imagine that this wouldn't be the case..

						- Bill


-----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBLveeD7T+rHlVUGpxAQFPmAP/SH8FVIKZJqt1OCTHamxmvILo2kEoz/GP
aObHB7X76QWOQXecicGcz/RCKQ7usoHzEI9+P8NkR1yCiZUVAmuK9lFR2YVcDW/Z
KkAglcoppBEQjf2bFhTH7D6W9uSLAYii5M0I0tNTUU61riruhn3akeJ0ur0E7Smw
xN+lKzXuRUo=
=Aiqk
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

Bill Sommerfeld writes, quoting me:
>> Is there something I am overlooking, some way to buy things
>> privately with DigiCash?

>Yes... at least one TCP/IP proxy system (socks) lets the client
>receive incoming connections (the client makes a second connection to
>the socks server, and the socks server informs it of the addr/port
>that it's listening on; when a connection comes in to that port, the
>two incoming connections are gatewayed to each other); that's how
>socksified FTP works, by the way.

I read about socks last night, and while it has some nice features I
don't know if it is suitable for a process which you want to have
persist and be able to accept connections on an ongoing basis.  With
socks, the ecash process would tell the socks server to open a listening
socket on its behalf.  Then when a connection comes in from a merchant,
it gets forwarded to the ecash process.

This is the problem: the socks server probably cannot generally get
the same port number as the ecash process.  I don't know if it even
tries.  So you have to note the port number.  Well, you have to do this
already because the ecash process may not get the port number it wants if
somebody else already has it.  But, with socks you only get one incoming
connection and then the socks server closes.  The ecash process would
have to request another listening socket each time it got a connection.
And each of those could have a different port number.  So this would be a
constantly changing bit of information that you would have to keep in
mind.

If the ecash process were integrated with the web client, this would not
be so bad, as the new port number could be supplied to the merchant
server automatically.  But with the current implementation this would
have to be done manually.

I was thinking of a socks-like model where you could have persistent
servers running behind a socks firewall.  The socks implementation is
really designed for ftp transfers, where the ftp server has to make a
connection back to the ftp client, and these are pretty transient.  For a
persistent server you would need a more complex structure.  Probably
there should be a persistent connection between your process and the
socks server, separate from a listening socket that your process sets up.
When a new connection comes in to the socks server for your machine, it
does a connection of its own to your listening socket.  Then there could
be multiple connections to your server active at one time.  The
persistent connection would just be a "lifeline" so that if your server
exited then the socks server would know to close down the proxy socket it
holds for you.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLvhTBRnMLJtOy9MBAQHSCAH8DEC7mPaFDNSRQ6bV5TMs75pRrYd6M7x5
4xlVpVq/K3jKm76wAhJVZou6Vx6lGCHwwwYb3kU0CeE33SkPyzHJrA==
=ILoI
-----END PGP SIGNATURE-----