Tag: programming

  • 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.

  • 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.

  • Messaging Threat models

    I talked yesterday at Bornhack about the current state of secure messaging and the different primitives and threats that groups are working to address.

    The talk is on youtube.

    The slides are on this site, as are the directions for dogfooding the talek system.

  • Accessing gnome-keyring on a mac

    One of the more common password managers in linux environments is the gnome-keyring, which is split into a service (gnome-keyring-daemon), and a user interface (most commonly, seahorse).

    After a bit of fiddling in the last couple weeks, this system can be compiled to run on a mac, with only a little bit of pain.

    On the off chance that it saves someone some pain who’s trying to do the same thing, here are the basic steps I needed to take:

    brew install autoconf automake dbus gettext gnome-icon-theme gobject-introspection gtk+3 gtk-doc intltool libffi libgcrypt libtool p11-kit pkg-config vala
    brew install libsecret --with-vala

    mkdir keyring-buildenv
    cd keyring-buildenv

    mkdir /usr/local/opt/seahorse

    git clone https://github.com/GNOME/gcr
    cd gcr
    wget https://gist.githubusercontent.com/willscott/fb5d50eba8a2fda17b7ead7d6e6ed98d/raw/5dcdc33f617e1196d5b365dda6b3b8e798f6b644/0001-patch-for-osx-compilation.patch
    git apply 0001-patch-for-osx-compilation.patch
    glibtoolize
    intltoolize
    autoreconf
    automake -a
    PATH=/usr/local/opt/gettext/bin/:$PATH ./configure --enable-valgrind=no --enable-vala=yes --disable-nls --prefix=/usr/local/opt/seahorse
    make
    make install

    cd ..
    git clone https://github.com/GNOME/gnome-keyring
    cd gnome-keyring
    glibtoolize
    intltoolize
    autoreconf
    automake -a
    PATH=/usr/local/opt/gettext/bin/:$PATH PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig/:/usr/local/opt/seahorse/lib/pkgconfig/ ./configure --disable-valgrind --without-libcap-ng --disable-doc --disable-pam --disable-ssh-agent --disable-selinux --disable-p11-tests --disable-nls --prefix=/usr/local/opt/seahorse
    make
    make install

    cd ..
    git clone
    cd seahorse
    glibtoolize
    intltoolize
    autoreconf
    automake -a
    PATH=/usr/local/opt/gettext/bin/:$PATH PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig/:/usr/local/opt/seahorse/lib/pkgconfig/ ./configure --disable-ldap --disable-hkp --disable-sharing --disable-ssh --disable-pkcs11 --prefix=/usr/local/opt/seahorse/
    make

    To run, you’ll need to run these components connected by a DBUS instance.
    The following script seems to accomplish this:

    #!/bin/bash

    #dbus session.
    HERE=`pwd`
    dbus-daemon --session --nofork --address=unix:path=$HERE/unix_listener &
    DPID=$!

    #keyring daemon
    GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./gnome-keyring/gnome-keyring-daemon --start --foreground &
    KPID=$!

    #prompter
    GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./gcr/gcr-prompter &

    #seahorse
    GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./seahorse/seahorse

    # cleanup
    kill $KPID
    kill $DPID

  • First-party Google Analytics

    Third party analytics services are suffering from the growing prevalence of ad blocking, tracking protection, and the trend of minimizing connections and requests. However, from a site owner perspective, receiving usage information remains important for measuring site growth.

    My expectation is that we are already on the curve where ads and tracking software will be more tightly integrated into websites and make it significantly more difficult for clients to disambiguate
    “good” and “bad” scripts, which are mostly done today from the URL.

    Google already provides the tools needed to relay analytics communication through a third party server, and it took under an hour to put together a proof of concept that removes the final third-party requests that are required when viewing this page. In essence, my server proxies all the requests that would normally go to Google, and adds on a couple extra parameters to track who the real client is.

    The modified loading script for google analytics, and the corresponding nginx configuration to make my server a relay are here.

  • Clock

    A topic of conversation recently has focused on the practicality of Decimal time. Days would have 10 hours, each with 100 minutes. I recently completed a side project of converting an old clock to use decimal time.
    (If you aren’t willing to switch to decimal time fully, there’s an web version as well.)

    clock

  • Stunning

    I’ve started to dive once again into the mess of connection establishment. Network address translation (NAT) is a reality today for most Internet users, and poses a significant hurdle in creating the user-user (or peer-peer) connections. NAT is the process used by your router to provide multiple internal (192.168.x.x) addresses that are all only visible as a single external address on the Internet. The challenge caused by this device is that if someone outside wants to connect to your computer, they have to figure out how to get the router to send their traffic back to you, and not just drop it or send it to another computer on your network.

    Without configuring your router to add a ‘port forwarding’ rule, it isn’t supposed to do this, so many of the connection establishment procedures are really ways to trick your NAT into forwarding traffic without realizing what’s happening.

    There are two main protocols on the Internet today: UDP and TCP. UDP is stateless, each “packet” of data is its own message, and is self contained. In contrast, TCP is a representation of a longer “stream” of data – many messages are sent with an explicit ordering . TCP is much harder to trick routers into establishing, and there has been little work there.

    The current generation of p2p systems are led by high-bandwidth applications that want to offload traffic from central servers in order to save on bandwidth costs. Good examples of these are Google’s hangouts and other VOIP (video over IP) traffic.

    These systems establish a channel to send UDP traffic between two computers both behind NAT routers using a system called ICE (interactive connectivity establishment). This is a complex dance with multiple sub-protocols used to try several different ways of establishing connectivity and tricking the routers.

    One of the key systems used by ICE is a publicly visible server that speaks a protocol called STUN. STUN servers provide a way for a client to open a UDP connection through their router to a server that is known to be able to receive messages, and then learn what that connection looks like outside of its router. It can then provide that external view of how it’s connected to another peer which may be able to send messages to the same external address and port and have them forwarded back to the client.

    One of the unfortunate aspects of this situation is that the complexity of these systems has led to very few implementations. This is unfortunate, since the existence of libraries making it easy to reuse these techniques can allow more p2p systems to continue working in the modern Internet without forcing users to manually configure their routers.

    I’ve started work on a standalone go implementation of the ICE connectivity stack. Over the weekend I reached the first milestone – The library can create a STUN connection, and learn the external appearance of the connection as reported by the STUN server.

  • Server update

    Another year, another dive into what’s changed in running a web server. This VM is now basically up-to-date, and supports most of the shiny new web transport improvements, like HTTP/2 and OCSP stapling. Hopefully nothing broke too badly in the process.

  • sp^3

    I’m scheduled to give a talk at toorcamp next month about packet spoofing and SP^3.