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

Re: State, when to use GET, and accountability

From: Jacek Kopecky <jacek.kopecky@deri.org>
Date: Fri, 02 Mar 2007 12:23:53 +0100
To: noah_mendelsohn@us.ibm.com
Cc: David Orchard <dorchard@bea.com>, www-tag@w3.org, www-tag-request@w3.org
Message-Id: <1172834633.32351.180.camel@localhost>

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

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