Polkadot Products Devote - Feedback (Privacy)

Tech Talk
1

I put some comments in X posts recently here .

I don’t mean them as harsh criticism, I’m more trying to understand the goals and potential compromises that come with making this an iPhone/Android app.

Gist of it is that whilst there will always be a link between which appleid installed something from the App Store, there appears to be several in-app things that store/publish/reveal identity that could be configured away or solved for.

Is the intention to solve for these? What is the current goal re-in-app privacy?

linked x post content:

Genuine q from a beta user. I expected the app to be private: no email/phone/keys on device. But the repo shows Firebase contacted every launch, screen views tied to a Keychain UUID that survives reinstall, and RPC nodes seeing my IP. Which of these change in prod?

expanding a bit as I go through the repo:

Privacy gaps in the iOS beta (ios-dev-v0.1.3):

  1. iceTransportPolicy unset → defaults to .all → calls hand your real IP to the peer. You already run TURN. One line to fix.
  2. Firebase contacted every launch, before Polkadot.

Firebase = Google sees IP first, & identity_backend_url stays remotely mutable. Nothing I audit today is pinned

PostHog also logs screen views against a Keychain UUID that survives reinstall

Asks:
— Config on-chain
— Tor + light client
— TESTNET_FEATURE off in prod
— .xcprivacy

2

Hey, thank you for the post!

It isn’t yet perfect and some things still need to be improved. Generally, the app will probably never solve “ip leakage”. You can already solve this by using e.g. TOR or a VPN service. However, RPCs will not be used in the future. The app is bound to use smoldot, but it isn’t fully there yet. Main problem being battery draining and it is being worked on.

The UUID that survives reinstall, I assume this comes from the unique device checks by the app. These will probably need to stay there, but maybe can be improved.

Firebase is right now used for the configuration, but will also be longterm replaced by some on chain config.

3

you can wrap rpc calls into a tor proxy client side, but it requires the users to run a heavy wasm binary in the browser which slows things down, shield.markets have a poc of it, might be worth checking out: tor-js | PSE (the alternative is to make a lighter implementation of snowflake proxy in wasm)

long term it would be nice to have some privacy preserving light client protocol thats not to complicated(like maybe: https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf)