- From: Francois Daoust <fd@w3.org>
- Date: Tue, 03 Feb 2009 17:43:51 +0100
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2009/02/03-bpwg-minutes.html
... and copied as text below.
In short:
- On CT:
* continuing discussion on HTTPS. Global action to review RFC3238:
http://tools.ietf.org/html/rfc3238
* Ref CT Guidelines Section 5, Adopt EdC's Clarification at
http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0073.html
- MWABP:
* Remove MWABP 3.1.2 and make a note somewhere about user
identification and the pros and cons of using network identification
mechanisms and consider where to place 3.1.1 to make a better flow
* This week's cancelled editorial meeting may be re-scheduled next
week on Tuesday 10 February. To be confirmed.
Francois.
-----
03 Feb 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0018.html
See also: [3]IRC log
[3] http://www.w3.org/2009/02/03-bpwg-irc
Attendees
Present
DKA, Jeff, Francois, tomhume, jo, adam, miguel, rob, Dom,
EdC, yeliz, chaals, kai, SeanP, jsmanrique, achuter, bruce
Regrets
nacho, abel, SangwhanMoon
Chair
Jo
Scribe
Tom
Contents
* [4]Topics
1. [5]F2F London Registration now Open
2. [6]Update on Mobile Accessibility
3. [7]CT Issues
4. [8]Update on MWABP aka BP2
5. [9]CT Clarification of the Testing section
6. [10]Editorial meeting on MWABP?
* [11]Summary of Action Items
_________________________________________________________
F2F London Registration now Open
jo: registration now open on 25-27 March
adam: have emailed to see if we can do without an NDA
dan: let's say we need to sort this out by end of the week
tom: is there any agenda?
jo: not yet, also can't guarantee that things will happen according
to agenda. should be 50% CT, 50% app best practices
dan: not completely up in the air but may have to reschedule
<chaals> [it is also possible to set some item and have it at that
time, if people are fixed - with flow happening around the fixed
items]
<dom> jsmanrique, have you just joined the call?
<jsmanrique> dom: just now
Update on Mobile Accessibility
jo: Alan's noted that there's no progress, so let's move on
<dom> jo, please note jeffs request on agenda order
CT Issues
<jeffs> re: ACTION-904 Initiate discussion on his blog ref feedback
on the MWABP
<DKA> ACTION-904
<dom> ACTION-904?
<trackbot> ACTION-904 -- Jeffrey Sonstein to initiate discussion on
his blog ref feedback on the MWABP -- due 2009-02-03 -- OPEN
<trackbot>
[12]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/904
[12] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/904
jeffs: would like to discuss HTTPS and feedback I received
<DKA> Please paste URLs into the IRC if possible Jeff.
<jeffs> [13]http://chw.rit.edu/blog
[13] http://chw.rit.edu/blog
<DKA> (or URIs if you must)
jeffs: As per action 904, I posted a page to get some feedback with
pointer to the document.
<dom> [14]jeff's call for feedback on MWABP
[14] http://chw.rit.edu/blog/?p=187
jeffs: I also solicited feedback from mailing lists and twitter, got
a load of private feedback
... And a large discussion on Oxford Mobile Forum
... To summarise the discussion on OMF and private emails: people
said if an author of a page sets up a link over HTTPS, no-one in the
middle should mess with it
... Second piece of feedback: we're building a best practices
document, not a "here's what some people do" doc. Let's stick to
best practices.
... I strongly agree that if an author of a page/site sets up link
as HTTPS, no-one should be encouraged to mess with it
jo: I too have posted pre-call. Central question: who is in the
middle, what does it count? If Opera are there and you've asked them
to be there, is that OK? If as a CP I've asked for it to be in the
middle, does that count? It's not about who's in the middle, it's
about whether they have authority
jeffs: if author says HTTPS, it should be HTTPS
chaals: anyone who claims that SSL gives you an idea of the
originator of the endpoint is talking rubbish.
... The author has no way of explaining who they are. There's a
secure connection to the client. It may be distributed/collected at
that end. As an author you don't have the right to tell me as a user
"I want a secure socket, and will tell you what your software looks
like". If I as a user select another way of interpreting your
byte-stream into something I understand using a single piece of
software or two pieces of software (e.g. browser+screen reader),
that's i
<jeffs> +1
chaals: transcoders should ensure the security of the connection
between them and the UA. In the case of Opera Mini, the path between
OM server and OM client, the connection is secure.
... That is a best practice. But it's not best practice to say "you
can use certain kinds of software for user agents, but not other".
<Zakim> chaals, you wanted to say that what a transcoder should not
do is remove security
francois: I agree with chaals. In the end we cannot say "sure you
can go ahead and deploy a proxy that replaces user endpoint by a
proxy endpoint". I don't think that's best practice. I'm not sure
what we can put.
jo: The precise construction of the client clearly cannot be a
matter for sensible discussion.
... It's about authority and domains of trust.
... It's legitimate for a CP to have a view about certain clients.
<chaals> [I agree with Jo that it is legitimate for a content
provider to block clients they don't like for security reasons (even
though that will entail, in practice, blocking clients for stupid
reasons too)]
EdC: We don't want to start making case-by-case discussion on how
clients are implemented. Overall I would tend to say if the client
can directly establish an end-to-end connection, it's a bit strange
that it's OK to break that connection and distribute it in a more
complex fashion.
... You have a URI stipulating HTTPS. The client can't establish a
connection directly (like opera mini). So in principle there's a
reason to start distributing HTTPS connections; it introduces
security issues. OM is different because it doesn't access internet
directly - this is a different beast. We're discussing browsers
which can, though.
<Zakim> chaals, you wanted to say that we should note there are
legitimate reasons for using transcoding proxies, and we should in
principle address best practices for them - including
chaals: there are legitimate reasons for transcoding proxies beyond
opera mini. e.g. corporate firewall, and I need to see who my users
are talking to.
... e.g. accessibility with requirements for content, using
transcoder to help me use the service.
jo: all these things are out of scope of what we're referring to...
as they're either distributed clients or distributed server, in the
domain of authority of the user.
chaals: i suggest we accept these are legitimate use cases and we
may/may not address them here. There are legitimate things to say
about these use cases and there are sensible reasons for doing them
jo: I don't doubt this
seanP: to address Eduardo's point re a browser which can connect
directly for HTTPS... reasons to choose transcoded HTTPS over HTTP
include the need to reformat content. These sites are common in the
US.
jo: chaals, I'm not clear on your earlier point that there's a need
for the group to assert there are legitimate use cases for this. Not
sure why you think this given that we have a document in 14th draft
on the subject... is this not self-evident
<EdC> Should Chaals write down the use cases he was referring at?
chaals: it is not self-evident to me that this is adequately
covered, but that may be due to ignorance
<EdC> Give an action to Chaals to write down the use cases he
considers insufficiently covered?
<jo> [15]Purpose
[15] http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#sec-purpose
<Zakim> rob, you wanted to echo SeanP - the reason for
transformation in HTTPS would be identical to the reason to
transform in HTTP
rob: ref Eduardo's question - the reason is the same as it is with
HTTP. There's no real difference in why you might want to do it with
HTTPS as HTTP. The difference is that there are security
implications.
EdC: having the possibility of transcoding trumps privacy, security,
etc? that's a very strong statement. Yes there are security
implications.
jo: it can't be said in all cases that presentation comes behind all
the other considerations you listed.
... it has to be taken case-by-case
edC: as there is no way for the end-user to determine whether they
want/don't want secure connections to be intercepted, then we have
to assume they don't
rob: we've already discussed ways for CPs and end users to say "I
don't want transcoding" - these methods should work with http and
https
jo: i don't think we have a good way of saying https links should
not be intercepted
<brucel> sorry for late; had 15.00 start in my calendar
<Zakim> chaals, you wanted to say the semantics of "don't transcode"
may not be clear
edC: on this point, the issue is not to specify whether the app
wants to be transcoded, but whether the secure connection wants to
be respected. there's no way for an app provider to control from
where the site is accessed, so there's no way to control whether
https links will be rewritten or not.
chaals: the no-transform request is specifically intended to mean "I
have already made this stuff nice for the UA asking for it, please
don't mess that up". that's very different to "...by the way, this
has to be very secure so don't mess with it for security". I don't
want to see us conflate these two.
... "don't transform my presentation" is not the same as "don't put
anything in here, this is supposed to be secure"
jo: ...we're probably redefining http, which we've already had our
wrists slapped for doing
<Zakim> DKA, you wanted to wonder aloud if there is a "middle way"
here between no transcoding and allowing all transcoding - e.g.
giving the user a strong warning that the security of
dan: the discussion seems to be around "yes it's ok to transform" or
"no it isn't". if the user is making an informed decision "I'm ok to
be less secure, I trust them", that's different
jo: no-transform is no use in protecting https. if i pull an https
link out of the sky and plug it into a mobile browser, its
interception is not governed by no-transform
... the no-transform issue is a red herring (as Eduardo has pointed
out). It's about informed user and content provider consent to this
activity - it doesn't matter whether it's http or https
... transformation is an issue of consent for 1 or 2 parties
dan: shirley there's an extra level of consent implied by
(non)transformation of data. you may not be aware of the extra
security implications as a non-technologist.
jo: this comes back to the point that blanket consent to any of
these activities is not sufficient as a level of informed consent
<Zakim> tomhume, you wanted to point out that we're not talking
about transformation of https resources, but rather transformation
of http resources *leading* to them
jo: caveats must be put into the flow, etc. what we're lacking is
the idea that consent must be 2-party, what can we do about that
... one of the things we were advised to do by IETF was demonstrate
we'd considered OPES.
... OPES says a number of relevant (and complicated) things. if we
want to consider it in detail we should look closely at rfc3238
<EdC> Should we all (that is, some of us) look deeply in OPES?
<francois> [16]Jo's email on OPES
[16] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0021.html
jo: their doc starts out painting a picture of disagreement and
disharmony, as here around a similar topic
... "One view on OPES has been that "OPES is deeply evil and the
IETF should stay far, far away from this hideous abomination"
jo: the difference between our topic and theirs is in degree and not
substance. we should look at this stuff and consider it light of the
fact that we're unlikely to disagree with them, as they've had a
lengthy debate about it.
... if we do disagree we should say why, otherwise fall in line with
what they say. There's prior work here and we have no reason to
disagree.
... they say 1-party consent is adequate for most of these things.
you must judge apps on case by case basis. if there's true informed
consent by the user and they know things are being done that they're
satisfied with, that's ok.
... what constitutes informed consent is not clear to me. small
print in a contract isn't it (tho IANAL)
<EdC> Are there W3C groups/activities/guidelines wrt security and
informed consent?
<dom> the web security context working group
<chaals> [there i one with respect to security and in particular
implications for user interfaces
<chaals> ...what dom said]
<dom> [17]web security context working group
[17] http://www.w3.org/2006/WSC/
<dom> [18]Web Security Context: User Interface Guidelines
[18] http://www.w3.org/TR/wsc-ui/
jo: if we're to follow OPES guidelines, we need to clarify this.
Interception of communication and "are you sure" is one way. Is
installation of Opera Mini consent? (IMHO probably not). The CP
aspect of this needs to be taken into account. CPs aren't in a
position to approve/disapprove of transcoder operations
jo: proxy indicates that it's there, but a vocab for signalling
various types of operations isn't there
... thus we need to apply a rule of reasonableness: "in general a CP
can prohibit any type of transformation if it's not under https"...
consequently transforming https is unworkable without the permission
of the CP in my view. so something outside of the protocol must have
happened,
... in general, reasonableness says interception of links and
transformation of content is reasonable, but it cannot be reasonably
determined that in the case of https there is reason to do it unless
there's consent on the part of both parties
edC: what outside of the protocol, and which one?
jo: HTTP
edC: from the POV of the CP, since there's no way to know what a
proxy is doing, there can be an informed decision. If I know there's
a proxy I might say "HTTP 40[$1\47]6" and stop.
jo: a proxy cannot know in general if a CP is aware that it's there,
which makes it unsafe for a proxy to assume it's OK for it to
intercept https links
sean: in the general case, the first https request is a login page.
user requests the login page, it comes back, has no secret content,
at which point the CP can put no-transform on it, at which point the
proxy can do a redirect etc.
... the first request can be identified as coming from a proxy
jo: if they're looking for this. making reasonable inferences in a
landscape like this seems hard to do
<Zakim> chaals, you wanted to point out that a proxy *can* say it is
there, and maybe *must* as a best practice and to say that the CP
has no idea what the user's user agent does in
chaals: to go back to my accessibility example, few services have
any way to say "you're using a screen reader, I'm not going to serve
you this content".
jo: agree from the POV of reasonableness that such transformation is
all normal and accepted. one can't object to transformation of
content per se.
<Kai> Hi, unfortunately I have to leave the call due to a
conflicting meeting, but I can say, from the CP's perspective, that
in general the "outside world", i.e. everything beyong our systems,
is a cloud. We have no knowledge what's out there in terms of
transcoding proxies or similar entities. If this were to become
important it would be due to a deterministic relationship with some
other company where the communicaton does contain some
transformation proxy. If that w
chaals: the question of informed consent is beyond scope of what we
do. we should make it clear that there is transformation happening,
that they've chosen it. beyond that it's a question for a lawyer
....??? I don't think we have to define informed consent.
... it's quite clearly defined as to how informed consent is given
(e.g. 12yo can't give it in some conditions)
jo: from our pov we need to be cautious about saying anything about
this other than "if a CP isn't specifically looking out for a proxy,
it's reasonable to make some inferences, unreasonable to make
others"
<EdC> Agree.
jo: where a user has expressed a preference for using opera mini and
CP hasn't expressed a preference, that's fair enough (and out of
scope of our doc)
... where it's a question of a 3p proxy chosen by neither user nor
CP, making assumptions becomes more dangerous and fragile. That's
what this is about.
chaals: the question of whether consent is informed is to do whether
they've signed up to some kind of service. in the case of an https
connection, either user or provider has decided to use that service.
the only other way to get into that chain is through providing a
corrupted browser.
dan: we want to steer clear of legal issues in this doc, don't we?
we can't issue legal recommendations, esp considering the law
changes depending on regulatory regime.
... if it were up to me i'd say "create an action to put some
wording together that would steer clear of legal issues raised
here". from an agenda perspective today we need to get onto MWBP if
we're to cover it.
jo: let's take an action to review the OPES doc, it's about this
subject and we should be informed about it.
<EdC> There are really several OPES documents!
jo: we want to look at policy issues behind OPES, a good starting
point for these ones - rfc3238
<EdC> What about 4902 Integrity, Privacy, and Security
<EdC> in Open Pluggable Edge Services (OPES) for SMTP
<EdC> Forget it.
Update on MWABP aka BP2
adam: not sure what to do with some points raised on the doc. posted
a link to a rough rewrite of 3.1.1 3.1.2
... not happy with either BP, feel a bit waffly
... 3.1.1 says "retain information for personalisation" and
summarises a few ways of how (cookies, form elements, etc.)
... some are server-side too
... 3.1.2 i proposed to merge into 3.1.1 - we're saying "if you're
storing info on the server you want them to login to have a key for
that info". with that in mind i've trimmed it down.
... can't see an easy obvious way of merging the two. cut down 3.1.2
with the intent "if you're storing info on the server you need to
login for it"
... there's not much mobile-specific here, so why not remove 3.1.2?
... do we need a best practice to say "login"?
<francois> +1 to remove 3.1.2
<EdC> Wouldn't the mobile aspect recommend mobile-specific login
modes (MSISDN, whatever)?
<adam> [19]http://docs.google.com/Doc?id=dft77cn8_31d6wvbdr7
[19] http://docs.google.com/Doc?id=dft77cn8_31d6wvbdr7
adam: BP as it stands says "if you have relationship with operator,
use that for identity"
<EdC> What about smart cards within mobile devices?
francois: second adam, we should remove 3.1.2
edC: if it's to be a BP, first sentence in 3.1.2.2 should be "if
operator provides user info, it should be used in preference..."
adam: not sure we can put a BP around that
jo: I'm not personally convinced. we also say it's BP to sync
personalisation between mobile and non-mobile. if this ID mechanism
isn't available outside of mobile, you have to implement 2
mechanisms and knit them together
... suggest that in the context of 3.1.1, add a bit around "user ID
needed in some form, sometimes available from the network..."
<jo> PROPOSED RESOLUTION: Remove MWABP 3.1.2 and make a note under
3.1.1 about user identification and the pros and cons of using
network identification mechaisms
adam: should it go into 3.1.1 or along with the previous one-web
section?
... 3.1.1: there's something worth saying. i'll find somewhere to
slot it in, maybe at expense of section on personalisation
<EdC> of using network id mechanisms and standard Web mechanisms
(which may have disadvantages in a mobile context).
<jo> PROPOSED RESOLUTION: Remove MWABP 3.1.2 and make a note
somewhere about user identification and the pros and cons of using
network identification mechaisms and consider where to place 3.1.1
to make a better flow
<adam> +1
<EdC> Pros and cons should also be for std Web mechanisms?
<jo> +1
edC: web form you're talking about login/password. best practice is
to use numbers only
adam: i've not seen that in use
edC: because you only have to tap once per key
<francois> [I think it requires a keypad to be there.]
adam: not seen this enforced or encouraged in mobile ui
edC: encouraged by users of mobile web sites, who normally criticise
entering a password.
jo: eduardo, can you take an action to provide adam with some text
around specific differences?
<EdC> +1
RESOLUTION: Remove MWABP 3.1.2 and make a note somewhere about user
identification and the pros and cons of using network identification
mechaisms and consider where to place 3.1.1 to make a better flow
<jo> ACTION: Casais to note specific mobile good practice for login
forms regarding use of numerics and mixed case and so on [recorded
in [20]http://www.w3.org/2009/02/03-bpwg-minutes.html#action01]
<trackbot> Created ACTION-908 - Note specific mobile good practice
for login forms regarding use of numerics and mixed case and so on
[on Eduardo Casais - due 2009-02-10].
CT Clarification of the Testing section
jo: back to an outstanding action, Eduardo...
... action-891
<jo> ACTION-891?
<trackbot> ACTION-891 -- Eduardo Casais to provide some text to
clarify the intent of the Testing section -- due 2008-12-09 -- OPEN
<trackbot>
[21]http://www.w3.org/2005/MWI/BPWG/Group/track/actions/891
[21] http://www.w3.org/2005/MWI/BPWG/Group/track/actions/891
edC: I'd like people to read it and comment on ambiguity
... it wasn't clear what "testing" should encompass - could be wide.
... and what's an "interface" here
<EdC>
[22]http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0073.htm
l
[22] http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0073.html
jo: i'm happy w/that clarification
<jo> PROPOSED RESOLUTION: Ref CT Guidelines Section 5, Adopt EdC's
Clarification at
[23]http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0073.htm
l
[23] http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0073.html
+1
<francois> +1
<jo> +1
<EdC> +1
<SeanP> +1
RESOLUTION: Ref CT Guidelines Section 5, Adopt EdC's Clarification
at
[24]http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0073.htm
l
[24] http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0073.html
Editorial meeting on MWABP?
<Zakim> francois, you wanted to wonder whether the idea of an
editorial meeting in a near future on MWABP was abandoned
francois: what about cancelled editorial meeting? when the snow
melts, shall we set up a new one?
<DKA> How about we set this up for tuesday the 10th?
jo: go ahead on 10th, but i'll be absent
... not in london again til the end of week-after-next
dan: tues pm is next regular BP call. I can get meeting room at
Paddington to do editorial meet before/after?
... (for adam/francois mainly)
francois: will arrive london 2pmish
... am homeless for next tuesdays call
<brucel> bye all
jo: see you next week
Summary of Action Items
[NEW] ACTION: Casais to note specific mobile good practice for login
forms regarding use of numerics and mixed case and so on [recorded
in [25]http://www.w3.org/2009/02/03-bpwg-minutes.html#action01]
[End of minutes]
Received on Tuesday, 3 February 2009 16:44:26 UTC