Upromise — An Example of How Privacy May Improve Software Development

Upromise (a business name with “promise” in it always sounds like trouble — why didn’t they just call it “Ends in Tears”?) is an online college savings program just settled an FTC complaint.  

Upromise users save money for college through purchases made through participating merchants. Kind of a nice idea,  you, your parents and anyone else who wants to help out signs up at Upromise and then, so long as purchases are made through the approximately 800 participating merchants, the merchants give money back to a user’s college savings program.

Where Upromise ran afoul of the FTC is that Upromise users, unless they unchecked a box at sign up, downloaded a “TurboSaver Toolbar” that is supposed to identify Upromise partner companies.  The toolbar also had a personalization feature that, when enabled, allowed Upromise to collect information about the user to better tailor college savings opportunities.

However, when you enabled the personalization features, Upromise collected everything: search terms, where you went on the Web, what you clicked, passwords, credit card numbers — along with expiration dates and security codes, and social security numbers.  Your total privacy nightmare.

This was contrary to the Upromise privacy statement which told you that filters were in place to prevent collection of financial data, such data would be collected “infrequently” and any data Upromise collected was sent encrypted.  What actually happened was that everything was collected all of the time and sent unencrypted.  Why did Upromise lie in its privacy statement?

While I don’t know what actually happened, I bet Upromise did not intentionally mislead anyone.   If that were the case they could have at least drafted a more devious privacy statement.  My guess is that there was a disconnect between people who drafted the privacy statement and people who developed the software.

I can see it now, the person who drafted the privacy statement asked the head of the software development team, “you have protections in place so financial data isn’t unintentionally collected — right?” and the response was “Absolutely.”  What was missing was an investigation as to how the privacy features, such as  the financial filters, were supposed to work.  While Upromise’s filters would not collect any data from a field marked “PIN”, they happily passed along data from fields marked “security code” or “personal I.D.”  So while the head of software development might have thought adequate filters were in place, there was no auditing of the filters against what the Upromise privacy statement.

Historically, software developers have lived in the world of “good enough.”  A long time ago, there was an email going round about what would happen if Microsoft built cars.  You would drive, then the car would suddenly stop and need to be rebooted; you may get an error message when you tried to use your windshield wipers while the radio was playing — that sort of thing.  Outside of critical operations, like nuclear power plants, it is perfectly acceptable for software to be far less reliable than just about anything else we use.  In fact, it is a standard provision in most software licenses that the software is not to be used in critical operations, like nuclear power plants.

The actions of the FTC may make privacy the new critical operation, the “nuclear power plant” of any business.   Privacy related software will need to work flawlessly and be audited against what is in the privacy statement. That’s the hope, anyway.

The FTC’s page on Upromise is available at: http://www.ftc.gov/os/caselist/1023116/index.shtm