Re: Possible optimization to State-Info proposal

Shel Kaphan:
>  [Bob Wyman:]
>  2. If you remove the requirement for forwarding of State-Info, you break
>  the ability of servers to use State-Info for click tracking. This is,
>  unfortunately, one of the applications that State-Info is supposed to
>  support. If it wasn't for click tracking, I would whole-heartedly support
>  your suggestion.
>
>Hmmm.  Bug or feature?  Personally I think statefulness is important
>enough to support well even if click tracking isn't supported by the
>same mechanism.  

General support for click tracking should be *separated* from
stateful dialog support mechanisms like state-info.

The reason for this is privacy: a user should have the option of
disabling the standard click tracking mechanism for *all* servers,
while still being able to choose to engage in a stateful dialog with
*some* servers (engaging in a dialog with a server implies allowing
that particular server to track clicktrails).

Dave proposes an `always do state-info/never do state info'
configuration option in browsers which would apply to all servers at
once.  I don't feel that this is a good enough solution to privacy
problems.

As a made-up statistic, under Dave's proposal, 90% of users will set
their browsers on `always do state-info', because they want to use at
least one stateful server on the web.  But by doing so, these 90% of
users allow 100% of server administrators (not just the administrator
of the stateful site the user is interested in) to gather clicktrail
statistics by using (abusing) the enabled state-info support in their
browsers.  60% of the 90% of users does not care about this, the
remaining 30% would have rather had a web protocol that would give
better privacy protection.

This abuse of stateful dialog support by server administrators to get
better statistics without offering a more interesting (stateful) site
in return is one of the main issues addressed in my `non-persistent
cookie proposal', posted here a some weeks ago.

I think I'll be posting a new version of this proposal in the near
future, even though Dave's changes to his proposal, and my
(non-published) changes to my proposal have made the two much more
similar than they were originally.  The only differences remaining are
privacy protection mechanisms and the requirement that caches always
forward state-info.

Koen.

Received on Friday, 25 August 1995 04:34:38 UTC