Public listing of multiplayer apps in user profile

Apps Identity
#1

Edit: this is a continuation of a discussion about the fact that what multiplayer apps are used from a discussion that occurred in this open engineering meeting.

Sorry I couldn’t make this meeting.

An aside, i really like the zoom recording - the transcript on the side made it really easy for me to skim through to get a general id of the discussion.

Having said that, it would be cool to put a couple bullet points in the meeting notes regarding any decisions/conclusions that came from the meeting. I skimmed the transcript but couldn’t easily figure out what the conclusion was re publicly sharing the apps you’re using.

Few comments:

  • Users aren’t terribly interested in the technical reasons for something not behaving according to their expectations.

  • If Facebook published in their Facebook profile that people used a bunch of dating apps, people would be pretty pissed, there’d be a ton of negative PR and it would probably destroy a bunch of peoples’ relationships.

  • If the user choice is between a big public company like Facebook or Apple knowing what apps they’re using an app and the whole world knowing, my guess is most people would choose the first option.

  • This seems like we’re moving the privacy ball in the wrong direction - on the “whole world knowing which apps I use” metric, objectively worse than the status quo.

  • People haven’t complained over the past year+ because up until recently there weren’t really any apps. Developers on Blockstack have a perverse incentive to support this public discovery of apps mechanism because it gives them growing public usage metrics (ie. graphs on https://theblockstats.com). We’ve seen this as single player apps complain that their apps don’t show up in stats.

Those are my thoughts based on the discussion that occurred.

Seems like there are two paths forward:

  1. If the apps are going to be publicly listed in the profile file like they are today, I’d be hesitant to solve the problem by obscuring it by hiding in in the explorer. Instead, let’s own it and leverage it as an advantage.

It enables cool stuff like finding your friends using the same apps. We can also improve copy and education so that people who want to hide their identity know that they should use separate blockstack ids for sensitive apps.

  1. Do a bunch of R&D to come up with a multiplayer storage discovery mechanism that’s more privacy friendly

Look forward to seeing what you decide!

4 Likes
2019-03-13 Engineering Meeting (Open to Public)
2019-03-27 Engineering Meeting (Open to Public)
2019-04-03 Engineering Meeting (Open to Public)
2019-03-27 Engineering Meeting (Open to Public)
#2

True! Nobody care about any technical reason of anything. People only care about their expectations.

E.g. If Tesla car crash >>> nobody care about how hard to coding AI and engineering stuffs.

Agree!

True! But Why?

Muneed used to PR that People only need 1 Blockstack ID…

#3

Thanks for the notes here, @larry. I agree with your general assessment of expectations and potential reactions to this vis a vis Facebook, etc. I’m just not sure when this might arise as a practical concern for more than a few users (it’s a bit of a ticking time bomb).

I think I’m personally in the camp of “let’s own [the public knowledge of app usage for multiplayer apps] and leverage it as an advantage” since it’s one aspect of decentralization that seems unavoidably public, so any attempt to paper over the public nature will be half-satisfactory at best – and even more deeply surprising / disappointing to users who uncover it, at worst.

That’s why I’m thinking this new issue to add better guidance during app authorization around its public nature seems like the first best step to take:

That said, I’m not against reducing its visibility in the Explorer per se, especially since we don’t currently have a strong counter need to show apps there prominently (I believe @aulneau.id added them during the redesign simply because the data was available in profiles and it seemed like fun information to show, assuming users liked it displayed). But I don’t believe we decided to show them then for any deeper reason, so if we wanted to make them less prominent, I’d have no objections:

As for your point that we could “do a bunch of R&D to come up with a multiplayer storage discovery mechanism that’s more privacy friendly”, that’s intriguing (and to me clearly the best theoretical solution to balancing functionality with privacy and personal preferences), though I’m not sure how feasible on the face of it?

Perhaps someone here already has some promising ideas, though, on how to enable multi-player without revealing app authorizations. If so, I’d encourage them to create an issue about that in the most relevant repo.

Search and Discovery of User-Owned Data (EU funding)
#4

These are very good points and I agree with @larry Many people don’t realize their list of apps is public.

There are a couple of points I want to mention:

  1. If apps are completely private - there’s no way to discover user. You can’t have both - full discovery and complete privacy.
  2. Web of trust can be a good balance between the two. You list your apps only to trusted contacts. But not the whole world.
  3. With Facebook you trust the third party to protect the info about what apps you have (you trust Facebook). In Blockstack world, you could choose a sort of centralized provider that you trust that would manage your apps list and who can access it. Similarly to how you trust your gaia provider not to disclose your apps and your file names.

I like option 2. This would require a sort of a social protocol built into Blockstack infrastructure. In fact, Blockstack Token Whitepaper mentions web of trust for a slightly different use case:

In the second part, after the network goes live,we will introduce mechanisms for how the initial trusted-set can be expanded to include more users similar to how the traditional web of trust protocols [31] work. This part of the web-of-trust mining mechanism is under active development and we will release more details on it in a future version of this paper. We plan to fall back to a process with gatekeepers, similar to how the initial trusted-set is curated, if the algorithmic approach does not lead to a reliable mechanism. We discuss our ongoing work on algorithmic expansion of the trusted-set in Section 6

3 Likes
#5

I think we can do a better job of communicating to the user that the apps they use are publicly visible. But the solution of using a separate ID for sensitive apps is effective for now. If you didn’t choose a username that can be tied to you, then there is no way to connect the app usage to you. And it’s not very difficult to create a new ID from the browser. I also agree that in the long term we should find a better solution for the multiplayer storage protocol that provides more privacy. Perhaps apps can explicitly choose to be “incognito” and not be listed in the profile. We could then have users exchange storage bucket info directly through the use of an inbox-like feature.

2 Likes
#6

But they already can - they just don’t request the ‘publish_data’ scope.

There are apps, like Graphite, that absolutely require you to publish your gaia address in your profile. When you share a public Graphite doc, the code looks at the username and document ID in the URL, and then fetches that file from the user’s published Gaia address. How could you do something like this without making it publicly known that you use Graphite? Other apps like Debut require the same mechanism (and not just to get your list of apps).

I think part of this is apps being a little overzealous about requesting the publish_data scope, because users don’t push back on this permission. If we have a stronger notice that “granting access will make it publicly known that you’ve used this app”, which we should, then there will likely be more pushback from users. It is totally possible to build your app so that it doesn’t require the publish_data scope, and if it did end up needing that permission, it could make a second auth request for that scope, with the reasoning of why the app needs it.

With radiks, there is a level of obscuration that prevents the server or anyone else from knowing which models are created by which users. This is done for privacy purposes. Thus, it doesn’t necessarily need the publish_data scope, but that’s because it has an indexer. With proper p2p syncing between radiks servers, you mostly eliminate the need for the publish_data scope, while still maintaining a high level of decentralization.

1 Like
#7

The complaint from privacy-focused apps (not single player) is that theblockstats is touted as a real metric for popularity. It is not that we want to be listed.

I personally consider it a point of pride NoteRiot doesnt show up there, and I believe the privacy is a huge benefit of the Blockstack platform.

#8

As an app (debut) that display user apps to the public, I am definitely considering doing an opt in feature from a front-end perspective down the line. If you really want to know what apps a user has installed, you can go to their profile.json via explorer.

At least with the opt in feature, even though it is public via API, it will give off the perception of user control.

Out of curiosity, is there a percentage of users that have brought this issue up?

1 Like
#9

“If you really want to know what apps a user has installed, you can go to their profile.json via explorer” <-- my main issue with this discussion is that people can see what apps users are using way before debut.social came out, but now that debut.social is utilizing this in a way that currently is more interactive and engaging for app exploration in app that our own browser (despite updates coming) it is now a topic of discussion.

31%20PM
Screen Shot 2019-03-28 at 2.14.31 PM.png558×1140 102 KB

This shows that the real issue is not with an app (for example: debut.social), but with rendering whats already publicly available on blockstack explorer/our API.

“As an app (debut) that display user apps to the public, I am definitely considering doing an opt in feature from a front-end perspective down the line. If you really want to know what apps a user has installed, you can go to their profile.json via explorer.” - kkomaz.id

Should we really ask Alex to build out this feature at the app level when people can just see it anyways here? https://explorer.blockstack.org/name/ginxh.id.blockstack

It looks like Alex could prioritise this feature over other things that could help his app grow, but since he is the first one to add this feature, which for the most part really helps users explore the blockstack app ecosystem outside of app.co, in a social way (what your friends are already using, which helps other apps based on social networks get user engagement) but it could be more responsibly handled on the Blockstack API side, since Alex’s app won’t be the only one who will want to use this functionality.

The original two suggestions in the beginning post are an all or non selection about this, in which the all or none options seem to be biased for or against themselves in one vs. the other.

Instead of relying on each app developer to implement their own incognito selection if they want to use this feature, I would suggest looking more in to Hank’s proposed solution:

“Perhaps apps can explicitly choose to be “incognito” and not be listed in the profile.” -Ken

"But they already can - they just don’t request the ‘publish_data’ scope

I think part of this is apps being a little overzealous about requesting the publish_data scope, because users don’t push back on this permission. If we have a stronger notice that “granting access will make it publicly known that you’ve used this app”, which we should, then there will likely be more pushback from users. It is totally possible to build your app so that it doesn’t require the publish_data scope, and if it did end up needing that permission, it could make a second auth request for that scope, with the reasoning of why the app needs it." - hank

The reason I think we should explore Hank’s proposed solution is because it is a good middle ground from some of the ideas here I see about taking the ability away entirely and it focuses on existing functionality in our API.

In other non Blockstack apps, like whatsapp for example, you can see who else is using whatsapp by importing your existing contacts, and actually the user has less control that way, to choose whether other people know they are using that app, than Hank’s solution, which is a good middle ground that allows people to engage eachother with the social network effect or keep some things private.

1 Like
#10

Might be a dumb question, but isn’t there some technical solution to keep multi-player storage and discoverability working but also prevent public visibility? And if so, wouldn’t this be a superior default? Here is a scenario:

Bob discovers a new app that he wants to use
Bob approves auth request
Bob assumes his login is public knowledge
vs.
Bob assumes his login is private

I would assume Bob and 99.9% of people would assume private. I don’t have any data to back this up yet. And it is unclear what kind of value we are providing to Bob in this case? So making him choose this option seems like needless friction in the process. My assumption would be different if:

  • Apple, Android, and other apps publicly published app usage (or even provided such an option).
  • By making the login public, we were providing Bob with some great feature or value.
#11

I agree with your assumption here, and how this is different than other platforms. It is unintuitive. The issue is that, if I’m using Graphite, how can I say “hey world, I made a post on graphite, you can see it here” in a decentralized way, without making it known that you’re using Graphite.

I think part of the problem is that app developers could definitely structure their app so that they only request the publish_data scope when you actually need it. It’s easier to just request it up front.

#12

@larry

Any updates on this? Is the default listing of used dapps in fact compliant with GDPR?

#14

Bumping this as I believe the visibility of this list should be controllable by the user. Ideally through the Blockstack Browser.

Edit: related Github issue: https://github.com/blockstack/blockstack-browser/issues/1944

#15

I’m no lawyer, but I think when a user signs into an application that uses the publish_data scope, that user is being notified of how their data will be used. However, what does not appear to be GDPR compliant is the ability for a user to later remove that data. Right now, the only possibility is for a user to use the CLI and manually update their profile.

We are working on a mechanism as part of the SimpleID toolset that would give developers the ability to drop in update functionality for users to update their profile.json from any app that uses the SDK.

2 Likes