Input on privacy goal

[Volker Krause]

On Monday, 22 January 2018 13:25:55 CET Sebastian Kügler wrote:
> On vrijdag 19 januari 2018 15:30:25 CET Volker Krause wrote:
> > On Friday, 19 January 2018 14:49:58 CET Sebastian Kügler wrote:
> > > I'd like to collect some more input from the wider KDE community about
> > > our
> > > privacy goal for the next years. If you're unsure what I'm talking
> > > about,
> > > please have a look at
> > > https://vizzzion.org/blog/2017/11/kdes-goal-privacy/
> > 
> > Here are some thoughts on threat models for this, as a possible way to
> > better capture what we want to achieve.
> 
> [...]
> 
> excellent! I've added these threat models to the phabricator task at
> https:// phabricator.kde.org/T7050
> 
> > What else? Which of those do we want to address? Do you think that's a
> > useful approach to guide/validate our work?
> 
> This is something I want to direct at the community. We really need to get
> out of the mindset of sitting on our hands and waiting for others to start
> moving. This goal is not something that can be driven by just a few people,
> it needs a coherent movement by many of us. In that sense, there must be
> more input from people especially regarding specific plans, and if there
> isn't, we're collecting a whole lot of useful academic and probably
> technically sound opinions and ideas which end up bearing little practical
> impact.
> 
> So, can more people please share their plans, even if small, that impact
> privacy in KDE software?

Sure, I have specific plans too, I just wanted something to evaluate them 
against first :)

On-going work:
* Investigate what's possible regarding a free alternative to the digital 
travel assistance services like Google Now.
- extracting reservation information from booking confirmation emails: to make 
their life easier Google is pushing a structured data standard there, which we 
can use as well. We have flights, train trips and hotel bookings implemented 
for this. We also have a fallback extractor mechanism for providers not 
supporting this.
- augmenting itineraries with static information (such as the geo position or 
time zones of the involved airports/stations): implemented for airports based 
on compiled-in Wikidata data (ie. fully offline)
- augmenting with dynamic information (flight delays etc): no implementation 
yet, there is no free source for this data, but some providers (e.g. DB or LH) 
offer cost-free REST APIs that might be usable.

The code is in a KMail plugin right now (as the booking email is the entry 
point), but besides adding your trip to your calendar with correct timezone 
data and showing you the involved stops on a map it can't do much yet.
Lots of possible integration points of course (navigation to/from the airport 
using Marble and/or PublicTransport, a mobile itinerary and boarding pass 
management app, feeding the data into Mycroft, etc).

https://cgit.kde.org/kdepim-addons.git/tree/plugins/messageviewer/
bodypartformatter/semantic
https://cgit.kde.org/kdepim-addons.git/tree/plugins/messageviewer/
bodypartformatter/pkpass

This is addressing one tiny aspect of threat 3.


* The telemetry policy is still waiting for a final decision on how to resolve 
the Kexi exception issue.


Plans:
I'd like to look into better tools to verify our use of network connections 
and transport encryption. Ie. something that helps us to easily find our own 
bugs rather than find software that tries to evade detection.
- short and low-frequent connections (such as telemetry ones) should be 
detectable and not drown in e.g. the video streaming data
- what data am I leaking by DNS queries?
- are all connections encrypted?

tcpdump/wireshark produce way too much data and overhead, the eBPF-based TCP 
connection tracking example of the bcc tools looks very promising (and has 
found a few issues on a first test in the past), but for a long-time recording 
it's still missing aggregation, PID resolution, correlation with DNS queries, 
etc. Should be fairly straightforward to implement though.

- for encrypted connections, are we using the best possible cipher, and do we 
properly check the certificate validity? Essentially a client-side counter-
part to server scanners like https://www.ssllabs.com/ssltest/.

This looks a bit more tricky, I have no concrete idea yet about how to 
approach that.

My suspicion is that those two tools would find the occasional accidental 
http:// connection, but also show some shortcomings in our network stacks 
regarding things like CAA or encrypted DNS that we need to address deeper down 
in the stack. 

This would help to address aspects of threat 1 and 4.


Privacy is also a topic for the KDE PIM Sprint, see https://marc.info/?l=kde-pim&m=151645518010920&w=2 for some concrete plans/proposals. I'd expect that 
topics like Tor or VPN support would need to be addressed on a wider scope 
than just PIM though.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20180122/fb19a9e2/attachment.sig>