[liberationtech] Explaining Different Types of Trust?

[Guido Witmond]

On 04/16/2013 03:25 AM, Nick M. Daly wrote:
> Hi folks,
>
> Apologies for abusing the word "trust" some more, but I don't know what
> other word to use.  Feedback would be lovely.  Sorry for the cross-post.
>

Trust is earned, it can be given. It can never be forced.


> So, one of the goals folks worked out during FOSDEM was that each
> FreedomBox package should be able to explain to the user in a
> straightforward way (1) who the user is trusting, (2) for what purpose,
> (3) how that trust can be abused, and why such abuse would be bad for me
> (4).

"Explaining users" is one of the six dumbest ideas in Marcus Ranum's 
list on computer security.


> For example, with DNS requests (2), I trust my router, my ISP, my DNS
> host (possibly Google, if I use 4.4.4.4), and (if I'm unlucky) anywhere
> in-between (1).  Each of them can view the DNS requests I make and
> tamper with the responses (3), causing me to visit a fraudulent bank
> website, for example (4).  They could also record these requests
> permanently (3) allowing them to track (4) and advertise (4) relative to
> my movements.  Other harms based on that stored data are also
> imaginable, but perhaps too unlikely, in the average case, to be worth
> mentioning.
>

The average user *expects* the systems to be secure and it will protect 
him. Bad things only happen to other people.

Explaining the user all the parts that he is *required to trust* in 
order to get the security he expects is not going to help him.

Instead, it's going to give *fear*. The only way he can use the 
system/network is to be in denial mode.

The user will run away from the system that tries to help him be more 
secure (Freedombox) to a system that doesn't scare him 
(Windows/Mac/Google/Facebook).

Scaring will make our user vulnerable to phishing scams that suggest to 
have a solution but instead gets him deeper into trouble.


The DNS example above is a good example of all the parts that a user is 
*required* to trust. As you point out, the user is totally lost, 
security wise.

So instead of educating the solution is to make things secure by 
default. It's what users expect of their computers, anyway.

Our user expects his operating system and browser to validate all DNSSEC 
lookups. He expects a clear and easy to understanding error message when 
some validation fails. He wants a message stating. "Sorry you cannot 
connect to <example.bank> because the security checks have failed. It's 
not secure!" And don't give the user a button to override.

 From that security, our user can *gain trust* in the system to do his 
electronic banking safely, or to jabber with friends.



> Similar profiles can be drawn up for other services, such as Jabber,
> where an attacker can fake my buddy list and my buddies' conversations,
> and so forth.

>
> What are generic attacks that are service independent that would be
> widely useful here?  I'm thinking:
>
> - Can Learn (Profile)

To protect against profiling, there is only Tor.


With regards, Guido.