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
-----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-----
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 )
participants (3)
-
Bill Sommerfeld -
Hal -
Jonathan Cooper