November 2019 NIL Scoring Proposals

#1

This month, we’re proposing 2 new scoring criteria for and 1 policy change based on our experience reviewing apps and feedback from the Blockstack community. Please leave comments on the relevant github issues.

Open Source

When an app’s source code is available, it becomes easier for others to audit its behavior. It also makes it so that users can run their own copy of the app, reducing their dependence on the app developer.

We propose that developers self-declare their open source status at app mining submission time, provide a link to the source code and indicating the type of license it is under. App developers can choose to make their app’s source code visible but continue to hold exclusive rights to its use. Alternatively, they can license the code under a license that grants use of the code.

We define “source available” as meaning that a generalist developer should be able to run their own copy of the app in a “reasonable” amount of time and code should not be obscured. Developers should make a good faith effort to meet this standard.

We reserve the right to spot check developer claims and propose a whistleblower system as the enforcement mechanism. That is to say, we will award points based on the developer’s claimed status with random spot checks and encourage community members or peers to reach out during the audit period if they think an app claims open source status for which is not qualified.

We propose the following scoring:

  • No source code available/Commercial or unclear license: 0
  • Source available - Non-OSI approved license or commercial license: 1
  • Source available - OSI-approved license or public domain: 4

Since the community is subsidizing app’s development, we feel it makes sense to award apps that return the favor by contributing their code back to the community through an OSI-approved license.

A dry run of this new open source criteria will be conducted during the app review period that begins on December 1, 2019 (November 2019 cohort).

Can’t Be Evil Sandbox

We introduced the Can’t Be Evil Sandbox late last month at the 2019 Blockstack Summit in San Francisco. Two weeks ago, we shipped the developer preview of our New Internet Extension which implements v1 of the Can’t Be Evil Sandbox.

We propose the following scoring:

Cookies

  • Uses cookies: 0 points
  • Does not use cookies: 1 point

Use of cookies is defined as either a server trying to set cookies in the user’s browser or code running in the user’s browser trying to send cookies with a request. We will erase cookies. Cookies that existed prior to each round of testing will be erased from browsers used in testing.

3rd party resources

  • Uses 3rd party resources: 0 points
  • Does not use 3rd party resources: 1 point

3rd party resources are defined as any requests to app origins that are not self origin as defined by Content Security Policy (CSP) specifications. Requests that fall under the CSP policy connect-src are allowed for all origins and explicitly exempt from this run under v1 of the Can’t Be Evil Sandbox.

Opts-in to Can’t Be Evil Sandbox

  • No: 0 points
  • Yes: 1 point

Apps opt-in to the latest version of the Can’t Be Evil Sandbox by setting the can't-be-evil header to true. Opting in means that the New Internet Extension and other user agents that support the Can’t Be Evil Sandbox will enforce the rules instead of merely reporting violations.

A dry run of this new criteria will be conducted during the app review period that begins on December 1, 2019 (November 2019 cohort).

Redirects away from app origin policy

We’ve seen a number of apps that submit one app origin to app mining and redirect users to one or more origins when the user tries to use the app. Blockstack app security is centered around an app origin - when a user authorizes access to Gaia storage for an app, they’ve giving access to a particular origin. Redirecting users to different app origins without their permission is dangerous and confuses them as to which app they’re actually using.

We attempted to manually determine how many apps in app mining exhibit this behavior in the past couple months. In October 2019’s app mining session, we conducted a dry run and counted at least 27 apps that redirected users to other app origins besides the one that was submitted to app mining.

We also found that even when a user is proactively looking out for an origin change in the address bar, it was very easy to miss. Put another way, even well-educated users have trouble keeping track of where they are on the web.

We propose that going forward, our review of apps will conclude when the app navigates away from the submitted app origin (excluding any navigation to the Blockstack Browser/authenticator). we recommend this as a policy change instead of a scoring item.

There are two reasons for this. 1) it moves us closer to clearly defining what an app is - an app is some code distributed from a name. Right now that name is the app origin, in the future it will be a Blockstack name. Different name, different app. 2) Trying to treat this as a scoring item make is complicated: Testing manually is very challenging because the tester needs to pay very close attention to what’s in the address bar. Testing it automatically is also challenging because an extension performing the test needs to maintain state across arbitrary app origins and somehow determine that arbitrary collection of apps origins is part of one app.

This policy will take effect in the app review period that begins on December 1, 2019 (November 2019 cohort).

closed #2