- From: Tom Hume <tom.hume@futureplatforms.com>
- Date: Tue, 24 Nov 2009 13:54:11 +0000
- To: Luca Passani <passani@eunet.no>
- Cc: public-bpwg-comments@w3.org
- Message-ID: <a293dbd10911240554j406f79f6t9547e043c8ddd81d@mail.gmail.com>
Not that I'm going to go around the houses with you on this one again, Luca... My point is, you're applying a double standard: in the case of probing you're expecting site authors to account for it (which as you say, they can do easily). In other cases (looking at different HTTP headers or adding a no-transform directive) you're saying it's unreasonable for them to be expected to make changes. I think either position could be consistent by itself, but together they're contradictory. 2009/11/24 Luca Passani <passani@eunet.no> > 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> >> >> >> > -- Future Platforms: hungry and foolish since 2000 work: Tom.Hume@futureplatforms.com play: tomhume.org
Received on Tuesday, 24 November 2009 13:55:11 UTC