“Animation” URL in NFT marketplaces considered harmful for privacy

The widespread adoption of blockchains, notably Ethereum and Bitcoin, has brought about an increased focus on privacy concerns within these decentralized systems. Except for a few notable exceptions, in most public blockchains, privacy relies on a single pillar, namely, pseudonymity. Indeed, Ethereum, Bitcoin, and many other blockchains store all the information in the clear on the blockchain, exposing the entire transaction history. This means that anyone accessing the blockchain is able to retrieve information about the amount of funds each account holds and the transaction history between accounts, much of which is usually considered sensitive and private information.

The only thing that prevents linking account balances and transaction history to specific individuals and companies is the use of pseudonyms as identifiers in blockchains. Accounts in those blockchains are associated with pseudonyms (e.g., Ethereum and Bitcoin addresses) that cannot be directly linked to a specific person or company. Each participant in a blockchain can have multiple pseudonyms simultaneously or sequentially over time and can easily transfer assets between them. Being able to link pseudonyms to other pseudonyms or to other Personally Identifiable Information (PII) would result in a severe privacy breach. Unsurprisingly, most exchanges that deal with cryptocurrencies and other onboarding processes are legally required to identify their customers (under the so-called Know-Your-Customer KYC regulations) [1], so that authorities are able to compel them to link the on-chain pseudonyms to actual entities in the physical world if legally mandated.

It is also not surprising that linking pseudonyms with PII and other pseudonyms is a preferred goal of attacks against the privacy of blockchain users. Over the last year, Non-Fungible Tokens (NFTs) were devised as a means to perpetrate such types of attacks. NFTs have grown more and more in popularity due to their unique ability to represent digital ownership. While they are based on complex blockchain technology, end users do not need deep technical knowledge to use them and enjoy their benefits. Because they are based on the blockchain, they are easy to verify and impossible to forge or duplicate, making them ideal for representing digital assets with intrinsic value.

One of the primary benefits of NFTs is their ability to create scarcity and exclusivity, allowing creators to monetize their digital content in a way that was previously impossible. Their usage ranges across a wide variety of categories, including art, music, and collectibles. Unfortunately, early last year, it was reported that NFTs can be used to disclose users’ IP addresses [2]. This attack uses a basic technique (URL rendering) and is used to disclose basic personal information (i.e., the IP address). In this paper, we show that it is possible to extend these attacks, leveraging more advanced user-tracking techniques, specifically fingerprinting, to dramatically increase the scope of the reported attacks. Web fingerprinting can uniquely identify users using a set of the user’s browser properties. It is a well-known and proven technique that is extensively used for targeted advertising and other customized web services.

The contributions of this paper are as follows:

• We describe NFT-based attacks that are capable of retrieving enough browser attributes to enable web fingerprinting and uniquely identify the owner of the blockchain account that possesses the NFT. These attacks can be directed to specific blockchain accounts by airdropping the NFT to the target account.

• We describe how it is possible to use NFT-based attacks and fingerprinting to determine that two targeted blockchain accounts belong to the same owner.

• We build a proof of concept of the described attacks to showcase that the attacks are feasible and effective.

• We provide a set of recommendations and countermeasures for the different parties affected by the attacks, so they can prevent the attacks or at least mitigate their effects.

The rest of this paper is structured as follows. In Sect. 2, we provide background and related work regarding previous attacks against user privacy using NFTs, as well as the state of the art in user tracking techniques commonly used on the web. In Sect. 3, we describe the method identified to extend the existing attacks and enable fine-grained user tracking. In Sect. 4, we describe the experiments performed to verify the feasibility of the new extended attacks, including the description of the experimental setup, the actual experiments, and the obtained results. In Sect. 5, we propose a set of recommendations and countermeasures against the described attacks. Section 6 concludes the paper.

2.1 Privacy attacks based on NFTs

The attack leveraging NFTs to disclose the user’s IP address holding a given Ethereum address was first reported in [2] and it consists essentially in including the URL of a server controlled by the attacker into an NFT and then airdropping the NFT to the victim’s Ethereum address. When the user explores her NFTs, the rendering of the NFT fetches the URL’s content, naturally disclosing the IP address of the device of the user to the attacker’s server. This is aggravated by the default behavior of some wallets, such as Metamask [3] (the most popular wallet with more than 21 million users worldwide), which automatically renders the NFT contained in the wallet. This approach can also be used to launch a DDoS attack if the NFT points to the victim’s server instead and the NFT is distributed to a large number of users.

As a follow-up to [2, 4] described another mechanism to learn the users’ IP using NFT through the Opensea NFT market [5]. In this case, the attacker’s NFT is uploaded to the market. The NFT includes an image, which is uploaded to the market and rendered from servers selected by the marketplace, typically through IPFS (Inter Planetary File System). The use of IPFS prevents attackers to control the server hosting the NFT content and consequently to have visibility of the IP addresses of the clients browsing the marketplace. However, Opensea supports what they call an “animation URL” which is passed to the user browsing the market, which is then accessed directly by the end-user. To perform the tracking attack, the attacker includes in the “animation URL” an image stored in a server controlled by the attacker, so that when the client renders the content of the “animation URL”, it exposes its IP address to the attacker.

As opposed to the previous attack on Metamask, this attack is not directed to a specific target Ethereum address, but to any user that is displaying the attacker’s NFT as they browse through the NFTs available in the market. As such, it is unclear how useful is the information retrieved, as the attacker would then obtain a set of IP addresses that belong to users that were browsing the market, but not directly bound to any other relevant information, such as an Ethereum address. The authors suggest that it would be possible to send the link to the NFT to the victim and scrap the victim’s IP address out of all the IP address logged by the NFT, coming from all the viewers of the NFT, i.e. the victim and other users browsing the NFTs in the marketplace.

2.2 Advanced web tracking techniques

The term web fingerprint was introduced in 2010 by Eckersley et al. [6] in the first study at scale that showcased that is was possible to uniquely identify users through the combination of the user’s browser properties.

Web browsers have a set of libraries and application programming interfaces (APIs) that allow access to information about the browser, the operating system and/or the device. For example, one of these functions reveals the type of connection of the user. This allows to accordingly adjust the load imposed by the rendering to the connection type of the user e.g. a user connected using WiFi has no problem with retrieving high quality images, but a user connected to the mobile network is likely to prefer to have lower quality images to optimize data consumption.

Web fingerprinting, or device fingerprinting, is a technique used to track users by collecting information using the libraries and APIs available in the user’s browsers. A wide variety of attributes can be collected through these APIs, including, User-Agent, Screen resolution, List of fonts, Timezone, System information, and many others. By concatenating these attributes, the fingerprinting algorithms create a hash that can uniquely identify a user. An overview of web browser fingerprinting techniques and solutions can be found in the survey by Laperdrix et al. [7], that provides the current status and definition of browser fingerprinting and the available solutions.

Web fingerprinting has raised concerns regarding user privacy and tracking since its inception. This is because it is usually implemented without any form of user consent [8]. Even if a user deletes cookies or uses private browsing, the fingerprinting technique can still be effective.

The privacy risks of web fingerprinting have been extensively studied by the research community [9,10,11,12,13,14,15,16].

We explore the possibility of extending the attacks presented in Sect. 2.1. More specifically, we investigate whether it is possible to use state-of-the-art web-tracking techniques to extract further information through NFTs.

As we described earlier, the attacks presented earlier manages to learn the IP address of users that display the adversarial NFT. While this attack exposes one piece of personal information (the IP address), it is hardly enough to uniquely identify users or any other form of malfeasance, since IP addresses change with the Internet attachment point and are commonly shared between multiple users, both simultaneously and sequentially, due to the pervasive adoption of Network Address Translation (NAT) and Carrier-Grade NAT (CGN).

We next describe several extensions to the proposed attacks that expand their scope and increase their potential effects. Specifically, we look into techniques that enhance the attacks in terms of precision of the targeting, accuracy of the attack, amount of information retrieved and domain of the attack.

Enabling accurate tracking: While the IP address is recognized as personal data, relying solely on logging IP addresses is ineffective for user tracking. The widespread implementation of NATs and CGNs in mobile networks has resulted in multiple users sharing the same public IP address. Moreover, this IP address changes when users switch their internet connection points. By expanding the scope of collected information beyond the IP address, it becomes possible to uniquely identify users and enable individual user tracking. In this regard, we propose utilizing the well-established web fingerprinting techniques detailed in Sect. 2.2. These techniques offer various approaches to uniquely identify users on the web. Specifically, we have developed a custom JavaScript script, commonly referred to as a “pixel” in the online tracking jargon, to gather additional device parameters such as User-Agent, browser language, screen size, and installed plugins. Literature has proven that a combination of these parameters is able to uniquely identify a device and by association, a user [7, 17].

The attack we describe is to leverage these web fingerprinting techniques to identify individual devices/users associated with different blockchain addresses. If such identification proves possible, it would represent a significant breach of security and privacy in the ecosystem.

Cross chain attack: Attacks described in [4] were executed on the Ethereum main blockchain, targeting Ehtereum users. It is possible to extend the attack to cover other blockchains and Layer 2 solutions in Ethereum. Specifically, we show that it is possible to launch attacks using other of the blockchains supported by the vulnerable market places. This actually greatly expands the attack surfaces, since the attack is now capable of linking PII not only to Ehtereum addresses, but also to addresses of other blockchains. Being able to launch attacks over other blockchains enable the attackers to benefits from the specific characteristics of the blockchains. For instance, using NFTs airdops as vehicle to deploy an attack in Ethereum is expensive, since each airdrop requires an NFT transaction. However, an attacker can launch the attack in other cheaper blockchains, such as Polygon. This approach drastically reduces the costs of the attack, significantly expanding the scale of the attack under the same budget constraints. In Ethereum, the NFT contract would cost approximately 50$, and each mint 10$. Therefore, targeting the top-1 M accounts would cost  10 M. Using Polygon or Solana is several orders to magnitude cheaper.

Attack to link multiple addresses:The goal of the original attack described in [4] was to obtain the IP address information of the victim. We argue that it is possible to expand the scope of the attack, so that the attacker is able to link multiple blockchain address of a single user with very high precision. Suppose that an attacker has the suspicion that two Ethereum addresses belong to the same user. To confirm that this is the case, the attacker airdrops one malicious NFT to each of the suspected Ethereum addresses and when the NFTs are rendered, the attacker is able to retrieve the victim’s information and confirming that the two addresses belong to the same user. Moreover, it is feasible to launch this attack in cross-chain manner, that is, to target multiple addresses in different blockchains e.g. the attack can link one Solana address and one Polygon address to the same user.

Target precision: The method used in [4] for targetting users browsing NFT marketplaces is to send the URL of the NFT to the victim and then try to discriminate the victim’s IP from other users who also looked at the malicious NFT. It is possible to significantly increase the precision of the attack in NFT marketplaces using airdrops as proposed in [2]. The attack is initiated then by airdropping a malicious NFT to a target’s Ethereum address. When the user connects to the NFT market place, the NFTs associated to the victim’s Ethereum address are rendered, including the malicious NFT that was airdropped. Relying on the “animation URL”, the malicious NFT causes the victim to connect to the attacker’s address, disclosing its IP address and other information useful for tracking. Since we airdrop different NFT to different victim’s Ethereum addresses, we can properly bound one IP address to each attacked Ethereum address.

In this section, we build a proof of concept of the described attacks and then we use it to perform a series of experiments to validate the feasibility and the effectiveness of the attacks described in the previous section. Specifically, the goals of the experiments are:

1. 1.

   Verify if it is possible to use attacks based on airdropped NFTs to gather the information required by web fingerprinting techniques to uniquely identify users.

2. 2.

   Verify if it is possible to determine that multiple addresses belong to the same user.

Architecture diagram

Full size image

We first describe the proof of concept implementation of the attacks and the experimental setup used. We next describe the experimental methodology used and finally, we present and analyze the obtained results.

4.1 Experimental setup

The purpose of the experiments is to create a real environments where we can execute the attacks. We will perform both the role of attacker and the role of victim, to refrain from attacking any third party or infrastructure.

From the attacker’s perspective, we create a malicious NFT smart contract and we deploy the web server to which the NFT connects when it is rendered at the victim’s device and stores the victim’s private information. To launch the attacks, we deploy the NFT smart contract in the selected blockchain and perform the airdrops.

In terms of the victim, we need to create several addresses which will receive the airdroped NFTs and access them through the wallet and through the selected NFT market places.

All the components involved in the experiment are depicted in Fig. 1. We next detail each of the components of the experimental setup.

4.1.1 Blockchain selection

We first select the blockchain used in the experiments. We decide to execute our experiments using Polygon. The reasons that motivated this choice is that Polygon is fully compatible with Ethereum but it is significantly cheaper.

In particular, Polygon uses Ethereum addresses. This means that is a user can use the same address for both Ethereum and Polygon, and whatever we can learn about an address in Polygon is also valid for this address in Ethereum. For example, if through the attack using the Polygon blockchain we are able to determine that two addresses belong to the same user, then we can conclude that these addresses belong to the same user also in Ethereum.

Also, the same NFT smart contract can be deployed in both Ethereum and Polygon. So, the same NFT that is used to launch an attack in the Polygon blockchain can be used directly to perform the attack in the Ethereum blockchain.

Finally, the gas fees required to perform the experiments in Polygon are several orders of magnitude lower than in Ethereum.

This by itself is an interesting insight of this work. Cheaper Layer 2 solutions that re-use Ethereum address and Ethereum smart contracts can be used to launch cheaper attacks and disclose potentially valuable information about Ethereum. As mentioned earlier, the proposed attack is able to link two Ethereum addresses using the Polygon blockchain.

4.1.2 Attacker setup

The infrastructure required by the attacker includes the attacker’s blokchain setup, the NFT smart contract, the NFT market place setup, the tracking script and the control server used to track the user. We describe each of the components next.

Blockchain setup for the attacker: We create a Polygon address for the attacker. This is needed to be able to deploy the NFT smart contract, mint the NFTs and airdrop them. We provision some MATIC (the Polygon currency) to the attackers account. We use the Metamask wallet to manage the attacker’s accounts.

Tracking script: The tracking script is the script that when executed at the client’s device, it will convey the information used to track the client. It is a JavaScript code, embedded in the NFT, which will be executed once the NFT is rendered. We have then developed the JavaScript code that collects some of the typical parameters that are sufficient for accurately fingerprint users, according to the state of the art presented earlier. These parameters are listed in Table 1. The table reports the name of the field retrieved, a description of the information retrieved, the JavaScript function used to retrieve it, and an indication of whether the parameter itself could imply a privacy risk for creating a unique identifier. In this column, high means that the parameter reveals personal information that can serve as a unique identifier, medium means that although it is not a unique identifier, it can have sufficient granularity to be unique, while low means that it does not reveal any personal information by itself. However, the combination of some of these parameters has been reported to potentially lead to a unique identifier, regardless of whether they collect personal information or not [7, 14].

Control server: In addition to the tracking script, we build the infrastructure that we use to render the script and that will also store the information extracted through the script. The architecture that we will use is the following:

• server.js: Javascript file idly running on the control server side. It will be listening to WebSocket connections in the specified port (in our case 8080) and sending them to our SQL database.

• client.html: HTML file embedded in the NFT which loads the desired image and also runs the client’s Javascript code and initiates the websocket connection.

• client.js :  Tracking script (described in the previous section) implemented in Javascript that is executed when loading the HTML file. It connects to the server via a WebSocket.

This pipeline can be better visualized with the diagram of Fig. 2.

Detailed diagram experiment setup

Full size image

NFT smart contract and metadata: We create a standard ERC-721 NFT smart contract using the OpenZeppelin [18] library to create our NFTs. The NFT contains a jpeg image that we store in IPFS. For the experiments involving a marketplace, we also define that corresponding is able to associate metadata. The NFT metadata is a JavaScript Object Notation (JSON) file that follows the standard defined for the selected combination of chain and marketplace. We follow the guidelines detailed in [19]. There are some optional fields that we may not need for our purposes. The ones we will use are:

• id :  unique integer representing the NFT’s id.

• description :  The text that will be shown with an NFT explorer.

• \(animation\_url:\) (optional) HTML or MP4 file that can be embedded in the NFT. This field is key for our study, since we will use a tracker embedded in this file.

• \(external\_url:\) (optional) Link to a external website (For instance, creator’s website or NFTs collection web)

• image :  Link to NFT’s image.

• name :  NFT’s name

We use the \(animation\_url\) field to include a pointer to the web page stored in the Control Server that embeds the tracking script. The image field contains the URL of the image file stored in IPFS.

Lastly, we upload the JSON metadata configuration file to a hosting service. In our case, we used [20], which allows to host any json file if it is previously pushed to a GitHub repository.

4.1.3 Victim setup

On the victim side, we tested different configurations, varying the device, the browser, the Internet connection point, and the wallet. Regarding devices, we used two devices: a Windows laptop and an iPhone mobile phone. Regarding browsers, we used Edge, Firefox, Brave, Safari, and Chrome. In terms of wallets, we used Metamask, Phantom, and Coinbase Wallet. We used two different Internet connection points, both of them fixed using a Wi-Fi access. We configured different Polygon addresses for each combination of device-browser-wallet-Internet connection.

4.2 Experiment description

We perform the following experiments:

4.2.1 EXP1: Extracting user fingerprinting information through client’s wallet

In this experiment, we first launch the attack performing the following steps (which would be executed by the attacker):

1. 1.

   We embed a link to the client.html in the NFT itself (i.e. in the NFT smart contract).

2. 2.

   We deploy the NFT smart contract in the Polygon blokchain using the attacker’s account.

3. 3.

   We mint a new NFT.

4. 4.

   We airdrop the newly minted NFT to the account of the client we are aiming to track.

Next, we perform the role of the victim and we open the client’s wallet, and we test if the NFTs available in the client’s account are automatically rendered, enabling the tracking.

In this experiment, we test different client configurations. Specifically, we test the different combinations for the different browsers (Edge, Firefox, Brave, Safari and Chrome) and the different wallets (MetaMask, Phantom and Coinbase). To each browser-wallet combination, we configure a different Polygon address.

4.2.2 EXP2: Extracting user fingerprinting information through NFT marketplaces

Similarly to the previous experiment, we first execute the necessary steps executed by the attacker to launch the attack. In this case, these are the following:

1. 1.

   We create the NFT smart contract which only includes an image stored in IPFS.

2. 2.

   We mint one NFT.

3. 3.

   We create the NFT metadata JSON file and we include the link to the client.html in the “animation” URL field.

4. 4.

   We upload the metadata file to the hosting service.

5. 5.

   We airdrop the NFT to the target’s Polygon Address.

We next execute the role of the victim and we connect to the NFT marketplace using the client’s wallet. We test if the NFTs available in the client’s account are displayed and the tracking is enabled.

We tested eight popular NFT market places, extracted from [21]. Specifically, we tested OpenSea, Rarible, Unick.io, Wen Moon Market, Floor, polygonscan.com, element.market and NFTTrader. Similarly to the previous experiment, we also tested the different client configurations considering all the aforementioned browser-wallet combinations.

4.2.3 EXP3: linking multiple ethereum/polygon addresses

In this experiment, the attacker performs the following steps to launch the attack:

1. 1.

   We create the NFT smart contract and include the relevant pointer to the client.html :  (i.e. either in the NFT itself in the case of wallet based attacks or as part of the metadata in case of the marketplace based attacks).

2. 2.

   We mint several NFTs (one per target account).

3. 3.

   We airdrop different NFT to each of the target’s Polygon Addresses.

In order to play the part of the victim, we sequentially connect to the different accounts and retrieve the NFTs associated with each of them. We test if the different Polygon addresses of the victim can be linked together using the retrieved information in all the cases.

We use all the different combinations of NFT market place, browser and wallet described in the previous experiments. Additionally, we perform experiments using the same Internet attachment point to connected to the different accounts and we also perform experiments using different Internet attachments points when accessing the different accounts, in order to assess the robustness of the described tracking techniques to changes in the Internet attachment point information.

4.3 Results

We next describe the results obtained for the different experiments.

4.3.1 Results for EXP1 about extracting user fingerprinting information through client’s wallet

In this experiment, we try to increase the accuracy of the attack by embedding into the NFT a link to HTML code to retrieve sufficient information that can be later used to uniquely fingerprint the user.

The result of this experiment is negative, as it was not possible to achieve the goal of the experiment because the tested wallets only render image files and not general HTML files.

Specifically, we tested the most widely used wallet, Metamask, which also happens to be the wallet tested in the prior work [2]. We observe that while it is possible to extract the IP address of the client, it is not possible to extract further information to increase the accuracy of the tracking. We also tried with different wallets, including Phantom and the Coinbase wallet and we observe similar results. The “invisible” pixel html is not loaded. We observe the same behaviour irrespectively of the browser used.

4.3.2 Results for EXP2 about extracting user fingerprinting information through NFT marketplaces

Among the NFT marketplaces we tested, we found that for both OpenSea and Rarible (the most popular NFT market places), enhanced tracking was possible because the “animation” URL was automatically loaded while browsing the NFTs. For the remaining NFT market places (NFTrade, Unick.io, Wen Moon Market, Floor, element.market, NFTTrader and polygonscan.com), enhanced tracking was not possible because of different reasons, as we describe next.

NFTrade is a popular NFT marketplace that also supports the Polygon chain. When testing it, we conclude that fingerprinting cannot be performed since HTML animations are not loaded (a placeholder image is shown instead). We observe a similar behaviour in other market places, including Unick.io, Wen Moon Market, Floor and polygonscan.com (official explorer of the Polygon Chain). In the case of GhostMarket, NFTs are not viewable because they have to be minted using their own Smart Contracts. Nevertheless, the NFT’s HTML animation would not be viewable since the metadata format that they use do not account for an equivalent to the “animation” URL field according to their developer guides [22].

Finally, some of the NFT market places simply did not display the NFTs in the client’s wallet. These are element.market and NFTTrader.

On those marketplaces where it was possible to add an animation_url (i.e. OpenSea and Rarible), we inserted the custom JavaScript described in Sect. 3 and tested the feasibility of retrieving the common parameters that allow performing web fingerprinting. We performed experiments using the different browser/wallet combinations available.

The results indicate that it is indeed possible to retrieve a set of parameters detailed in Table 1, which is sufficient to fingerprint users. In Table 2, we showcase a sample of the set of values retrieved, indicating that with standard fingerprint algorithms, it is possible to uniquely identify clients, as long as the same browser is used. If a different browser is used, tracing becomes more challenging, as the number of invariant fields in the fingerprint is reduced.

4.3.3 Results for EXP3 about linking multiple ethereum/polygon addresses

In this section, we present the results of our experiment aimed at associating two Polygon addresses with the same user through the utilization of various NFT marketplaces on the Polygon PoS chain.

We replicated the experiments conducted in Sect. 4.3.2 using multiple Polygon accounts using different configurations of device, browser, wallet and internet access point.

When we access the different accounts using the same device and the same browser, but changing wallet or Internet access point, we obtained consistent values for the different parameters necessary to create a user fingerprint. This consistent behavior was observed in the two marketplaces where the attacks described in the preceding section proved successful, namely, OpenSea and Rarible.

When a different browser is used to access the different accounts, the fingerprinting information exhibits larger variations, making it challenging to execute the attack.

4.4 Applicability to other blockchains

In this section, we discuss the applicability of the presented attacks to various blockchains. In this paper, we conducted our experiments using Polygon. We did that mostly because Polygon allowed us to perform the experiments at low cost.

Polygon is fully compatible with Ethereum, both in terms of addresses and smart contracts. This means that Ethereum is also vulnerable to the attacks presented in the paper. Moreover, as we mentioned earlier, since Ethereum and Polygon use the same addresses, launching the attack on Polygon would provide information about the Ethereum address (and the cost of the attack would be cheaper).

NFTs are also available in Solana. The Solana NFT standard also defines an “animation” URL in the NFT metadata. Because of that, we hint that the attacks presented are also reproducible in the Solana blockchain.

Through our experiments, we have shown that it is possible to use NFT airdrops and standard fingerprinting techniques to uniquely identify users while browsing popular NFT marketplaces. Moreover, we have shown that it is possible to use these techniques to determine that several blockchain accounts belong to the same user. Both of these are severe privacy breaches.

We next present a set of recommendations and countermeasures that can be deployed to prevent and/or mitigate these attacks. We describe them from the perspective of the different actors involved in the attack.

NFT market place Market places are in the best position to prevent the presented attacks. These attacks rely on the “animation” URL to be effective. As we have presented earlier, several market places prevent the loading of HTML contained in the “animation” URL, which blocks the described attacks. Others, get rid of the “animation” URL altogether, which also prevents the attacks.

End-user While is not trivial for the user to prevent these attacks, there are a few best practices that the user can adopt to limit her exposure to them.

• The most effective countermeasure that end users can adopt to prevent an attacker to determine that multiple blockhain accounts belong to the same user is to use different browsers to access their different accounts.

• Users should check for (and possible delete) new airdropped NFTs using their own wallet (such as Metamask) before connecting their account to one of the vulnerable NFT market places. As our experiments have shown, wallets may leak the IP address but prevent the leakage of further information. The IP address by itself is not enough to track users. If a user wishes to be extra careful, she can change the Internet attachment point when accessing two blockchain accounts that she does not not want to be linked together.

• Users should avoid using the same blockchain address in two different blockchains even it the same address format is supported. For example, a user should avoid using the same address for Polygon and for Ethereum, even if that is possible. The reason is that if an attacker is able to associated several accounts to the same user in Polygon, this also holds for Ethereum. And launching attacks is Polygon is far cheaper than in Ethereum. Using the same accounts in both blockchains lowers the costs for the attack against the privacy of Ethereum accounts.

Browser As a primary countermeasure against fingerprinting, we suggest leveraging specific features that are already integrated into various browsers to mitigate web fingerprinting. Although some of these features are still in the testing phase, adopting proactive measures can improve the situation and help avoiding web fingerprinting. Examples of measures implemented by browsers, listed by their popularity, include:

• Chrome: Google Chrome is one of the most used browsers. The browser has announced their Privacy Sandox, which includes several measurements, but is still under development and testing  [23]. They have started to restrict third-party cookies by default for 1% of users for testing purposes and announced that for early 2025 they will proceed with the full deprecation of third-party cookies in their browser.

• Safari: Since 2019, the versions of the browser come with features like Intelligent Tracking Prevention and fingerprinting defense turned on by defaults. These techniques block the trackers and cookies, and do not allow APIs that includes things like location, sign-in status, and other data that can be used for cross device tracking [24].

• Edge: Microsoft is committed to providing all the information their clients need to make informed choices about data collection in Microsoft Edge. They do not have a specific sandbox for protecting privacy, but they have recently disclosed a whitepaper detailing how to protect user privacy, leaving the decision directly to their users [25].

• Firefox: Firefox implemented the Enhanced Tracking Protection feature as the default setting in 2019, blocking known trackers and cookies by default [26]. This feature also offers an opt-in option to prevent the collection of certain API parameters, such as fonts or operating system versions.

• Brave: Brave accounts with a privacy feature to defense against browser fingerprinting. It includes two types of fingerprinting protections, blocking or removing the parameters reported by certain APIs or randomizing the parameters return by the APIs [27].

There are solutions that are even more restrictive, such as the browser Tor [28], but they are less functional solutions, as it has been studied that being so restrictive affects the quality of the users’ experience [29]. Therefore, we have only listed some of the most popular and functional browsers.

Wallet Wallet vendors have already implemented an important safety measure to protect users from NFT-based attacks against their privacy. As observed in our experiments, wallets block the loading of HTML files embedded in the NFTs and they only render images from NFTs. It would be possible for wallets to implement further safety measures to protect users. For example, wallets could issue a warning when an NFT containing a “animation” URL is present in the wallet, so that users are aware that connecting the wallet to the marketplace would jeopardize their privacy.

In this paper we have shown that it is possible to use NFT airdrops to obtain enough information from the browser/device in order to uniquely fingerprint the user associated to a blockchain address, such as Ethereum or Polygon address. The fingerprinting breaks the existent privacy assumptions on most blockchains, namely, that blockchain addresses are pseudonyms that cannot be linked to real users (unless legally mandated). This fingerprinting can be used in different manners. One possibility that we show in the paper is that it can be used to link multiple blockchain accounts. The attacker can target a number of addresses of the same or different blokchains and aridrop NFTs to all of them. Through the fingerprinting, the attacker can verify if the different blockchain addresses belong to the same user. Another possibility is that the entity collecting the fingerprints has other information associated to it, retrieved through the browsing history of the user and it can link the blockchain addresses to other user preferences and history.

We have proposed a number of recommendations and countermeasure to protect the users or at least mitigate the effects of these attacks. Specifically, we recommend that users use a different browsers when connecting to NFT markets using different accounts that they wish to remain unrelated to the rest of the world.