Profile picture
Alec Muffett @AlecMuffett
, 39 tweets, 10 min read Read on Twitter
1/ Applying this idea to WhatsApp, it would mean that—upon receiving a court order—the company would be required to convert a 1-on-1 conversation into a group chat, with the government as the third member of the chat. But that’s not all.
2/ In WhatsApp’s UX, users can verify the security of a conversation by comparing “security codes” within the app. So for the ghost to work, there would have to be a way of forcing both users’ clients to lie to them by showing a falsified security code, ...
3/ as well as suppress any notification that the conversation’s keys had changed. Put differently, if GCHQ’s proposal went into effect, consumers could never again trust the claims that our software makes about what it’s doing to protect us.

- Nate Cardozo, @EFF
4/ MUFFETT NOTES: one matter that I have not seen discussed in either the @EFF article, or in the @NCSC/@GCHQ @lawfareblog posting that described it, is the relative complexity (impossibility?) of maintaining secrecy of the list of "people who are under surveillance"
5/ The nature of E2E encryption is that it is driven by the client devices - ie: phones - yet logic dictates that in the "ghost" scenario there must be special configuration pushed out to the devices of a select few surveilled individuals
6/ As such - to start with the worst-case comedy scenario, there would be a WhatsApp client-config API endpoint which anyone in the world could hit, to either obtain a list of who is under surveillance, or acting as an oracle to determine whether the user at-hand is surveilled.
7/ There are other approaches to solving the same problem (eg: pushing out config bundles for individual users, directing how the app should behave) but they all have varying degrees of questionable protection for the metadata of "to whom should ghost-surveillance be applied?"
8/ That kind of information invariably ends-up in crash reports, in the hands of the bug-triage team. Are you going to security-clear them all? If so, in which jurisdictions? The whole proposition is a metadata nightmare.
9/ But what would I know? I was only the original architect and lead engineer for adding End-to-End Encryption into Facebook Messenger. It's not like I've had to rebut these kinds of semi-well-intentioned but misconceived suggestions previously. No, never. Pshaw! The very idea!
10/ - riffing on #7 - if you push-out a one-off flag to the client device(s) saying "throw yourself into GhostMode" - then all the person needs to do is delete & reinstall the app, to switch off the surveillance; also that flag will be checkable/recoverable from local storage.
11/ if (to combat app-deletion) you set a bit in every message exchange in order to say "if you are not already in GhostMode, enable it now" then you are creating a hella lotta surveillance metadata which will egregiously leak into (eg) all bug reports from the device.
12/ a "dynamic" Ghost-Enablement-Bit would perforce have to travel out-of-band (in message "frame" data, rather than in-band (amongst message content) because enabling the latter would (a) bring us back to #10, or else (b) require an additional E2E message channel to WhatsApp.
13/ It would be hilariously interesting to see the resultant press releases if/when some app-tester or academic (@matthew_d_green?) enables that bit on a fresh install, and suddenly observes the app kicking-over to group-chat-ghost-enablement. It might be a bit of a clue.
14/ Of course, the presumption is that if the Gov't can "normalise" this concept, and make "a spy in the conversation" the acceptable face of spookery, then it can all be publicly acceptable, right?
15/ Takeaways: if you use "ghosts" to spy on E2E conversations:

- where do you keep the secret list of those to be spied upon?

- how do you deal with app-reinstalls deleting surveillance enablement?

- how do you hide from app-forensics?
16/ And of course: how do you stop people fleeing to applications which simply will not cooperate with surveillance, and yet are becoming increasingly competent? (@signalapp, @BriarApp)
17/ "We could just mark-as-suspicious any user who deletes and reinstalls their app multiple times per day…" — cute idea, but very much not in sync with the real lives of people who live in developing countries, equipped with shitty old 3G phones and at-best 1Gb of storage.
18/ A long time ago there was a hack to bypass the "three-strikes" password-lockout implementation on $someunix; the trick was (something like) to kill your attempt when the when the "Login:" prompt came back with an initial lowercase letter "L", or without a hostname...
19/ This was because the "three strikes" mechanism was implemented by /bin/login (with lowercase L) but the initial login attempt was by /bin/getty kicking-over to /bin/login … it's all a bit hazy, but point: THE UX WAS DIFFERENT BETWEEN THE TWO SECURITY MODES.
20/ So, again, some team from UCL, Cambridge, JHU, whatever, is going to pore over the application and write trite little white papers saying "ZOMG WHEN YOU ARE BEING SURVEILLED BY @GCHQ GHOSTS, THE USER INTERFACE IS DIFFERENT IN 13 WEIRD WAYS..." — probably because i18n.
21/ (actually, it may have been whether a colon ":" was/was-not present after the word "login", it was something subtle like that)
22/ Here's a fun hypothetical: if I can send a message to your phone saying "All messages you send from here onwards, must be copied to me via a group chat" (see #11) then it would be a book to abusers to spy upon their partners, or even children.
23/ ergo: the "ghost-enablement" facility must be denied to the general public, even though all clients are equal and talk directly to each other; this forces that the "Ghost Bit" must travel out-of-band from the E2E crypto, where WhatsApp could filter-out enablement by abusers.
24/ So you won't be able to hide the fact that someone's messages are subject to ghost surveillance terribly well, if at all.

To be effective the following will need to be written on the outside of most, possibly _every_ message "envelope" that they receive:
25/ IF YOU ARE NOT ALREADY IN "GHOST" MODE, DROP THIS MESSAGE AND ENABLE STATE-SURVEILLANCE IN A "GHOST" GROUP CHAT, AND THEN REQUEST A RESEND OF THIS MESSAGE SO THAT IT IS LOGGED.
26/ …and there would have to be fine (and centralized) control over which accounts are permitted to be ghosted into a conversation.
27/ (typo in #22, it should be "boon" but I can't be bothered to redo the entire thread for that)
28/ I'm going to go out and play @PokemonGoApp for a bit, get some fresh air, but before I do, some other #PokemonGo-inspired issues regarding the @NCSC/@GCHQ "Ghosting" E2E-surveillance proposal:
29/ Anyone who plays #PokemonGo seriously will know there is an entire aftermarket of third party apps, of varying dubiousness and malwareishness, which inspect your game state, tell you the IV-stats of your catches / impending catches, etc, and show you adverts to "monetise"
30/ …from this, and from (above) having determined that the "Ghost Enablement" must travel out-of-band and be both repeatedly sent AND stored on the device, WE CAN hypothesise an entire after-market ecosystem of "IS THE GOVERNMENT SPYING ON YOU?" applications, caused by this.
31/ These apps will be all of:
- snake oil
- vectors for malware & ad-injection
- causes of crashes (see #11, above)
- exfiltration of "secure" E2E messages, at-scale
- bad user experiences
…and will need to be combatted by the (eg) WhatsApp, or other messenger dev teams.
32/ Plus: some will ACTUALLY work, and will tip-off Don Corleone that his WhatsApp (or whatever) is being spied upon.

So: the Gov't will be inviting users to undermine their own security, by inviting users to break the application trust model / lard their phones with malware.
33/ So, overall the proposal risks:
- leaking lists of the surveilled into the public domain
- and fomenting an ecosystem of malware
- driving people to use unsurveilled software
- and driving the bad guys away from platforms where at least there is comms metadata available.
34/ Not to mention:
- forcing platform providers like Facebook to implement surveillance-enabled software architectures, in a pursuit that is ultimately self-sabotaging and harmful to all parties, including law enforcement.

There's only one reasonable response to this:
35/35 <SLOW CLAP>
If you want to read @matthew_d_green's earlier take on this, link is below; I consider Matt's take to be (a) high level & (b) optimistic, whereas I come at it from the perspective of one of the poor sods who would be asked to implement this foolishness.
blog.cryptographyengineering.com/2018/12/17/on-…
Can I summarise the #1 problem with the @GCHQ "Ghost" proposal, in one sentence?

"For this surveillance mechanism to work, people will have to be prevented from [using helper apps to] access to data which exists on their own mobile devices, and we cannot achieve that."

Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Alec Muffett
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!