Richard M. Smith talks about information flow. Passing information to Omniture. Forms that point to expired domain names. Frames, pictures, scripts that are redirected to Sitefinder.
A lot of information is sent to sitefinder.
Fundamental point: Why not run sitefinder as applet in a web browser? Do it at the client side.
Q: Interesting presentation, but falls into trap that happens a lot in Washington: Separating intentions from technology. Does Verisign have intent to collect information?
Q: Error message? Service! Maybe data can be used to improve service. A: There are alternative ways to implement typo-fixing service. Client side excellent. You avoid all the other issues then. Do it the right way.
Q: How is Verisign hiding who they are? A: Didn't say that. Q: Don't understand earlier point. ... A: Expired domain, Fred's cars. Verisign responds. Q: User deceived? A: No. Software sends data meant for Fred's cars to Verisign.
Q: Verisign not pretending to be someone else. Just receiving requests for someone else. A: On protocol level, they pretend.
Q: Stub mail server? Not very RFC-comopliant, 200-series for first pieces of data, then 550 for the third one. Verisign gets to read typoed e-mail? A: Verisign receives only envelope, not content. Q: What prevents them from taking entire address? A: Nothing.
Crocker: Somoe things observable, some not. Body does not go in there, that's observable. Matter of trust with non-observable things. Accepting messages would be observable change.
Q to Verisign: Some mail clients might be so dumb to submit mail body when recipients don't exist. Larson refers to author of RFC 2821. John Klensin responds. At least one widely-deployed client sends data, and only reports error when DATA fails. Crocker: ooops. Larson: Consider Wildcard MX to nonexistent target.
(Webcast interrupted.)
