IRC log of bpwg on 2008-10-07

Timestamps are in UTC.

13:55:01 [RRSAgent]
RRSAgent has joined #bpwg
13:55:01 [RRSAgent]
logging to http://www.w3.org/2008/10/07-bpwg-irc
13:55:03 [trackbot]
RRSAgent, make logs public
13:55:03 [Zakim]
Zakim has joined #bpwg
13:55:05 [trackbot]
Zakim, this will be BPWG
13:55:06 [trackbot]
Meeting: Mobile Web Best Practices Working Group Teleconference
13:55:06 [trackbot]
Date: 07 October 2008
13:55:09 [Zakim]
ok, trackbot; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 5 minutes
13:55:34 [francois]
Chair: francois
13:55:40 [francois]
Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0011.html
13:56:22 [Zakim]
MWI_BPWG(CTTF)10:00AM has now started
13:56:29 [Zakim]
+ +2
13:56:32 [tomhume]
zakim, +2 is me
13:56:32 [Zakim]
+tomhume; got it
13:57:56 [jo]
jo has joined #bpwg
13:58:11 [jo]
zakim, code?
13:58:11 [Zakim]
the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), jo
13:59:10 [Zakim]
+??P16
13:59:27 [jo]
zakim, ??p16 is me
13:59:27 [Zakim]
+jo; got it
14:00:52 [Zakim]
+Francois
14:01:23 [rob]
rob has joined #bpwg
14:02:04 [Zakim]
+ +0207287aabb
14:02:24 [rob]
Zakim, aabb is me
14:02:41 [Zakim]
+rob; got it
14:03:25 [SeanP]
SeanP has joined #bpwg
14:04:16 [Bryan]
Bryan has joined #bpwg
14:04:49 [Zakim]
+ +1.630.414.aacc
14:04:59 [SeanP]
zakim, aacc is me
14:05:27 [andrews]
andrews has joined #bpwg
14:05:28 [Zakim]
+SeanP; got it
14:06:53 [jo]
sean: jo
14:07:10 [jo]
s/sean: jo//
14:07:14 [jo]
scribe: jo
14:07:50 [Zakim]
+ +0789972aadd
14:08:04 [francois]
zakim, aadd is andews
14:08:04 [Zakim]
+andews; got it
14:08:12 [francois]
zakim, andews is really andrews
14:08:12 [Zakim]
+andrews; got it
14:08:35 [jo]
Topic: Report from W3M Project Review
14:09:14 [jo]
francois: I presented guidelines to W3C team to raise their attention to CT so they knew about it
14:09:44 [jo]
... no solutions to the problems, unfortunately - good because it seems that we are heading in the right direction
14:10:11 [jo]
... main concern is about security and breaking of https, much concern about this
14:11:07 [jo]
... similar frustration expressed as we have - want to write something with more subtle control/communication but not chartered to do this hence POWDER might be a good direction for the future
14:11:36 [jo]
... nothing further to report - they had no practical solutions to add to what we have done
14:11:41 [jo]
zakim, mute me
14:11:41 [Zakim]
jo should now be muted
14:11:51 [jo]
Topic: HTTPS Link Rewriting
14:11:54 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Sep/0013.html Tom's initial comments on HTTPS
14:12:04 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0012.html Tom's further thoughts
14:12:22 [jo]
francois: we got a lot of lc comments on this, and Tom summarised some thoughts
14:12:59 [jo]
tom: broad agreement that it breaks end to end security, need to make sure that users have control, but how this is done is tricky
14:13:36 [jo]
... also need to ensure that content providers are aware of what is going on, but puts the burden on CPs to look out for that
14:13:56 [jo]
francois: so in the end, there is no real way to forbid link re-writing
14:13:59 [jo]
q+
14:14:08 [Zakim]
-tomhume
14:14:20 [francois]
ack jo
14:14:21 [jo]
... we need to emphasise that we don't recommend it
14:14:33 [Zakim]
+??P1
14:14:43 [jo]
zakim, ??P1 is tom
14:14:43 [Zakim]
+tom; got it
14:15:51 [jo]
jo: can we just confirm the views of those on call ref forbidding HTTPS rewriting
14:16:28 [jo]
andrews: we currently allow our proxy to re-write links, they generate an interstitial, and the choice can be kept for future pages
14:17:04 [jo]
... I agree that it is undesirable, but pragmatically speaking a lot of services won't work if we don't do it. So the important thing is to advice the user and give them the choice
14:17:19 [rob]
q+ to second what Andrew's just said
14:17:34 [jo]
seanp: yes that how the implementation works and we have done the same for other customers
14:18:05 [jo]
... not ideal, but there is more than just banking sites - e.g. login to email, facebook etc.
14:18:45 [jo]
... it's up to our customer (operator) to decide whether they want it or not. Would not want to violate transformation guidelines but if the customer wants it we'd have to do it
14:18:50 [francois]
ack rob
14:18:50 [Zakim]
rob, you wanted to second what Andrew's just said
14:19:17 [andrews]
q+ to say that Vodafone UK uses a "black list" of financial institutions that we will not intercept
14:19:20 [tomhume]
q+
14:19:29 [jo]
rob: agree with Andrew and Sean - if guidelines were to forbid it then all deployments would not conform to this one point
14:19:49 [jo]
ack a
14:19:49 [Zakim]
andrews, you wanted to say that Vodafone UK uses a "black list" of financial institutions that we will not intercept
14:19:50 [francois]
ack andrews
14:20:17 [jo]
andrew: we have an "exclude" list and we do not intercept that traffic
14:20:35 [jo]
... we don't want to expose ourselves to potential problems
14:20:47 [francois]
ack tomhume
14:20:53 [jo]
... the ones we do allow we explain to the customer what we are doing and give them a choice
14:21:21 [jo]
tom: do we have any figures for what percentage of customers that make the choice to proceed as opposed to those who don't
14:21:33 [jo]
s/don't/don't?/
14:21:54 [jo]
seanp: don't think we keep track of it I could try to find out
14:22:10 [jo]
rob: we don't track it as we don't know what the choices are
14:22:20 [jo]
francois: why would that help Tom?
14:22:33 [jo]
tom: if a lot [bubble bubble]
14:23:20 [jo]
francois: paraphrasing what I think Tom was trying to say:
14:23:44 [tomhume]
+1
14:24:05 [jo]
... if a lot of users refused it then we could forbid it, whereas if a lot followed the link then it seems to be a "desirable" feature
14:24:43 [jo]
ACTION: patterson to find out if novarra has figures on whether users choose to proceed at the HTTPS interstitial page
14:24:43 [trackbot]
Created ACTION-858 - Find out if novarra has figures on whether users choose to proceed at the HTTPS interstitial page [on Sean Patterson - due 2008-10-14].
14:24:51 [jo]
francois: a couple of extra points
14:25:37 [jo]
... ref opera mini, [although we know it is out of scope], it can't be secure as it needs to be decrypted in their server, so can't be end to end
14:26:38 [jo]
... secondly, there is a fear that parties are trying to push client certificates for secure connections and these kind of certificates are supposed to ensure the end to endedness of the connection
14:27:07 [jo]
... and so in order to continue the proxy might ask the client to supply their certificate which would be even worse
14:27:09 [rob]
q+
14:27:13 [francois]
ack rob
14:27:40 [jo]
rob: pushing client certificate - it won't work for the Web site to push it
14:28:05 [jo]
francois: link rewriting can't work with client certificates
14:28:25 [jo]
... but if the proxy possesses the client certificate then it can act on behalf of the end user
14:28:42 [jo]
... and the fear is that they might do that
14:29:00 [jo]
... afaik client certificates are not commonly deployed
14:29:05 [jo]
q+
14:29:09 [francois]
ack jo
14:30:15 [andrews]
q+
14:30:26 [jo]
jo: what are the more general guidelines for servers to assess whether they are talking to who they think they are talking to in any case
14:30:27 [francois]
ack andrews
14:30:51 [jo]
francois: maybe I should take an action to write something on this
14:31:28 [jo]
andrews: the nature of the security is just that the end user can check the server certificate, so there is nothing to stop a man-in-the-middle attack
14:31:46 [jo]
... user still thinks they are connected to a secure service
14:32:42 [jo]
jo: suggest that francois wrties to wsc wg to see if they have some preferred text
14:34:03 [jo]
andrews: ref client certificates - user must have given permission and should not do that for some types of transaction - and for that reason we do not want to interfere with transactions of this kind because of the liability issues
14:34:18 [jo]
s/wrties/writes/
14:34:45 [jo]
francois: thomas (WSC) recommended that we talk to the IETF TLS working group
14:34:54 [jo]
... so I could send them an email
14:35:56 [jo]
ACTION: daoust to contact IETF TLS group and advise them of what we are thinking and ask for guidance on what to recommend to Content Provider about detecting the presence of a man-in-the-middle proxy
14:35:56 [trackbot]
Created ACTION-859 - Contact IETF TLS group and advise them of what we are thinking and ask for guidance on what to recommend to Content Provider about detecting the presence of a man-in-the-middle proxy [on Fran├žois Daoust - due 2008-10-14].
14:36:24 [jo]
rob: there is no way for a Via header to appear unless the HTTPS session has been intercepted
14:36:56 [jo]
francois: there is a tiny difference between a proxy being used in proxy mode vs linked mode
14:37:32 [jo]
... we need to be clear that although the Proxy is actually the client when intercepting https it must still insert via headers
14:38:15 [jo]
ACTION: JO to add clarification to HTTPS rewriting to make it clear that the via header MUST be added
14:38:15 [trackbot]
Created ACTION-860 - Add clarification to HTTPS rewriting to make it clear that the via header MUST be added [on Jo Rabin - due 2008-10-14].
14:38:43 [jo]
ACTION-860 [this especially ref HTTPS]
14:39:15 [jo]
francois: there is no other way to encrypt data for responses
14:40:15 [jo]
... so should we put something in scope for future work, we need something more fine-grained to allow transformation and secure links. XML encryption and signature could be something in the future
14:40:53 [jo]
+1 to something in the future in some possible world :-)
14:41:36 [jo]
francois: to summarise, I am going to contact IETF and Jo will add some clarification ref the via header
14:42:27 [jo]
PROPOSED RESOLUTION: Accept the thrust of Tom's submission on this, and editor to make sure that the wording is beefed up to make it clear that this is a horrible bad thing but if you _must_ do it the user MUST know and MUST have a choice
14:43:17 [jo]
PROPOSED RESOLUTION: Accept the thrust of Tom's submission on HTTPS, and editor to make sure that the wording is beefed up (e.g. by saying that if a proxy rewrites HTTPS ... rather than saying a proxy MAY) to make it clear that this is a horrible bad thing but if you _must_ do it the user MUST know and MUST have a choice
14:43:42 [rob]
+1
14:43:43 [tomhume]
+1
14:43:47 [francois]
+1
14:43:47 [SeanP]
q+
14:43:51 [francois]
ack SeanP
14:44:35 [jo]
seanp: understand the reasoning, what we have already seems fairly close to sufficient, we seem to be saying we realise you need to do this, but don't do it, which looks odd
14:44:40 [andrews]
q+
14:44:49 [jo]
... we already have warnings etc.
14:45:00 [francois]
ack andrews
14:45:04 [jo]
... stronger warning would not hurt
14:46:12 [jo]
andrews: I think the current wording is right, perhaps we could add a para before the existing wording emphasising the seriousness of doing this - i.e. breaking the trusted link. the current wording is right and precise and would not want to change existing phraseology
14:46:53 [jo]
francois: I think we are all going in the same direction - we don't propose to say don't do it, but if you do ...
14:47:23 [jo]
... we did get a lot of LCC that we should not ignore, so it is not being read the way we wrote it so more clarification is needed
14:47:27 [jo]
q?
14:47:49 [jo]
... we might add a few normative statements e.g. about invalid certificates
14:48:33 [SeanP]
+1 to "editorial magic"
14:48:46 [jo]
... maybe Jo can find some wording to make it clearer to the public at the same time as satisfying us as to what we want to say
14:49:12 [jo]
andrews: yes, all for editorial magic, being it on!
14:49:18 [jo]
s/being/bring/
14:49:47 [andrews]
+1
14:50:04 [jo]
PROPOSED RESOLUTION: Accept the thrust of Tom's submission on HTTPS, and editor to make sure that the wording is beefed up (e.g. by saying that if a proxy rewrites HTTPS ... rather than saying a proxy MAY) to make it clear that if you _must_ do it the user MUST know and MUST have a choice
14:50:08 [jo]
+1
14:50:10 [francois]
+1
14:50:12 [rob]
+1
14:50:14 [tomhume]
+1
14:51:20 [SeanP]
+1 to the resolution + Francois' comments
14:52:08 [andrews]
+1
14:52:26 [jo]
RESOLUTION: Accept the thrust of Tom's submission on HTTPS, and editor to make sure that the wording is beefed up (e.g. by saying that if a proxy rewrites HTTPS ... rather than saying a proxy MAY) to make it clear that if you _must_ do it the user MUST know and MUST have a choice
14:53:13 [jo]
s/ RESOLUTION/RESOLUTION/
14:53:20 [francois]
List of comments on HTTPS: LC-2026, LC-2027, LC-2085, LC-2028, LC-2029,
14:53:20 [francois]
LC-2030, LC-2015, LC-2031, LC-2016, LC-2032
14:53:20 [francois]
LC-2001, LC-2033, LC-2004, LC-2024
14:54:12 [francois]
Topic: LC-2078: claim of conformance in a Via HTTP header
14:54:18 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0009.html
14:54:20 [jo]
Topic: LC-2078 Claim of Conformance in Via HTTP header
14:54:56 [jo]
francois: comments about what claim of conformance is constituted by including this in a via header
14:55:22 [jo]
... I think the main use case is to advertise transforming functionality, conformace is not implied
14:55:30 [jo]
+1 to rewriting to clarify this
14:56:06 [jo]
... I realise that you are unlikely to include such a comment if you are wildly uncoformant
14:57:10 [francois]
s/uncoformant/unconformant
14:57:20 [jo]
PROPOSED RESOLUTION: Rewrite section 4.1.6.1 to clarify that inclusion of a via comment of the form indicated is not a conformance claim, but is an indication that the proxy is "non-transparent" or can be so
14:58:14 [jo]
PROPOSED RESOLUTION: Rewrite section 4.1.6.1 to clarify that inclusion of a via comment of the form indicated is not a conformance claim, but is an indication that the proxy may restructure or otherwise modify content
14:58:22 [francois]
+1
14:58:25 [rob]
+1
14:58:26 [tomhume]
+1
14:58:28 [andrews]
+1
14:58:30 [SeanP]
+1
14:58:38 [jo]
RESOLUTION: Rewrite section 4.1.6.1 to clarify that inclusion of a via comment of the form indicated is not a conformance claim, but is an indication that the proxy may restructure or otherwise modify content
14:59:32 [Zakim]
-rob
14:59:34 [Zakim]
-tom
14:59:34 [jo]
francois: thanks and au revoir
14:59:36 [Zakim]
-andrews
14:59:36 [Zakim]
-Francois
14:59:37 [Zakim]
-SeanP
14:59:41 [jo]
[meeting adjourned]
14:59:51 [Zakim]
-jo
14:59:53 [Zakim]
MWI_BPWG(CTTF)10:00AM has ended
14:59:55 [Zakim]
Attendees were tomhume, jo, Francois, +0207287aabb, rob, +1.630.414.aacc, SeanP, +0789972aadd, andrews, tom
14:59:57 [francois]
s/Topic: LC-2078 Claim of Conformance in Via HTTP header//
15:00:09 [francois]
RRSAgent, draft minutes
15:00:09 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/07-bpwg-minutes.html francois
15:01:16 [Bryan]
sorry I have been on another cll
15:01:24 [jo]
present+ Bryan[IRC_Only]
15:01:25 [Bryan]
I tried to follow but was not able
15:01:55 [francois]
RRSAgent, draft minutes
15:01:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/07-bpwg-minutes.html francois
15:02:10 [Bryan]
thanks
15:08:49 [rob]
rob has left #bpwg
15:30:40 [francois]
RRSAgent, bye
15:30:40 [RRSAgent]
I see 3 open action items saved in http://www.w3.org/2008/10/07-bpwg-actions.rdf :
15:30:40 [RRSAgent]
ACTION: patterson to find out if novarra has figures on whether users choose to proceed at the HTTPS interstitial page [1]
15:30:40 [RRSAgent]
recorded in http://www.w3.org/2008/10/07-bpwg-irc#T14-24-43
15:30:40 [RRSAgent]
ACTION: daoust to contact IETF TLS group and advise them of what we are thinking and ask for guidance on what to recommend to Content Provider about detecting the presence of a man-in-the-middle proxy [2]
15:30:40 [RRSAgent]
recorded in http://www.w3.org/2008/10/07-bpwg-irc#T14-35-56
15:30:40 [RRSAgent]
ACTION: JO to add clarification to HTTPS rewriting to make it clear that the via header MUST be added [3]
15:30:40 [RRSAgent]
recorded in http://www.w3.org/2008/10/07-bpwg-irc#T14-38-15
15:30:43 [francois]
Zakim, bye
15:30:43 [Zakim]
Zakim has left #bpwg