Regulation, the Internet way

I recently wrote a white paper for the Data-Smart City Solutions program at the Harvard Kennedy School on this topic, which I have neglected to blog about here so far.  It's quite long, but the above is basically the TL;DR version. I mention it today because we continue to be faced with the challenge of applying regulation 1.0 models to a regulation 2.0 world. Here are two examples: First, the NYC Taxi and Limousine commission's recently proposed rules for regulating on-demand ride applications.  At least two aspects of the proposed rules are really problematic:

1. TLC wants to require their sign off on any new on-demand ride apps, including all updates to existing apps.

2. TLC will limit any driver to having only one active device in their car

On #1: apps ship updates nearly every day.  Imagine adding a layer of regulatory approval to that step. And imagine that that approval needs to come from a government agency without deep expertise in application development.  It's bad enough that developers need Apple's approval to ship iOS apps -- we simply cannot allow for this kind of friction when bringing products to market. On #2: the last thing we want to do is introduce artificial scarcity into the system.  The beauty of regulation 2.0 is that we can welcome new entrants, welcome innovations, and welcome competition.  We don't need to impose barriers and limits.  And we certainly don't want new regulations to entrench incumbents (whether that's the existing taxi/livery system or new incumbents like Uber) Second, the NYS Dept of Financial Services this week released their final BitLicense, which will regulate bitcoin service providers.  Coin Center has a detailed response to the BitLicense framework, which points out the following major flaws:

• Anti money laundering requirements are improved but vague.

• A requirement that new products be pre-approved by the NYDFS superintendent.

• Custody or control of consumer funds is not defined in a way that takes full account of the technology’s capabilities.

• Language which could prevent businesses from lawfully protecting customers from publicly revealing their transaction histories.

• The lack of a defined onramp for startups.

Without getting to all the details, I'll note two big ones, which are DFS preapproval for all app updates (same as with TLC) and the "lack of a defined on-ramp for startups". This idea of an "on-ramp" is critical, and is the key thing that all the web platforms referenced at the top of this post get right, and is the core idea behind regulation 2.0.  Because we collect so much data in real-time, we can vastly open up the "on-ramps" whether those are for new customers/users (in the case of web platforms) or for new startups (in the case of government regulations). The challenge, here, is that we ultimately need to decide to make a pretty profound trade:  trading up-front, permission-based systems, for open systems made accountable through data.

The challenge here is exacerbated by the fact that it will be resisted on both sides: governments will not want to relinquish the ability to grant permissions, and platforms will not want to relinquish data.  So perhaps we will remain at a standoff, or perhaps we can find an opportunity to consciously make that trade -- dropping permission requirements in exchange for opening up more data.  This is the core idea behind my Regulation 2.0 white paper, and I suspect we'll see the opportunity to do this play out again and again in the coming months and years.

I recently wrote a white paper for the Data-Smart City Solutions program at the Harvard Kennedy School on this topic, which I have neglected to blog about here so far.  It's quite long, but the above is basically the TL;DR version. I mention it today because we continue to be faced with the challenge of applying regulation 1.0 models to a regulation 2.0 world. Here are two examples: First, the NYC Taxi and Limousine commission's recently proposed rules for regulating on-demand ride applications.  At least two aspects of the proposed rules are really problematic:

1. TLC wants to require their sign off on any new on-demand ride apps, including all updates to existing apps.

2. TLC will limit any driver to having only one active device in their car

On #1: apps ship updates nearly every day.  Imagine adding a layer of regulatory approval to that step. And imagine that that approval needs to come from a government agency without deep expertise in application development.  It's bad enough that developers need Apple's approval to ship iOS apps -- we simply cannot allow for this kind of friction when bringing products to market. On #2: the last thing we want to do is introduce artificial scarcity into the system.  The beauty of regulation 2.0 is that we can welcome new entrants, welcome innovations, and welcome competition.  We don't need to impose barriers and limits.  And we certainly don't want new regulations to entrench incumbents (whether that's the existing taxi/livery system or new incumbents like Uber) Second, the NYS Dept of Financial Services this week released their final BitLicense, which will regulate bitcoin service providers.  Coin Center has a detailed response to the BitLicense framework, which points out the following major flaws:

• Anti money laundering requirements are improved but vague.

• A requirement that new products be pre-approved by the NYDFS superintendent.

• Custody or control of consumer funds is not defined in a way that takes full account of the technology’s capabilities.

• Language which could prevent businesses from lawfully protecting customers from publicly revealing their transaction histories.

• The lack of a defined onramp for startups.

Without getting to all the details, I'll note two big ones, which are DFS preapproval for all app updates (same as with TLC) and the "lack of a defined on-ramp for startups". This idea of an "on-ramp" is critical, and is the key thing that all the web platforms referenced at the top of this post get right, and is the core idea behind regulation 2.0.  Because we collect so much data in real-time, we can vastly open up the "on-ramps" whether those are for new customers/users (in the case of web platforms) or for new startups (in the case of government regulations). The challenge, here, is that we ultimately need to decide to make a pretty profound trade:  trading up-front, permission-based systems, for open systems made accountable through data.

The challenge here is exacerbated by the fact that it will be resisted on both sides: governments will not want to relinquish the ability to grant permissions, and platforms will not want to relinquish data.  So perhaps we will remain at a standoff, or perhaps we can find an opportunity to consciously make that trade -- dropping permission requirements in exchange for opening up more data.  This is the core idea behind my Regulation 2.0 white paper, and I suspect we'll see the opportunity to do this play out again and again in the coming months and years.

>1.2K subscribers

>1.2K subscribers