Re: session-id redux (resend)

[This seems to have disappeared from the queue; apologies if it shows up
twice.  Regarding Thomas Maslan's message, I also often get beheaded
messages from this list.]

>I suspect that I will end
>up with session-munged-URLs even though I believe this to be a fools path.
[...]
>My point, and the original poster's, was that this group may wish to see
>that ad-hoc solutions to session issues are not in the best interest of
>the web and should be addressed.

Yes, 'session-munged-URLs' are "broken" and "bad" and "ugly" and all the
rest.[1]  They also have the unfortunate side effect of getting the
immediate job done, which is why they keep popping up.  The quoted
conclusion above is right on target -- the ad-hoc solutions will persist
until they are obsolete, so let's make them obsolete (that is, let's not
give up on this, okay?).

All of the privacy concerns raised over SIDs could just as easily be raised
over SID-munged-URLs.  The 'naive' user -- the one who leaves "Show
Location" off in their browser, or who browses in "Novice" mode -- won't
see the munginess of the URL, or may not recognize a munged URL as any
uglier than a plain-old URL.  Perhaps their expectation of privacy has been
raised by a "Dateline"[2] piece on anonymous remailers and anonymity on the
Internet.  They fill out a survey, go somewhere else on the site, and look
at anarchist pamphlets thinking their requests are still anonymous.  There,
that's a privacy violation.  Maybe site A munges a URL to site B, so B gets
the SID A used, and A can give B the marketing info about that user.
(Roy's point about sharing between sites.)  That's another privacy
violation.

I don't mean to sound mocking.  I completely agree that there are privacy
concerns with some of the SID proposals.  I just don't think current
practice is one bit better.  Therefore, the "no action" alternative seems
to me just as insidious[3] as the worst SID proposal.  If we can provide
privacy protections in a standard implementation, and then IMPLEMENT that
standard, there will be no reason for ugly URLs, and the alert user can
steer away from sites that still use them.  ("This is your URL.  This is
your URL on SIDs...")

A while back someone asked what was so wrong with the Netscape Cookie
proposal.  A long-delayed response: it doesn't tell the user what it's
doing.

Marc Hedlund <hedlund@best.com>

[1] <URL:http://www.amazon.com/> does this "bad" "ugly" "broken" thing as
well as it can be done, by throwing the session-ID (SID) into PATH_INFO --
if PATH_INFO contains garbage, assign a new SID.  A clean break, at least:
it uses PATH_INFO for (gasp) its intended purpose.

[2] Sensationalist U.S. news show.

[3] No pun intended.

Received on Wednesday, 26 July 1995 17:50:58 UTC