W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Should we discuss "split UAs" in the context of proxies, was: Proxies (includes call for adopting new work item, call for input)

From: John Mattsson <john.mattsson@ericsson.com>
Date: Wed, 25 Jun 2014 10:48:47 +0000
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>, Julian Reschke <julian.reschke@gmx.de>
CC: Eric Rescorla <ekr@rtfm.com>, "Diego R. Lopez" <diego@tid.es>, "Martin Thomson" <martin.thomson@gmail.com>, Martin Nilsson <nilsson@opera.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-ID: <CFD07250.198D2%john.mattsson@ericsson.com>
Given the huge privacy implications alone, I would say that either:

- the protocols need to be standardised
- or the cloud part of the browser needs to be downloadable and deployable
by the user and third-party cloud providers.

A data center implementing the proprietary cloud part of the browser will
be an excellent information source for organizations doing pervasive

Just being transparent and letting the user (whether it is an person or an
enterprise) be able to turn off the feature is not enough. Just as the
user of the browser can choose which device to run the browser on, the
user must be able to choose which cloud to run the browser in.

John Mattsson

On 23/06/14 15:45, "Nicolas Mailhot" <nicolas.mailhot@laposte.net> wrote:

>Le Lun 23 juin 2014 15:04, Julian Reschke a écrit :
>> - think about why browser developers deploy non-standards-based proxies.
>> Some obvious reasons are:
>> 1) so that they can optimize the protocol (performance, security),
>> 2) to simplify configuration (a check box is simpler to explain than a
>> proper proxy config UI).
>3. they found like everyone else the current standard does not permit
>deployment of effective proxies without cheating (lack of reliable way to
>express trust, lack of reliable way to convey errors, lack of any decent
>browser UI, browser refusal of TLS termination)
>4. it's easier not to ask permission of anyone least of all the user
>5. natural developer bias for internal coding instead of something else
>Nicolas Mailhot

Received on Wednesday, 25 June 2014 10:49:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC