[Pearg] PearG IETF 103 notes

Corinne Cath <corinnecath@gmail.com> Thu, 08 November 2018 02:59 UTC

Return-Path: <cattekwaad@gmail.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D544A130F02 for <pearg@ietfa.amsl.com>; Wed, 7 Nov 2018 18:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PORKrOBQgM-a for <pearg@ietfa.amsl.com>; Wed, 7 Nov 2018 18:59:39 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F8D130EF7 for <pearg@irtf.org>; Wed, 7 Nov 2018 18:59:38 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id f1-v6so524438wmg.1 for <pearg@irtf.org>; Wed, 07 Nov 2018 18:59:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hc+znZvWc6a9ho9JtdA8enU/B87Oq1m/59dpZ5VpNZI=; b=dVuP3FSeULzFNAl+UaUAZnSFLjqK0ndVPvIxUIFFKTZjklP1QxYNDgWb22STzbOqL8 DxTVRelbCNf6eX/L9Wz0qD0AUo+ZOVvyE5RQVbuyGRjx3mxWg6eKeay03RYkxNiocy1R hmIT3bd7GoybuLUcPl5Tx+J5xSwrhVkJCuGIn2uv+bTqVluQ+Vb8KRYUy8JdSW/kTUyj AKx3XLCyJSzGIaLEKN6kaT+l6I3RhQHgUa6QJiVcgsZSCx7NuX7UuYFLXajQK3GDRV14 7Mldq13iGitqGOsLIjWEIkrqDBmwUsvwtHUHvsg0sBra6IjTBLrYdas0Hl1+exdmBztB Pw0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hc+znZvWc6a9ho9JtdA8enU/B87Oq1m/59dpZ5VpNZI=; b=odc+cvjiruwObbFxCFr6lnCsxWfy+N8tCeHIiFgZn2Ki+DRn2MdS/tzsW72BwWXjv3 slTG8pF8Fmqkke+ffEkN6HmJF50EXmtYmp/JQi+6lGCTDtdfgIKd9lZBdbgIq2j0mr3m G+nyxaqZIeRPlqyGperBoBsuEFhIJWOWx29qFd5ka8guNLV+QLqrNBVrgr4C0hHRw79W bka7IbsterFyHtrAYQodrjMcM22aq4D30af85RF6pV+1c7KonTPPJx85WMJyr5Dwg4hO x8Lgm9Lc9R76/IdBTV9y9I3aqZSLnQZYhTpskb7nFjhcU5oC8pohNvQOweccF4vddR7v RotA==
X-Gm-Message-State: AGRZ1gLlPOLbJyLbp5lXMx2MXFi6EunGAAgJSPR/AjqPT6PO6/k00lHt JnAFsUx8o9nM8QedrcX3rwl4A9Ej611zF+UoAxj6Jw==
X-Google-Smtp-Source: AJdET5dFWsMyZt6zZZr0bok+cg1ZbB+2ipWS4lBRidAGh97xRpyjbjGwXkVvj6rapzppHb5Fhq9P5kAjhGQxKGhI2TU=
X-Received: by 2002:a1c:6754:: with SMTP id b81-v6mr2150585wmc.104.1541645977072; Wed, 07 Nov 2018 18:59:37 -0800 (PST)
MIME-Version: 1.0
References: <CAD499eL+ND2HRBFau=3p4j621wzjbRLxTMZoH390sHO4gJUu-w@mail.gmail.com>
In-Reply-To: <CAD499eL+ND2HRBFau=3p4j621wzjbRLxTMZoH390sHO4gJUu-w@mail.gmail.com>
From: Corinne Cath <corinnecath@gmail.com>
Date: Thu, 8 Nov 2018 09:58:59 +0700
Message-ID: <CAD499e+yvq6=rM7d0vVo0pKizSr5inNmyX3Aat991E7uOFPtfw@mail.gmail.com>
To: pearg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000d53aa4057a1e6c2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/dufsxosoduVSoMFk9qNiPR97Oxw>
Subject: [Pearg] PearG IETF 103 notes
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 02:59:51 -0000

hi,

Please find below the notes I took during the inaugural PearG meeting
yesterday.

Ommissions, Dutchisms and mistakes are all mine.

Best,

-- 
Corinne Cath - Speth
Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: ccath@turing.ac.uk & corinnecath@gmail.com
Twitter: @C_Cath


*Administrivia*



*Charter:*

Mic-line:

Q: how do you define privacy? Is it about protocols? Maybe look at the
business model of data monetization.

A: yes, the privacy of protocols but we will also look at the application
layer.



Q: I thought it was notable that privacy beyond just confidentiality was
highlighted, but no particular research items or topics seemed to be
suggested.



*Presentations:*

Presentation 1: Bennett Cyphers (staff technologist) from EFF on Privacy
Badgers

-       EFF is member funded non-profit

-       Privacy, free expression and innovation



Context of privacy badgers: a story of how sometimes protocols are not
enough.



2009 – 2012: DNT and the dream of a universal opt-out. Let’s do this.
Industry was interested too, in order to pre-empt (more) regulation,
amongst other reasons.



2012 – 2018. Turn around on DNT in late 2012 because things were breaking
down. EFF saw need for other way to allow people to opt-out of tracking.
Privacy badger is born.


Privacy Badger:

- Both sticks and carrots (stop non-consensual tracking, spread awareness,
promote DNT compliance, publish trackers who don’t DNT by blocking them)

- But faced constraints as small non-profit.



It turns DNT on in your browser.



Next steps: Badger Sett

-  Pre-train privacy badger on popular sites

-  Use privacy badger to survey the web

-  Test out new heuristics and measure the effectiveness

- Privacy Badger mobile is needed bc of the importance of mobile browsing
and apps.



Mic open:

-    Privacy badger as part of the W3C DNT, why not?

-    Privacy sett does more than you mentioned in your talk

-   Interaction with other extensions sometimes is a problem

- No telemetry data back to EFF, so your model of doing your own surveying
of the web is great.

-  How much of cat and mouse game is it? A: it’s a pretty small extension,
add-blockers operate on such a scale that they consider it to be much work
to avoid privacy badger.

- Do you also provide guidance for privacy-preserving website? A: We refer
to the DNT policy that is available for people who are interested in
guidance.

- How does it interact with add-blockers? A: we don’t block adds perse,
because they also track. You can also auto-adjust your settings.





Presentation 2: Sofia Celi & Jurren van Bergen (Centro de autonomia
digital) No evidence of communication: Off-the-record messaging protocol in
version 4 (OTRv4)

-       Comes out of an academic paper

-       Provides encryption w forward secrecy; authentication, deniability.

-       Different version

-       Other protocols drew inspiration for it (like signal)



Why version 4?

-       Deniability is crucial

-       Has a specification

-       Can find more info on the git repo



Mic open:

-  Work in IETF on MLS, how does it relate? A: MLS does not provide
deniability.

-  MLS wants to improve crypto, so it would seem that you have the same
security guarantees, maybe you want to have the same kind of scrutiny
applied to your stuff. We are an inspiration protocol.

- Can you explain what is message and participation deniability? A: it
means that no one can prove you participated and that nobody can prove that
you sent that message.

- MLS is agnostic on deniability currently. We would love to have your
participation in the MLS working group.





Presentation 3: David Oliver (Guardian Project) pluggable transport
(obfuscates the address and network flows, to prevent DPI.) Surveillance is
bad. Privacy is core to enabling human rights. Guardian Project focuses on
mobile operating systems.



DPI:

-       IP was to route, but routing data got weaponized.

-       DPI of traffic analysis, you can see the content of every packet in
your traffic

-       Encryption also adheres to recognizable patterns.

You can defend through obfuscation:

-       Service address

-       Content of the packet



What is suspicious develops fast and deployment of work should hence also
be faster = pluggable transports.



Mic open:

- Tensions between scale and half-life of mechanisms, the more successful
you are the quicker you will have to turn over. A: yes, we are on the
cutting edge and we expose a lot of problems so others can get involved.

- Could you make all of the normal things the same? A: good point, lets
talk offline.

-  Transport services working group might be relevant.

- Have you thought of use-cases where both end-points are compromised? How
do you detect anthrax and bombs (in the mail analogy). What about security
concerns and not just privacy? A: primarily, with the earlier version the
net-effect – we are not exposing anything that previously got exposed.
Let’s take it offline.

- What if you want to inspect traffic for child pornography? A: I can’t
speak for the implementers. There is a tension.


Presenter 4: Gunes Acar paper on Battery Status not included: assessing
privacy in web standards New web features lead to privacy concerns.

W3C has a self-review questionnaire. Came out of the privacy interest group
(PING).



Battery status API introduced in 2011. New research shows multiple privacy
vulnerabilities.



Mic open:

- Recommendations on measurement are relevant. Participated in it 8 years
ago. I think this should not be standardized. Because there is no way of
having the info in the API without leaking. But drive in the W3C was very
strong. This is an important part of history on device API. Our threat
model understanding is better now but it remains a back-and-forth.

- PING group is very happy with this research. Security and privacy
questionnaire in W3C is currently being updated. We need people to get
involved in the work. We should reach out early.

-Implicit assumption in this work that API enable this kind of
fingerprinting are bad, but that’s not the consensus of the browser
vendors. It is not practical to prevent it in many cases.