[Mailman-Developers] Re: subscription confirmations

[Jay R. Ashworth]

On Tue, Jul 17, 2001 at 02:35:24AM -0400, Gerald Oskoboiny wrote:
> #     Naturally, it is not possible to ensure that the server does not
> #     generate side-effects as a result of performing a GET request; in
> #     fact, some dynamic resources consider that a feature. The important
> #     distinction here is that the user did not request the side-effects,
> #     so therefore cannot be held accountable for them.
> # 
> #     -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1
> 
> but once all that's been said, it's really up to the implementations
> to do the right thing.

It seems worth noting here that Zope makes this even worse: "procedure
calls" won't necessarily be POSTs *or* GETs.

> > > 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.
> > 
> > No, but it can cause actions you'll regret. You started this by bringing up
> > one as a problem. Now, however, you're saying "well, that's no big deal".
> > 
> > Which is it? No big deal? Or a problem? And if we can trigger actions you
> > might or might not like, you can bet it'll honk off others. And if we can
> > trigger actions, so can others, and those won't necessarily be innocent
> > ones.
> 
> If it happens once in a while with an obscure site here and there,
> that's much less of a problem than if some popular software like
> Mailman is doing the wrong thing and sending out tens or hundreds
> of thousands of these messages every day. (in part because every
> time one of these is used, it helps legitimize the practice of
> 'click this URL to unsub', which is the wrong message to be
> sending to people.)

Certainly.

> I don't expect all the incorrect implementations in the world to
> suddenly get fixed overnight, but I'm trying to get the ones I
> know about fixed.

But the problem here, Gerald, is that Chuq and I are having the "should
the standard actually say this in the real world" conversation, and
you're assuming that it should.  Chuq's asked you for your reasons why
you support this, him having given his... and so far, his outweigh
yours, for *me*.

> > One of the best things I think W3 could do in these cases is not only to
> > write "good" "bad", but generate cookbooks of techniques, with explanations
> > of why they're good, or why they ought to be avoided. Especially in the
> > subtlties of the standards that might not be intuitively obvious, or which
> > might be involved in emerging technologies (like wireless) that the typical
> > designer hasn't had time to worry about yet (or doesn't know to worry
> > about).
> 
> I agree this kind of thing needs to be done, but I think it can
> usually be done quite well by third parties, in online courses
> and articles, printed books, etc. But like I said above, I think
> W3C will start doing a bit more of this than we have in the past,
> it's just a matter of finding the time...

Um... *it's time*?  HTTP underlays half the planet.  Someone needs to
explain that to the people who pay the bills of the folks on the
committee.

> > >> 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?
> >
> > But there's a difference here -- we're talking about possible
> > security issues, not just whether someone adopts a tag.
>
> A bad implementation of a spec can always cause security problems.

Precisely our point.  Thank you.  :-)

> This distinction between GET and POST in the HTTP protocol is
> specifically there to *prevent* problems: if I make a stock trade
> using an online brokerage and then hit my browser's "back" and
> "forward" buttons, I don't want the same transaction executed again!
> That's why brokerages, banks, and other quality sites use POST for
> such transactions, and browsers written to the spec will prompt the
> user for confirmation before rePOSTing a form.

No, that's why anyone competent doing that sort of coding will put a
Transaction Sequence Number cookie in a hidden field in the form, and
bounce duplicate submissions.  Depending on the browser there is
another of those false senses of security Chuq was talking about
earlier.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015

   OS X: Because making Unix user-friendly was easier than debugging Windows
     -- Simon Slavin in a.f.c