[W3C] Draft Mobile Web BPWG / comments

To the W3C Mobile Web BPWG.

This is a response to the call for comments regarding the "Working
Draft of the Content Transformation Guidelines" from 1.8.2008.

1) Section 4.1.1

Add to the section:

Proxies MUST NOT convert POST methods into GET ones, or vice-versa.

Rationale: This kind of transformation may make exchanges between
clients and servers inoperative. In particular, this kind of
substitution has been known to cause problems for content downloading
applications in the mobile Web.

2) Section 4.3

Following item to be added to the guidelines:

A Content Transformation Proxy receiving a response that contains a
non-empty meta-tag "Copyright" MUST NOT restructure or recode the
content, nor dependent resources (such as pictures or videos, or other
textual content).

Rationale: The following content alterations may constitute willful
copyright violations:
a) Insertion of additional links, advertisements, navigation elements
(e.g. scroll bars), or extraneous content.
b) Modification of the look and feel (e.g. through reorganization of
the page, filtering out elements such as pictograms). 

The following alterations may also constitute defacement of trade
marks and other registered elements:
c) Changing the representation of trademarks, logos and other
registered design elements, as a change in the representation may
affect its legibility, the colours or the colour palette.

The following alterations may also constitute disactivation of or
bypassing IPR protections:
d) Re-encoding images or videos which embed steganographic IPR
protection information may eliminate or render ineffective these
mechanisms.

A copyright meta-tag, in the absence of any other indication, is
enough to signal that the content must not be transformed. This
meta-tag is widely used in the WWW, and its inclusion in content as a
meta-tag (invisible to end-users) is precisely intended to control
automatic processing in the delivery chain.

3) Section 4.3.6

Under "Examples of mobile specific DOCTYPEs:", add:

	-//WAPFORUM//DTD WML 1.3//EN
	-//WAPFORUM//DTD WML 1.1//EN

Rationale: WML is still in use in the mobile Web. Responses of this
type are precisely the kind that should not be transformed, as WML is
intrinsically targeted at mobile devices only. WML can also be
delivered over HTTP, so the draft applies to this content as well.

4) Section 4.3.6

The proposed heuristics seem to fail completely for i-mode sites, because:
a) i-Mode sites often do not have peculiar URL distinguishing them
from (non-mobile) sites, and in any case the prefix imode.* is not
included in the list of URI patterns to check for.
b) i-Mode sites return mostly their content as text/html.
c) i-Mode sites do not include a DOCTYPE.
d) The markup for i-Mode does not cater for the utilization of the
link element as proposed in the draft, which is therefore not included
in i-Mode content.
e) i-Mode servers do not have much use for the "no-transform"
directive, and hence do not necessarily implement it.

5) Section 4.3.6.1

I miss any discussion or reference in the document about the issue of
character encodings.

Transforming content across different charsets is a mine-field and
affects a number of aspects:
a) Content may rely upon widely different character encodings,
depending on the targetted devices and markets. In particular, the
trio China -   Japan - Korea (CJK) continues to rely on a number of
encodings (such as Shift_JIS, BIG5, etc) whose handling is a complex
matter; for instance, there are not necessarily bijective mappings
between these encodings and others, including UTF-8. 
b) Documents may have multi-encoding representations. Different
encodings may be associated with external entities through the charset
attribute (see HTML 4.0.1). How transformation proxies deal with such
a situation is left undefined.
c) Similarly, the draft does not explain what happens when a server
associates an attribute accept-charset to a form, and whether proxies
respect or manipulate such information.
d) In i-Mode, and at least in the Softbank environment (Japan),
unreserved character points in the character encoding space are used
to represent pictograms. Any attempt to convert these characters
directly will fail; they should therefore not be transformed, but
preserved, taking into account the fact that the character points thus
referred to differ between Unicode and Shift_JIS, and that DoCoMo and
Softbank do not use the same code points for the same pictograms.

A consequence of all this is that if a proxy does not operate natively
with the character encoding of the content returned by the server, or
is not able to ensure a bijective mapping between this encoding and
other encodings it deals with, recurrent and irrecoverable problems
will creep.
A simple way that could go some way towards alleviating this risk
would be to forbid any transformation if the server announces (either
via the HTTP field Content-type: charset=..., the XML declaration, or
a meta-tag) an encoding different from ASCII or perhaps UTF-8.

6) Section 4.3.6.2

The possibility to break the end-to-end security of an HTTPS
connection is unacceptable and must be forbidden. This jeopardizes the
set-up of mobile e-commerce, which had difficulties to get established
in part because of the point-to-point, hop-wise secure connection with
WTLS, and makes a sham of security for other applications that require it.

Besides, there is no guarantee that transformations performed by a
proxy preserve the content being exchanged between client and server
to a point that does not further disturb the secure exchange. As an
example, there is no explicit prohibition in the draft against turning
POST requests into GET ones, the resizing of images may make visual
captchas unreadable, and reordering elements may make forms or
security information difficult to figure out at the client side.


In general, I must state unequivocally that our experience with
current transformation proxies deployed throughout the world has
always been negative, since all proxies seem to transform original
mobile content regardless, with results ranging from passable to
outrageously unusable.  The draft, while an interesting attempt to
bring some order in the wild practices that abound in the mobile Web,
is still vague and incomplete in several points, and thus, in its
present form, may not stem some of the more egregious forms of
transcoding we have witnessed so far.

Eduardo Casais
areppim AG
Bern, Switzerland

Received on Tuesday, 5 August 2008 12:00:26 UTC