Don't Burn the Cake: A Managed Attribution Strategy
Think of managing attribution like baking a cake rather than peeling an onion.
Part One of this series defined terminology and identified the need to establish ground rules and use cases for any managed attribution strategy. This article will discuss suggested guardrails and introduce common use cases.
If you’re reading this because part one made such a compelling argument that you can’t wait to get started, that’s fantastic. As legendary guitar instructor Phoebe Buffay once said, “If you want to learn to play guitar, don’t touch the guitar.” Phoebe’s methods were unconventional, but her logic was sound. With managed attribution platforms starting at $10k+ and costs growing exponentially, it’s important to refine technique before handing over a delicate instrument.
Procedural Guardrails
The first step when adopting a managed attribution platform is establishing ground rules. Some of rules will be more firm than others. As a general practice, whether you are an independent researcher or managing hundreds of users, you should establish a set of rules prior to adopting any new managed attribution strategy. It is equally important to reassess your strategy on a regular basis, including any time you add a new use case or piece of hardware. Proper prior planning will ensure you don't make compromises that end up hurting you—and your budget—in the long run.
- Don't mix business with pleasure: Do not under any circumstances log in to an operational account (e.g., one used to access resources on the dark web or engage in other high-risk activity) from a personal device, and do not log in to a personal account from within your managed attribution platform.
- Don't mix business with business: You should not access operational accounts using company-issued devices that have access to your company's sensitive internal resources. Nor should you log in to a corporate account associated with your identity or the identity of your employer from within your managed attribution platform.
- Never grant a container privileges in excess of its host: For example, do not log in to a password manager in a virtual machine (VM) if the password manager also manages secrets for the VM's host (or other VMs for that matter). Additionally, do not grant a container SSH access to a resource that has administrative privileges for the container's host.
- Compartmentalization is key: Storage is cheap. Spills last forever. Create as many containers, virtual machines, and any other compartmentalization strategies as necessary to ensure no two functions overlap. Don't let the loss of one container bring down your entire house of cards. Better yet, don't build your house out of cards. Contrary to popular opinion, unless physical security is part of your threat model, consider recording passwords and backup codes in hard copy (i.e., writing them down in a notebook like the monks did) rather than storing them digitally. Hardware-based FIDO passkeys offer a safe and convenient digital alternative.
- Cakes > Onions: Don't rely on one layer where three will do, but not all layers are made equal. There are numerous reasons why The Onion Router (Tor) may not be appropriate for certain use cases, but everybody likes cake! Your use case may have specific requirements based on the individual layers of your defense strategy. Think of designing a managed attribution strategy more like baking a cake than peeling an onion. It takes time and precision, but the end result is far more appealing to users.
Account Management
Regardless of your other use cases, you're nearly guaranteed to have some administrative overhead. This may include keeping track of virtual wallets, managing cloud services, receiving one-time passcodes, or generating API keys for automation tools. These types of services frequently rely on specialized software and/or persistent cookies.
Consistency is the theme for account management. If you've gone through the trouble of setting up a privacy LLC to establish commercial accounts and maintain your personal anonymity (see Extreme Privacy: What it Takes to Disappear by Mike Bazzell), you probably don't want to get locked out of your new bank account for "suspicious activity" because you logged in using Tor or a commercial VPN.
Instead, your bank may be more forgiving to security-savvy business clients who enlist a static VPN endpoint (see Tailscale or Outline) for account management. By emulating this common business accounting practice, you’re likely to have a more stable accounting experience. You may also be able to get by with a commercial VPN provider that offers static IP addresses or SOCKS5 proxies as an alternative to self-hosting static VPNs. Additionally, using a common operating system and web browser with rules in place to persist cookies in new containers decreases the likelihood of unintentionally triggering fraud prevention measures and losing access to critical resources.
For consistency and high availability, these types of instances are easiest to maintain in virtual machines stored on a local host workstation, but you may also choose to store them on a removable hard drive for further protection when not in use. Either way, the images should be encrypted at rest and backed up offline on a regular basis. Most type-2 hypervisors (see VirtualBox or VMWare) have straightforward options for creating snapshots and can be combined with common file backup services for offline storage.
Passive Browsing
Passive browsing involves short-duration browsing sessions on the surface web that do not require accounts or login credentials. This type of browsing behavior is best limited to short durations and a narrow focus on widely accessible resources (e.g., news outlets, search engines, and social media sites not requiring a login). One-time use containers such as Kasm Workspaces should be used exclusively for this type of activity, taking care not to commingle research on more than one topic of interest within a given session.
When performing passive browsing, it is often preferable to take a circuitous route to the information you seek and include irrelevant searches (noise) in the process. This can be thought of as a traditional surveillance detection route, except with the limited goal of making it harder for a potential collector to discern your intent or correlate the activity to the rest of your research. This is considerably harder in practice than one might expect, which is why it's always good to have a plan before you begin. The Wiki Game provides a fun and practical exercise for learning what circuitous search routes may look like in practice.
One of the most prevalent threats during passive browsing is correlation across activities; therefore, the greatest vulnerability is exposure to advertising technology. There is a $300 billion industry dedicated to correlating devices, users, and activity that ought not be correlated. To the greatest extent possible, endeavor to use DNS filtering, fingerprint-resistant browsers, and similar tracking protections to avoid unnecessary correlation. The Electronic Frontier Foundation (EFF) and PrivacyGuides.org are excellent resources, while the Mullvad Browser goes to great lengths to provide similar protections as the Tor Browser, without requiring the tears of the onion.
Be on the lookout for our next segment on managed attribution when we’ll walk the tightrope of subscription-based accounts and discuss approaches to data-processing and analysis.
Not everyone wants to learn to play guitar, and using the internet shouldn’t be this hard. Reach out to learn how we can help your organization address its managed attribution needs without breaking the bank—or a guitar.
