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 Friday, 2 March 2007 11:24:16 UTC