Re: Content Transformation Guidelines 1r

Jo, I know you are a clever, well-educated and eloquent man, so I can 
feel how frustrating it must be for you to be forced to write stuff like 
this in the vain attempt to make everyone happy:

"Since there doesn't appear to be a way in which the URI sent to the 
User Agent can be manipulated to preserve security related to same 
origin policies it is permissible for a CT proxy to act on content in so 
that security is nonetheless preserved as adjudged by conformance tests 
that are to be researched. If no such security tests can be found then 
there cannot be conformance associated with link rewriting and it cannot 
be permissible for CT proxies to do so"

wouldn't it be much simpler to state that HTTPS *MUST NOT* be messed 
with, and those who do it are simply doing it without W3C blessing?

may I remind you, and everyone on this list, that while a handful of 
transcoder vendor are trying to extort a CTG spec that supports them in 
their wrong doing, there is a whole ecosystem of developers out there 
who simply hate Novarra and this pathetically stupid technology which 
goes under the name of transcoding? 2 years after Novarra's infamous 
launch with Vodafone UK, you still have people who write (today!!!):

http://mobilesoapbox.wordpress.com/2008/05/04/transcoding-the-truth/#comments

"Hi,

I am facing somewhat different problem with novarra. Novarra sees fit to 
change RSS feeds to HTML so any AJAX / JSON web applications don’t work.

Having spent some 15 years in the industry, I have seen quite a few of 
these tardy, unprofessional and downright obnoxious services. However, I 
can’t blame them – they clearly have no idea what they are doing – if 
they knew something they would have done a better job with obeying 
standards. I blame operators who pay Novarra money to break all the 
rules and destroy the user experience.

Thanks"

and the previous comment deserves special mention too:

"As one of the tech leads in the biggest content-selling company in 
France (and well established in america), I can only confirm that we 
HATE Novarra. Their blabla is totally lies. Everybody in the mobile web 
industry hates them. Because of them, we loose 10s of hours trying to 
bypass their ugly transcoders. We want to have the freedom to name our 
wapsite as we wish, not with .mobi or other long names.
We produce wapsites optimised for every device, since we have our own 
handset database with all the properties of phones (useragents, formats 
supported, screen sizes, etc.); Novarra is breaking them badly. They are 
especially bad with CSS : they strip half of the CSS, making sites 
totally buggy (like an input in which you cannot enter any character 
anymore, or such bugs).
We had to search on the web in order to discover that they started 
transcoding sites on Verizon handsets without letting us know.
I still don’t understand why they don’t do it properly = check the 
markup we send, and “optimise” it only if it’s NOT WML or XHTML-MP.
It would be so much simpler that playing with headers and screwing up 
all sites.. there are specific mobile markups, so why the hell aren’t 
they checking if we use them ?
Silly Novarra, I hate you
T.Delerm (no, I won’t be anonymous)"

Luca

Jo Rabin wrote:
> Hello folks, a new draft available, taking into account everything up 
> to the F2F.
>
> You'll find it at
>
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090607 
>
>
> Diff to previous versions linked from the doc itself.
>
> Jo
>
>
> Known Dangling ends:
>
> a) Need to clarify that CT Dangling Ends
>
> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0167.html
>
> have all been dealt with.
>
> b) Jo's ACTION-934 Try to draft another doc to the TAG about D.1.3.2
>
> c) Discuss Francois's ACTION-925 on testability of link rewriting
>
> d) Discuss Eduardos's ACTION-929
>
> e) Any resolutions after the F2F have not been dealt with yet.
>
> Done:
>
> 1) Abstract - from Matt Womer
>
> inter-work? And it needs rewording to reflect bumping CP stuff into an
> appendix
>
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/090313#abstract 
>
>
> Rewritten omitting the reference to interworking
>
> However, note that Eduardo's ACTION-929 has not been discussed yet.
>
> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/929
>
>
> 2) A few typos, from Francois
>
> http://lists.w3.org/Archives/Public/public-bpwg/2009Mar/0108.html
>
> 3) ACTION-930 was a response to a crie-de-coeur from Rotan and has 
> resulted in a new section in the introduction
>
> Write something in the introduction about respect for CP prefernces, 
> respect for user preferences and the CP's ultimate sanction on the 
> degree of preference they are willing to accommodate
>
> 4) Resolutions from the 26th March (London F2F)
>
> http://www.w3.org/2009/03/26-bpwg-minutes.html
>
> (new section on "link rewriting")
>
> RESOLUTION: In the following and in all subsequent discussions Link 
> Rewriting is considered to include insertion of links and frame 
> flattening and other techniques that introduce the "same origin" issue
>
> RESOLUTION: Link rewriting is a form of transformation and at a 
> minimum is subject to the same limitations as other forms of 
> transformation described in this document
>
> RESOLUTION: Proxies MAY rewrite links, where content transformation is 
> permitted, providing that content domain origin distinctions are 
> preserved by the proxy such that browsers accessing content via the 
> proxy do not inappropriately misconstrue different content origins as 
> being the same and inappropriately share cookies, or allow execution 
> of scripts or do other things that cause security problems as a result 
> of not knowing that different origins are involved
>
> RESOLUTION: Since there doesn't appear to be a way in which the URI 
> sent to the User Agent can be manipulated to preserve security related 
> to same origin policies it is permissible for a CT proxy to act on 
> content in so that security is nonetheless preserved as adjudged by 
> conformance tests that are to be researched. If no such security tests 
> can be found then there cannot be conformance associated with link 
> rewriting and it cannot be permissible for CT proxies to do so.
>
> RESOLUTION: Include text on the following lines as a note under a 
> section on Link Rewriting: "Link rewriting is always used by CT 
> Proxies that are accessed as an origin server initially, e.g. which 
> provide mobile-adapted web search and navigation to the web pages 
> returned in the search results, or to which the browser is redirected 
> through the CT Proxy for adaptation of a web page. Link rewriting 
> *may* be used by CT Proxies acting as normal HTTP proxies (e.g. 
> configured or transparent) for the browser, but may not be required 
> since all browser requests flow through the CT Proxy."
>
> RESOLUTION: Proxies must never transform https content unless a prior 
> agreement has been reached with the specific origin server.
>
> but
>
> RESOLUTION: Interception of HTTPS and the circumstances in which it 
> might be permissible is not a "mobile" question, as such, but is 
> highly pertinent to our document. We are aware that interception of 
> HTTPS happens in the network today. We think that interception of 
> HTTPS is inherently problematic and may be unsafe. We'd like to refer 
> to more general conformance criteria to protocol based signalling 
> mechanisms to achieve this. Pending futher developments in this area 
> the practice of intercepting HTTPS links is strongly NOT RECOMMENDED.
>
> RESOLUTION: Add .mobi to the list of mandatory heuristics as it is a 
> stronger indication of mobile intent than many of the content-types 
> and DOCTYPEs already agreed - other URI patterns are more ambiguous as 
> to their intent
>
> ACTION-926: Inser sections under proxy decision to transform a. to 
> specify SHOULD NOT in the presence of the features listed at 
> http://www.w3.org/2009/03/10-bpwg-minutes.html and b. to include the 
> current cullets listed as heuristics
>
> RESOLUTION: We delete all non-normative heuristics and close issue-288
>
> RESOLUTION: Close Issue-284
>
> ACTION-927: To preface the first sentence in 4.1.5 with Aside from the 
> usual procedures defined in [RFC 2616 HTTP]
>
> RESOLUTION: Leave X-Device headers in as they add value and close 
> ISSUE-289
>
> RESOLUTION: Accept Jo's editorial changes detailed in email 13 mar 2009
>
> RESOLUTION: adopt the text as proposed by Eduardo and modified by Jo 
> regarding X- prefix, we will register the header with IETF and close 
> ACTION-912
>
> ACTION-931 Insert informative text in the relevant appendix describing 
> the use of 403 in declining to server content because of security 
> concerns or whatever
>
> ACTION-932 Specify what he means by the USer Agent editorial note 
> under 4.1.5 - really can't remember, note removed
>
> ACTION-933 Propose text for section 5 referring to \"reasonable terms, 
> timeliness, of access and so on, relating to the use cases of bug 
> determinations, testing and so on
>
>
>
>
>

Received on Monday, 8 June 2009 16:14:23 UTC