Do You Own Your Data If You Can't Control Or Access It?

[alexc.id]

The forum discussion on Possible App Impersonation Attack is not clear. Specifically:

1. Is there really an “impersonation attack” happening or is a user just not reading dApp dialogs?
2. Is this specific to web instead of mobile?

AFAIK, it appears to be a user reading issue / messaging improvement issue, and not one where a user is unwittingly tricked into allowing one dApp access to another dApp’s GAIA bucket. Can someone elaborate if I am wrong? (See my reposted comment below for what happens in mobile today.)

Stealthy is working with other dApp developers to write data to their dApp GAIA buckets directly from Stealthy mobile. We’re using the redirect mechanism to access their GAIA buckets. This is required for a demo in late November, so if changes that will break this functionality are being committed, please let us know @friedger & @shreyas and provide us with an alternate mechanism for users to be able to work with their data? (We don’t have plans to update our use of Blockstack mobile SDKs in that timeframe so if the changes are scoped to the SDK that is fine, however going forward, this mechanism should be provided for in new SDK releases too).

---

The “impersonation attack” description sounds like a user choosing to access their data from a different dApp (i.e. using TweetDeck to access Twitter data). The user downloads Fake.app knowing that it is not Authentic.app. @Jude’s point about clearer messaging to the user when accessing Authentic.app’s bucket from Fake.app is important .

Here’s an illustration of the situation today when a Stealthy User taps to access their Graphite bucket (using redirect.html):

Graphite Stealthy Login.jpg1608x1270 255 KB

It could be clearer if it said something like @hank suggests or this: “Would you like to access your Graphite data from Stealthy? (Tap to learn more.)”

[friedger]

For Android, there are currently no plans to change the login flow. It will be the redirection for a while.

It is up to the developers of the other dApps to allow handling of the redirect by your Android app (and other apps). They can enforce link handling by their own app by setting up App Links for their domain.

[friedger]

Re 1.) On Android, there can be a “impersonation attack” when the redirect is done with a custom scheme for example. Any Android app can declare that it knows how to handle that scheme and the user is first presented with the legit dapp dialog. Then the user is redirected and either presented with an app chooser dialog or redirected to the default app for that scheme (what ever app is the default one).

This is true for all links in general, a mailto: url or twitter.com deep link url can be handled by many apps. Hence, Android added support for App Links. This prevents handling of twitter links by other apps. This does not prevent handling of mailto: urls by more than one app.

[JeffryR]

If data is the new oil, then there is going to be a land grab and plenty of squabbles over who owns it. And the battles are just beginning.

As the cloud becomes more commonplace and data from sensors populate Internet of Things (IoT) streams, there will be a scrum of who has access and owns what information. Surely, you own your customer data, right?

Maybe. You own it as long as your technology partner makes it easy for you to access, integrate, and innovate. The hopes and dreams of the so-called API economy ride on companies providing access to data and an ecosystem built around sharing. The reality is that IT vendors, as well as operational technology vendors, may control your company’s data. Data Kumbaya is all fun and games until there’s money to be made.