[Pkg-privacy-maintainers] ITP: intel-me-cleaner -- under the umbrella of this team?

[Daniel Kahn Gillmor]

On Tue 2018-10-09 16:04:15 +0200, intrigeri wrote:
> Georg Faerber:
>> I've took over the ITP of intel-me-cleaner [1], after offering help some
>> months ago.
>
> Excellent! \o/

agreed \o/!!  thank you georg!

> With this in mind, it seems to me that some of the threat models in
> which people will bother using me_cleaner fit very well into the set
> of use cases our team is supporting.  So I take back my initial
> objection to this proposal :)

:) -- i agree with intri that this is a tricky balance.  the traditional
"security" team doesn't look at systemic issues the way this team seems
inclined to look at them.  Rather, they look at very tightly-controlled
notions of a "security vulnerability":

 * does a piece of software do what it claims to do?

 * can untrusted inputs lead to modifications of trusted components?

 * does it leak information it claims to keep confidential?

 * does it correctly represent the security properties of a piece of
   data or a component to the user?

in contrast, the pkg-privacy team seems more interested in
bigger-picture questions, (as well as more opinionated, pro-active
users):

 * does a package help to mitigate unintended information leaks?

 * does a package help people to be indistinguishable from a large mass
   of other users?

 * does a package help in avoiding leaving local state on a machine?

 * does a package help users identify information leaks?

 * does a package modify another package to put it in a more thoughtful
   mode?


Note that you can solve some "security problems" (in the former set) by
changing documentation or intent -- if a word processor doesn't claim
that it keeps the author's name private, then it's not a security
vulnerability to leak the author's name.  With a privacy focus, the
upstream package doesn't get to make that decision.

moreover, privacy is generally an interdependent, interconnected problem
space.  If my privacy and data protection practices are weak, that has
an impact on everyone who i share data with.  So from a privacy
perspective, we can't afford to take a narrow view.

> (Tangentially related: at some point I'd like us to collectively think
> about where we should focus our energy. Seeing dkg struggle mostly
> alone with Enigmail maintenance is heart-breaking and makes me wish we
> could take a step back together and prioritize which parts of the
> ecosystem we feel responsible for most.)

i really appreciated intrigeri's sympathetic ear. it actually helped me
a lot to talk to him (and a few other good people) about the details of
the technical struggles i was going through with enigmail and GnuPG.  I
don't know whether they were in enough detail to be considered "rubber
duck" sessions, but they were certainly useful for me in getting things
organized in my head (as well as a chance to vent about frustrating
technical choices).

You'll be happy to know that i've proposed updates to GnuPG for stretch
(https://bugs.debian.org/910398) that, if accepted by the release team
(or if pushed forward by the security team, despite not fitting narrowly
in the definition of security fixes) should permit inclusion of enigmail
2.0.8 in stretch.

I welcome feedback on that ticket, if folks have the time or inclination
to review it.

To the extent that this team can offer opportunities for mutual support
-- even just in the simple form of listening and asking the right
questions -- i am grateful for it.

     --dkg