Edit comment LC-2270 for Mobile Web Best Practices Working Group

Quick access to LC-2267 LC-2268 LC-2269 LC-2270 LC-2289 LC-2316 LC-2317 LC-2318 LC-2319 LC-2320 LC-2321 LC-2322 LC-2323 LC-2324 LC-2327 LC-2328 LC-2329 LC-2358 LC-2359 LC-2360

Comment LC-2270

Comment Shortname:

Commenter: Eduardo Casais <casays@yahoo.com>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeGuidelines for Web Content Transformation Proxies 1.0 W3C Working Draft 6 October 2009 Abstract Status of this Document Table of Contents Appendices 1 Introduction (Non-Normative) 1.1 Purpose 1.2 Audience 1.3 Scope 1.4 Principles 1.4.1 IAB Considerations 1.4.2 Priority of Intention 2 Terminology (Normative) 2.1 Types of Proxy "A transparent proxy is a proxy that does not modify the req... "A transparent proxy is a proxy that does not modify the req... 2.2 Types of Transformation Restructuring content is a process whereby the original layo... Recoding content is a process whereby the layout of the cont... Optimizing content includes removing redundant white space,... 3 Conformance (Normative) 3.1 Classes of Product 3.2 Normative and Informative Parts 3.3 Normative Language for Conformance Requirements 3.4 Transformation Deployment Conformance 4 Behavior of Components (Normative) 4.1 Proxy Forwarding of Request 4.1.1 Applicable HTTP Methods 4.1.2 no-transform directive in Request 4.1.3 Treatment of Requesters that are not Web browsers 4.1.4 Serving Cached Responses 4.1.5 Alteration of HTTP Header Field Values In this section, the concept of "Web site" is used (rather t... 4.1.5.1 Content Tasting 4.1.5.2 Avoiding "Request Unacceptable" Responses 4.1.5.3 User Selection of Restructured Experience 4.1.5.4 Sequence of Requests 4.1.5.5 Original Header Fields 4.1.6 Additional HTTP Header Fields 4.1.6.1 Proxy Treatment of Via Header Field 4.2 Proxy Forwarding of Response to User Agent 4.2.1 Applicable Responses 4.2.2 User Preferences 4.2.3 Receipt of Cache-Control: no-transform 4.2.4 Use of Cache-Control: no-transform 4.2.5 Server Rejection of HTTP Request 4.2.6 Receipt of Vary HTTP Header Field 4.2.7 Link to "handheld" Representation In this document the term current representation means a "sa... 4.2.8 WML Content 4.2.9 Proxy Decision to Transform 4.2.9.1 Alteration of Response 4.2.9.2 Link Rewriting In this document two URIs have the Same-Origin if the scheme... 4.2.9.3 HTTPS Link Rewriting 5 Testing (Normative) A References B Conformance Statement C Internet Content Types associated with Mobile Content D DOCTYPEs Associated with Mobile Content E URI Patterns Associated with Mobile Web Sites F Summary of User Preference Handling G Example Transformation Interactions (Non-Normative) G.1 Basic Content Tasting by Proxy G.2 Optimization based on Previous Server Interaction G.3 Optimization based on Previous Server Interaction, Server has Changed its Operation G.4 Server Response Indicating that this Representation is Intended for the Target Device G.5 Server Response Indicating that another Representation is Intended for the Target Device H Informative Guidance for Origin Servers (Non-Normative) H.1 Server Response to Proxy H.1.1 Use of HTTP 406 Status H.1.2 Use of HTTP 403 Status H.1.3 Server Origination of Cache-Control: no-transform Including a Cache-Control: no-transform directive can disrup... H.1.4 Varying Representations H.1.4.1 Use of Vary HTTP Header Field H.1.4.2 Indication of Intended Presentation Media Type of Representation I Applicability to Transforming Solutions which are Out of Scope (Non-Normative) J Scope for Future Work (Non-Normative) J.1 POWDER J.2 link HTTP Header Field J.3 Sources of Device Information J.4 Inter Proxy Communication J.5 Amendment to and Refinement of HTTP K Acknowledgments (Non-Normative)
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

A proposal to endow servers with the possibility to protect their HTTPS services from
URL rewriting.


I.    CONTEXT

The CTG allows proxies to rewrite URL, including those indicating that the
communication between terminal and server is to be established as an end-to-end
connection over TLS/SSL.

The W3C acknowledges the serious security concerns that arise from such rewriting
operations, but does not provide any mechanism for servers to protect their services
from the corresponding security risks.

HTTPS URL rewriting has perhaps been the more contentious issue of the CTG so far,
and has serious consequences on the credibility of the mobile Web for advanced
applications requiring privacy, payment security; it opens up a can of worm regarding
liability and certification of mobile e-commerce solutions.


II.     PROPOSAL

The following text is to be added to a new section 4.2.9.4 of the CTG:

"Proxies must provide a means for servers to express preferences for inhibiting
HTTPS URL rewriting regardless of the preferences expressed by the user.

Those preferences must be maintained on a Web site by Web site basis."


III.    RATIONALE

The proposal addresses the issues raised by HTTPS URL rewriting, without imposing
a specific mode of implementation. As such, it does not prescribe (non-standard)
mechanisms, nor introduces new technology into the CTG, but only sets formal
requirements as to their end-effect.

I re-establishes the consistency between on the one hand the facts that
a) the original decision to establish HTTPS connections lies within the server;
b) the knowledge about what level of security is appropriate for a Web application
lies on the server side;
c) problems of liability, customer support, and commercial reputation fall back onto
the server;
and, on the other hand, the facts that
d) the server is not given any decision power as to whether end-to-end security is to
be respected or not;
e) only the end-user, who does not possess all required knowledge to assess the
situation, is given mechanisms in the current CTG to prevent transformations on site
by site basis.

It takes into account the fact that none of the available mechanisms utilized by
well-behaved proxies is reliable when it comes for a server to detecting whether an
HTTPS URL rewriting has taken place or not. In particular, "via" fields may or may
not be retransmitted integrally by some HTTP standards-compliant proxies, as indicated
in section 4.1.6.1 of the CTG.

It is in line with the practice in some countries, where operators have set up
mechanisms such as "white lists" to exclude financial institutes from HTTPS URL
rewriting. This demonstrates that, notwithstanding whatever is stated about the
relevance of rewriting HTTPS links, the consequences of such operations are taken
quite seriously.


E.Casais

Related issues: (space separated ids)

WG Notes: Resolution: http://www.w3.org/2009/12/10-bpwg-minutes.html#added05

Resolution: We agree that this is important but note that no standard mechanism can be used for establishing two party consent at the time of writing this document. A section was added in the Scope for Future Work appendix to point out that such standard mechanism is needed.

(Please make sure the resolution is adapted for public consumption)