W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

RE: Mandatory encryption

From: Anil Sharma <asharma@sandvine.com>
Date: Thu, 19 Jul 2012 10:17:39 +0000
To: Willy Tarreau <w@1wt.eu>
CC: Roberto Peon <grmocg@gmail.com>, Paul Hoffman <paul.hoffman@gmail.com>, Phillip Hallam-Baker <hallam@gmail.com>, "grahame@healthintersections.com.au" <grahame@healthintersections.com.au>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Mike Belshe <mike@belshe.com>
Message-ID: <06923070D47780469EBD9A1CDABAB6D6197FDF45@blr-exch-1.sandvine.com>


-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Thursday, July 19, 2012 3:32 PM
To: Anil Sharma
Cc: Roberto Peon; Paul Hoffman; Phillip Hallam-Baker; grahame@healthintersections.com.au; ietf-http-wg@w3.org; Mike Belshe
Subject: Re: Mandatory encryption

On Thu, Jul 19, 2012 at 09:55:54AM +0000, Anil Sharma wrote:
> " in HTTP they always force safesearch to on in outgoing
> requests so that they rely on google's ability to filter out unsuitable
> contents. In HTTPS they obviously can't do this so google images then
> becomes a single-handed browsing tool."
> 
> Didn't understand this point? From compute server point of view (which is providing you search results) it shouldn't matter whether transport used was secure or not?
> Did I miss something?

When the request is sent in clear text, the proxy modifies it to force
"safesearch=on" in the requests so that Google refrains from returning
-----------------------------> Why can't TLS proxy do it ( anyways I thought the browser or the user decides it but even if lets its company policy and proxy does it for all the request)   Just trying to understand......

unsuitable contents. In https, it obviously cannot force that on the
users' request so the user has complete access to the whole internet
cached in "google images". There are places where this type of access
is not accepted at all so google is not in the SSL whitelist.

Regards,
Willy
Received on Thursday, 19 July 2012 10:19:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 July 2012 10:19:15 GMT