W3C home > Mailing lists > Public > public-bpwg@w3.org > February 2009

[minutes] Tuesday 3 February 2009

From: Francois Daoust <fd@w3.org>
Date: Tue, 03 Feb 2009 17:43:51 +0100
Message-ID: <49887447.2090201@w3.org>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>


The minutes of today's call are available at:

... and copied as text below.

In short:
- On CT:
  * continuing discussion on HTTPS. Global action to review RFC3238:
  * Ref CT Guidelines Section 5, Adopt EdC's Clarification at 

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


03 Feb 2009


       [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


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

           nacho, abel, SangwhanMoon




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

    <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


      [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

    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

    EdC: having the possibility of transcoding trumps privacy, security,
    etc? that's a very strong statement. Yes there are security

    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

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

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


      [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


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


    <francois> +1

    <jo> +1

    <EdC> +1

    <SeanP> +1

    RESOLUTION: Ref CT Guidelines Section 5, Adopt EdC's Clarification

      [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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC