On Sun, 8 Feb 2004, E.B. Dreger wrote: > SD> Instead of Doubleclick tracking users with Cookies, they > SD> would be able to track the unique computers from the MAC > SD> address in the reverse DNS record over time. > > A MAC address is six octets. Append time past Epoch when IP was > assigned; that's another four octets. Append six random octets. > Encrypt. Make hostname-friendly using %x equivalent. > > One now has 32 characters that contain the MAC address and time > the DHCP lease (or whatever) began, yet are meaningless to those > who lack the key. Consider periodically changing the six random > octets to protect users with long DHCP leases. > > It's extra hassle, but one can clearly have tracking _and_ > protect user privacy.
Again, why does an ISP need to spend the money and as you point out the extra hassle, to do this? ISPs already have all the information they need to trace a subscriber from the IP address and timestamp. Why does the ISP need to install Dynamic DNS servers, links between their RADIUS servers and the DDNS, and the databases to keep track of the which keys were used at which time. How long should ISPs be expected to maintain the keys to decode the DNS cookies. If someone wanted to know which subscriber was using an IP address in 1994, should that be possible? How long should the key length be to prevent people from cracking it years or decades later? Should ISPs provide the government copies of their keys so national security can keep track of the information. The privacy advantage of not using "DNS Cookies" is RADIUS logs only last as long as the ISP keeps them and there is nothing to crack. We made this mistake once already by having /etc/passwd files world-readable (encryption would protect the passwords). Don't repeat the mistake. If you suspect a particular computer, know the time, how long would it take to brute-force the remaining six characters? Technology is cool, but is this solving a problem?