20131027

Does Healthcare.gov violate their own privacy policy?

I have read some reports that we need not be overly concerned about Healthcare.gov security because the site doesn't keep much personal information. While we can't look into the site from outside to see what they do internally with the personal information they collect, we can view their published privacy policies and the data returned to the browser.

So let's take a look at a couple of things that concern me...


Use of 3rd Party Web Analytics Tools

The Privacy Policy says:
HealthCare.gov uses a variety of Web measurement software tools. We use them to collect the information listed in the “Types of information collected” section above. The tools collect information automatically and continuously. No personally identifiable information is collected by these tools.
However, the system sends some personal information to 3rd party analytics and advertising companies. For example, the following two images show my username and password reset codes being sent to a couple of 3rd parties:





Not only does this violate Healthcare.gov's stated privacy policy, it likely also violates the privacy policies of these 3rd parties. Even if the 3rd parties receiving the data can be trusted to not abuse the data, they may not protect it as personally identifiable information should be protected -- especially if they are not expecting to receive personal information.


UPDATE 10/31: It appears that the sending of usernames and password reset codes to 3rd parties has been fixed. I hope that there was an overall review and correction of cases in which this occurred rather than just patching the specific instances I have identified.

UPDATE 11/02: I now see another case in which Healthcare.gov is sending a 3rd party account activation codes (this is also the password reset code). This is occurring when I follow the account activation link I received when I created my account -- even with the site currently being down for maintenance.



It seems that they may have corrected the two specific examples I previously reported without taking the effort to seek out other cases in which they are unintentionally sending personal information to 3rd parties. Perhaps more remain.

UPDATE 11/16: The above issue appears to have been fixed. I no longer see account activation or password reset codes being sent to 3rd parties.

The FTC has previously fined MySpace, Facebook, and others for doing just this: sending private information to 3rd parties that they promised to not share. For example:


The F.T.C. asserted that from January 2009 through June 2010, and again from October 2010 through October 2011, Myspace, a social media Web site, transmitted information, including internal identification numbers of users, and their ages and genders, to outside ad networks that served ads to Myspace.

Using that information, the F.T.C. said, third parties could obtain the user’s name and other personal information and use a file placed on the user’s computer to view a history of Web sites the user had visited.




Returning Previously-Provided Information Back to the Browser

 The published Privacy Policy says:
If you choose to provide us with personally identifiable information through an email message, request for information, paper or electronic form, questionnaire, survey, etc., we will maintain the information you provide only as long as needed to respond to your question or to fulfill the stated purpose of the communication.

If in order to contact you we store your personal information in a record system designed to retrieve information about you by personal identifier (name, personal email address, home mailing address, personal or mobile phone number, etc.), we will safeguard the information you provide in accordance with the Privacy Act of 1974, as amended (5 U.S.C. Section 552a).

The privacy policy says that information will be retained only as needed to fulfill a request. While it doesn't explicitly say this, I believe this also implies they won't respond with previously-provided information that's not needed to fulfill the current request. They do this in parts of the site. For example, you can change your security question answers but not see them.

However, when I log into the system, it returns a whole bunch of information I previously provided that is not needed for the purpose of logging into the system. This information is sent encrypted, but it does create unnecessary opportunity for the information to be compromised should an account or a user's computer become compromised.

For example, here's one data structure containing my information (none of it from the actual insurance application) sent to by browser when I login to my account: (with my personal information removed)

{
"csrf":null,
"systemUser":{
"csrf":null,
"firstName":"FIRST NAME",
"lastName":"LAST NAME",
"middleName":null,
"suffix":null,
"emailAddress":"CURRENT EMAIL ADDRESS",
"systemUserLoginName":"USERNAME",
"dateOfBirth":"BIRTHDATE",
"addressLine1":"ADDRESS",
"addressLine2":"",
"city":"CITY",
"state":"STATE",
"zipCode":"ZIPCODE",
"phoneNumber":"PHONE",
"phoneNumberExt":null,
"ssn":null,
"language":null,
"userLevel":null,
"systemUserIdentifier":"A USER ID",
"registeredStateCode":"STATE",
"personIdentifier":"SOME OTHER USER ID",
"userEmailConfirmationUuId":null,
"userTrackingNumber":"A THIRD USER ID",
"exchangeUserInsuranceApp":[
{
"csrf":null,
"exchangeUserId":"A FOURTH USER ID",
"insuranceAppId":"AN INSURANCE APPLICATION ID",
"insuranceAppStatus":"STARTED",
"state":"STATE"
},{
"csrf":null,
"exchangeUserId":"A FIFTH USER ID",
"insuranceAppId":null,
"insuranceAppStatus":null,
"state":"STATE"
}
],
"termsAccepted":true,
"emailConfirmationId":"THE UNCHANGING CODE USED TO ACTIVATE AN ACCOUNT AND RESET PASSWORDS",
"isAuthorizedRep":null,
"receiveEmailNotificationIndicator":true,
"receiveTelephoneNotificationIndicator":true,
"receiveMarketingMessageIndicator":true,
"personIDProofingEvent":[
{
"csrf":null,
"proofingEventDate":"THE DATE I VERIFIED MY IDENTITY VIA EXPERIAN",
"personIdentityProofingEventSourceTypeCode":"2",
"proofingEventSuccessIndicator":true,
"proofingEsdEngagedIndicator":false,
"proofingEventRidpSessionIdentifier":"SOME KIND OF SESSION ID",
"personIdentifier":null,
"systemUserIdentifier":null,
"systemUserLoginName":null,
"proofingEventBarcodeIdentifier":null,
"personIDProofingEventTask":[],
"applicantPersonInfo":{
"csrf":null,
"applFirstName":"FIRSTNAME",
"applMiddleName":"",
"applLastName":"LASTNAME",
"applSuffix":"",
"applBirthDate":"DATE OF BIRTH",
"applEmailAddress":"EMAIL ADDRESS AT TIME OF IDENTIY VERIFICATION",
"applFullNumberCode":"PHONE",
"applStreetName1":"ADDRESS",
"applStreetName2":"",
"applCityName":"CITY",
"applStateCode":"STATE",
"applZipPlus4Code":"ZIPCODE",
"applSsnNumber":"",
"applPersonIdentifier":null
},
"forwardingPhysicalDocument":[]
}
]
},
"generatedPersonExchangeSystemIdentification":"AND A 6TH USER ID"
}

See any personal information in there? This doesn't include my social security number, but I never gave that to the system when it asked. I suspect that if I had provided it, it would have been returned with the other information. (UPDATE 11/01: I have confirmed that if a social security number is provided to verify one's identity, it is returned to the browser with each login -- even after the identity verification has been completed.)

Once my identity has been verified, I see no purpose for hanging onto the details I provided to identify my identity. That data is also stored elsewhere.

I expect a secure system -- especially one containing so much personal information -- to only return data to the browser when it is needed, and only as much as is needed.


UPDATE 11/16: I no longer see ID proofing information returned in accounts created weeks ago. However, the same information exists in the completed insurance applications and is being returned to the browser in a data object that contains all the data entered into the application and some data retrieved from other sources.

No comments:

Post a Comment