RE: [HTTPS] Thoughts on HTTPS Links rewriting

Here are some "non-contrived" examples from the U.S. where HTTPS
rewriting makes the sites more usable on a mobile phone:

--buy.com

--radioshack.com

--blockbuster.com

--staples.com

--oreilly.com

--acm.org

--ieee.org

--harryanddavid.com

--thenerds.net

--www.zipzoomfly.com (this one puts my phone in an infinite redirect
loop)

--bestbuy.com (now has a beta mobile site, but you are not redirected to
it and you can't buy anything on it--you have to call a phone number)

--circuitcity.com (redirects to mobile site but you can't buy anything
there; has a link to the full site, but that crashes the browser on my
phone)


All of the above sites, unless otherwise noted, locked up the browser on
my phone (a Nokia 6682) because there wasn't a mobile version.  Each of
them also has an HTTPS login (or "My account") link.

I didn't have to work very hard to find these sites--I just opened up my
webmail inbox and looked for junk mail and went to those sites.  There
were just a few sites that I tried that had mobile versions--the rest
didn't.  Most of these sites are well-known, at least in the U.S.  I'm
sure it would be easy to find lots more similar sites, especially among
less heavily trafficked sites (the "long tail").


Sean


> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Eduardo Casais
> Sent: Monday, December 01, 2008 6:58 AM
> To: public-bpwg-ct@w3.org
> Subject: Re: [HTTPS] Thoughts on HTTPS Links rewriting
> 
> 
> Tom,
> 
> It seems to me that your message got mangled during editing. Here are
some
> comments.
> 
> > On (a):
> >
> >1. If the end-result of HTTPS rewriting is a poor user
> >experience (thanks to broken scripts, missing variables)
> >then I think that's no different from transcoding in general.
> 
> Correct, this is no different than transcoding, and my point is that
the
> CTG should not deal with specifying how to perform specific
> transformations -- whether it is https URI rewriting, character
encoding,
> markup conversions, table linearization, image rescaling, cookies
mapping,
> or anything else.
> 
> >On (b), it seems this is no different to any proxy
> >operation.
> 
> Correct, so why are the CTG singling out https rewriting  without
dealing
> with other security issues as well? My proposal is to handle all these
> aspects in one section "security considerations".
> 
> >On (c), I agree, though can't see how (5) will be
> >reached.
> 
> Probably thus:
> no-transform in requests => requests upstream no longer get modified;
no-
> transform in responses => responses downstream no longer get modified.
> 
> >On (d), I can imagine a user case. Many sites use
> >HTTPS on simple login forms as gateways to the rest of
> >the service. I'd be personally happy to login to Amazon,
> >for instance, using transcoded HTTPS. I'm not sure I
> >agree with the argument that this is a contrived use case.
> 
> So far, only abstract justifications have been provided. Whenever a
> concrete case is proposed as an example, it appears to be artificial,
as
> there is always a pefectly valid and usable mobile alternative. Thus
for
> Amazon:
> 
> "A different version of this web site containing similar content
optimized
> for screen readers and mobile devices may be found at the web address:
> www.amazon.com/access"
> 
> BA.com had been mentioned earlier -- the BA site has a mobile-specific
> version. Web-mail from a Nokia 6230i had been mentioned -- this model
has
> a mobile-optimized e-mail client. And so on, and so forth.
> 
> A non-contrived, reasonable, real use case justifying https in the
absence
> of a valid mobile alternative proves elusive.
> 
> 
> E.Casais
> 
> 
> 
> 
>

Received on Wednesday, 10 December 2008 22:05:03 UTC