PaperlayerView exact revision on arXiv

Source-linked AI summary

When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies

Steven Goldfeder, Harry Kalodner, Dillon Reisman, Arvind Narayanan

arXiv:1708.04748v1cs.CR

TL;DR

The paper asks how web tracking affects the privacy of cryptocurrency users. It analyzes tracker-visible payment information and develops two complementary attacks that link purchases to blockchain activity and identities, including through CoinJoin. The attacks work broadly in measurements, while proposed mitigations remain imperfect and involve tradeoffs.

  • Problem

    The paper studies the privacy impact of pervasive third-party tracking on users who pay online with cryptocurrencies.

  • Method

    The paper combines web measurement with blockchain transaction-linkage analysis and evaluates a cluster intersection attack against CoinJoin.

  • Results

    Trackers can often link cryptocurrency purchases to blockchain transactions, web activity, and identities, while repeated observations can reveal address clusters despite CoinJoin.

  • Takeaways & Limitations

    Passive web tracking can compromise cryptocurrency privacy beyond individual purchases by connecting blockchain transactions to users and their broader transaction histories.

  • Takeaways & Limitations

    The end-to-end evaluation used only 1 or 2 mixing rounds, limiting its assessment of higher-round mixing tradeoffs.

Abstract

from arXiv · show

We show how third-party web trackers can deanonymize users of cryptocurrencies. We present two distinct but complementary attacks. On most shopping websites, third party trackers receive information about user purchases for purposes of advertising and analytics. We show that, if the user pays using a cryptocurrency, trackers typically possess enough information about the purchase to uniquely identify the transaction on the blockchain, link it to the user's cookie, and further to the user's real identity. Our second attack shows that if the tracker is able to link two purchases of the same user to the blockchain in this manner, it can identify the user's entire cluster of addresses and transactions on the blockchain, even if the user employs blockchain anonymity techniques such as CoinJoin. The attacks are passive and hence can be retroactively applied to past purchases. We discuss several mitigations, but none are perfect.

I. INTRODUCTION

The paper shows that third-party web trackers can link cryptocurrency purchases to blockchain transactions, users’ web activity, and real identities, then use repeated observations to defeat mixing. Measurements indicate that this risk is widespread, while available defenses involve substantial tradeoffs.

  • Core attacks: Trackers often receive enough purchase information to link a cryptocurrency payment uniquely to a blockchain transaction and connect it to web activity and identity.Leaked transaction-specific addresses make linkage trivial, while leaked personally identifying information connects blockchain transactions to users.
  • Core attacks: A tracker can use cookie-linked observations of multiple payments to identify a user’s address cluster despite CoinJoin.The attack needs only auxiliary information that multiple mixed transactions belong to the same entity.
  • Empirical evaluation: At least 53/130 merchants leak payment information to at least 40 third parties, most frequently from shopping cart pages.The study analyzes 130 online Bitcoin merchants using an extended OpenWPM measurement tool.
  • Empirical evaluation: Unique linkage is possible in over 60% of cases under realistic uncertainty, and the anonymity set is 5 or less in the vast majority of cases.The attack degrades gracefully as uncertainty about transaction time and value increases.
  • Empirical evaluation: With 3 rounds of CoinJoin and two observed payments, the cluster intersection attack links transactions back to the victim’s wallet with 98% accuracy.This result comes from simulations based on 78,697 CoinJoin transactions identified over two years.
  • Empirical evaluation: In an end-to-end evaluation, trackers identified the user’s wallet in 20 of 25 mixed-purchase pairs.The evaluation involved 21 purchases on 20 merchant websites, including 11 purchases made with freshly mixed coins.
  • Defenses and limitations: No mitigation is complete because privacy protections conflict with merchants’ analytics needs and the public nature of the blockchain.The paper discusses user, merchant, and alternative-payment mitigations, each with tradeoffs.
  • Defenses and limitations: The attacks are passive and can be applied retrospectively, while tracking protection has false positives, false negatives, and does not address every adversary.Even with tracking protection enabled, 25 merchants leaked sensitive information to third parties.

III. THREAT MODEL AND ATTACKS

The threat model treats merchants, payment processors, and trackers as participants in cryptocurrency payments, with trackers observing transaction-relevant web data. Two attacks use this data to link users to blockchain transactions and, across purchases, recover wallet clusters despite mixing.

  • Threat model: Trackers can observe payment timestamps, addresses, prices, and personally identifiable information during cryptocurrency checkout flows.Receipt pages provide especially precise timing, while leaked payment addresses directly identify blockchain transactions.
  • Attack 1: single transaction linkage: Attack 1 links a web user identified by a cookie or PII to a transaction on the cryptocurrency blockchain.The attack considers trackers as adversaries and remains relevant even when users employ mixing to separate the payment from other transactions.
  • Threat model: Passive tracker observations can connect blockchain activity to real identities, while active scripts may extract transaction data or PII from accessible pages.The paper assumes users may use desktop wallets and communications anonymity, but ordinary address heuristics can still link addresses.
  • Attack 1: single transaction linkage: Trackers can search blockchain transaction logs using uncertainty windows around payment value and time when the receiving address is unavailable.Price uncertainty can arise from shipping and exchange rates, while timing uncertainty reflects checkout, broadcast, and observation delays.
  • Attack 2: cluster intersection: Attack 2 uses knowledge that multiple blockchain transactions belong to the same user to undo mixing through cluster intersection.The attack targets users who mix coins before spending and can exploit repeated observations linked through cookies or device fingerprinting.

IV. WEB MEASUREMENT: LEAKS OF SENSITIVE DATA

The study measures sensitive-data leaks on Bitcoin-accepting merchant websites using a crawl and modified OpenWPM instrumentation. It examines ordinary tracking and the residual risk when tracking-protection filter lists are enabled.

  • Measurement design: The researchers crawled 130 Bitcoin-accepting merchants selected from larger community-maintained and popularity-filtered site lists.The initial list contained 1438 sites, was reduced to 283 domains, and yielded 130 merchants still accepting Bitcoin.
  • Measurement design: Actual purchases on a smaller subset were required to analyze payment receipt pages, whereas most payment-flow steps could be collected without payment.The broader crawl covered product viewing, cart creation, checkout initiation, and receipt of payment addresses and prices.
  • Measurement design: Modified OpenWPM collected HTTP(S) requests and responses while researchers manually marked and automatically recorded PII and payment-related information.The instrumentation was designed to identify which third parties received sensitive data during merchant-site visits.
  • Tracking-protection evaluation: Tracking-protection risk was measured by rerunning the analysis after removing third-party URLs matching EasyList and EasyPrivacy.This evaluates users relying on community-maintained filter lists such as those used by Adblock Plus and uBlock Origin.

B. Findings

The crawl found widespread disclosure of transaction-relevant information to third parties across Bitcoin-accepting merchants. Leaks included payment data, cart prices, receipt-page information, and invoice-page access, often through mechanisms that enable blockchain linkage.

  • Bitcoin address or BTC-denominated price: 17/130 merchants sent a Bitcoin address or BTC-denominated price to third parties, making blockchain linkage trivial.These leaks occurred mainly on less-popular payment processors and sites implementing their own Bitcoin payment processing.
  • Bitcoin address or BTC-denominated price: QR-code services received Bitcoin addresses and prices through requests that could be retained in logs for later blockchain analysis.11 of the 12 websites leaking Bitcoin addresses sent them to third-party QR-code services.
  • Receipt and invoice-page leakage: Receipt-page leaks exposed payment addresses through referer data, with one Overstock receipt page leaking an address to 42 third parties.Invoice-page URLs were also leaked, and invoice contents from Coinbase and BitPay were accessible without access control.
  • Cart-price leakage: 43/130 merchants sent non-BTC cart-price data to third parties, although missing shipping and handling increased uncertainty about the final BTC amount.Cart prices were shared more often than BTC prices or addresses.
  • Leak mechanisms: The study distinguishes intentional sharing from unintentional referer leakage based on the HTTP request carrying transaction-relevant information.The distinction concerns whether the data was deliberately sent to a third party or exposed through referer transmission.

3) Third parties receiving product page visits:

Third parties receive information from product-page activity, checkout timing, receipt pages, and identity fields, creating multiple inputs for transaction linkage. Access to PII and transaction data can allow trackers to attach blockchain clusters to users’ identities.

  • Third parties receiving product page visits: Third parties can infer cart subtotals from product pages and receive explicit add-to-cart events that approximate pre-shipping cart prices.28 merchants shared add-to-cart events, and Facebook received them on 26 merchants’ sites.
  • Timing and transaction information: Receipt-page loads give trackers approximate transaction timestamps, while checkout events provide an earlier timing signal.245 third-party domains loaded resources on merchant receipt pages, and Facebook’s InitiateCheckout event appeared on 15 sites.
  • PII leakage: 49 merchants leaked some form of PII to 137 third parties, allowing transaction-relevant data to be connected to real-world identities.21 third parties received both PII and transaction-relevant information and could label the resulting blockchain cluster.
  • Active attacks by third parties: Some entities lacking the data for a passive attack could collect it through active attacks using third-party JavaScript access.This extends the risk beyond information already received during normal tracking operations.
  • Active attacks by third parties: Third-party scripts had access to transaction-relevant information on 107 sites and to some form of PII on 125 sites.The access model reflects scripts’ ability to read data in the frames or pages where they are embedded.

2) Network adversaries:

The paper finds that network exposure during payment flows can reveal transaction-relevant information or PII, while blockchain analysis tools help adversaries link observed payment details to transactions. These risks extend across Bitcoin-like blockchains, although Ethereum is out of scope.

  • Network exposure: 36 merchants failed to use HTTPS for crucial payment-flow components, allowing network adversaries to observe transaction-relevant information or PII in cleartext.The affected components included cart pages.
  • Third-party exposure: At least 24 merchants shared PII with BitPay even though BitPay did not require merchants to send it.
  • Third-party exposure: BitPay and Coinbase shared full Bitcoin transaction details with merchants, making blockchain identification easier for those merchants.
  • Analysis infrastructure: The authors use BlockSci and empirical blockchain analyses to show how trackers can use payment information to identify Bitcoin transactions.Many trackers need no such analysis when merchants already share transaction-specific information.
  • Analysis infrastructure: BlockSci supports CoinJoin identification, address clustering, P2P transaction monitoring, exchange-rate data, and several altcoins.Ethereum and other blockchains with complex scripts are out of scope.

B. Method

The single-transaction attack models an adversary matching observed payment price and timing information to blockchain transactions under explicit uncertainty windows. It evaluates anonymity sets and success rates using sampled purchases, timestamps, exchange-rate data, and transaction logs.

  • Research design: The analysis asks how price, exchange-rate, and transaction-time uncertainty determine transaction anonymity-set sizes and adversary success probabilities.The anonymity set contains candidate transactions, one of which is the actual payment.
  • Sampling and simulation: The simulation uses 100 sampled item prices and 100 random timestamps to generate 10,000 payment flows.Each flow includes completed-payment and non-completed-payment cases.
  • Uncertainty model: The model represents price uncertainty through possible final prices, often constrained to fewer than 10 values when the user’s shipping country is known.Cart prices may differ from final prices because of shipping and taxes.
  • Uncertainty model: Payment-time uncertainty is tied to observed shopping, checkout, or receipt-page activity, with processors typically imposing a 15-minute payment window.
  • Evaluation: Success is measured using true positive and true negative rates for correctly identifying completed payments and correctly rejecting non-payments.
  • Adversary model: For each simulated flow, the adversary searches broadcast-transaction logs for matches within the specified price and time uncertainty windows.Matching transactions form the anonymity set; the adversary outputs a unique match, a random candidate, or no transaction.
  • Adversary model: The attack also uses transaction heuristics such as regular recipient addresses, two-output payments, and fresh addresses.Address reuse would generally make linkage easier rather than harder.

C. Results

The single-transaction linkage attack is effective under realistic uncertainty assumptions and remains robust as uncertainty increases. Its success can improve further when adversaries exploit processor-specific transaction patterns or additional information.

  • Default results: 76% true positive rate and 62% true negative rate occur under default uncertainty parameters, where the most common anonymity-set size is 1.Defaults are 15 minutes of payment-time uncertainty, 5 minutes of exchange-rate uncertainty, and a price-uncertainty set size of 5.
  • Uncertainty sensitivity: High accuracy remains when price uncertainty expands to 10 possible values.The paper relates this robustness to the typically small number of shipping-price possibilities.
  • Uncertainty sensitivity: The attack degrades gracefully as payment-time or exchange-rate uncertainty increases, while receipt-page observation can reduce time uncertainty to seconds and produce extremely high success rates.
  • Uncertainty sensitivity: A high success rate is possible when uncertainty is low along any one of the three dimensions: price, time, or exchange rate.
  • Robustness: The results are essentially unchanged when prices are doubled, and they remain similar when prices are sampled from blockchain transaction amounts.The latter sampling strategy slightly improves accuracy.
  • Robustness: Litecoin produces a higher success rate than Bitcoin, plausibly because its two-year transaction volume is lower: 3,605,028 versus 150,614,721.
  • Scope: The reported results use conservative assumptions, so payment-processor behavior or additional adversary information may make practical attack success higher.
  • Additional heuristics: Knowing that BitPay rounds amounts to multiples of 100 Satoshis substantially improves accuracy by eliminating incompatible transactions.

VI. THE CLUSTER INTERSECTION ATTACK

The cluster intersection attack exploits auxiliary information that multiple mixed transactions came from the same wallet. By tracing mixed coins through CoinJoin paths and intersecting resulting wallet clusters, it can recover a unique cluster under suitable assumptions.

  • Attack premise: The attack applies when the adversary knows that two or more mixed-coin transactions trace back to the same wallet cluster.Web trackers may obtain this auxiliary information by observing multiple purchases.
  • Attack procedure: The clustering step recursively expands addresses using multi-input and change-address heuristics while excluding identified mixing transactions.
  • Attack procedure: The algorithm identifies CoinJoin transactions, traces candidate coins backward through at most r mixing rounds, and computes the intersection of their wallet clusters.A unique intersection yields the wallet cluster; otherwise the algorithm reports incorrect assumptions.
  • Evaluation setup: The section presents a large-scale simulation, while empirical validation using the authors’ own wallets is deferred to the next section.
  • Evaluation setup: The study identifies 95,239 JoinMarket transactions, including 78,697 during the two-year evaluation period.
  • Evaluation setup: The simulation assumes a wallet with 100 mixed coins and up to 5 mixing rounds, with the adversary observing two transactions linked to that wallet.Five rounds represents a very high degree of anonymity according to JoinMarket advice.

B. Results

The experiments evaluate cluster intersection under varying mixing histories and validate both transaction linkage and wallet-cluster identification using empirical and purchase-based data. Success depends on the number and timing of observations, while experimental scale and mixing rounds constrain interpretation.

  • Cluster intersection: With one or two mixing rounds, observing two transactions is sufficient for the cluster intersection attack to succeed reliably.Figure 7 relates success rate to mixing rounds and observed transactions.
  • Cluster intersection: The attack becomes less effective as the age difference between mixed coins increases, but long-spanning purchase histories remain more exposed.Coins mixed at substantially different times have less-overlapping anonymity sets; repeated purchases and larger temporal gaps increase risk.
  • Empirical validation: 21 purchases across 20 merchant sites were used to validate the attacks, including 11 purchases made with mixed coins.The study sampled merchants known to leak transaction-relevant information and included both mixed and unmixed funds.
  • Transaction linkage: 48% of purchases had an anonymity set of 5 or fewer under default uncertainty assumptions.The analysis used 5-minute exchange-rate uncertainty, 15-minute payment-time uncertainty, and recorded shipping options.
  • Transaction linkage: When trackers observed the receipt page, the correct transaction was identified 90% of the time, with a true negative rate of 82%.For 14 of 17 such purchases, the anonymity set size was 1.
  • Cluster intersection: The wallet cluster was identified with 89% accuracy from two observed purchases and 99% from three.These results concern adversaries observing mixed-coin purchases whose corresponding blockchain transactions were known.

D. Validating the attack end-to-end.

The paper combines transaction candidates to identify wallets in an end-to-end attack and discusses defenses against tracker-based and blockchain-based linkage. The results support practical risk while emphasizing tradeoffs, incomplete protection, and scope limitations.

  • End-to-end attack: The two attacks can be combined by intersecting wallet clusters across candidate blockchain transactions returned by imperfect single-transaction linkage.Candidate combinations yielding empty intersections can be discarded; a unique nonempty intersection identifies the cluster.
  • End-to-end attack: 11 trackers could observe multiple purchases, creating 25 purchase pairs suitable for the end-to-end attack.The listed trackers included major advertising, analytics, and payment-related domains.
  • Discussion: The findings connect unexpected privacy leaks across interacting systems to retroactive cryptocurrency deanonymization risks.The paper frames these risks as arising when systems lacking well-defined privacy properties compose.
  • Mitigations: Mitigations span user self-defense, merchant practices, and alternative cryptocurrencies or payment mechanisms, but each carries tradeoffs.The paper attributes these tradeoffs to tensions between privacy, e-commerce, and the public blockchain.
  • Mitigations: Merchant mitigations include reducing third-party data sharing and avoiding Bitcoin-address, receipt-page, and unintentional PII leaks.Reducing sharing can conflict with advertising and analytics objectives, and some PII leakage may be intentional for cross-device linking.
  • Mitigations: Tracking protection is incomplete, and multi-round mixing improves privacy only imperfectly while increasing fees and confirmation delays.The end-to-end experiments used only one or two mixing rounds, limiting their evaluation of higher-round tradeoffs.
  • Alternative mechanisms: Lightning could make the attack ineffective because most payments occur off-chain, although the paper notes other privacy concerns.This defense depends on deployment and does not eliminate all privacy issues.

APPENDIX

The appendix describes heuristic identification of JoinMarket transactions and evaluates its computational limitations and empirical coverage. The resulting near-superset and near-subset support different simulation roles.

  • JoinMarket identification: The JoinMarket-identification algorithm filters transactions using structural heuristics about spendable addresses, participants, outputs, and input coverage.The procedure is presented as Algorithm 3 and implemented through sequential transaction filters.
  • JoinMarket identification: The algorithm checks whether inputs can cover output values and change values after allowing for a maximum liquidity-provider fee.The calculation uses partitions of inputs and a fee bound defined from the common output value.
  • Limitations: The procedure is exponential and was limited to transactions with at most 17 inputs because the underlying problem is NP-complete.The optimized implementation still required about 30 minutes to process 150 million transactions.
  • Empirical coverage: Applying the heuristic over May 2015–April 2017 identified 78,697 transactions as a near-superset of JoinMarket transactions.The authors report low false negatives, subject to transactions rejected because of unusually high fees.
  • Empirical coverage: A giant connected component contained 60,187 of the identified transactions, supporting the interpretation that many belonged to CoinJoin activity.The authors caution that non-CoinJoin transactions could occasionally satisfy the filtering criteria.
  • Simulation design: The near-subset is used for victim simulations, while the near-superset is used for adversary simulations.This assignment reflects different priorities: confidence that simulated transactions are CoinJoins versus broad adversary coverage.

B. Additional Tables

The additional tables and figures document robustness analyses for transaction-linkage success under altered timing, pricing, cryptocurrency, and payment-processing conditions. They also summarize third-party leakage and observed anonymity sets.

  • Additional tables: Table VI lists third parties that received transaction-relevant information despite tracking protection.The table focuses on residual leakage under browser-based defenses.
  • Additional tables: Table VII reports how often third parties received transaction-relevant information on at least two websites, with and without tracking protection.This layout supports comparison of repeated exposure across merchant sites and defense conditions.
  • Additional tables: Table VIII counts third parties receiving each type of personally identifiable information with and without tracking protection.The table organizes leakage by PII category and protection condition.
  • Additional tables: Table IX compares the number of third parties on payment receipt pages with the subset receiving transaction-relevant information.The comparison distinguishes presence on the receipt page from receipt of sensitive payment data.
  • Robustness analyses: Figures 10–13 test payment-time uncertainty under blockchain-sampled prices, doubled prices, Litecoin, and Bitpay transactions.Each figure is explicitly framed as a comparison with Figure 5.
Loading 1708.04748v1…