Platform Urbanism Data Sharing Policy Guidelines

There are a number of valid reasons for local governments to seek access to platform data—including goals related to regulatory enforcement, evaluation of impacts and externalities, operational coordination with platforms, or to support informed planning and policy making. However, given that this kind of mandate involves technical burdens imposed on private companies and requires the handling of potentially sensitive information by public officials, the bar for requiring data should be high. With that in mind, it’s important for local governments to define their goals and spell out why data is needed to achieve them.

Not only is stating program goals and data needs a crucial PUDS policy best practice, thinking through these specifics is an important process step and should be considered a prerequisite to pursuing the enactment of a PUDS program in the first place. For each goal, officials should ask themselves if data is truly needed, considering alternatives wherever feasible. Importantly, according to Beatriz Botero Arcila “The objectives should be related to advancing local welfare and should never be related to criminal law enforcement, as this would be in clear violation of users’ and firms’ Fourth Amendment rights.”

Communicating those data needs that do remain after considering alternatives will establish the public case for why potentially sensitive platform information will be collected and handled by government officials and why the platform must comply in order to operate within the community. This kind of clarity will have the added bonus of allowing members of the public to consider whether they agree with stated goals and data needs and to weigh in accordingly, ultimately helping to build public support and legitimacy and bolstering a PUDS program from potential challenges.

An important part of defining government objectives includes considering and documenting the ways in which platform data will be used. This kind of “data use case” might be as specific as stating that vehicle id data will be used to count unique vehicles deployed in the city in order to measure against a city’s micromobility permit rules and to ensure that a company’s fleet is not exceeding a predefined vehicle cap. Alternatively, a data use case may be more general, such as stating that trip data will be used to analyze mobility patterns in order to evaluate impacts on safety and traffic management and inform future transportation management and infrastructure policies accordingly. In either case, it is fundamentally important for PUDS policy to state these data use cases as clearly as the agency goal(s) will allow, as this in itself is a crucial aspect of best practice #5 “Transparency and Accountability” and will enable more catered approaches to the rest of our best practices, including data minimization (#2) and formats, fields, and frequencies (#3), as well as roles and permissions (#6) and privacy and security (#7).

Resources

• See the Open Mobility Foundation’s “MDS Use Case Database” for examples of how data sharing is being used in the context of micromobility platforms.

• See “Dockless Decoded” documentation of micromobility data needs.

• New York City Taxi and Limousine Commission (NYC TLC) gives detailed rationale for its data sharing requirements on for-hire vehicles in public hearings. See for example "Statement of Basis for Rules" here.

If guideline #1 is about collecting the information needed, guideline #2 is about not collecting or retaining the information you don’t need. Data minimization is the principle that only information that is necessary to achieve a given goal should be collected and retained by an organization, especially with regard to personally identifiable, potentially re-identifiable, or other potentially sensitive information. PUDS policies will lesson risk and mitigate the potential for privacy harm by including data minimization commitments tied to the government objectives and data use cases defined under guideline #1. Employing data minimization principles will also help guide considerations of the data formats, fields and reporting frequencies specified by a PUDS policy (guideline #3), ensuring that data can be aggregated, summarized, truncated, fuzzed, etc. to the least invasive technical requirements necessary.

In some cases data minimization might dictate that collecting raw, granular platform data is unnecessary. In other cases raw, granular data may be required to achieve a government auditing objective of ensuring that summary statistics are produced accurately and truthfully. In such cases where sensitive data is collected out of necessity PUDS policies should ensure that it is handled securely, with a defined and limited number of users granted permission, and in ways that are fire-walled from other systems and users that do not require access. These approaches related to data minimization are covered more fully in their own guideline (#7) below.

Resources:

• City of Seattle Privacy Principles and Privacy Program

• See also GDPR, principle (c ) “Data Minimization” overview of data minimization

Fields and frequencies are where “collecting what you need” (guideline #1) and “not collecting what you don’t need” (guideline #2) play out technically.

By considering what data fields are needed, at what level of aggregation and frequency can allow local governments to balance program objectives with data minimization principles.

• PUDS policies should specify that platform data reporting recur in a frequency appropriately catered to the regulatory need and appropriately minimized to be no more frequent than that need requires. For example, if the government objective is to evaluate impacts of a micromobility fleet on traffic patterns and mode share over the course of a 6 month pilot, data likely is not needed on a frequent basis, such as daily or real time, and monthly or quarterly data might do. Alternatively, if government officials are coordinating closely with a platform to ensure real time compliance with a no ride zone rule during a special event, more frequent data sharing may be called for.

• PUDS policies should specify required data fields, providing documentation of field names and definitions in a data reporting schema. In defining such data reporting schemas, city officials should work with platforms to understand what data is available and how it is structured, potentially requesting sample or synthetic data as a starting point for data design. However, officials should not equate available data with needed data, and should instead allow for certain sensitive fields to be summarized or aggregated to the least intrusive level of information sharing needed, and for unnecessary or especially sensitive fields—where the benefits of collecting data are outweighed by risks—to be fully excluded.

While such data specifications should be documented as part of PUDS policy, officials should be empowered to update and iterate on field, frequencies, and levels of aggregation administratively as data use cases are tested and tweaked, provided such tweaks continue to adhere to program goals (guideline #1) and data minimization approaches (guideline #2).

Resources:

• Coming Soon

In order for data sharing to be meaningful and useful, data formats should be specified in ways technically suited to government objectives and systems and in line with relevant industry standards and technical best practices. This means that

• PUDS policies should specify that data be shared in a structured, machine-readable format (not via PDFs!).

• PUDS policies should specify that data sharing protocols utilize non-proprietary, open formats to prevent lock-in or reliance on just one third party vendor or software system.

• PUDS policies should require that data conform to open standards for consistency and interoperability where such standards are available, for example, specifying the use of the Mobility Data Specification and General Bike Feed Specification in the context of micromobility platform data sharing.

As with guideline #3, while data formats and standards should be specified as part of PUDS policy, officials should be granted some flexibility to update and iterate on such formats administratively in order to make use of new formats, new versions releases of existing standards, or entirely new standards as industries and technologies evolve.

Another technical consideration closely related to specifying data formats and standards is the mechanism of data exchange, be that bulk download of flat files transferred via a secure process like an SFTP, or be it direct, queryable access to data via an application program interface (API). Navigating requirements for platform data transfer via bulk data or via API should be done in consultation with technical experts as well as with the likely users of the information, with the selected approach enforced in PUDS policy language.

Resources

• About the Mobility Data Specification (MDS)

• General Bike Feed Specification (GBFS)

Local governments collecting and handling private platform data have a responsibility to hold themselves accountable to public scrutiny. Transparency does not mean, of course, that any sensitive platform information should be made available to the public; however, it does mean that PUDS policies should commit to making program rules, procedures, and other documents easily discoverable and reviewable, as well as sharing metadata and other relevant information, such as what data fields are collected and handled by public officials and why (guidelines #1, #3), which departments or individuals are responsible for program oversight and administration, and specifically who has access to data and with whom data might be shared (including vendors or third party software providers), as well as what kinds of retention, privacy, and security practices are in place (guidelines #2, #6, #7). Accessibility of such program information should be considered whenever possible with overly technical documents translated into layman's terms and made available whatever languages are spoken in the community.

Commitments to transparency and oversights should also make space for public comment and feedback, both during the policy development and consideration process, as well as on an ongoing basis as platform data sharing is implemented and operationalized.

In addition to providing public oversight, transparency is also an opportunity for PUDS programs to communicate the value of platform data sharing to the public by revealing insights through the presentation of data analysis, summary dashboards or even through publication of appropriately aggregated and de-identified open data derived from PUDS program data. Perhaps more important than sharing summary data is sharing impacts and progress toward program goals, both with the public, and with their elected representatives. With this in mind, PUDS policies should commit to some form of regular reporting to the city council or chief executive, with such reports made available to the general public as well.

Resources

• The “Rideshare in Massachusetts Data Report” communicates the impacts of ride-hail platforms through data analysis and open data.

• Many program reports are available via our “Program Links / Associated Website” field of the PUDS Policy Database.

• See the Sunlight Foundation's Open Data Policy Guidelines

In addition to incorporating external, public oversight, PUDS programs should also commit to effective implementation and accountability by clearly defining what internal departments and positions are responsible for overseeing data collection and use, ideally establishing and naming a single authority in charge of administration of platform data sharing. Many policies specify that an existing public official/position already responsible for a related regulatory charge oversee platform oversight—for example, in the context of ride hail, the transportation official or commissioner responsible for overseeing the issuance of taxi licenses—including overseeing the collection and handling of platform data. However, new positions/authorities can also be created by PUDS policy, and indeed platform data sharing may present new technical challenges that require new organizational structure, if not always new staff. These considerations should be anticipated and planned for with responsible staffing, technical support, and other resourcing, including technical infrastructure, to meet such needs.

With such practical and material needs in mind, as with any policy establishing new agency responsibilities and digital infrastructure, developing and implementing PUDS Policy should be done with considerations for sustainability. One way to do this is to consider funding sources, such as platform permit fees to fund things like staff, software, and servers. Sufficient funding can mean the difference between successful and unsuccessful use of platform data as a key tool for oversight, evaluation, and coordination.

Clearly articulating roles and organizational structure in a PUDS program is crucial not only for effective implementation and for accountability, but also for privacy. As we will cover in guideline #7, below, it is critical to understand roles to be able to effectively set permissions for who should have access to what data, and why, and to ensure that those who don’t need access don’t have it.

Resources and Examples:

• See “Originating Body” field in our PUDS Policy Database for departments named in PUDS policies

As stressed throughout these PUDS Policy Guidelines the collection of private platform user data comes with serious responsibilities for relevant government parties to handle such data with appropriate care by ensuring best practices in data privacy and security. As discussed in guideline #2, this starts with a data minimization mindset and with avoiding the collection of unnecessary data, including any data for which risks posed by agency collection and handling are greater than potential benefits. For data that is collected to advance government objectives, PUDS Policies should build off of existing agency privacy policies to ensure that any personally identifiable information (PII), or other sensitive data that might pose concerns for re-identification or privacy issues are classified and safeguarded accordingly. This should include working with IT staff to ensure cybersecurity protocols are in place for sensitive data in rest and in transit, and to ensure that data is firewalled against access by those without appropriate permissions granted. Agencies should review PUDS roles and responsibilities (guideline #6) as well as PUDS data use cases (guideline #1) in order to set permissions for access to the most sensitive information in raw/granular form to only those who require access. Where such data is concerned, others who may have data use cases that do not require raw access should be permissioned to access only derivative or summary datasets that have undergone de-identification and aggregation, batching, or fuzzing of sensitive fields like timestamps and GPS location coordinates. In accordance with relevant privacy policies, it may make sense to require background checks or other pre-qualification requirements for those agency staff granted access to sensitive information, and such individuals should be subject to appropriate audits, monitoring or other checks and balances to provide accountability mechanisms in accordance with local laws and privacy procedures.

Department legal and policy advisors should be consulted to review relevant open records laws and consider disclosure obligations that may pose privacy risks for information that is substantively sensitive, but administratively not covered by open-records exemptions. Classification can help with this concern, and it is similarly recommended that data be labeled, formatted, etc. in ways that will support records act disclosure compliance without revealing detailed information about platform users. Records retention policies should similarly be reviewed, and can help set storage limits and timelines that can help reduce the risks and liabilities of storing sensitive user information.

For many legitimate government objectives and use cases, some data may need to be shared with other departments or even with outside agencies. In most instances, data aggregation and de-identification will allow for the sharing of non-sensitive derivative platform data. However, PUDS programs should require the establishment of clear processes and procedures for reviewing and documenting instances of data sharing and data access requests that may arise from time to time. Such processes should commit to transparency (guideline # 5) by keeping publicly available records of what requests for data access have been made and granted, to whom, and for what purposes. Depending on the context, it may also be appropriate to employ a standard license or data sharing agreement for such instances of data sharing that commits other departments or third parties to adhering to privacy requirements and limits use of information to predefined permitted purposes that align with stated government program objectives.

Importantly, unless otherwise compelled by law or court order, PUDS programs should firewall data against sharing with departments that deal with criminal justice issues for which privacy risks are particularly harmful, such as police departments or immigration services.

Resources:

• Center for Democracy and Technology (CDT): "Data in the On-Demand Economy – Privacy and Security in Government Data Mandates"

• Open Mobility Foundation - Privacy Principles for Mobility Data

• Open Mobility Foundation - Using MDS under GDPR

• LADOT - Data Protection Principles

• City of Seattle - Privacy Program