Blog

  • When do we get a Privacy-Preserving CDN?

    The surveillance-capitalism business model that defines the Internet today is only going to get more imposing. The vast majority of our online requests today are serviced and logged by centralized infrastructure – even more centralized than what we probably expect.

    While our collective hivemind takes rightful pride in the successful pushes that have improved this situation, most notably encryption in transit (HTTPS), we are still very much losing the war on metadata. Even when the payload is opaque, the who, when, and where of data access sheds an unfortunate amount of insight into our social networks and our behavior.

    This isn’t a fundamental tradeoff – but we need to invest and evolve our systems to protect ourselves from second order effects of metadata collection.

    Efficiency & Privacy

    Centralization is not an inherent evil, and it is on the path of least resistance for improved performance. It is the second-order effects that are the main risk.

    Caching data at the “edge”—physically closer to the user— is a natural performance optimization in minimizing the speed-of-light constraints. This should be aligned with our privacy goals – less hops in the network will see requests and traffic in a well designed system. Similar performance outcomes lead to single entities controlling constrained back-haul infrastructure (efficient spanning trees). This itself is not a problem, but it is natural for these powerful entities to then want to leverage the value of data they are transiting from their privileged positions, and especially in cases where the infrastructure providers extend to smarter ‘value added’ services, this secondary effect of value extraction leads to unfortunate designs for collection, logging, and eventually manipulation of traffic.

    With the rise of advanced traffic analysis and machine learning, the “anonymity” we enjoy thinking that our requests aren’t analyzed because of the scale of traffic they are ‘hidden’ within is no longer realistic. As analytical capabilities increase, the power structures exploiting this data will become more effective and will work even harder to embed themselves into core infrastructure.

    What does a better structure look like?

    To build a CDN resilient to modern passive and active surveillance, we need to go quite a bit beyond encryption. We need the infrastructure and system designed to limit metadata leakage. The good news is that there are both good research ideas and deployed systems that chip away at many parts of this problem already.

    Decoupling Identity from Intent (Oblivious HTTP)

    The most immediate path already charted by IETF drafts and Apple’s Private Relay is to have an independent entity relay traffic between the client and content. This can mean that the intermediary will know the user’s IP  but not the piece of data being asked for, and the content provider knows the content served, but not the user’s identity.

    This “de-linking” is important, but it is not by itself the end of the story. In the last decade, we have seen how easy it is to fingerprint the traffic signatures associated with visiting a website (which will involve loading a range of resources, each of a different size). A more effective mental model may be to think about the traffic patterns that would be generated by a series of back-and-forth conversations. Protecting metadata in this ‘repeated game’ scope will yield different systems than limiting scope to a single request. 

    Differential Privacy and Cover Traffic

    These fingerprinting concerns have been the impetus for a range of research looking at defenses. One important piece of intuition that has emerged from this field is that we must be willing to stray from optimal efficiency. There are a number of ways to do this: we could inject ‘fake’ traffic, fit requests into a pre-defined pattern, or increase latency to grow an anonymity set.

    Some examples of systems taking different approaches in this design space include:

    • Nym adds differential cover traffic to make an argument for statistical deniability in its mixnet design, while Tor trades off its resistance to a “global passive adversary” against latency and practicality concerns.
    • Pond was a proof of concept messenger demonstrating usage-agnostic communication patterns.
    • Mullvad offers the ability to add cover traffic to reduce classifiability of individual webpages.

    Private Information Retrieval (PIR)

    Private Information Retrieval” refers to the class of systems that answer a specific question: how can a user retrieve an item from a database (or cache) without the database learning which item was selected? While historically computationally expensive, recent advances suggest that sub-second, privacy-preserving cache lookups can be possible at scale.

    • Kohaku – is an ethereum wallet project demonstrating using PIR for hiding reads
    • Iphone live caller ID is the largest user of PIR currently

    Content Addressing and Blinding

    A variety of more exotic techniques for data transfer have been explored in the contexts of content addressed systems like Bittorrent and IPFS. A number of useful ideas have resurfaced in these contexts:

    • Files and data generally can be thought of as a series of fixed sized ‘chunks’, which helps with speed, and is already pre-requisite for the preceding constructions.
    • By requesting data by its hash, the response becomes verifiable by the client – so we can split who is responsible for ‘availability’ (any other peer) vs what the data is (the source leading us to get data in the first place). It also means that we don’t have to go to a single origin, but are more naturally able to take advantage of caches.
    • We can separate ‘discovery’ (the DNS equivalent of figuring out who might have data) with the transfer of the individual blocks from those peers, and get past a standard client-server model with minimal additional cognitive complexity.

    Reducing Centralization & Segmenting Information

    There have been a number of projects in the last year, mostly riding on the wave of interest in ‘DePIN’ (decentralized physical infrastructure networks) that looked at economic models for how protocols could directly split earnings with participating network nodes. This extends the coordination systems ideas from cryptocurrencies to how things like CDNs could be constructed to incentivize a decentralized group of participants to operate participating caches / parts of the overall network around the world.

    These systems sit somewhat orthogonal to a set of prior research on ‘Sybils’, which indicates there’s an additional coordination system of some sort needed to actually reduce centralization. Conceptually, if you set up incentives so that there are more rewards (and an incentive) for many small participants to form a network rather than a big central player, the large central player can generally split up their resources and make themselves look like multiple smaller entities (called ‘Sybils’). This means there needs to be some mechanism to confirm that different entities are really ‘independent’ if that is a desired property. A number of mechanisms – using social networks, or various forms of human identity have been proposed for this, though all with caveats.

    What’s next?

    We are missing two important pieces in the story of privacy preserving content delivery. The first is that there is currently no shelling point for this effort. Existing centralized players have been so far disincentivized from investing in this direction, because it is at odds with their business model, and there has not yet been a credible community effort that has emerged. 

    The second is that much of the market is driven by price. The reason there was a substantial shift from Amazon S3 to Cloudflare R2 was not because of a technical innovation, but because Cloudflare was able to leverage their infrastructure position to provide the same service at a cheaper price. The shift that allows for subsequent disruption is likely partially regulatory – that liability around the collection and exploitation of metadata needs to be disincentivized and in so doing leads customers to switch to a ‘safer’ or more privacy-preserving alternative.

    There is hope! Code is becoming cheaper to generate and deploy, so the marginal cost of building is dropping. On the flip side, the value of a Shared Private CDN will grow with usage. – This feels like a situation where the trick will be to get enough excitement and activation energy.

    We don’t just need better protocols; we also need the coordination, but there is hope and increasing incentives that make me optimistic that a better system here will emerge.

  • On Trust

    There has been a fair amount of effort on UCAN (User Controlled Authorization Networks), and other types of ‘decentralized credentials’ over the last couple years. These efforts perpetuate the same control structures that exist today, with delegated trees of hierarchical control. This is in contrast to a personal or ‘decentralized’ trust we might hope for in peer to peer networks. It is difficult to use DIDs, UCANs, or other proposed mechanisms for reputation and network formation without finding ourselves back trusting an authority – they are both easily captured and naturally lend themselves to centralization of control. We need a fundamentally different trust infrastructure in order to build resilient, peer to peer networks.

    On non-hierarchical models for trust

    The main barrier is not a technical one – we have seen technical implementations (e.g. the GPG web of trust) for decades. There is an intuitive design for how a flat trust model can be implemented. The problem lies in a dis-satisfaction from the emergent properties of that naive network structure. This tension has been framed in a couple different ways. One perspective is that the user experience in bootstrapping trust is overly cumbersome, and this friction leads to an insufficiently dense trust network. A different perspective on the same tension is that a user-driven trust system is at-odds with transitive / automatic trust relations, and that actions to ‘ease’ the user experience are fundamentally reducing user control.

    We can find a space for exploration, by calling out this tension as a false dichotomy. The choice is not between a single authority vs user-directed trust links, but about distributing trust structures. There is a space for organic / automatic way to generate and allow for the reflection and evolution of trust that is neither user-directed nor rooted in a single authority. The bit-torrent tit-for-tat mechanism is one form of this, where protocol-compliant behavior leads to an increasing buffer for data transfer within the protocol.

    Trust or Reputation

    There is a related notion that is more regularly referred to in protocols as a concept of ‘reputation’. Reputation can be viewed as a property of a node in a system rather than one of an edge. (e.g. reputation is often constructed as a metric that is transitive, or where a node has a single consensus value. This is different from how we normally think of our personal trust in another user.)

    What then exactly are we trying to capture in a measure for ‘Trust’? In the hierarchical systems of web 2, it’s meant to provide some assurance that “someone is who they say they are”. It isn’t an indication that there are ‘aligned beliefs’, but rather that the expected entity is behind a given identifier. The properties that come from systems like TLS / CAs look very similar to reputation in this sense. While each individual can over-ride and manually configure which authorities to trust, that definition of trust is meaning a confidence in adherence to protocol and of coherence between expectation and reality.

    Scoping trust

    A challenge we sometimes run into when talking about trust as it relates to technical networks is that our expectation of scope is typically much more limited in digital or transactional contexts than they are in real life. When you refer to a person as a “trusted individual”, the implication is not only that this is not an ‘imposter’, but also that the person has some level of altruism or aligned / positive motivations. While some formulations use reputation as a stand-in for this additional notion of trust, I would argue that it is perhaps better thought of as an understanding of motivations. The trust is that it is understandable what game someone is playing, what their motivations are, and thus what their rational behavior will be.

    Narrow interactions, like those scoped in technical protocols, are intentionally limited to exclude externalities, but this also makes it difficult to understand if other nodes have ulterior motives in participating in the protocol. The analysis of what can be learned by a participant, and the other uses that can be derived from participation is not always easy to analyze, and the lack of completeness is unsatisfying. In contrast, the design of protocols to not leak information is difficult-to-impossible, and difficult to justify. Even the determination and understanding of risk present in a system is an expensive proposition.

    Categorizing mechanisms

    How do we build distributed notions that reflect this notion of confidence that another participant is also playing the same game as us?

    If we take the narrower view of actions within the protocol, we can get to a somewhat useful taxonomy of work in this space.

    • The bit-torrent tit-for-tat algorithm uses the demonstration from the other participant that they’re following the protocol as a signal to continue the conversation.
    • A set of protocols use a proof of work, or computational puzzle as a way for participants to demonstrate that it is worth something to them to participate.
    • Protocols like TLS have added revocation lists, and things shaped like “proofs of bad behavior” as ways to share knowledge of identities that have misbehaved. If the cost of creating an identity is high, and your misbehavior causes “reputational damage”, your rational behavior becomes more incentivized to follow the protocol.
    • Finally, there is emerging growth of validation-based protocols. Cryptographic proofs are increasingly able to provide an assertion that computation has been performed per the expected protocol, and reduces the space of valid-but-not-compliant actions that can be taken.

    The complement to this category are protocols that make use of external costs. In many cases the cost is difficult to quantify, which leaves modeling of the strength of the protocol trust levels equally difficult to pin down. At the same time, it means that there is the ability for costs to be higher relative to what could be built into a protocol in isolation.

    • Protocols which involve a validation of ‘real name’ (linking an ID, bank account, cell phone, etc) are able to retaliate for misbehavior using the legal system.
    • Protocols involving social graphs use the potential of negative impact to your standing with your friends.
    • Protocols requiring registration with a phone number, or who distribute their app only for mobile devices are leveraging the cost of those assets as part of the account cost.

    Increasing trust

    From the previous categories we can see that there are two ways that they end up leaning on for increasing this notion of trust.

    The first is increasing the cost of defection. Increasing the costs tied to creating or re-creating an account increase this cost. Impacting a reputation or decreasing utility likewise are ways to increase the cost of not following a protocol

    The second way that trust is increased is by increasing a user’s confidence that they will be able to succeed in getting resolution when another user defects. In most of the ‘in protocol’ cost models, resolution occurs as part of the protocol itself. Bit-torrent won’t continue rewarding peers that aren’t honoring the tit-for-tat agreement. Submitting a computation without a valid proof transcript will be ignored. It is the out of protocol actions where this subjective confidence is most at issue. Actions like Facebook suspending Cambridge Analytica (and publicized moderation actions more generally) demonstrate to users that enforcement is taking place.

    Full circle

    How do we provide decentralized notions of trust that can be dense and mesh with protocol needs for automatic establishment?

    By ensuring that the risk associated with a trust link is less than what can be mitigated when trust is broken. This can be done in one of three ways:

    1. The benefit of breaking trust can be reduced
    2. The cost associated with punishment can be increased
    3. Regularity (or user perception) of breaking trust leading to punishment can be increased

    Concretely, the hesitancy to form a mesh network comes most often from the lack of a concretely defined threat model. When a protocol comes with a well scoped definition of misbehavior, it is typically much easier to enforce compliance and to frame the protocol in a way that provides comfort to participants.

    It’s worth noting that we are often concerned with one of the hardest forms of this scenario – which is balancing the ease of participation in a system with the indirect and difficult to identify surveillance risks. Concrete examples of this tension are nation-state identification of Tor users, RIAA identification of bit-torrent users, or IRS identification of crypto currency users. In all of these cases, a user joining the protocol may behave as normal, but may also record network identifiers of other participants they encounter. An unaccountable out-of-protocol leaking of these known identifiers then leads to repercussions to other participants. I don’t know if the preceding discussion is the best framing in this specific case. I think it can be used as a lens still, but the interesting question here is mostly around the first point of reducing the benefits around breaking trust, and in reducing the signal that such an attack gets in the initial level of participation in the protocol.

  • The City

    Earlier this week I visited The City with a group of friends. It’s an interesting place, and I’m glad I took the time to experience it, as it provided a unique context to reflect on a set of more abstract ideas.

    The claim to fame of the city is that it is the largest art installation on earth – a mile by 1.5 miles of terrain sculpted over something like 50 years into an aesthetically pleasing ‘city’ – a series of gravel mounds and hollows each curbed and delineated by gravel roads. There are a couple of distinct sculptures within the space – brutalist/minimalist concrete structures, a series of triangles on one end of the city and a deconstructed, cantilevered cube on the other.

    The city is as much the experience as it is the physical art itself – each day one group of 6 people is allowed to visit by the foundation set up to administrate the exhibit. The visit typically involves a 2.5hr pilgrimage from the antithetical los Vegas up to the city, itself near Area 51 in the high Nevada desert. The city as a place is meant to be timeless – which is effected with a permanent crew to rebuild after storms lead to erosion, and to sweep the paths each day to erase the footprints from previous visitors.

    • There were a few primary ideas I took away from the piece while walking through it for the 3 allotted hours. I’m sure much of this is a reflection of the head space I was in, and aren’t intentional on the part of Heizer as an artist.
    • Insignificance – The scale of the piece, while vast, remains dwarfed by the surrounding Nevada mountains and what nature has created
    • Illusory – The artifacts which appear as coherent monuments from afar break apart into a much more fragile and hard to interpret components as one gets closer to inspect them.
    • Permanence – Despite all efforts, any attempt at permanence is doomed to fail, but that can’t and shouldn’t discourage the attempt to fight against entropy. I think there’s an argument for a preference for growth/evolution over permanence, but I think that’s beyond the experience I took away from this piece.
    • The essence of urban life – what is the emergent behavior between the individual participants and the overall experience of a city?

    The city, along with its other restrictive policies requires visitors to agree not to take photos. There are enough photos online to get a reasonable approximation of the experience despite this. It perhaps indicates this policy has been effective in limiting the use of the city as a canvas for selfies / other subjects, and maintaining its position as a sole protagonist.

  • Retrieval Constraints

    A couple months ago I wrote up some of the edges that I’ve encountered in thinking about how to structure decentralized data transfer systems. These are an extension of the limitations that were initially encountered in bittorrent style tit-for-tat exchanges, and have now matured into a much more extensive field looking at incentives and other mechanisms that can be leveraged to create robust systems.

    See the long-form essay on mirror

    My top take-away from this line of thought is that it does seem like within our initial framing of how data transfer might happen we end up still relying on reputation as a way to estimate transferability of experience, and in estimating trust for whether past behavior will continue to subsequent performance.

  • Coordination, or Attention

    A current meme is that one of the major points of limitation in our ability to execute is coordination systems. The claim, which is somewhat enticing, is that our communities are already incredibly powerful, but we lack the coordination systems to reliably be productive together, or to scale up the types of systems we can create efficiently.

    I think there’s a counter argument worthy of exploration that attention remains a limiting resource. Our lack of coordination is not so much a technical limitation of the systems we use, but rather that the other people we are coordinating with are often distracted, and don’t pay attention to where boundaries are set.

    This tension remains a core reason for why in person gatherings can be so energizing – they force presence by participants and capture attention more effectively than our technical systems. As our work becomes increasingly global this hack will become less able to capture attention at frequent intervals.

    How do we capture dedicated attention? One path could be through curating memes. Belief can be an effective driver of attention and focus.

    One of the paths I’m most excited about is curiosity. Effectiveness of puzzles and creating experiences to activate curiosity is a set of techniques that are not well integrated into how we work and coordinate.

  • Private Retrieval

    It’s very exciting to have a public face to the thoughts around how to enable effective private access to data.

    Research Announcement

    EthCC Announcement

    The basic hypothesis here is that there’s a high-leverage opportunity to attract thought around scaling the range of anonymous database or data transfer techniques to reach something with better properties that the systems we have today.

    I’ve learned a lot about what goes into running a grant fund already in my minor involvement helping to set up this program, and am excited to see the next stage of it’s lifecycle as we begin to engage with proposals and grantees.

  • Building Decentralization

    Building Decentralization

    I talked earlier this week on some of the current problems in decentralization at the rc3 event. It’s easy to be pessimistic about the current silo’d technological landscape, but decentralized platforms are continuing to make progress and there’s reason to be hopeful. At the same time, there’s a green field of many more decentralized protocols to discover and define beyond the current notions of DHTs and Consensus protocols.

    The RC3 event was a great commemoration of the traditional chaos congress. The extent of culture and community that was brought into the 2d virtual world managed to capture some of the essence of the in-person event. Like the real events, it was a great opportunity for mixing whimsy and technical learning. In that spirit, I rehashed some measurement work to generate the following statistics about the event:

    • The most common character accessory was wearing a mask, which were donned by 30% of participants.
    • The badge shown on the most user profiles was ‘On Webcam‘, a badge I awarded to a scraped list of usernames on the 2nd day of the event. It was about 3x more popular than the second most popular badge, received for visiting the CERT, which only functioned near the end of the event.
    • A total of 385 badges were awarded and publicly displayed on user profile pages.
    • A total of 334 distinct pronouns were used by users. Only 5 of them were attempts at cross-site scripting attacks.
    • The user population was approximately that of the recent in-person events. Of those, my measurement estimated about 1/3rd participated in the 2d virtual world portion of the event.
    • There were only 2 users who used the same description of themselves on their profiles: ‘Moin!’

    These statistics come from a fairly simple script that measured user pages near the end of the event. User IDs were largely sequential and could be enumerated without issue. This was needed as a step in awarding badges, which could only be done with the non-enumerable “usernames”, rather than these User IDs. One of the things that makes the CCC events unique is their transience, which allows for a safer form of expression than our more usual permanently logged and recorded online experience. In that spirit I have subsequently deleted my collected list of usernames and saved only these summary statistics.

  • Unlocking North Korean Karaoke

    Unlocking North Korean Karaoke

    I recently got the opportunity to understand what was going on with a Tianchi android KTV console with north korean content loaded on it. A description of the encryption and evolution of DRM protections associated with the device is published on the North Korea Tech blog.

  • What's Left for private Messaging

    What's Left for private Messaging

    I had the privilege to address the annual Chaos Communication Congress (36C3) in Leipzig last week about the state and remaining issues in private communications.

    The recording of the video has been made available by the CCC, and I have also posted the slides.

    The TL;DR for me is that many of the trade-offs are balancing the stability of user experience with privacy mechanisms – and finding more ergonomic user experience interactions will be as important as new systems schemes are to improving the ecosystem.

    I am particularly excited by the number of ongoing effort reducing trust in central servers. Many of the mechanistic trade-offs we face are due to the topology of our systems. With systems designed for fully anonymous interaction, like mixnets, PIR, and oblivious messaging, we can model and mitigate threats from much more realistic adversaries than we do with popular channels today. (For instance, consider an office which has received a whistle blowing message. If the receiving investigation wants to identify the source, they likely control both the local network, and have the ability to send messages to the account that initiated the conversation. Our current designs will find it quite difficult to protect a user from this scenario)

  • Email Security Checklist

    There are a lot of various standards and protocols in play around SMTP that are being used today to validate email. when setting up self hosting, recently, I found it useful to refer to the following checklist of the following validations that I should be configuring.

    For a server receiving email on behalf of a domain:

    • Delegated by MX or A record
    • Correct PTR record matching server HELO
    • TLS Cert for StartTLS upgrade support
    • MTA-STS record to indicate the expectation of TLS
      • A dns record of the form _mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;" defining the current policy ID
      • the presence of which triggers an HTTPS fetch of https://mta-sts.example.com/.well-known/mta-sts.txt
      • that file contains a policy of the form
    version: STSv1
    mode: enforce
    mx: mail.example.com

    For longer term validation (these standards seem to still be getting adoption, so probably won’t be validated by most senders)

    • DNSSEC enabled for the domain
    • DANE dns records for the expected cert
      • there’s a tool to test your implementation.
    • CAA dns record to limit cert issuer

    For a server sending email on behalf of a domain:

    • Coming from a stable IP, ideally the same as the receiving server
    • HELO matches both MAIL FROM sender and the sending IP’s PTR record
    • Equipped with the TLS cert for the domain to be able to offer as a client certificate
    • SFP record
      • of the form example.com. TXT "v=spf1 +mx -all" (or “a” instead of “mx”)
    • DKIM header signing of messages
      • DNS <selector>._domainkey.example.com record with pubkey
    • DMARC
    • ARC headers
    • Register the domain on postmaster.google.com