Fire Crypto Wallet Browser Extension Basic Privacy Analysis

First, lets take a look at the privacy tab provided by Chrome

Quite a bit of user activity is collected, and is only sold to ‘approved third parties’.

When we install the extension, chrome is immediately sent to https://mint.joinfire.xyz in a new tab.

This generates quite a bit of traffic, specifically to alchemyapi.io

On the right side of the above image are timestamps – about 18 requests/second being sent from your browser to eth-mainnet.alchemyapi.io

The HTTP verbs POST and OPTIONS are used to maintain contact with this server. This amount of requests in quick succession will lead to the following.

Our browser eventually receives the HTTP response code 429 Too Many Requests.

Here we are served up Twitter ads from static.ads-twitter.com. The highlighted ‘Referer‘ header shows that this request for Twitter’s javascript was generated as a result of the forced visiting of https://mint.joinfire.xyz by the extension.

Above, the ‘Referer‘ header is not from the NFT mint page, but Fire’s normal front-end subdomain. It loads javascript from connect.facebook.net in your browser.

Below is a request to geolocation-db.com.

Notice I omitted the response from the server? That is because the following fields with corresponding values are returned by the server: ‘country_code‘, ‘country_name‘, ‘city‘, ‘postal‘, ‘latitude‘, ‘longitude‘, ‘ipv4‘, ‘state‘.

The provided latitude and longitude as displayed by Google Earth placed me 2.2 miles from my house

As you might imagine, I am not quite a fan of this. Y’all should know by now to check the Referer header, Fire’s NFT mint subdomain at work.

And even though geolocation-db.com returns your ip address, that’s not enough:

This request to api.ipify.org simply returns your ip address. Here we see the ‘Referer‘ is from the ‘app’ subdomain. Remember that I never add funds to these test wallets, so unfortunately we will not see a TX in action.

Trying to mint the NFT results in this page, showing we have insufficient funds. Below is the HTTP traffic of this action.

Here is a small glimpse into the actual functionality of the extension. This HTTP/2 POST request is sent to api2.services.joinfire.xyz. The POST body, displayed under the request headers, are sent to ‘/simulator/transaction‘. As stated by Fire’s website, “Introducing Fire – an extension that simulates transactions, showing you exactly what will go in and out of your wallet before you sign the contract. All under your control with your current wallet.”

This below request to www.4byte.dictionary is odd as it lacks a Referer header. I have no reason to believe that MetaMask created this request.

Search results describe the website as an ‘Ethereum Signature Database’. The request includes the HTTP Get parameter ‘hex_signature=‘ with a 4 byte value represented in hex, sent to the endpoint ‘/api/v1/signatures/‘. The value of ‘text_signature‘ in the response section being ‘mint()‘ leads me to believe that this request was generated by Fire.

And of course, the obligatory requests to sentry.io