To combine the useful customer service benefits of storing personal data with the privacy provided by not storing personal data, a combination of these two variations would be ideal. Users could provide as much personal information as they desired, and leave the other data fields blank.
In this method, each user has control over the balance they choose between privacy and functionality. For instance, if the credit card information is not provided, the customer would give up the ability to use automatic reloading. If no personal information is given, the customer would give up the ability to get a lost card reissued. However, in giving up these benefits, the customer would gain the level of privacy protection that he/she felt necessary.
For the system to handle this variation, a special symbol (false, for example) could be used to represent blank fields. In order for automatic reloading to occur, there could not be a blank for any certain fields. Whenever automatic reloading might be used, the system would first check the validity of all the necessary fields.
The disadvantage of this design is in explaining to customers what information they must provide in order to get certain benefits. Customers are at risk of becoming confused if instructions are not clear. However, this system has a big advantage of combining the benefits of the other two variations with customer choice.
Appendix C - Modifying a Current System to Incorporate our Recommendations
In this section, we detail how a current implementation can be extended to incorporate our recommendations. We proceed by explaining how to configure the database to separate travel information and personal information at regular intervals.
We treat the current database as a black box. The database needs three r equirements: data must be able to enter, data must be able to leave, travel data must have a time stamp, and data must be able to be deleted.
Figure B.3
A schematic of how an envelope design can be used to extend a current implementation to separate travel data from user data at regular intervals.
As in figure B.3, the new design would have three connections to the outside. The first would be a method of putting data into the system in the same manner as the original database. The second would be a method of extracting data from the system. This method would also be exactly the same as the old method. Preserving these interfaces would help ease integration of this new database to the rest of the system by following the same design specifications for input/output as the old system.
The new system would have an internal clock programmed to separate personal information from travel data after some amount of time (say, two weeks). We will refer to this component as a Data Purge Clock. Every two weeks, the Data Purge Clock receives all of the information from the database. It scans the information for places where personal information is connected to old travel information. In these cases, it copies the old travel information into one entry of the old database (an aggregated entry of some kind). It then deletes the travel data from the entry with the personal information.
The Data Purge Clock should have an override in the event that special circumstances arise in which the separation of travel data from personal data should not occur for a particular customer. E.g. if this customer is currently on trial, and the information in the database is considered evidence, the users name should be entered into the override.
The Data Purge Clock will be computationally expensive. To minimize the effects of this cost, the Data Purge Clock might be designed to check a portion of the alphabet each night, or only run at a set time in evening when the T system is not running. By operating on smaller chunks of the information more often, and operating when little other activity is going on, the computational expense will not be a drain on other components of the system.
Share with your friends: |