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. (https://example.com is one origin, https://alice.example.com 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!
Yours,
Larry