Overview 🌟

Deface is an app that piggybacks on Facebook and obfuscates timeline content: it makes user messages costly for computers to read, while preserving people's user experience. To achieve this, it relies on a novel approach based on the concept of proof of work.

Deface scrambles messages posted to Facebook. When friends see those Deface messages in their feeds, the app decrypts them.
Basic diagram of Deface functionality

Deface currently exists as a browser extension prototype for Chrome, and versions for Firefox and mobile devices are in the works. The application is expected to be released publicly some time in 2019. In the meantime, you can follow progress and contribute to the project on Gitlab.

Find Deface on Gitlab

Our approach to privacy 🤖

Why not just quit?

In the face of the blatant privacy abuses committed by Facebook, there's a growing consensus among the general public and tech experts that people should abandon the platform altogether. The open source community has been developing alternatives to mainstream social networks with a lot of success (e.g Mastodon, Scuttlebutt). So why are we creating a tool that gives people an excuse to remain on a platform whose financial interests are inherently opposed to protecting their communications?

We love Scuttlebutt and Mastodon too! Everyone should use them.
Mastodon and Scuttlebutt logos

While we agree people should consider alternatives, we believe expecting everyone to shut down their Facebook profile is an unrealistic approach that's rooted in privilege. There's a billion people who actively use Facebook, and each have their own reasons to do so. Some use Facebook because their livelihood depends on it, some others because that's where their community has settled. In a few words, people use Facebook because it works for them. Deface acknowledges the need for alternatives like Scuttlebutt, while focusing its efforts on providing legacy platforms with privacy tools that works for their users.

Besides, Deface provides a model that will be replicable on other platforms. There's many other places online that could benefit from content obfuscation, and we hope to get there when the time comes.

Piggybacking on Facebook requires respecting its interaction model

Many of the technical constraints that Deface deals with originate from our willingness to respect Facebook's interaction model. We set this goal for ourselves because we believe altering the platform's user experience would leave some people out. Every community who interacts on Facebook operates with its own codes, and making assumptions about how users should interact would automatically disrupt some people's ability to communicate.

A diagram showing a user being marginalized because of lack of access to Deface content.

This would not only be an issue in terms of user growth, but could cause harm to people who did not ask for anything. Because Deface makes content unavailable for Facebook users who have not installed it, disrupting the platform's experience means pushing people away, splitting communities, and marginalizing individuals.

These constraints make public-key encryption unfit for our purpose

Conventionally, software focused on privacy provides end-to-end encryption features: secure communications that prevent third-parties from accessing data while it's transferred from one end device to another. In other words, when communicating via Signal or Wire, users can safely expect that only the sender and recipient will access the content of a message. These systems rely on public-key encryption. Deface's core functionality does not use public-key encryption, and does not provide the sort bulletproof protection expected from conventional privacy-focused applications. Why?

An open conversation on a Facebook timeline is very different from a private conversation in a chatroom. By nature, public-key encryption facilitates communications between a sender and identified recipients. To be successful, this process requires users to maintain records of their contacts' trusted online identities. This is not viable on social media platforms where people organically deal with many tiers of relationships, from close friends to total strangers, and many levels in between.

Admittedly, Deface could restrict its scope to users that have exchanged their public key information, but this would be redundant with the role already fulfilled by messaging apps like Signal or Wire... and a lot less secure.

Encryption vs obfuscation

Traditional forms of encryption revealed too cumbersome to protect social media timelines, so we looked into other options. In 2018, we developed a prototype of Deface that decoupled Facebook content from the platform by posting content encryption keys to a distributed hash table. Among others, that approach posed the question of user verification: such a distributed database would be open to everyone, so how could we prevent bad actors from quickly accessing all of the content? We initially opted to use reCaptcha, but came to the conclusion that relying on Google to merely slow down Facebook's access was not satisfactory.

That's when we realized protecting people's public feeds would require a trade-off between user experience and security. We opted for obfuscation over encryption: a protection that's weaker for individuals, but could be more effective at scale. Because of its viral nature, Deface can spread across communities and enable people to protect each other by making personal data processing expensive and impractical.

Obfuscation becomes most effective at scale.
Diagram showing algorithms breaking through an individual's messages, and struggling to monitor a larger group of people

🚨 Opting for obfuscation over encryption means Deface, unlike conventional privacy tools, is not suitable for protecting the communications of dissidents and activists subjected to targeted surveillance. This distinction is critical to understand for Deface users, and in the future we will provide in-app information about the security trade-offs we make. 🚨

Deface's core functionality ⏳

Now we've seen why Deface focuses on obfuscating people's content. This section covers how the app leverages the concept of proof of work in order to provide a layer of obfuscation on top of Facebook's interface.

On one hand, an average social media user downloads a few hundred posts every day on their device. Each of those take a fraction of a second to load up. On the other hand, social media platforms process billions of messages. To do so efficiently, they need to access content very fast.

Diagram showing how Facebook processes a lot more messages than simple users

What if we put roadblocks in place, that slow down the access to each of those messages? Not slow enough that people would notice, but slow enough to render data processing impractical at scale. This is what Deface does: it slows down the internet a little bit, so only people can use it.

Deface acts as a roadblock that slows down access to user content. Users and Facebook are both impacted, but the platform's need for fast access makes it especially vulnerable to this strategy.
A roadblock slows done processing of every message. The user doesn't seem impacted, the robot bursts in flames.

To achieve this, Deface uses encryption of low entropy, a fancy term that means it can be broken easily by any computer, just like a weak password. Someone who wants to access a message simply needs to brute force the encryption key. This is what the app does when it detects a Deface post in someone's feed: it tries every character combination until it unlocks the encrypted content. For an average laptop, decrypting a message takes a couple of seconds.

When a user posts a Deface message, the app encrypts it by generating a random encryption key. Later, when friends see that message in their feed, their Deface client unlocks it by trying every character combination until it matches the encryption key.
Detailed diagram showing Deface's functionality: the app brute forces encryption keys to access messages.

Traditionally this would be considered extremely unsafe, since everyone can easily gain access to the encrypted information. But this is exactly what we're looking for: content available to everyone, that just takes an additional amount of computation to get to it. In other words, the encryption doesn't act as a protection, but as a proof of work mechanism that confirms an actor has invested a given amount of resources to access a piece of content.

Deface encrypted messages contain a hash of the encryption key, the initialization vector, the length of the character set used to generate the key, and the cipher text.
An animated gif of Deface message decryption in action. Random characters turn into intelligible content.

For people, this is a minor inconvenience, as their friend's messages might take an extra second to load up. For Facebook, this is a major disruption, as the platform will need to engage a significant amount of computation to gain access to the content of all Deface users.

In fact, if the cost of decrypting a message matches the revenue Facebook can derive from it, it becomes unprofitable to do so. In the future, we hope to modulate the complexity of encryption keys accordingly. For now, the interface lets people choose between incremental levels of security, based on their own privacy needs, the computing power available to their friends, or their own preference.

Users can select between several levels of encryption strength, which informs how difficult and costly it is to access their content.
A diagram showing a user selecting between several levels of privacy, resulting in algorithms struggling incrementally.

This strategy, of course, relies on the premise that proof of work can in fact make personal data mining impractical at scale. We are in the process of evaluating this cost, and comparing it with the computation that Facebook already commits to processing personal content. This cost analysis needs to take into account how proof of work can be made more efficient when done at Facebook's scale. In parallel, we will need to understand the inconvenience experienced by Deface users, in terms of waiting time and battery life cost.

Deface's advanced functionality 🔐

We believe the design outlined above increases the general level of privacy on social media platforms. There's however two shortcomings we would like to address in the future.

  • 🌍 Deface's proof of work mechanism has an environmental cost, since heavy computation drains a computer's battery more than normal. While we believe Facebook's untrustworthiness makes the company entirely responsible for this damage, we recognize the necessity to prevent redundant computation to the best of our ability.
  • 🐌 Not all computers are equal, and less powerful devices take longer to brute force encryption keys. This leaves individuals with slower devices with a choice between longer wait times and weaker protection. This is especially concerning because marginalized communities who benefit from this project the most are also those with least access to top of the line equipment.

These issues can be mitigated by providing a mechanism that enables Deface clients to directly exchange encryption keys after two users have become Deface contacts.

In order to make Deface less computation-intensive for users, we will include a mechanism that lets people manage contacts and share content more efficiently with them.
Diagram of two users exchanging public keys

From the user's perspective, this set of features boils down to making contact requests within the Facebook interface, and managing the resulting contact list.

People are able to add Deface contacts directly from the Facebook interface. Doing so sends a notification to the recipient of the request, who can accept it. We also plan on allowing contacts to verify each other's public key fingerprint.
A screen capture showing how Deface users can add contacts from the Facebook interface.
A screen capture showing how Deface users process contact requests and manage their contact list.

After two users have become Deface contacts, their subsequent Deface posts are automatically sent to each other at the time they're posted on Facebook. Past messages can be requested at any time. This means friends are kept up to date with each other's content, which reduces the overall reliance on brute force decryption.

Every time a user posts a Deface message, the encryption key is sent over to their Deface contacts. This allows them to skip the brute forcing process.
A detailed diagram showing how Deface contacts access content while skipping the brute forcing of encryption keys.

In addition, we're considering adding an advanced security feature that limits content access to Deface contacts only. Opting for this would disable other users from accessing messages through proof of work. This option could be useful for communities with specific privacy needs.

This option allows users to broadcast secure messages to their entire Deface contact list, or a subset of it.
Screen capture showing how Deface users can select contacts they intend to share content with.

Specification for this feature has yet to be written (help us!). We are considering a centralized server that manages asynchronous communications between Deface clients. Signal's Sesame algorithm could be an option. In any case, the solution we select will need to meet security expectations and prove to be computationally cheaper than Deface's regular proof of work approach.