[Mailman-Developers] Re: subscription confirmations (was Re: [Mailman-Users] [ANNOUNCE] Mailman 2.1 alpha 2)

[Gerald Oskoboiny]

On Sat, Jul 14, 2001 at 08:49:34PM -0700, Chuq Von Rospach wrote:
> On 7/14/01 4:32 PM, "Gerald Oskoboiny" <gerald@impressive.net> wrote:
> 
> > Regarding "I think they're wrong", I respect your opinion, but
> > the HTTP spec is the result of a decade of work on and experience
> > with HTTP by full-time web protocol geeks...
> 
> But web geeks are not necessarily user-interface or user-experience geeks.
> You can perfectly correctly build a nice system that's technically correct,
> but not right for the users.

Sure... I agree that it's possible for a standard to be irrelevant
or just not meet the needs of the users for which it was written.

But I don't think that is the case here: there really is a good
reason for this distinction between get and post, and it is widely
followed by popular sites *because* of the usability issues.
(I would like to back up my "widely followed" claim by doing a
survey of various popular sites, but don't have time today, and
probably won't until Friday at the earliest :( Anyway, I am
fairly confident that is the case.)

> > What if I have a smart system on my desktop PC that is configured
> > to prefetch any URLs it sees in my incoming email,
> 
> Given the number of viruses, spam with URLs and other garbage out there, I'd
> say you're foolish (bordering on stupid), but that's beside the point.

Either that, or I value my time more than that of some stupid machine's :)

Fetching a URL into my local http cache doesn't cause a virus to
be executed or anything else bad to happen, and I wouldn't use
software where that kind of thing would be possible anyway.

> It is
> an interesting issue, one I can't toss out easily; but I'm not convinced,
> either. I think it's something that needs to be hashed over, perhaps
> prototyped both ways so we can see the best way to tweak it.
> 
> Barry, what do you think about this instance? As the net moves more towards
> wireless, PDA, mobile-phone, stuff, could we be setting ourselves up for a
> later problem by ignoring this pre-cache issue Gerald's raised?
> 
> Gerald, does W3 have sample pages for "right" and "wrong" that can be looked
> at, or are we going to have to develop some? The more I think about this,
> the more I think it's  case where we ought to see if we can develop a
> prototype that follows the standards that we like, rather than toss it out
> at first glance. But if we can't come up with a system that we agree is
> 'easy enough', then we should go to what we're currently thinking.

I included pointers to all the stuff I could think of in my first message
in this thread, including a proposed implementation for mailman:
http://mail.python.org/pipermail/mailman-developers/2001-January/003579.html

If you think the docs on this subject at W3C are lacking, by all
means let me know.

Somewhat related, W3C recently published a note called "Common
User Agent Problems" <http://www.w3.org/TR/cuap> and it was
received quite well by the web community ("we need more of that
kind of thing", etc.) I think there is a plan to write a similar
one targeted towards site administrators, pointing out common
mistakes and raising awareness about little-known but important
RFC/spec details like this.

> > That would allow anyone in the world to sign me up for any
> > mailman-backed mailing list, whether or not I even see the email
> > confirmation requests. And that would be Mailman's fault, for
> > misusing HTTP GETs.
> 
> In disagree with this -- since as you say, any number of places already
> misuse GET, that usage is fairly common. A user who sets themselves up for
> it should know (or be warned by their mail client) that it has the
> possibility to trigger events. I'd say it's more a client issue than a
> Mailman issue. 

By "Mailman's fault" I meant that if mailman did this, it would
be the part of the equation causing problems by not abiding by
the HTTP spec. But this prefetching thing is just an example; the
main point is that the protocol has this stuff built in for a
reason, and there may be hundreds of other applications (current
and future) that need it to be there.

> And, thinking about it, since GET *can* do this, it's probably wrong for W3
> to push for it not to be used that way, because if things like your
> pre-caching system come into common use, the dark side of the net will take
> advantage of it, the way early virus writers took advantage of mail clients
> with auto-exec of .EXE's being on by default. So aren't you setting yourself
> up for problems by having a technology that can, even if you deprecate it,
> because it sets a user expectation that's going to be broken by those
> wanting to take advantage of it? I've got a bad feeling about this -- your
> example seems to set yourself up for abuse by those looking for ways ot
> abuse you, and that's a bigger issue than Mailman using it -- because if all
> of the 'white side' programs cooperate, it just encourages creation of
> things (like the pre-caching) that the dark side will take adavantage of.

I'm not worried about abuse, myself; I would have set this up on
my desktop system already if I had more time to hack it up...

> > But I'd be making this
> > argument whether or not that were the case, since it's clearly
> > the Right Thing to do imho...
> 
> And the more I think about it, the more it's an interesting point -- but on
> more than one level. Has W3c considered the implications of defining a
> standard that depends on voluntary acceptance here?

Which Internet standards *don't* depend on voluntary acceptance?

The HTTP spec (for example) just provides information on how HTTP
is meant to work. Then people who want to do the right thing have
a place to look up what the Right Thing is, and if there are ever
interoperability problems between different pieces of software,
people can check the spec and say "hey, look, you're doing this
wrong; see rfc nnnn, sec m.m; please fix." (and if that doesn't
work, there's always http://www.rfc-ignorant.org/ ;)

> Because the service you
> propose is unsafe unless you can guarantee everyone you talk to is
> compliant, and we know how likely that's going to be.

I disagree that it's unsafe; I don't especially want a bunch of
spam in my http cache, but don't really care about it, either.

-- 
Gerald Oskoboiny <gerald@impressive.net>
http://impressive.net/people/gerald/