Mobile Web Best Practices Working Group Teleconference

03 Feb 2009


See also: IRC log


DKA, Jeff, Francois, tomhume, jo, adam, miguel, rob, Dom, EdC, yeliz, chaals, kai, SeanP, jsmanrique, achuter, bruce
nacho, abel, SangwhanMoon


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


<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.

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> 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 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].

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> 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


<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

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 http://www.w3.org/2009/02/03-bpwg-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/02/03 16:39:41 $