3rd party HTTP services


#1
  1. Calls to HTTP(S) Services HTTPS GET/POST methods to 3rd parties are insecure. The data submitted to the server can be manipulated, they can be faked, etc. We rely on service to provide some data (e.g. Etherscan), this may be unavoidable at the moment. It’d be better to use something lik Oraclize.it. But we don’t give the user an option to enable/disable these features. They should be opt-in

This item from our Wall of Shame has come to my attention more than once recently as we’ve discussed adding additional 3rd party dependencies in the interest of, ironically, improving user security (with Google Safe Browsing) and search & discovery for DApps.

Because it has relatively little attention on it but is an issue pervasive across Status & growing, I thought I’d invite some discussion on it now.

Here are the 3rd party services that I’m aware of Status using or exposing users to:

  • Infura
  • CryptoCompare
  • Etherscan
  • NFT APIs for collectibles (CryptoKitties, CryptoStrikers, etc.)
  • Instabug
  • DApps using DNS
  • Firebase

We like these services because they all serve a role in improving the user experience. But is it time to start implementing some risk mitigation?

And what criteria can help us decide whether the introduction of a new API or HTTP service is justified? For instance, in the case of NFT APIs, the choice there is either to rely on them—or have no NFT feature in the wallet.

Of course, in future cases, with STRIDE or a similar framework applied, we could introduce mitigation tactics from the start.

Would be great to get a sense of 1) the urgency of this issue, perhaps for each individual service; and 2) possible solutions.

So far I’m aware of these issues:

Other tactics that have come up:

  • Use Oraclize.it as a data carrier
  • Make the use of each of these services (and related features) explicitly opt-in or opt-out for users
  • Implement a content security policy

cc @petty of course


#2

For the 7x 3P services we have, I wonder which of them would allow users to switch off (i.e. opt-out)? Some of them would make the app unusable, but imo user choice seems to be the most important spirit here.

Could it be something as simple as a settings page that allows users to disable the endpoints?


#3

There is no technical reason we could not make those opt-out via settings (modulo some native deps like instabug that could be more pervasive).
Some work will be required to make sure opt-outs gracefully degrade the app. How much depends on the dependency.


#4

For posterity: we’re now increasing this risk surface with extensions. Installing a new extension could leak a user’s information, so it’s very important that the user trusts the developer they are installing from.

For now, we’re adding a disclaimer about this on each extension installation screen, but in the future, we could also create a trusted developers program that could potentially offer users more peace of mind by verifying known extensions developers.