W3C home > Mailing lists > Public > www-tag@w3.org > March 2007

Re: State, when to use GET, and accountability

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 1 Mar 2007 16:55:16 -0500
To: Jacek Kopecky <jacek.kopecky@deri.org>
Cc: David Orchard <dorchard@bea.com>, www-tag@w3.org, www-tag-request@w3.org
Message-ID: <OF8B3AF013.CA9B0DD0-ON85257291.0077E0F6-85257291.00786DC5@lotus.com>

Well, I think the language about incurring obligations is in any case 
subject to pretty subtled differences of interpretation, so I think you're 
right to call me on that.

Jacek Kopecky writes:

> I assume the resources with reliable logging would be authenticated
> (otherwise the log would be unreliable). By logging in, the user would
> agree to the logging of their actions (that would be in the conditions
> of acquiring an account) and therefore no new obligations would be
> incurred with those GETs.

I think the crucial things about GET include that it's cacheable, raising 
the possibility that someone would get data from a cache without that 
access being logged, and also that user agents, spiders, etc. are free to 
issue GETs ahead of any explicit request by the user.  In your 
formulation, that seems to raise the risk that I would log on, and view 
web page 1, but that my user agent would quietly retrieve Web page 2 as 
well.  An audit would show that it had been accessed on my behalf, which 
might or might not be what you want.  Operations like POST have the 
characteristic that they tend to make it to the origin server, and in that 
sense offer a more reliable building block for creating audit trails.

So, while I don't disagree that you can make a case that I've agreed to 
certain things socially by "logging on", particularly if the logon page 
says I do, I'm not convinced that opens the door to assuming that GET will 
reliably have the side effect of updating an audit trail.  Of course, 
there's nothing wrong with having a server keep logs of GET requests that 
happen to make it that far, but I don't think you can assume that those 
are 1:1 with GETs issued by the user, logged on or otherwise.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------






        Jacek Kopecky <jacek.kopecky@deri.org>
        Sent by: www-tag-request@w3.org
        03/01/2007 04:27 PM 
                 To: noah_mendelsohn@us.ibm.com
                 cc: David Orchard <dorchard@bea.com>, www-tag@w3.org
                 Subject: Re: State, when to use GET, and accountability



Noah, 
the current definition of safety from the AWWW document talks about not
*incurring* obligations. In particular, "If an agent does not have an
obligation before a safe interaction, it does not have that obligation
afterwards." 

I assume the resources with reliable logging would be authenticated
(otherwise the log would be unreliable). By logging in, the user would
agree to the logging of their actions (that would be in the conditions
of acquiring an account) and therefore no new obligations would be
incurred with those GETs.

Please correct me if I'm wrong, but as far as I can see, this is a
useful view of safety. In particular, I can't see anybody triggering
anything they shouldn't do by using, let's say, a web accelerator that
opportunistically pre-fetches links.

Best regards,
Jacek

On Thu, 2007-03-01 at 14:53 -0500, noah_mendelsohn@us.ibm.com wrote:
> Dave:  I know you're collecting ideas for the finding on State in Web 
> application design.  One aspect of this that I understand is coming up 
> increasingly is the legal need in many contexts for certain enterprises 
to 
> reliably record every access that is made to certain data.  In such 
cases, 
> an obligation of a sort is implicit in every access, and presuming HTTP 
> GET in particular is inappropriate.  I think this is a real world issue 
> for many users of Web technology.  I'm thinking it might be the basis of 

> an interesting use case, though I'm somewhat on the fence as to whether 
it 
> fits better in the whenToUseGET space.  The fact that there are side 
> effects of the access seems to be whenToUseGet, but I imagine that in 
many 
> cases it will be important to record not just that an access has 
occurred, 
> but also information about the higher level interaction (session?) in 
> which the access occurs.  That might bring a tie in to the state 
finding.
> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
Received on Thursday, 1 March 2007 21:55:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:51 UTC