On Tue, 17 Jul 2001 21:08:59 -0400 barry@digicool.com (Barry A. Warsaw) wrote:
I was pulled away on other work for most of the day, but I think I've caught up with the whole thread.
On the micro-issue of what Mailman's ttw confirmation should do, I am much more swayed by Thomas's observation that we can actually add useful value by providing a form that allows the user to confirm or discard his request. Given that I agree with everything Chuq et al have said about the inherent insecurity of GET, that seemed to me a more persuasive argument as it pertains narrowly to Mailman.
Unless someone wants to volunteer to do usability studies (for which I don't have the time), I propose to change confirm.py to POST a form, and to pull in the ability to cancel held postings and subscription requests. Good idea Thomas.
But I definitely appreciate the discussions Gerald initiated, and I'm glad he did that. Hopefully, Gerald can bring the very valid concerns raised here before the W3C and the standards authors. I think they're vitally important to where the web is going. The security and privacy of the web has such a deservedly poor reputation, what with JavaScript and Java vulnerabilities (and the increasing number of sites that are simply unnavigatable without them), client-side trojans, web bugs, hijacked ActiveX certificates etc. etc. I really wish browser vendors would err on the side of security and privacy than on convenience. Sucker the user in enough times, or sucker enough of them in and the web will not be able to recover.
-Barry
This whole controversy might be my fault -- I don't know the pedigree of Barry's implementation, but I'd submitted a confirm-by-visiting-this-URL patch several months ago. Hey, what can I say? it was a quick hack. But since it was implemented I don't think I've had one I-can't-follow-the-instructions-to-confirm exchange with a cluefully-challenged proto-subscriber; neither have I had a single complaint about misuse of GET.
The discussion has been thought-provoking. I'm not entirely swayed to the position that it's morally wrong to use GET in this case, where repeating the GET doesn't have any effect beyond what was caused by the first. But Barry has a good point, that Thomas' idea adds value. IMHO it's a much better UI -- no matter how much text surrounds it, a URL in email isn't as clearly delineated as a big fat button in the middle of a web page. Having a "don't confirm" button also is even better. And regardless, using POST instead of GET is a fairly simple change. From a pragmatic point of view, there's not much reason not to comply with the published standard, even if its justification is weak. (This is not to devalue the discussion and debate of the W3C's position.)
-les