Wallet Privacy: Permission First Outbound Calls

Feature requests
, ,
1

Hi everyone,

Our current wallet implementation, in my opinion, breaks our promise of a privacy first application. We all aim for our approaches to align with our principles and to understand how these approaches impact on our privacy first mission. As part of this I’d like to highlight one aspect that is out of step with our public goals.

The Problem

TLDR: We do not inform about or ask users for permission to make HTTPS calls within the wallet.

At present, when a user navigates to the wallet screen, the application makes at least 8 outbound HTTPS calls per wallet account to various service providers. This occurs regardless of whether the user just browses to the screen or actively uses the wallet. This exposes the user’s IP address without their knowledge or explicit consent. For an app that prioritises privacy, this behaviour is undesirable and will undermine user trust.

For a more detailed look at what we currently expose please see my work on cataloging the places our app shares user data Privacy With Status Third Parties — Status

Where We Currently Inform and Ask For Permission

Consider the messenger part of the app, which already handles a similar situation in a privacy-first manner. Specifically:

  • When accessing features like URL unfurling or third-party hosted GIFs, the app explicitly asks the user for permission.
  • Only if the user consents, and only with whitelisted service providers, will any outbound requests occur.

Example:

image
image1550×1092 55 KB

image
image1737×1092 56.9 KB

Please see the following information for more details:

The Proposal

I propose that we apply a similar model for the wallet:

  1. Explicit Permission: Before making any outbound HTTPS calls related to wallet services, the app should request the user’s permission.
  2. Whitelisting Providers: The app should limit outbound calls to a predefined and whitelisted set of providers, ensuring users know exactly where their data may be sent.
  3. Transparency: Clearly inform users of what data will be shared (e.g. IP address) and why it’s necessary.

This change would greatly enhance the app’s privacy stance and align wallet functionality with the privacy-first principles applied elsewhere in the app.

I believe that with these changes, we can improve user trust while maintaining essential wallet functionality.

Looking forward to hearing your thoughts!

2

Has Tor integration been considered instead of the proxy strategy? tldraw • very good free whiteboard

1 Like
4

The proxy strategy is not a user centric service, it protects our API keys from large scale abuse. I know we spin the proxy as a privacy feature. It isn’t.

Tor integration has been discussed a few times over the years, I’ve recently suggested that users should use Tor when using the Status app in my article here Privacy With Status Infrastructure and Insights — Status .

I think that the main issue with Tor is the latency issues inherent with Tor. It is worth reconsidering.

5

Todos

  • Make and share a list of all HTTPS calls that are triggered when wallet opens.
  • Details the other HTTPS calls that are triggered in wallet at other times.
6

Seems like a potentially (relatively) low cost, low risk option, it may require a lot of QA though. And a discussion about whether Tor is default on or off. Do you have any opinions @fryorcraken ?

The Bine lib looks like the best option for go given it is recommended by karalabe (Péter Szilágyi) · GitHub here GitHub - ipsn/go-libtor: Self-contained Tor from Go

Here’s an example tor client:

I have concerns about latency issues, which for API calls shouldn’t be too bad, we’ll need to see.