Re: Feedback on content transformation guidelines ( LC-2066 LC-2067 LC-2068 LC-2069 LC-2070 LC-2071 LC-2073 LC-2072 LC-2074 LC-2075 LC-2076 LC-2077 LC-2078 LC-2079 LC-2080 LC-2081 LC-2082 LC-2083 LC-2084)

Tom Hume wrote:
> I agree, it can be done safely and easily - though many to date 
> haven't done so; in much the same way that site authors can 
> reconstruct original headers by looking at X-Device-User-Agent, and 
> prevent transformation by adding a "no-transform" header - safely and 
> easily.

I disagree. The onus of safeguarding mobile content sits squarely on the 
shoulder of transcoders and operators who deploy them.

It is not fair (nor reasonable) to force everyone to change the way 
their web applications work to avoid falling victim of the greed of some.

Luca


>
> 2009/11/24 Luca Passani <passani@eunet.no <mailto:passani@eunet.no>>
>
>
>     I agree that there may be trouble if one downloads a JAD file
>     multiple times.
>
>     I disagree that there may be trouble if a proxy hits:
>
>     http://www.acmilan.com/
>
>     in order to check whether a mobile experience is being offered or
>     not. The fact that there may be (easily identifiable) cases where
>     multiple GETs may change the status of the site, does not mean
>     that probing the site cannot be performed safely for all the
>     parties involved.
>
>     Luca
>
>     Tom Hume wrote:
>
>         I've seen mobile content services where repeat-GETs cause
>         problems. For instance:
>
>         1. Download services that limit the number of downloads (GETs)
>         to protect content assets;
>
>         2. Download services which trigger the build of an asset
>         server-side (e.g. JAR file for MIDlet) based on the User-Agent
>         of the first hit;
>
>         3. Statistical analysis of server logs where double-hits can
>         affect page views, etc.
>
>         All these are IMHO common techniques that I've seen more than
>         one provider of mobile content use.
>
>         2009/11/24 Luca Passani <passani@eunet.no
>         <mailto:passani@eunet.no> <mailto:passani@eunet.no
>         <mailto:passani@eunet.no>>>
>
>
>
>            Hi Mark, I am not part of BPWG, but I followed the work of
>         the WG
>            very closely and I think I can provide some of the answers  to
>            your questions (Disclosure: I am the author of the
>         Manifesto for
>            Responsible Reformatting,
>
>            http://wurfl.sourceforge.net/manifesto/
>
>            The Manifesto addressed the same issues CTG that is addressing
>            with overwhelming support from the community, operators and
>         a few
>            key transcoder vendors too)
>
>            comments (and answers) in-line
>
>
>            Mark Nottingham wrote:
>
>
>                * 4.1.5.1 "The theoretical idempotency of GET requests
>         is not
>                always respected by servers. In order, as far as
>         possible, to
>                avoid misoperation of such content, proxies should avoid
>                issuing duplicate requests and specifically should not
>         issue
>                duplicate requests for comparison purposes."
>                Existing proxies can and do already retry GETs; I'm not
>         sure
>                who you're trying to protect here.  
>            They are protecting Novarra Inc. ( http://www.novarra.com/
>         ). "GET
>            idempotency" is an excuse to kill a reasonable approach to test
>            whether a website has a mobile experience ready for visitors or
>            not. Proxies could make a request with unaltered HTTP headers,
>            ascertain that there is no mobile experience ready for that
>         device
>            and move on to spoof the UA string for that site from that
>         moment
>            on (if there is a mobile experience in place, then their
>            intervention is not needed and in fact totally undesirable).
>
>            The problem with this approach (for Novarra) is that this would
>            not allow their proxy to fool the website and extort full-web
>            content also in the presence of a mobile experience.
>
>            Please also observe that "probing" is what some commercial
>         proxies
>            do (and performance is not an issues, because nothing prevents
>            that a proxy caches the result of recent "probs" for a few
>         hours).
>
>
>                My concern is that Recommending this document will
>         cause more
>                harm than good to the Web overall (even if it does
>         represent a
>                consensus of sort among a more limited community).
>
>
>            I of course agree. Just wanted to observe how the "limited
>            community" is in fact "very limited", since it only
>         accounts for
>            the needs of some transcoder vendors and Vodafone. The
>            overwhelming majority of the mobile ecosystem hates transcoders
>            and support for the aforementioned Manifesto proves this.
>
>            Thank you
>
>            Luca
>
>
>
>
>
>
>         -- 
>         Future Platforms: hungry and foolish since 2000
>         work: Tom.Hume@futureplatforms.com
>         <mailto:Tom.Hume@futureplatforms.com>
>         <mailto:Tom.Hume@futureplatforms.com
>         <mailto:Tom.Hume@futureplatforms.com>> play: tomhume.org
>         <http://tomhume.org> <http://tomhume.org>
>
>
>
>
>
>
>
> -- 
> Future Platforms: hungry and foolish since 2000
> work: Tom.Hume@futureplatforms.com 
> <mailto:Tom.Hume@futureplatforms.com> play: tomhume.org 
> <http://tomhume.org>
>
>

Received on Tuesday, 24 November 2009 13:51:33 UTC