Re: State, when to use GET, and accountability

I'm not concerned so much with cases in which a cache is being used on 
behalf of a single user of HTTP;  my real concern was about shared proxy 
caches, which are quite common.  With those, you might request some 
information using HTTP GET, and your access would be appropriately 
recorded at the origin server.   My concern is with the case in which I 
come along to request the same information, but a proxy cache somewhere in 
the network satisfies the request without contacting the origin server. My 
access is likely not recorded, except in the unusual special case that the 
proxy and the origin server are cooperating on maintaining the audit 
trail.

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








Jacek Kopecky <jacek.kopecky@deri.org>
03/02/2007 06:23 AM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     David Orchard <dorchard@bea.com>, www-tag@w3.org, 
www-tag-request@w3.org
        Subject:        Re: State, when to use GET, and accountability


Noah, 
what I'm saying is that my limited experience gives me no example where
an one more or less GET would actually be harmful in any way. 
If I get it from cache, I'm not getting anything new above what I had
already downloaded (of course, cache setting private assumed here); and
if my user agent gets something that I don't end up viewing, I can't see
how anybody could have an issue with it.

For example a doctor viewing patient data. We don't need to have a log
that the doctor retrieved it twice in a day (when the second GET uses
the cache). And I don't expect that a patient record will have a link to
"next patient" and "previous patient", which would introduce spurious
"the doctor viewed the data of these other patients" if their browser
downloaded it opportunistically.

I guess we're actually in agreement in principle, just differing in our
estimate of the use cases; I say estimate because no concrete scenarios
have been presented in this short thread yet.

Best regards,
Jacek

On Thu, 2007-03-01 at 16:55 -0500, noah_mendelsohn@us.ibm.com wrote:
> 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 Monday, 5 March 2007 17:40:39 UTC