[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Freedombox-discuss] Explaining Different Types of Trust?



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.

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).

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.

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)
- Can Influence (Lie)

What others would we need to cover all our (generic) bases? The
important bit is to list out the attack surfaces and explanations, on a
per service basis.  Would it be possible to include generic explanations
that can apply between services that cover the same purposes?  How would
we organize this, at a framework level?

I appreciate your thoughts and your time,
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130415/3c82bd55/attachment.pgp>


Reply to: