See also: IRC log
VQ: Any regrets for next week?
<DanC> checking calendars for 25 Oct, timbl
<timbl> k
Roy at risk for next week
Next week's scribe: Dave Orchard
<Roy> yep, regrets for Oct 25 (SNA to DFW)
VQ: let's do the computer misuse topic first, so Henry can participate
<DanC> I found noah's analogy to signs and doors quite good.
Noah thanks Dan for the encouragement
DC: let's add issue 37 at end of today's agenda
VQ: comments on last week's minutes? http://www.w3.org/2005/10/11-tagmem-minutes.html
... Noah said OK, anyone else?
??: me too
VQ: Propose to approve minutes of last week.
RESOLUTION: Minutes of telcon of 11 October 2005 at http://www.w3.org/2005/10/11-tagmem-minutes.html are approved
<timbl> [1] http://www.theregister.co.uk/2005/10/11/tsunami_hacker_followup/
<timbl> [2] http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1
VQ: This was raised on the public TAG list at http://lists.w3.org/Archives/Public/www-tag/2005Oct/0019.html
<timbl> http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html
VQ: Is this from British Law?
TBL: Well, it came in part from a case decided in a British court.
... If Henry's not available, I can summarize my understanding. Disclaimer: I don't know this first hand, and there seem to be inconsistent rumors going around.
... This is all hearsay pending a look at official court records.
... It's alleged that a person used http://donate.bt.com/tsunami/relief to donate to the Tsunami. I think he'd used lynx.
<ht> donate.bt.com
TBL: He got no response and got suspicious that he had been victim of phfishing
<ht> The actual law in question is http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1
TBL: He tried appending /../../../ to see if the site was legitimate.
... He was convicted and fined 1000 pounds including costs, even though the judge acknowledged there was no malice.
... We have to said that doing a GET should always be "safe"
<ht> HST has also failed to find a full transcript
TBL: There is some suggestion that the judge thought the accused changed his story, which might or might not cloud the evaluation of this particular case
... There is a strong sense in which being fined is "unsafe"
... Perhaps the question is whether he was doing something intentionally to "hack" the site.
... He got an error, but it was the ISP that had a trigger on URIs of that form and flagged it.
... The URI spec clearly points out the danger of using more levels of ../.. than there were /'s in the original
NM: Were there more in this case?
TBL: yes
HT: Really, I'm surprised.
... Checking
<timbl> 5.4.2. Abnormal Examples
<timbl> Although the following abnormal examples are unlikely to occur in
<timbl> normal practice, all URI parsers should be capable of resolving them
<timbl> consistently. Each example uses the same base as that above.
<timbl> Parsers must be careful in handling cases where there are more ".."
<timbl> segments in a relative-path reference than there are hierarchical
<timbl> levels in the base URI's path. Note that the ".." syntax cannot be
<timbl> used to change the authority component of a URI.
<timbl> "../../../g" = "http://a/g"
<timbl> "../../../../g" = "http://a/g"
<timbl> Specifically, he accessed the page
<timbl> http://donate.bt.com/tsunami/relief/../../../
TBL: So, he did go one level above.
HT: did you get this from my message.
<timbl> http://news.zdnet.co.uk/internet/security/0,39020375,39226548,00.htm <http://news.zdnet.co.uk/internet/security/0,39020375,39226548,00.htm>
<timbl> ^ zdnet articles by John Airey
<timbl> by Colin Barker and Graeme Wearden
<DanC> (is much more background essential? can we move on to discussion of what the TAG should agree on, if only that previous things we've agreed on apply here?)
<timbl> http://news.bbc.co.uk/1/hi/england/london/4255591.stm
RF: To the extent this information comes from The Register, we should be careful about drawing conclusions as to what happened and whether we have all the details.
TBL: I've put a link to a short BBC article
<ht> http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1
HT: I've posted the link to the law in question.
<DanC> <ht> The actual law in question is http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1
HT: it's at http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1
... The pertinent portion is:
... 1.—(1) A person is guilty of an offence if—
(a) he causes a computer to perform any function with intent to secure access to any program or data held in any computer;
(b) the access he intends to secure is unauthorised; and
(c) he knows at the time when he causes the computer to perform the function that that is the case.
HT: The quotes I've seen so far don't really answer the question.
TBL: I heard that he did not succeed in accessing the system.
HT: Doesn't matter.
TBL: But he didn't actually "cause" the computer to do anything
HT: But even the error code counted as getting it to do something
<timbl> Do not click here: ______________
TBL: So if we have a link that says "Member Only" and a non-member clicks it, they're guilty under this law
HT: Yes, see section 17 which says:
<DanC> good example, timbl... a link labelled [member only]. if anybody clicks on one of those, they break this law
Scribe fell behind and could not transcribe Henry's quote of section 17. You can follow the link.
HT: I think that we should consider doing something, but not quite clear what.
... Deep linking is pertinent. But there's no issue here of intentionally passing on the link, so that's different.
... Note also that this law predates the Web, and seems to me to be contrary to what we'd like for Web architecture.
<Roy> http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html
HT: How to do that, I don't know, and I'm afraid I have to leave.
VQ: This is going to be a legal issue.
... As a legal problem, this feels to me more like a W3C issue then a TAG architectural issue.
... There may be a possibility of clarifying Web architecture, but I'd like to keep the legal and architectural issues separate.
... Legal issues should be W3C-level; the architectural part is ours.
<Zakim> timbl, you wanted to talk about deep linking. Yes, this isvery bad because it would allow people to put arbitrary constraints on what you have to have done befroe following a
TBL: I think this is important and we in the TAG should do something to make the technical part clear. What the W3C does is another question.
... this relates to deep linking insofar as deep linking is saying "here are the rules for using my links", and it relates to the question we're discussing now.
<Zakim> DanC, you wanted to say that the architecture question I hear is: true or false: it's always authorized to ask a server the "GET /any_path" question; i.e. it's not unauthorized to
TBL: regardless of whether anything happens with this case, we should go right up to the line in saying how we think things need to work on the Web.
DC: For the court to key on a code like 400 or 500 seems wrong, because that's what's telling you the status of the resource.
TBL: but the form he used was well known on certain servers as a security flaw. Similar forms on those servers give access to /etc/passwd
... there are details of the case where you can argue about motivation
... the law seems not to require him to succeed in unauthorized access, only to try
<timbl> .../../../etc/passwd
DC: I claim doing a GET doesn't count as trying
TBL: you could argue that he should have known that doing this would be a way to compromise the system. Rumor has it that some viruses are exploiting this as a hole in some systems.
... So, this is a suspicious thing to do.
... He represented himself, supposedly, as someone who knew how to crack sites, or so I've heard.
... By the way, suggesting that anyone would attack a site after carefully id'ing himself with his credit card does seem improbable
... Still, we need to look at court records before drawing conclusions
... There may be differences between doing a GET, and doing a GET for something you know is subject to exploitation
<DanC> (I'm reminded of the Schwartz case. http://www.lightlink.com/spacenka/fors/ )
TBL: do you want to protect the world from doing something that is reasonable in the architecture, but at another level is known specifically to be a source of system exploitation?
<DanC> (I don't think crawlers try random URIs. they follow links from seeds.)
<timbl> Noah: In general, it is true that you can make any commitment or be in trouble for anything for doing a GET. One can argue about the intent.
<timbl> ... If the URIs were more opaque,this would not be possible.
<timbl> ... We should encourage people to keep them opaque.
<timbl> .. Maybe this case -- we don't know -- we don't have the records -- is an exception.
NM: I think the right answer is that doing a GET is presumed OK, just as walking in the door of a business at midday on a weekday is presumed OK.
... Doing a GET is only a problem if you have malicious intent, or could have been reasonably expected to know that your access would cause trouble. Analogy: trying the door of a business at 3AM may be presumed malicious, depending on the circumstance.
... This case is a bit tricky insofar as some are suggesting that the person in question may have known that the URI being used could be the basis of a system exploit.
... On a separate note, I find the relationship between this question and the opacity of URIs to be interesting. Hierearchical URIs are non-opaque; there's a heuristic that says adding /.. will get you to a related real world resource.
Someone: crawlers don't use ../
Crawlers don't have permission to try things up the hierarchy of a hierachical URI? I find that surprising.
<Roy> The article claims he entered "../../../" with Safari. The current version of Safari will translate that to "/" before any message is sent to the server.
<timbl> At one point lynx was mentioned.
RF: We've worked with browser developers for some time to get them to do this stuff on the client. I've just tried Safari and it doesn't actually send the ../'s to the server.
... I want to say again that we should get the court records to find out what happened before we do anything. I suspect that more happened than we've heard. In fact, I suspect he may have used telnet.
TBL: One article suggested lynx.
RF: If lynx did that, it was on old copy. Lynx is the most likely thing that would actually send that to a server.
VQ: Let's move on
... Let's try to find out more details
... Can someone volunteer to find the facts, and if possible the court records?
... Tim, what about folks in the technology and society domain.
TBL: Well Henry's not here, but he's in the right time zone. maybe we should ask him. The T&S domain is a possibility.
VQ: Well, I'm not in Britain, but I can try and talk to people who may be able to point me in the right direction.
<scribe> ACTION: Vincent to try and get official information about the Computer Misuse Act case referenced in http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html [recorded in http://www.w3.org/2005/10/18-tagmem-irc]
VQ: Dave, could you summarize discussion of your draft?
DO: I published a rough start to a TAG finding on state ( http://lists.w3.org/Archives/Public/www-tag/2005Oct/0025.html )
... I followed the same banking scenario through several designs including, stateless, cookie-based, web services using WSA EPRs.
... I discussed a bit about making such an EPR available as a URI, focussing on the customer key as an example
... I showed 4 or 5 examples of different bindings to URIs, and even to HTTP cookies
... Previous to that I had some definitions of "state", and I got comments on those.
... I had a section on architectural properties of stateful vs. stateless wrt/ performance, reliability, ease of use, security, etc.
... I want to get 2 things out of the finding: 1) bring in the architectural issue about state and relationship to web services, giving guidance on choices 2) also want to talk about EPR issus
VQ: Dan had an action to review what Dave posted
DC: I got hung up on state definition stuff and didn't go much further
<Zakim> noah, you wanted to ask about finding vs. response to WSA
<Zakim> Roy, you wanted to explain why "Roy Fielding argues in his REST dissertation [1] that stateless server has the benefits of increasing reliability, scalability, visibility and while
<Roy> http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_4_3
NM: Seems to me the time urgency is on deciding whether to respond to the WSA drafts; doing a finding on state will take time and seems lower priority
RF: See link to my dissertation. Dave references it. Having a discussion of all these things is useful, but I'm not sure Dave's draft is careful enough about separating, e.g. session state from application state.
... You quote my dissertation as arguing that stateless servers has advantages. That's not what I said. I said that having stateless interaction models trades off gains in security, manageability etc. for network performance, since we tend to pass around things like cookies.
... Working on this seems like a good thing to do. Also suggest putting in some state transition diagrams to illustrate where state is in various scenarios.
DO: I hear you, but there's no quick answer I can give right now.
VQ: getting back to Noah's question...
... I'd like feedback on whether we should respond to WSA.
DO: I think we've agreed that figuring out what to do is high priority.
... I put this out as something to support that, and as something that would live longer.
<Zakim> noah, you wanted to say that the finding may be useful, but is not a fast way to get to decision on WSA
<dorchard> Roy, I agree with all you said.
<dorchard> Definitely want to do STDs but I couldn't find my copy of visio...
NM: I think that by looking at this as a finding, we're discussing some things that are not critical do deciding a WSA response, such as the definition of state.
DO: OK, I guess that's so.
VQ: So, what do we want to respond to WSA?
DC: We have a one line version that's too short, and a long version that's too long, though I can live with one line version.
... I don't feel urgency of replying to WSA.
<Roy> (more links for background follow)
<Roy> http://f-m-c.org/projects/apache/html/2_5Session_Management.html
TBL: no urgency to WSA?
DC: I still like the short version.
... But Dave said we had to do a lot more, and we can't do that in a week.
<DanC> recalling the proposal: "Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them.
NM: well, I though we were close to asking them to put a note in their Rec, and it's late in the process. IF we are asking them to change the Rec, then I think we have to fast track that advice, or else make a quick decision not to ask for anything.
... Giving other advice on how to use the Rec after it's published we can do in a more leisurely way.
DO: I'm not sure that short advice saying "don't do that" isn't useful.
... I think there is stuff missing that would help people follow the guidance we'd like to give them.
... I don't know how to say "don't do bad things" if we don't tell them how.
DC: I'm not sympathetic to that. I just want to be sure that whatever we ask for can be understood.
... first point, do no harm.
TBL: maybe if we explain the constraint, then the design can get done
... if you can say what needs to be designed, we don't necessarily have to it.
<DanC> (yes, they can do the design, they being app developers. if patterns emerge, they might be worth standardizing)
NM: this doesn't give advice, it states a (purported) fact: doing X is contrary to Web Arch.
... Maybe or maybe not the reader feels that matters in his or her case
VQ: I hear less support for the short statement
NM: I think I can support it.
TBL: Remind me where it is.
Copying: "Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch"
TBL: If we said that, and then said that we realize that current tools may not make it easy to do things that way, e.g. because of dispatch issues...
... ...would it work to do that and not propose a solution?
DO: That makes me a bit more comfortable, in that it acknowledges current reality.
TBL: I want to refer to "current web services implementations"
DO: I'd prefer implementations and technologies
<timbl> Specifically the way current WS implementations dispatch on URIs
TBL: I have problem with the word technology
<DanC> "deployed technologies" perhaps? "widely available technologies"
DO: I think you've got it. You could imagine new specifications for QName to URI mapping, etc., that would upon implementation in software enable that.
<timbl> "Defined, agreed way of doing things?"
<DanC> (or old specifications, such as RDF ;-)
TBL: If the problem is just the way the server is built, that it doesn't allow the same program to be called with the same URI, then it's going to be difficult.
... that's an example of lack of implementation flexibility.
DO: I think it's both. Standards can help, but you don't always need them.
<Zakim> noah, you wanted to talk about SOAP
<DanC> (this discussion between timbl and daveo is a very rushed version of reviewing a state finding. I'm more inclined to do it slowly. I think the TAG undercuts itself when we make proclamations that don't have well-argued justifications.)
<timbl> if the problem is just the way the server is built, that it doesn't allow the same program to be called for many many DIFFERENT uris (of differenet objects), then it's going to be difficult to use the URI as an object identifier
NM: Well, I think it is technology and implementation. The SOAP Recommendation is what these folks are implementing, and it says to dispatch on QNames of elements. The issue is that those mechanisms make sense for things like DSIG headers, but people are now trying to stretch that for identification-related dispatching.
... I think it's legitimate that they build implemenatations that follow naturally from the SOAP Recommendation.
DO: My position is unchanged. People are building software to SOAP and related specs that is the natural software for those specs. I think there is in sufficient technology now set out to make it practical to make Web Resources of all the things now identified with EPRs.
... I'm willing to make that one sentence "contrary to Web Arch" statement,but only if we acknowledge that the current state of things makes it hard to in fact integrate with Web Arch in some important cases.
... I'd like the TAG to spend some time helping to find the technologies that would help make those resources available on the Web.
... That's the sort of goal the TAG should undertake.
VQ: I'm getting less optimistic...
<DanC> would timbl accept an action to write his proposal in email to www-tag?
<DanC> ... and discuss it for the next week or so
DO: I think we're actually getting close. If you start with TBL's formulation and mix in some of Noah's observations on SOAP headers, that might be OK. Then again, I'm not yet sure exactly what text we'd ask them to change.
... I like your suggestion to ask Tim to take an action.
DC: one to two paras?
Noah thinks the measure of success is to know specifically what we're asking WSA to put >into their REC<.
VQ: what about sending a line or two that we'll tune up this week in email discussion.
TBL: worried about the total of my TAG commitments
DC: the WSA stuff seems urgent
NM: my end of the CDF review is coming this afternoon, if that will give Tim a leg up on his?
TBL: where are pieces of text?
<DanC> let's record the action and adjourn to give tim 2 minutes of quiet
VQ: in the minutes (IRC)
<timbl> Fodder: """Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that current tools may not make it easy to do things that way, e.g. because of dispatch issues.
<scribe> ACTION: Tim to send email starting discussion of text to ask WSA to put into their REC. [recorded in http://www.w3.org/2005/10/18-tagmem-irc]
TBL: would like to believe text above might be pretty close to fulfilling the action.
DC: mail it.
<DanC> remind me who's scribing next week?
<dorchard> I'm sribing
<timbl> ACTION*: Tim to digest and ermail """odder: """Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that current tools may not make it easy to do things that
ACTION 1=Tim to send email starting discussion of text to ask WSA to put into their REC. E.g. Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that current tools may not make it easy to do things that way, e.g. because of dispatch issues.
Nuts, replaced the wrong one. I'll straighten it out.
VQ: adjourned.
ACTION 1= Vincent to try and get official information about the Computer Misuse Act case referenced in http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html
ACTION 2=Tim to send email starting discussion of text to ask WSA to put into their REC. E.g. Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that current tools may not make it easy to do things that way, e.g. because of dispatch issues.
ACTION 3=
<DanC> action -3