Meeting of the GNOME Privacy BoF during GUADEC, 2014-07-31

Original: https://etherpad.mozilla.org/xtbteSZ2ih

What's broken?

Epiphany

• Epiphany SSL/TLS handling is not optimal
• Accepts self-signed by default (good)
• Does not staple self-signed (bad)
• Does not report to user if site changes from CA-signed to self-signed (stapling again)
• Behaviour should be modeled around the SSH behaviour, or "trust on first use". Accept quietly by default (leap of trust) store the cert, and move on.
• User chrome should not indicate self-signed as secure, or less secure than HTTP plain text.

Some GNOME apps are leaking private information

• gnome-weather (or libgweather) - leaking location in clear text

  • https://bugzilla.gnome.org/show_bug.cgi?id=734048

  • Station => NOAA cleartext (Invalid CN for SSL - akamai)

  • GPS Position => yr.no Cleartext (No SSL for web UI, No SSL for API)

  • Leaks even when NOT using weather app.
• gnome-music: - Always fetching music metadata at start, cleartext (SSL avail)
  • Grilo plugin
• gnome-maps:

  • Tiles / GPS => mapquest, cleartext (SSL avail) Routes => graphhopper, cleartext (SSL not avail)

• Gravatars (commonly used by many apps, has SSL support available, cleartext, leaks address book & email addresses of others.)

• WiFi:

  • - MAC Address is static (we should randomize at least on scanning, like iOS does)
• Sandboxing based on BTRFS still working
  • Discussion about the suitability of btrfs
  • Development, teams, resources on btrfs / production

• SELinux is not really doing its job: https://bugzilla.redhat.com/show_bug.cgi?id=1112382

• Applications using disk as a backing store, e.g. terminal content.
  • Create an ephemeral encryption key at session startup for applications requiring on-disk storage of transient-but-sensitive information
  • Mount encrypted filesystem at a known location - encourage all applications to use that path for their temporary storage.
  • XDG standard dir for this?
  • Fuse-encrypted/library approach -- find *some* unprivileged way to set up encrypted filesystem.
    • fuse might cause pain
    • gvfs?/library
    • library solution instead?
  • Isn't some part of the application framework privileged anyhow (launching/application control/monitoring) ? Possibly not requiring filesystem related capabilities however?

Solutions

Audit / Formalized

• Tails project? They'll have a good idea of what leaks information.
• Reach out: Tor browser bundle to create an app

Audit codebase, especially for usage of HTTP / port 80

• Start on grilo, plugins, libfolks.
• Empathy? Telepathy / Evolution Data Server / Folks / Avahi
• Use of dictionaries?
• extensions.gnome.org
• TLS update?
• Can gnome.org provide a proxy service with SSL for other APIs?
• Talk to service providers, encourage them to enable SSL
• Wrapping in SSL is not enough, but it's a first step.
• Switch Maps to use raw data from OSM + client side rendering

Add GPG setup in first-login wizard?

• (See section below)

Sandboxing applications

• (See section below)
• Consider (internally) proxying all network access
• Consider disallowing access to localhost. Motivation: "Fake a system dialog, ask user for their password and SSH into localhost (thus circumventing the sandbox)

Sandboxing legacy applications

• Private image for each, using system mountspace to isolate.
• FUSE filesystem that only shows some parts of /dev/usb and /home/$USER.
• Poor UI.
• Probably needed due to large amounts of legacy apps.
• Legacy app sandbox will get simpler things.
• Can give home dir access and some others.

Randomize MAC address when scanning for WiFi access points

NetworkManager Tor integration with simple and easy to use UI

• Managing expectation of Tor integration. Avoid "I am using Tor thus I am safe"

Replace the X window system with Wayland

Coverity reports for Gnome

• Do we have them?
• -Werror in build.gnome.org
• clang builds in build.gnome.org

What works?

• Captive portal detection?

Setting Expectations

• Re-framing things into Safety.
• Safety is for people, Privacy is for paranoids and Reporters.
• Define specific everyday examples, like identity/credit card theft.
• Important to use words that imply safety and emotional state
• Privacy perfection is not a possible goal to start with.
• Make sure we have basics sorted.
• Degrees of safety.

Sandboxed applications / Different security models

• Shitty software that forces you to upload private data to do things
• "Like us on Facebook to get access"
• "To keep playing this game, download this social app"
  • "Coercion vs. Consent"
• We should ship "preset auth" capabilieites ( signed? )
  • to avoid asking the user unnecessarily for permissions
  • Video conference app should always have permission to use video
    • If signed and trusted by "gnome.key" , permissions are auto-allowed
    • Otherwise ask.
    • Google has been solving this for some time, capabilities
    • Look at other implementations. We are not more qualified than others, can't say that our solutions are "better" than anyone elses.
  • We need a permissions model
    • We need UI designs
    • We need research
    • Not getting anywhere today.
    • Upfront vs. interactive?

    • Give enough metadata to the user on requests ("Do you want to allow the website at http://blah to use the camera?")

• We need a kind of system indication:
  • "Camera being used" that shows which application uses it. See volume (Apps using sound), and similar indication for other sensitive services
  • Tie usage to window chrome?
• Background audit/logging of accessed services?

  • Work already done by Allan Day: http://blogs.gnome.org/aday/2014/07/23/sandboxed-applications-for-gnome-part-2/

Should we add GPG setup in first-login wizard?

• Gnome Software => Which vendors do we trust? Gnome.org signatures are good by default?

• Trust random vendor Yorba? Leap of faith / trust on first use?
• Reuse GPG web of trust for validating sandboxed applicaitions?

• "Accept Gnome as a trusted vendor" <- sign, set trust

• Reuse GPG infrastructure, separate key for each machine?
• Try to avoid reinventing the wheel.
• Reinventing the CA model with GPG?

UI designs needed

• Client side decorations mean the app can fake system dialogs. That's not good. We need a design to prevent this.
• Sharing / File contents / data
  • optionally scrub personal information
    • Twitter wants your cat pictures. Give them your location too?
  • optionally show geolocation on a map, (or automatically, if UI design allows)
  • Content selection designs (Pictures. Videos, Contacts, Documents)
• In the window's decorations(?), show which services the application is using ("using the camera", "using the contacts list") so you don't forget which permissions you granted across the whole set of apps.
• When asking for permissions to access a service (contacts list, webcam, etc.) do it contextually, not at installation time, so you know exactly why the app wants to use the service.
• Grant / Revoke permissions for sandboxed apps
• Clipboard design needs to be figured out. How does an application request to paste text?

Trust models

• Matthew Garret suggests taking contact with various research groups, in order to build better models.
• Interface could show preview,
  • Surprising: User did not give permission yet but we turned on the camera anyway, during "do you want to let $app use the camera?"
  • Mitigation / Check my hair-button?
  • We should be careful to only turn things on in response to user action.
• Nagging vs. Default
  • Should we ask people constant questions or not?
  • Different people, different needs

Pattern Language

• Consent with the user
• Respect the user's agency
• Maintain the user's safety
  • Sanitize data to be shared
  • Non-spoofable applications
    • Signed identities for applications
    • D-Bus services for sharing data
• Example:
  • Agency: "I want to share pictures" Safety: "I don't want my privacy violated" Consent: "What metadata do you want to share in your pictures?"

Sharing discussion

* App wants to share something to somewhere

• should app get list of available shares?
• should the system push such?
• Solutions
  • Sharing/holding area suggestion, seems cumbersome
  • clipboard/recent files
  • david richards had a solution in nautilus; when an item is chosen, explicitly ask what to do with it

  • find file => insert into X application

  • rather than fork out and select files

Planning courses of action

• GNOME Goal?

Documentation

Policy Framework

• "Privacy mode : Enabled?"
• Applications should be aware
• Over-engineering: mechanism that shows metadata, could queue/centralized
  • allow/disallow, always through tor/central proxy
  • fine-grained.
• UI for Privacy / sandbox permissions (Showing the user / giving expectations)

Points of action

• Start on documentation for developers/interns
• writing proposal about research/interaction
• contact engagement team
• contact design
• file bugs
• Find research groups

  • Spid: asks bensessa & Klaus Kruse

  • Matthew G. : Cambridge
  • Garret L. : ...?
  • Federico: Justin Troutman
• Request that the board form a privacy working group to define standards for behavior of GNOME components
  • Permit release team to merge privacy patches if some maintainers are unwilling / uncaring about privacy as it affects users.