Location based road tolls

 

This is a pre proposal for a location based road toll system. It’s modified from one that I wrote in Finnish for a local discussion on the subject. It’s “pre” in a that it doesn’t even try to be complete, rather privacy and reliability against cheating are considered. Privacy from both the perspective of real time location as well as from the perspective of a location archive. Location is defined with the extra attribute that it is collected in a distributed manner, the car (or users device) collects it based for example on GPS or other satellite locationing system, or for example by a LIDAR.

See also Jakke’s take on the subject.

That governments are inventive in creating new things to tax is taken as a given. It is not my intention to consider what would be the correct toll level of the toll at any time, location, vehicle type, weather etc. The reason to have a toll system that covers all public roads and has a road use cost that changes depending on conditions is efficiency. Limited resources are available for example to road building and maintenance. By setting the price of road use higher at rush hour it is possible to control the number of people that decide to use that part of the road at that time. In short the system creates a market for a good. The reason to have a location based system is that it has very fine granularity, for example it is able to set the price of using a road near a school higher and thus able to give an incentive to select an alternate route.

Premises:

a) The system doesn’t need to be perfect. Someone might be able to cheat and not get caught. This is true with most rules, there is no need to catch every shoplifter or tax evader to keep the correspondent problem at bay. To give some context: in March 2012 a the newspaper Helsingin Sanomat reported that in  Finland the police is able to solve about 42 % of all property, violence and sex related crimes.

b) The ability of (local) governments to manage software and technology projects is limited (this may be true universally, but I know its true in Finland). Thus it would be beneficial to use private resources to develop the system.

c) monitoring of compliance should be done in the traditional way, i.e. spot checks. This may be automated, but the number of checks should be limited.

d) For those that have difficulties to use new technology or oppose it on principle an alternate way of paying is offered. For example a ticket that is valid for a day or a month. For a large majority this should be more expensive that using the location based system. When buying such a ticket some routes may be restricted. These limitations are needed to make most people use the location based system. Otherwise the market would not function properly.

e) A fairly reliable wireless network and cheap devices to use it are available.

Technical details are not considered in detail as they are considered to be fairly easily solvable. Some changes to laws may be required depending on the jurisdiction and at least in Finland there will be an outcry if a private company collects payments resembling taxes.

Figure 1 shows a simplified flow of system operation. Vertical dashed lines partition the operations done by the three different stake holders. The boxes marked “SW” show that the driver gets the software from the company, for example through an app store.

The third party (i.e. “company”) is brought to this picture mainly because I believe that it can develop and operate the system more efficiently. Secondly it is much easier to take ones business elsewhere than to do the same with a government. Thirdly losing consumer trust is a bigger thing to a company than losing trust of citizens is for a government.

At “Start” either the car or the driver starts the system. Several different kinds of automatic ways of doing this are possible for example Bluetooth connection with car can trigger the system. The information that recording has started is transmitted to the company. Location may be sent with the information but this might not be mandatory as only information that the system is recording could be enough at this point. At set intervals (location or time) the location is recorded. It is possible to encrypt and transmit this information at longer intervals, this information could be used by the company to check that the final trip info (sent later) is correct. At “End” the location information is sent to the company.

The tolls are defined by the (local)government or the owner of the road. The “Price” may be dependent on time, weather, location, congestion or other parameters. It is possible to have continuously varying prices, but at least human (in contrast to robot) drivers may prefer to have the prices before the journey.

A HASH is calculated to make it possible to check that the information has not changed after it leaves the drivers device. “Encrypt and save” the data to the users device for further use. Unencrypted information is transmitted to the company so that it can check that the trip appears to be a valid one.

If it could be assumed that the software or hardware has not been tampered with, the information could be transmitted to the company in encrypted form and the possibility of a privacy violation at the orange “Check” could be avoided. I don’t believe that this is possible without either using expensive custom hardware or severely restricting the users ability to use the device. Another way could be to transmit only encrypted information but trust the checking mechanisms introduced below. This however could lead to more frequent point checks which would be an other kind of privacy violation.

When the trip information is received by the company, it is checked for consistency. For example are the location points sensible or are some located in the middle of the Pacific ocean or are some points missing? If there are some problems the user is notified and the information about the problems is archived. For those who have a lot of problems actions can be suggested, to update devices etc. If everything is fine, the information is encrypted and the unencrypted data is destroyed. Encryption is done by using the public key of the driver. This means that no accessible database of driver location is formed. The data can only be accessed if the driver gives his private key.

Billing is done as indicated in the figure, at the same time the encrypted info is copied to the governments archive.

For those who value their privacy more than others it is possible to sell prepaid codes that are connected to an account on a company database. The driver could use for example a Tor network to update the location information to the company database. This way the company would at no point know for certain who is travelling. Of course if the trips start at home or work it would be fairly easy to match this information to at least a group of people.

Figure1_roadtolls
Figure 1. Simplified system operation.

In addition to tampering with the soft- or hardware it is possible to trick the system by simply not initiating a journey when necessary. To be able to rely on something else than trustworthiness of the users Figure 2 shows a procedure to check that the user is doing his end of the deal.

The inspector asks the driver to stop. The driver then gives the inspector a code from his recording device. This code is given to the company which returns with information on the device’s status, either a trip is ongoing or not. Depending on how strict the privacy is the company could also give information on how long the trip has been going on or what has been the distance travelled. It could for example tell if the distance is over one kilo meter. By following the driver for a short while this could rule out cases where the trip is started only after the request to stop has been given.

It is likely possible to automate the checking procedure for example by reading the licence plate using machine vision and checking from the company if a car with these plates is on a trip.

Checking of driver
Figure 1. Checking of driver

If the company income is tied to the amount the driver pays incentive for the company to cheat is diminished. This is true especially if the invoice makes a trip through the government bureaucracy as this makes it possible to check that the sums are statistically in the ballpark. Figure 3 shows how the company can be inspected without violating the privacy of the driver. The idea is to pay (random) drivers for revealing their whereabouts. When voluntariness and an auction is used, no one needs to yield unless the compensation is adequate.

The encrypted information saved in the users device is compared to those the company has given the government. If this is done by the driver the government never knows where the driver has been. Because these inspections would hit a company fairly often it can be assumed that enough honest drivers are reached to be able to determine if a company is following the rules.

As the road prices need to be public it is possible for the driver to make certain, perhaps by using free software, that the company is charging the correct price.

Figure 3. Checking the company.
Figure 3. Checking the company.

Published by

Niko Porjo

Joys: comedy, cycling and spotting argumentation errors in live speech. Physicist and thinker, a little bit of an amateur philosopher. I like to build things but when they work that’s enough, no polishing.

Translate »