Talking about privacy computing from the investigation of Didi

This article is sourced from Lishen Technology Commentary, authored by Bai Shuo.

Didi has just "quietly" gone public in the United States, and the security review by the National Cybersecurity Administration has followed closely. The conclusion of the review was announced yesterday, and Didi's app has been explicitly ordered to be taken down.

Whether it involves customer privacy or the outbound data of national road infrastructure, it is an undeniable fact that Didi, as a platform company, possesses and is aware of this data. Since 2017, I have repeatedly introduced and called on the industry to pay attention to privacy computing technology in various speeches, mentioning privacy computing in no less than a dozen talks. The current situation serves as a good annotation to my calls over the past few years. This article attempts to analyze from the perspective of privacy computing technology to see if these two parts of data being "available but invisible" would affect Didi's business.

First, to address the matter directly, for the ride-hailing business, who the customer is actually does not matter. As long as you have the ability to pay, location information, and travel needs, it is sufficient to dispatch the required vehicle, regardless of who you are. Of course, some may ask, if a real user is not bound, how do you know if they have money.

This is actually simple; the user can "anonymously" deposit a prepayment into a smart contract, and once the transportation service is completed, the smart contract can distribute the payment to the driver and the platform according to the agreed ratio. If the service needs to be interrupted, it can also be settled according to the conditions specified in the smart contract. Here, who the user is clearly does not matter. As long as the job can be accurately pulled in and the payment received, there should be no inquiry into who the user is.

Secondly, for the ride-hailing business, road data is indeed an indispensable information infrastructure, but the effectiveness of road data does not depend on the platform "knowing" that data as a basic premise.

Under the framework of privacy computing, road data can be "back-to-back" associated with the customer's geographical location and the vehicle's geographical location. In other words, road infrastructure can respond to customer requests like a black box through API interfaces, matching nearby vehicles, calculating optimized routes, estimating time and prices, and so on.

None of these require the platform company to "see through" the road data; however, with the help of privacy computing technology, the results of the calculations can be confirmed as trustworthy without seeing through the calculation process. Therefore, with privacy computing technology, road data services can be encapsulated as a black box, where the data is invisible, but the API is available, and the use of the API can be self-evident in the context of privacy computing. As long as national laws require that this part of the data must not be disclosed, the black box can remain a black box, and it can even be entrusted to a specially recognized team by the state to develop and operate it.

Some may argue that inferring a customer's payment ability based on payment history, and thus linking it to recommended pricing (big data discrimination), means that in addition to online order taking, matching, and dispatching, there must also be background big data analysis. Without the "visibility" characteristic of data, can all of this still be achieved?

Of course, the privacy computing framework for big data analysis itself is not yet perfect, but in reality, it is already technically feasible to allow customers to initiate business in two different anonymous ways: one is "one-time anonymity," meaning this trip is not associated with any of the user's historical trips; the other is "consistent anonymity," meaning this trip can be associated with the user's previously chosen "consistent anonymity" trips, but it remains unrelated to who the customer is outside the travel scenario.

By putting the control of the association switch in the hands of the user, it can prevent the platform from abusing the associated data. If a customer chooses to initiate business anonymously, it precisely indicates that the customer does not want their current travel behavior to be associated with their historical travel behavior. Forcing an association, claiming it is for the customer's benefit or anything else, does it not somewhat go against the customer's will? What is sought behind this, is it not a bit beyond the scope of business?

The trajectory of individual travel may be useful for "relevant parties." Here lies a technical arrangement issue that is invisible to the platform, irrelevant to unrelated parties, but can be seen by "relevant parties."

This technical arrangement is not impossible; the key is the management of private keys. If this is done well, it saves each platform from waving the flag of "relevant parties" to demand privacy data from users. The more openings relevant parties have to access privacy data, the harder it is to manage. It is better to have a single opening to solve the real-name mapping issue, while the remaining privacy data obtained from the platform can be restored to visible data under real-name mapping. This is the best way to prevent the loss of privacy data.

I look forward to the day when platform companies can use the fact that they have not touched user privacy data or national critical infrastructure data as a selling point, while the existing service functions of the platform remain intact. This day may not be too far off. To those engaged in the research and development of privacy computing technology, let us work hard to welcome this day.