Re: Input on privacy goal

[Sandro Knauß]

Hey,

> > Here are some thoughts on threat models for this, as a possible way to
> > better capture what we want to achieve.
> > 
> > (1) Public Wifi
> > 
> > Assume anyone can see your Wifi network traffic (e.g. via recent
> > vulnerabilities in WPA2). Using your device in such an environment should
> > be safe and not compromise your privacy any more compared to using a
> > wired network at home.
> > 
> > Possible counter-measures: Encrypted communication, VPN.
> 
> Since (I think) iOS 10, the Wi-Fi configuration gives pretty loud warnings
> if you connect to an unsecured Wi-Fi network. Perhaps the Plasma
> NetworkManager applet needs similar UI improvements in that area.

just to mark all non encrypted Wifi as insecure and mark everything with WPA2 
as secure is too simple. The most bars I now have also a WPA2 secured Wifi, 
you the the password by asking are looking into the papers laying around. But 
I never would trust those encrypted Wifis. Everyone you have the password can 
see my traffic, and as those bars never changing their password... I would 
like to see a way to tell the computer "kontact and owncloud-client should 
only be active for my home by default". Otherwise ask me, if they should go 
online. And at second level it would be nice to say, if I'm not at my home 
connection kontact should use this VPN to connect...

sandro

Re: Input on privacy goal

[Sebastian Kügler]

On Monday, January 22, 2018 7:14:27 PM CET Volker Krause wrote:
> Sure, I have specific plans too, I just wanted something to evaluate them
> against first 
[...]

That's awesome. Thanks Volker!
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: 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=151645518010920=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

signature.asc
Description: This is a digitally signed message part.

Re: Input on privacy goal

[Ivan Čukić]

Hi all,

My main target for this is improving the Plasma Vaults. There are
quite a few things in the works for after-the-LTS-release of Plasma
(kinda already done, but didn't want to merge for LTS):

- Forcing airplane mode (going offline) when certain vaults are open
(per-vault configuration)
- Support for gocryptfs (it recently received a favourable 3rd party
security audit) as the default encryption system

Other things will mostly be about usability.

Cheers,
Ivan

Re: Input on privacy goal

[Martin Steigerwald]

Hello Eike.

Eike Hein - 22.01.18, 13:49:
> I'm planning to continue my work to modernize the user interface of
> Konversation and adding Matrix support.
[…]
> It's my opinion that a Kirigami-based Konversation with Matrix
> support is currently the most viable path toward to meeting our
> needs and bringing privacy and security back to our communication.

I appreciate Matrix support! :)

Does that mean that KDE Telepathy is on its way out? I had the impression it 
did not receive much love since quite some time.

If its basically not maintained anymore, it may make sense to deprecate it 
once the modernized Konversation is out, as using an unmaintained  chatting 
stack is a privacy risk in it self.

Thanks.
-- 
Martin

Re: Input on privacy goal

[Eike Hein]

I'm planning to continue my work to modernize the user interface of
Konversation and adding Matrix support.

Based on the IM Survey we did recently spearheaded by Thomas Pfeiffer,
we know the community has a problem with the increasing fragmentation
and migration of KDE's comm channels to proprietary solutions like
Telegram, which can compromise privacy e.g. by requiring a SIM card
to make an account, among other concerns. According to the survey,
this does not sit well with the community.

On the other hand, the community also desires rich clients with a
nice modern UI and features like image sharing, on both the desktop
and handsets. Free solutions don't check all the boxes here at the
moment. The one that does it all is missing, and people are left
making a choice for either side of the divide this has created.

It's my opinion that a Kirigami-based Konversation with Matrix
support is currently the most viable path toward to meeting our
needs and bringing privacy and security back to our communication.


Cheers,
Eike

Re: Input on privacy goal

[Boudewijn Rempt]

On Monday, January 22, 2018 1:25:55 PM CET Sebastian Kügler wrote:
 
> So, can more people please share their plans, even if small, that impact
> privacy in KDE software?

Well... I don't really have plans. 

We fixed an issue last year where people's name could get leaked into saved 
images. 

We're considering currently building a welcome screen to help people 
understand that they need to open or create an image: one of the things we'd 
love to have in there is an rss feed with news from the krita website, but 
because that could be seen as phoning home, it probably won't happen.

Finally, last year's gsoc project for telemetry did not end up being mergable, 
so that's unlikely to happen. The student had not implemented it according to 
the telemetry policy.

-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

Re: Input on privacy goal

[Sebastian Kügler]

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?

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: Input on privacy goal

[Nicolás Alvarez]

> On 19 Jan 2018, at 14:58, Sandro Knau�  wrote:
> 
> Hey,
> 
>>> Here are some thoughts on threat models for this, as a possible way to
>>> better capture what we want to achieve.
>>> 
>>> (1) Public Wifi
>>> 
>>> Assume anyone can see your Wifi network traffic (e.g. via recent
>>> vulnerabilities in WPA2). Using your device in such an environment should
>>> be safe and not compromise your privacy any more compared to using a
>>> wired network at home.
>>> 
>>> Possible counter-measures: Encrypted communication, VPN.
>> 
>> Since (I think) iOS 10, the Wi-Fi configuration gives pretty loud warnings
>> if you connect to an unsecured Wi-Fi network. Perhaps the Plasma
>> NetworkManager applet needs similar UI improvements in that area.
> 
> just to mark all non encrypted Wifi as insecure and mark everything with WPA2 
> as secure is too simple. The most bars I now have also a WPA2 secured Wifi, 
> you the the password by asking are looking into the papers laying around. But 
> I never would trust those encrypted Wifis. Everyone you have the password can 
> see my traffic, and as those bars never changing their password...

This is not quite true. Being in a WPA2 network where everyone knows the 
password is not equivalent to being in an unsecured network. If it's unsecured, 
traffic is in plaintext (unless, of course, higher level protocols do their own 
encryption, such as TLS). A WPA network transmits traffic encrypted with 
negotiated keys, and you can't passively intercept it and decrypt it even if 
you know the password.

It *might* be possible to do a man-in-the-middle by running your own access 
point with the same SSID and password, and get the victim to connect to you 
instead of the real one, but it's much harder to pull that off.

> I would 
> like to see a way to tell the computer "kontact and owncloud-client should 
> only be active for my home by default". Otherwise ask me, if they should go 
> online. And at second level it would be nice to say, if I'm not at my home 
> connection kontact should use this VPN to connect...

Ohh, I'm interested in this feature too, for a different reason: choosing which 
apps can connect to the network when I'm tethered to my phone and using my 
horribly limited 3G plan.

-- 
Nicolás

Re: Input on privacy goal

[Valorie Zimmerman]

On Fri, Jan 19, 2018 at 12:24 PM, Carsten Pfeiffer  wrote:

> Am Freitag, 19. Januar 2018, 15:30:25 CET schrieb Volker Krause:
>
Hi,
>
> > Here are some thoughts on threat models for this, as a possible way to
> > better capture what we want to achieve.
>
> that's a good start!
>
> I'd like to add
>
> 6) Rogue local software
>
> Assume you run any kind of software not coming from a trusted source (your
> distribution). E.g. you clone a github repo and run the code. That code may
> pull in further untrusted dependencies (maven, node, ...). It should be
> easy
> to protect your personal data, kwallets, browser history, etc. and local
> network from that code.
>
> Possible counter-measures: easy and configurable sandboxing
>
> Thanks
> Carsten
>


On just this "rogue code" see this enjoyable post:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Valorie

-- 
http://about.me/valoriez

Re: Input on privacy goal

[Nicolás Alvarez]

> On 19 Jan 2018, at 11:30, 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.
> 
> (1) Public Wifi
> 
> Assume anyone can see your Wifi network traffic (e.g. via recent 
> vulnerabilities in WPA2). Using your device in such an environment should be 
> safe and not compromise your privacy any more compared to using a wired 
> network at home.
> 
> Possible counter-measures: Encrypted communication, VPN.

Since (I think) iOS 10, the Wi-Fi configuration gives pretty loud warnings if 
you connect to an unsecured Wi-Fi network. Perhaps the Plasma NetworkManager 
applet needs similar UI improvements in that area.

> (2) Stolen Device
> (3) Mega Corporations ("Google")
> (4) Global Surveillance ("NSA")
> (5) Targeted Surveillance ("Snowden")
> 
> What else? Which of those do we want to address? Do you think that's a useful 
> approach to guide/validate our work?

We may need more stuff related to our own services. Do we have a privacy policy 
in all websites that need one? What can we use logs for?

And maybe we should have a proper internal policy of what info KDE sysadmins 
are allowed to peek into, and for what purposes.

-- 
Nicolás

Re: Input on privacy goal

[Volker Krause]

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.

(1) Public Wifi

Assume anyone can see your Wifi network traffic (e.g. via recent 
vulnerabilities in WPA2). Using your device in such an environment should be 
safe and not compromise your privacy any more compared to using a wired 
network at home.

Possible counter-measures: Encrypted communication, VPN.

(2) Stolen Device

Assume your device gets stolen in a switched off or locked screen state. This 
should not result in a disclosure of personal data.

Possible counter-measures: Local encryption.

(3) Mega Corporations ("Google")

It should be possible to enjoy the benefits of state-of-the-art consumer 
electronics, communication and content without individual companies creating 
detailed user profiles.

Possible counter-measures: Free alternatives for proprietary services.

(4) Global Surveillance ("NSA")

Assume the entire Internet traffic being recorded, as well as deliberate 
attempts to break or weaken encryption.

Possible counter-measures: State of the art encryption, minimize network 
communication, Tor.

(5) Targeted Surveillance ("Snowden")

Could be politically motivated or industrial espionage, by an actor with 
significant skill and resources.

Possible counter-measures: ???

What else? Which of those do we want to address? Do you think that's a useful 
approach to guide/validate our work?

Regards,
Volker


signature.asc
Description: This is a digitally signed message part.

Input on privacy goal

[Sebastian Kügler]

Hi all,

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/

Specifically, I'm collecting input on the following questions / topics:

* What are your plans, plans within your subproject regarding privacy?
* What are, in your opinions the greatest challenges for KDE, within your 
  subproject or in general?
* How do you think we can get closer to our goal?
* Where do you think we stand currently?
* Anything else?

I know, I'm vague and this is a rather open question. I'm after a bigger 
picture and overview of what's going on in the community, knowing what's going 
on and what should be, and more buy-in from community members towards specific 
actions.

Thanks for your input already!
-- 
sebas

http://www.kde.org | http://vizZzion.org