Re: What will incentivize deployment of explicit proxies?

It's hard to make assertions about the UX without knowing how often 
you're going to come up against a proxy that you haven't seen before. We 
are willing to cooperate much more with a "first time wizard" than with 
something that pops up every few minutes.

The only TLS proxy I ever interact with is on the wired LAN at work. So 
if I get a new computer, I have to teach it only once about a proxy (or 
install the CA certificate with a MitM proxy). If that's all that is 
going to be, we can go with a UI like this

+
| WARNING
|
| You can't access your destination: https://www.facebook.com because a 
TLS proxy is installed on this network
|
| The proxy is authenticated, and is called "sslproxy.example.com". 
Working through this proxy would mean:
|  * that all your SSL traffic is decrypted by the proxy
|  * that all your personal information, passwords and credit card 
numbers are visible to the proxy
|  * that the proxy could potentially impersonate you for purposes of fraud.
|
| This browser is blocking communications since we cannot ascertain 
whether this proxy is harmful or benign.
|
| TLS proxies can only be used if they are configured. To learn more 
about trusted proxies, click here
+

I think users can live with that, and read the help, and go to the 
Tools->Options, or Safari->Preferences, or about:config and set that 
proxy. This is assuming it's a very rare event. If we get TLS proxies at 
ISPs, Coffee shops, airports, hotels, and schools as well as workplaces, 
we'll have to figure something else out.


On 7/12/13 1:08 AM, Tim Bray wrote:
> Whatever we ask people, a very high proportion are going to take the 
> default. This is independent of how much work you put into the UX. 
>  Thus, it’s very very important that we design things such that the 
> “default default” is safe, and that it’s difficult or impossible to 
> configure a network installation with unsafe defaults.
>
>
> On Fri, Dec 6, 2013 at 2:42 PM, Yoav Nir <synp71@live.com 
> <mailto:synp71@live.com>> wrote:
>
>     "Don't let anybody kid you. It's all personal, every bit of business."
>
>     In this case, I disagree with Martin. This is not a problem that
>     we can avoid externalizing. Deciding whether a particular proxy is
>     acceptable to the user of a browser requires information that we
>     don't have. We don't have it at the IETF, and we don't have it
>     where browsers are developed.
>
>     A browser can learn of the existence of a TLS proxy. This
>     information may come from an HTTP code, a TLS alert, DHCP, DNS, or
>     whatever other discovery mechanism we can think of. Whether this
>     proxy is acceptable depends on so many factors:
>
>      * Who deployed this proxy? (can probably be deduced from name in its
>        certificate, but only sort-of) Maybe your workplace is acceptable,
>        but the ISP or some other workplace is not.
>      * What is it doing with the cleartext traffic?  Caching? Filtering?
>        Recording? Looking for terrorism/criminal activity? Assuring a
>        non-hostile workplace?  There are no technical ways to know these
>        things. You'll have to learn them by social means - ask the IT
>        person, ask your boss, require by law all installed proxies to
>        disclose what they are doing. None of this can be done by Will or
>        his security team.
>      * Does the product used for the proxy have a recording function that
>        can be used in case of a legal mandate?  If so, what procedural
>        mechanism protects the users from someone at IT using it to spy
>     on them?
>      * Does the product used for the proxy have a backdoor for
>        interception?  Will and his security team don't know. The boss and
>        the IT person may not know that either.
>
>     It's a complex decision affected by many objective factors and
>     some subjective attributes of the user. This is not a decision we
>     can make on behalf of the user. This is very different from
>     reporting on a bad certificate.
>
>     Hopefully, this will be a rare decision that users don't have to
>     face every day.
>
>     Yoav
>
>
>
>     On 7/12/13 12:12 AM, William Chan (陈智昌) wrote:
>
>         Hey hey, there's no reason to make this personal :) I never said I
>         have no responsibility here. I just tried to make a funny quip
>         that
>         the...more passionate factions of the larger Chromium project
>         will be
>         very...passionate in their response to certain ideas. Is there a
>         reason you wish to make this about me all of a sudden?
>
>         Let me be clear, I in general think it's terrible to burden
>         the user
>         with decisions which they are largely unable to reason about.
>         And I
>         think it's wrong to expect them to have the knowledge to
>         reason about
>         it. And I disagree with the argument that browser vendors must
>         provide
>         all possible configuration options so users can do whatever
>         they want.
>
>         On Fri, Dec 6, 2013 at 1:27 PM, Martin Thomson
>         <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>
>         wrote:
>
>             On 6 December 2013 12:26, Werner Baumann
>             <werner.baumann@onlinehome.de
>             <mailto:werner.baumann@onlinehome.de>> wrote:
>
>                 [...] the dogma that users are stupid.
>
>             Not stupid, never stupid.  It's respect.
>
>             UI surface area imposes costs upon users.  We cannot -
>             should not -
>             externalize our problems by shunting them on users.
>
>             This isn't purely a security problem either; there are
>             security
>             aspects to this, but they aren't the only concerns.  I
>             expect better
>             of Will than to try to shift focus onto some faceless
>             "security team",
>             he owns some responsibility here too.
>
>
>
>