Re: [W3C] Draft Mobile Web BPWG / HTTPS comments ( LC-2028 LC-2029 LC-2030 LC-2031 LC-2032 LC-2033 LC-2027 LC-2026)

 Dear casays ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the Content Transformation
Guidelines 1.0 published on 1 Aug 2008. Thank you for having taken the time
to review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/.

Please review it carefully and let us know by email at
public-bpwg-comments@w3.org if you agree with it or not before 6 November
2009. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts

 1. http://www.w3.org/mid/g7a3q2+j33h@eGroups.com
 2. http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/


=====

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> c) Similary, the guidelines leave completely open the way of how
> to "provide the option to avoid decryption...", and do not 
> require it to be an OSTENSIBLE one. If the users miss the
> alternate (or rather, the original) link, they may unwillingly
> and unconsciously access the server without the expected
> security.
> 
> As an example, a small icon (perhaps representing a key) in a
> corner of the first page accessed via HTTPS, and linking to the
> end-to-end HTTPS link, fully conforms to the guidelines. How 
> many users would notice it and understand its significance?


Working Group Resolution (LC-2028):
We have added text to this section that goes some way to addressing your
concern

----

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> d) Informing the user that there are security implications in 
> the way he chooses to access the server, and providing him with 
> an alternative link to it risks causing the following reactions:
> i. WWW-beginners may simply not bother reading the advice and 
> always take the default action, which according to the
> guidelines seems to correspond to taking the less safe,
> point-to-point HTTPS connection.
> ii. Somewhat WWW-knowledgeable users, aware of the existence of
> Trojan horses and phishing, may reel at the invitation to try 
> alternative links. If they are curious and examine the URI of
> the current page, they may further suspect foul play, as the
> rewritten URI may not match the one they accessed originally.
> iii. Expert WWW-users will understand the implications of the
> proxy set-up, but may be wary at using its services for HTTPS
> links -- after all, what is the guarantee that the proxy will
> not misuse or unintentionally disclose private information in
> a point-to-point connection? And if there is a proxy acting as
> middle-man, what is the guarantee that the end-to-end HTTPS
> link is actually an end-to-end one and the proxy is not just
> performing some other tricky manipulations?
> 
> Overall, fiddling with HTTPS connections risks reducing, rather
> than increasing, the willingness of end-users to access the
> mobile Web. A relevant point is that these end-users may 
> actually assign the fault with the untrustworthy connections
> to the content or application provider, rather than to the 
> operator of the proxy.


Working Group Resolution (LC-2029):
We have added text to this section that goes some way to addressing your
concern

----

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> e) The guidelines allow the client to go through a first
> point-to-point session establishment with the proxy, and if so
> desired, through a second end-to-end session establishment with the
> server. 
> 
> Establishing an HTTPS connection is a somewhat heavy process for
> wireless devices, requiring the delivery and possibly acceptance of
> certificates. A double initiation procedure reduces, rather than
> increases, usability at session start.


Working Group Resolution (LC-2030):
We have added text to this section that goes some way to addressing your
concern

----

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> f) In the absence of any requirements regarding the reliability
> of proxies and their operating environment, one can only 
> wonder why anybody would choose a point-to-point connection
> through an uncontrollable middle-man over an end-to-end one
> if the intent is to access private information safely over 
> the mobile Web. The experience of WTLS taught some hard lessons 
> there.


Working Group Resolution (LC-2031):
We have added text to this section that goes some way to addressing your
concern.


----

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> g) The guidelines rely upon a fundamentally flawed assumption:
> in the HTTPS connection, the client is the only party concerned 
> with security, and which must take a decision as to whether to 
> access resources over a point-to-point or end-to-end link. 
> 
> This is incorrect: there are actually two parties to the secure
> connection, client and server, both with legitimate security 
> concerns. The server has thus as much a right to determine whether 
> it wants to provide services over a point-to-point connection 
> as the client. I can very well imagine that for instance 
> banking, electronic commerce or social networking application
> servers may decide to sever point-to-point connections rather
> than providing services over them, and inform the end-user 
> about the reasons.
> 
> Unfortunately, because of the flawed assumption of the guidelines,
> there is strictly no way a server may reliably detect whether
> it is communicating over a point-to-point link or not. 
> 
> Consider:
> i. The proxy rewrites links but the replacement links must have
> HTTPS; hence for the server communication obviously takes place 
> over HTTPS.
> ii. If the proxy preserves the HTTP header fields (such as 
> user-agent, accept, accept-charset, etc), which is actually
> encouraged by the guidelines, then the proxy cannot detect
> that transformations may be taking place.
> iii. Further, the "via" HTTP header field does not constitute
> a proper mechanism to detect the presence of a transformation
> proxy, and whether HTTPS is point-to-point or end-to-end.
> First, the comment "http://www.w3.org/ns/ct" indicating the
> presence of a transformation proxy is not mandatory, as per
> the guidelines. Secondly, RFC2616 authorizes proxies to use 
> a pseudonym instead of a domain name for the "received-by" 
> part of their hop, which does not necessarily have a meaning 
> for servers.
> 
> The server is therefore not in a position to take educated
> decisions as to its secure communications with clients through
> a transformation proxy.


Working Group Resolution (LC-2032):
We agree and have added text to this section that goes some way to
addressing your concern.

----

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> Overall, the guidelines follow the rule that accessing the
> WWW is the prime intent of the end-user, and that security
> comes only second. Hence the approach of defaulting to the
> transformation chain, with the possibility of opting out of
> it. This is a questionable assumption precisely in the
> context of secure transactions. There, secure access is the
> paramount requirement, and must therefore be fulfilled by
> any proxy set-up, with the possibility to opt-in to the
> unsecure transformation chain.


Working Group Resolution (LC-2033):
We agree and have added text to this section that goes some way to
addressing your concern.

----

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> b) The guidelines do not state that the users "must be advised
> of the security implications of rewriting HTTPS links" BEFORE
> they have a chance to perform any operation with the target site.
> If the advice takes place after an operation, then users may 
> unknowingly access the server through the point-to-point HTTPS
> connection instead of the end-to-end one.
> 
> As an example, a small icon (perhaps representing a question
> mark) in a corner of the first page accessed via HTTPS, and
> pointing to a description of the consequences of the rewritten
> HTTPS links, fully conforms to the guidelines. How many users
> would notice it? How many would click on it, take the time to
> read its content fully (and understand it), before performing
> any further action?


Working Group Resolution (LC-2027):
We agree and have added text to this section that goes some way to
addressing your concern.

----

Your comment on 4.3.6.2 HTTPS Link Re-writing:
> a) Tthe guidelines state: "[...] and must provide the
> option to avoid decryption and transformation of the 
> resources the links refer to."
> 
> This stipulation theoretically allows manipulations of the
> HTTPS stream that are not strictly related to decryption and 
> transformation of the content. 
> 
> What is required is that the client may establish an HTTPS 
> connection with the server in the exact, undisturbed context
> as if the proxy were a transparent one, performing no
> transformations whatsoever.


Working Group Resolution (LC-2026):
We agree and have added text to this section that goes some way to
addressing your concern.

----

Received on Tuesday, 6 October 2009 15:34:30 UTC