August 2019 App Mining NIL proposals and policy clarifications

August 2019 App Mining NIL proposals and policy clarifications

Hi Blockstackers & App Miners!

Congratulations on a record breaking August 2019 cohort! I was really impressed with your apps and the progress the ecosystem has made!

In our August 2019 review of apps, we at New Internet Labs (NIL) noticed a number of practices being used by apps that in our view either run counter to the Blockstack vision and ethos or are problematic for reviewing.

In this post, I want to clarify a few of NIL’s policies for App Review and submit a few proposals to the community for discussion and possible adoption. Proposals have Github issue links, so please comment on the issue if you have feedback on the proposal!

Policy clarifications

These are clarifications of how we will handle problems that we’ve encountered reviewing apps and how we will treat them.

Payment required

Some apps require payment.

Policy: Paid functionality will not be reviewed unless app developers provide a comp’d way to access it for reviewers. This could be a test credit card number, a wallet with adequate crypto tokens, etc. Clear instructions for this should be provided.

Excluding certain browsers

We’ve clearly communicated the range of mainstream browsers and platforms that we expect apps to work on. Some app developers engage in user agent sniffing and/or other methods to prevent their apps from working on otherwise compatible browsers. For example, a few apps indicate that their apps are desktop + chrome only. The intent behind this seems to be that the developer does not want to spend the effort to make sure his app functions on multiple browsers. The effect is that app developers that do this get to choose the web browser on which their app is reviewed while other developers have to make sure their app functions properly on all major browsers. This is not fair.

Policy: All apps will be reviewed on the same browser/platform. Apps that require a certain browser and actively prevent other browsers from being used will be ineligible for app mining in that month.

Unsigned native apps

We’ve recently seen a number of native apps for both macOS and Windows. Most of these apps are unsigned by the developer and will not install in default configurations of both operating systems unless the user overrides the security settings to allow installation of software from unknown developers. This is dark pattern behavior we don’t want to encourage because it unsafe for users and unsafe for our reviewers.

Policy: Apps must be installable using the default security settings on a fresh install of the targeted operating system. Apps that require overriding default operating system security settings will be ineligible.

3rd party accounts / APIs / Devices required

A number of apps require third party accounts. Two that come to mind are Coinbase and Facebook accounts. Coinbase accounts are only available in certain jurisdictions, require AML/KYC and are easily frozen by “strange behavior” of which testing apps qualifies. Facebook accounts are similarly troublesome to create and require unused phone numbers, etc.

Other apps require lightning nodes or accounts on custodial lightning node providers to operate. It isn’t realistic to require app reviewers to have their own accounts with these apps nor is it trivial to create test accounts. In some cases, geographical restrictions prevent reviewers from creating those accounts.

It’s also not reasonable for app reviewers to set up nodes of other software to review one app.

Policy: Like external hardware devices, functionality that requires third party accounts, software and/or API access won’t be reviewed.

Proposed app mining changes

These proposals have github issues linked to each.

Email required for Authentication

Some apps require that the user provide an email to access the app. In some cases, this email is required before the user even signs in with Blockstack. It is our view that this requirement runs counter to the Blockstack ethos because it forces app users to give away personal information to a third party before even using the app. It is our position that is not compliant with Blockstack authentication which only requires the signed authentication token to access the app.

Proposal: Apps that require email in addition to Blockstack auth should be treated as if they are using 3rd party sign in methods and scored as such. Blockstack Browser should also make email optional by providing an option to skip it. Github Issue

App Redirects

A number of apps redirect users to different origins from the origin submitted to app mining. ( is one origin, is a different origin).

Blockstack’s security model is origin-based - a different origin is a different app. It is important that users understand which app they are using and redirecting between multiple origins hurts that goal.

Proposal: App developers must submit the origin of the app they wish to review. Redirects to other origins will not be reviewed. Github Issue

Blockstack auth hard to find

As I wrote in my post on the death of Jabber, it is critical to our success that users form a strong mental model of Blockstack ID & Blockstack Auth. In our current app mining set, every app uses a different method of presenting Sign in with Blockstack. Some apps use a branded button that mentions Blockstack. Other apps use language such as “get started.” This lack of consistency doesn’t help us in building this mental model. In the current state, users can’t have some basic expectation of what to look for if they want the benefits of a Blockstack app.

Proposal: We develop a set of branding, button placement and language requirements so that Sign in with Blockstack is presented consistently across apps and incorporate this into the review process. Github Issue

Reviewing for Gaia usage

Reviewing for use of gaia is challenging. Our current standard is that apps that write any data to gaia receive full marks. Even with this very low and simple to meet standard, it’s not always clear if an app doesn’t use Gaia or we are unable to find that app’s use of Gaia.

Proposal: As part of the monthly app mining submission process, developers should explain how Gaia is used by their app . Reviewers will follow those instructions to verify Gaia usage. Github Issue

Improper Gaia usage

We’ve also seen instances were the app writes to Gaia but this is being done improperly (ie. encrypting data on server side instead of client side, not encrypting data that should be encrypted). The security and data ownership benefits of Gaia come from client-side encryption, user control over those encryption keys and user control over the location of their Gaia hub.

Proposal: If we find that Gaia is used improperly, apps will be ineligible for app mining. Github Issue

I look forward to hearing your thoughts. If you have feedback on one of these proposals, please comment on the the linked github issue. If you disagree with some of the policy clarifications, please create a github issue with a suggestion of how to change it.

I’m really excited for September’s App Mining cohort and the opportunity to try out the latest version of your apps. Look forward to seeing what you have built!



So Blockstack has this big push towards lightning and acts like they care about apps that can’t be evil, yet won’t review apps that require lightning. You people need to get your incentives aligned.


To clarify, Blockstack does want to incentivize these apps and we love lightning. Larry and NIL are independent, and have their own independent opinions.

I’m not sure what the easy answer is, but I think NIL’s job is evaluating proper use of Blockstack’s tech, and shouldn’t extend to evaluating eligibility based on 3rd party accounts/APIs/Devices. It doesn’t make sense that an app should be ineligible because they use the lightning network.


I’ve kept quiet on this, but after some discussion this week, I feel the need to speak up.

In there is an attempt to legitimize unsigned apps, but this opens up huge security holes.

For all we know these apps could be installing key loggers, capturing bitcoin keys, stacks keys, passwords…

In this specific case, we have no reputation at stake, no source code, just the fact that its not flagged by anti-virus, and a little “Trust Us” flag waving.

Additionally, related to the argument in #151,

  • The appeal to avoid using existing gatekeepers (OS makers) makes absolute sense, but then why then appeal to another existing gatekeeper (Anti-Virus) to attempt to prove authenticity?
  • Relying on the fact that Insecurity industry does not flag an app is not good enough. Have we never seen Anti-virus make mistakes?
  • Is the converse argument in #151 also legitimate? If I sign my app, but its flagged by anti-virus, can I claim that “Look, my app is signed, therefore my app is legitimate”?

Blockstack apps are supposed to be enabling user data security and portability. We do not see this in the current desktop or mobile space. The fact that I put my app on a platform that has a lower security requirement, should not be enough for an app to qualify for app mining.

To be clear, I am NOT saying that the app in #151 is doing malicious things. But we’re opening up an attack vector here that needs to be closed. They will not be the last team to do this.

The first time that someone uses this process to steal whatever, under the Blockstack app mining program is the time that Blockstack loses all trust and authority.

Native apps should be signed or removed.

1 Like