See also: IRC log
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
jo: Alan's noted that there's no progress, so let's move on
<dom> jo, please note jeffs request on agenda order
<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> 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> 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> jeff's call for feedback on MWABP
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> 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> Jo's email on OPES
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> web security context working group
<dom> Web Security Context: User Interface Guidelines
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[5]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.
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> 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 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].
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> 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> 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 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 http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0073.html
<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