Privacy and Data Security: Minimizing Reputational and Legal Risks

10/27/2014
1
Agile Development &Agile Development &
Better Software Conference East 2014Better Software Conference East 2014
November 12 2014November 12 2014November 12, 2014November 12, 2014
Tatiana MelnikTatiana Melnik
Melnik Legal PLLCMelnik Legal PLLC
tatiana@melniklegal.com | 734tatiana@melniklegal.com | 734--358358--42014201
Tampa, FLTampa, FL
I. Regulating Privacy
Outline
II. Is Someone Regulating Software?
A. Federal Enforcement
B. State Enforcement
C. Private Enforcement
D. Costs of a Data Breach
III. Privacy by Design and the
Software Development Life Cycle
2

10/27/2014
2
Outline
3
o Federal Laws
US C i i
The Foundation of Privacy
US Constitution
Statutes
Federal Trade Commission
Act (1914) - Section 5
Electronic
Communications Privacy
Act (1986)
Sarbanes-Oxley Act (2002)
Health Insurance
Portability and
Accountability Act (1996)
and the more recent
Computer Security Act
(1987)
Gramm-Leach-Bliley Act
(1999)
Health Information
Technology for Economic
and Clinical Health Act
(2009)
Many more…

10/27/2014
3
U.S. Constitution
o Supreme Court Cases
Griswold v. Connecticut – emanations from
penumbras
Roe v. Wade – the right of women to
choose
Whalen v. Roe – privacy vs. the public
interest
U.S. Constitution
o Context Matters
“The Constitution does not explicitly mention“The Constitution does not explicitly mention
any right of privacy” - Roe v. Wade
“Zones of privacy” - Griswold v. Connecticut
First Amendment: Right of association
Third Amendment: Right not to have to quarter
soldiers
Fourth Amendment: Right against unreasonableg g
search and seizure (“expectation of privacy”)
Fifth Amendment: Right against self-incrimination
Ninth Amendment: Preservation of unenumerated
rights

10/27/2014
4
U.S. Constitution
o Context Matters
Justice Potter Stewart’s famous quote,
holding that the Constitution protected all
obscenity except “hard-core pornography.”
U.S. Constitution
o Context Matters
Justice Potter Stewart’s famous quote,
holding that the Constitution protected all
obscenity except “hard-core pornography.”Stewart wrote:
“I shall not today attempt further to define the
kinds of material I understand to be embraced
within that shorthand description; and perhaps Ip ; p p
could never succeed in intelligibly doing so. But
I know it when I see it, and the motion picture
involved in this case is not that.”

10/27/2014
5
o Context Still Matters
Federal Legislation
Targeted Information
Financial (GLBA)
Medical (HIPAA)
Targeted
Constituency
Segregation of
Super Private
Information
STDs
Mental health
Consumers (FTC
Section 5)
Children (COPPA
Obligations for
using particular
information
Substance abuse
State Laws
• Social Security Numbers
• Drivers licenses
• Protection of health care information
• Recordkeeping and data destruction
• Breach disclosure

10/27/2014
6
State Laws
What is PII?
Social Security Number
Credit / Debit Card Number (with a pin no.)
What state are you in?
Medical history or treatment
Health insurance policy number
Username or e-mail address plus password
o EHNAC (Electronic Healthcare Network
A dit ti C i i )
Industry Standards
Accreditation Commission)
an independent, federally recognized, standards
development organization
o PCI DSS
o NIST
sets standards for U.S. federal agencies, which
often become the de-facto standards throughout
industry

10/27/2014
7
o E.U. Privacy Directive 95/46/EC
International Laws
Addresses the collection, use, processing,
and movement of personal data
o E.U. Internet Privacy Law of 2002
(Directive 2002/58/EC)
Protects data in electronicProtects data in electronic
transactions
o Individuals countries have
their own laws
What do the Laws Cover?
What information can be collected
How it must be stored and secured
Under what circumstances it can be shared
Under what circumstances it can be disclosed
Responding to data breaches and data losses
Penalties for data breaches and data losses

10/27/2014
8
Outline
15
o Who is Enforcing Privacy and Security?
Enforcement Landscape
Federal Trade
Commission
HHS Office of
Civil Rights
State’s
Attorneys’
General
SEC
Consumers
State Boards
Insurance Regulators
FFIEC
NYDFS

10/27/2014
9
Works for consumers to
prevent fraudulent,
F d l T d
p
deceptive, and unfair
business practices
Section 5 – “unfair or
deceptive acts or
practices in or affecting
commerce ...are... declared
unlawful ”
Federal Trade
Commission
unlawful.
Has authority to pursue
any company
Has pursued companies
across a number of
industries
o Practices the FTC finds
bl ti
problematic
Improper use of data
Retroactive changes
Deceitful data collection
Unfair data security practicesUnfair data security practices
For a more detailed analysis, see Daniel J. Solove & Woodrow Hartzog, The FTC and the New
Common Law of Privacy, Columbia Law Review (2014)

10/27/2014
10
o In the Matter of HTC America, Inc.
July 2013
Phone and software manufacturer, using
Android and Windows operating systems
Allegation:
company failed to take reasonable steps to
secure the software it developed for its
smartphones and tablet computers,
introducing security flaws that placed sensitive
information about millions of consumers at risk
o What did the FTC allege HTC did
wrong?
wrong?
respondent engaged in a number of practices
that, taken together, failed to employ
reasonable and appropriate security in the
design and customization of the software
on its mobile devices
Assess Security - failed to implement an
adequate program to assess the security ofadequate program to assess the security of
products it shipped to consumers
Provide Guidance and Training - failed to
implement adequate privacy and security
guidance or training for its engineering staff

10/27/2014
11
Testing and auditing - failed to conduct
assessments, audits, reviews, or tests to
assess e ts, aud ts, e e s, o tests to
identify potential security vulnerabilities in its
mobile devices
Failed to follow standards - failed to follow
well-known and commonly-accepted secure
programming practices, including secure
practices that were expressly described in they
operating system’s guides for manufacturers
and developers, which would have ensured
that applications only had access to users’
information with their consent
No communication - failed to implement
a process for receiving and addressing
a process for receiving and addressing
security vulnerability reports from third-
party researchers, academics or other
members of the public, thereby delaying its
opportunity to correct discovered
vulnerabilities or respond to reported
incidentsincidents
HTC introduced numerous security
vulnerabilities in the process of
customizing its mobile devices

10/27/2014
12
Introduced numerous permission re-
delegation vulnerabilities through its
delegation vulnerabilities through its
custom, pre-installed applications
Because no check, third party apps could
enable the device’s microphone; access the
user’s GPS-based, cell-based, and WiFi-based
location information; and send text messages --
ll ith t ti th ’ i iall without requesting the user’s permission
could have prevented this by including
simple, well-documented software code –
“permission check” code
Failed to use readily-available and
documented secure communications
docu e ted secu e co u cat o s
mechanisms in implementing logging
applications on its devices, placing sensitive
information at risk
Instead of using one of these well-known, secure
alternatives [(e.g., Android inter-process, secure
UNIX sockets)], HTC implemented
communication mechanisms (e g INET sockets)communication mechanisms (e.g., INET sockets)
that could not be restricted in a similar manner
Failed to implement other, additional security
measures (e.g., data encryption) that could have
secured these communications mechanisms

10/27/2014
13
HTC failed to deactivate the debug code
before its devices shipped for sale to
before its devices shipped for sale to
consumers
HTC could have detected its failure to
deactivate the debug code in its CIQ
Interface had it had adequate processes and
tools in place for reviewing and testing the
it f it ft dsecurity of its software code
o HTC settled with the FTC – agreed to:
Establish implement and maintain a
Establish implement, and maintain, a
comprehensive security program that is
reasonably designed to
(1) address security risks related to the development and
management of new and existing covered devices, and
(2) protect the security, confidentiality, and integrity of
covered information, whether collected by respondent or
input into, stored on, captured with, accessed or
transmitted through a covered device.
• Such program, the content and implementation of which must
be fully documented in writing, shall contain administrative,
technical, and physical safeguards appropriate to
respondent’s size and complexity, the nature and scope of
respondent’s activities, and the sensitivity of the covered
device functionality or covered information, including:

10/27/2014
14
designation of an employee or employees
to coordinate and be accountable for the
to coordinate and be accountable for the
security program
identification of material internal and
external risks to the security of covered
devices that could result in unauthorized
access to or use of covered deviceaccess to or use of covered device
functionality, and assessment of the
sufficiency of any safeguards in place to
control these risks
[in assessing and designing risk program,
consider] risks in each area of relevant
operation, including, but not limited to:
(1) employee training and management;
(2) product design, development and research;
(3) secure software design and testing,
including secure engineering and defensiveg g g
programming; and
(4) review, assessment, and response to third-
party security vulnerability reports

10/27/2014
15
[in assessing and designing risk program,
operation, including, but not limited to:
(1) employee training and management;
(2) product design, development and research;
(3) secure software design and testing,
including secure engineering and defensive
What kind of program
does your company
have for monitoring
and testing software
?
?
?
g g g
programming; and
(4) review, assessment, and response to third-
party security vulnerability reports
g
deficiencies?
? ?
o HTC has a 20 year compliance period
E er t o ears m st get a third part
Every two years, must get a third party
audit that
Evaluates its “administrative, technical, and
physical safeguards”
Certifies that its “security program is operating
with sufficient effectiveness to provide
reasonable assurance that the security ofreasonable assurance that the security of
covered device functionality and the security,
confidentiality, and integrity of covered
information is protected and has so operated
throughout the reporting period”

10/27/2014
16
o GMR Transcription Services, Inc. & the
T P i i l O
Two Principal Owners
Providers of medical transcription services
Liability based on action of contractor
Company = 20 years compliance
o GMR Transcription Services, Inc. & the
T P i i l O
Two Principal Owners
Providers of medical transcription services
Liability based on action of contractor
Company = 20 years compliance
IT IS FURTHER ORDERED that respondents Prasad and
Srivastava [(the individual owners)], for a period of TEN (10)
YEARS after the date of issuance of the order, shall notify the
Commission of the following:
(a) Any changes to . . . residence, mailing addresses and/or
telephone numbers, within ten (l0) days of the date of such
change;
(b) Any changes in . . . employment status (including self-
employment), and any changes in ownership in any business
entity, within ten (10) days of the date of such change. Such
notice shall include: [lots of stuff]; and
(c) Any changes in . . . name or use of any aliases or
fictitious names, including “doing business as” names.

10/27/2014
17
Enforces HIPAA
HITECH Act (2009)
HHS Office of Civil Rights
HHS Offi f HITECH Act (2009)
expanded the scope of
coverage to authorize
enforcement authority
over certain vendors
(BAs)
HHS Office of
Civil Rights
By OCR
Statement AGs
Mandatory penalties
Enforces HIPAA
HITECH Act (2009)
HHS Offi f HITECH Act (2009)
expanded the scope of
coverage to authorize
enforcement authority
over certain vendors
(BAs)
HHS Office of
Civil Rights
By OCR
Statement AGs
Mandatory penalties

10/27/2014
18
Covered Entities
h lth id h lth l t
Business
Associate
IT
Management
Company
Business
Associate
EHR
Vendor
Business
Associate
Mobile App
Developer
Business
Associate
Integration
Specialist
healthcare providers, health plans, etc.
Company
Subcontra
ctorSubcontra
ctor
Subcontractor
Data
Destruction
Vendor
Subcontrac
torSubcontractor
Data Center
Subcontrac
torSubcontractor
Analytics Firm
Subcontrac
tor
Subcontractor
Interface
Developments
o Enforcement by HHS Office of
Ci il Ri ht
Civil Rights
As of Aug. 7, 2014, 21 organizations have
paid out a total $22,446,500 in settlements
(with one fine)
o Cignet Health ($4.3M) (fine)
Blue Cross Blue Shield of TN
o WellPoint ($1.7M)
Massachusetts Eye and Earo Blue Cross Blue Shield of TN
($1.5)
o Phoenix Cardiac Surgery ($100K)
o Idaho State University ($400K)
o Alaska Dept. of Health & Human
Services ($1.7M)
o Massachusetts Eye and Ear
Infirmary ($1.5M)
o Skagit County, Washington
($215K)
o New York & Presbyterian Hospital
($3M) (settlement)
o Columbia University ($1.5M)

10/27/2014
19
Enforcement under State
laws and because of
State’s Attorneys’ General
State’s laws and, because of
HITECH, under HIPAA
Can take action on
behalf of State or on
behalf of State residents
Most active areas
State s
Attorneys’
General
Healthcare
Mobile app developers
State’s Attorneys’ General
Indiana AG sued
WellPoint
Connecticut AG
sued HealthNet
California AG active
in mobile space
Also
settled
with OCR
for $1.7M
Vermont AG
sued HealthNet
Minnesota AG
sued Accretive
Massachusetts sued a
Rhode Island hospital

10/27/2014
20
Private Enforcement
Class
Actions
Individual
ClaimsActions
Negligence
Breach of warranty
Claims
Negligence
Intentional infliction of
emotional distress
Consumers
False advertising
Unreasonable
delay in notification
/ remedying breach
Invasion of privacy
Negligent supervision
Private Enforcement
Class
Actions
Individual
ClaimsActions
Negligence
Breach of warranty
Claims
Negligence
Intentional infliction of
emotional distress
ConsumersAbigail E. Hinchy v. Walgreen Co. et al. (Indiana
Superior Ct., 2013)
• Pharmacist improperly accessed medical
records of one patient
• Patient reported the incident to Walgreens and
W l did t di bl th h i t’
False advertising
Unreasonable
delay in notification
/ remedying breach
Invasion of privacy
Negligent supervision
Walgreens did not disable the pharmacist’s
access
• Jury awarded $1.8 million, with $1.4M of that to
be paid by Walgreens

10/27/2014
21
o Data breaches are expensive to handle
Costs of a Data Breach
Source: Ponemon Institute, 2014 Cost of Data Breach Study: Global Analysis (May 2014)
o Data breaches are expensive to handle

10/27/2014
22
$3.3M – Average lost business costs
$5.85M - Average total organizational cost of
data breach
$509,237 – Average data breach notification
costscosts
$1.6M – Average post data breach costs
Software Matters
o Processed and analyzed over 100 terabytes of
traffic dailytraffic daily
49,917 unique malicious events
723 unique malicious source IP addresses
375 U.S.-based compromised health care-related
organizations

10/27/2014
23
Software Matters
o Processed and analyzed over 100 terabytes of
traffic dailytraffic daily
49,917 unique malicious events
723 unique malicious source IP addresses
375 U.S.-based compromised health care-related
organizations
Outline
46

10/27/2014
24
o “Privacy by Design”
Privacy by Design
Phrased first used in 1995, in a joint report
by the Dutch Data Protection Authority and
the Ontario Information Commissioner
A systems engineering approach that
advocates for “building in privacy up front -
i ht i t th d i ifi ti dright into the design specifications and
architecture of new systems and
processes”
o “Privacy by Design”
Privacy by Design
Phrased first used in 1995, in a joint report
by the Dutch Data Protection Authority and
the Ontario Information Commissioner
A systems engineering approach that
advocates for “building in privacy up front -
i ht i t th d i ifi ti d
“Privacy by Design advances the view that the future
of privacy cannot be assured solely by compliance
with regulatory frameworks; rather, privacy
assurance must ideally become an organization’sright into the design specifications and
architecture of new systems and
processes”
assurance must ideally become an organization s
default mode of operation.”
Dr. Ann Cavoukian, Information & Privacy Commissioner Ontario, Canada

10/27/2014
25
Proactive not Reactive; Preventative not Remedial
Privacy by Design
Privacy as the Default Setting
Privacy Embedded into Design
Full Functionality — Positive-Sum, not Zero-Sum
End-to-End Security — Full Lifecycle Protection
Visibility and Transparency — Keep it Open
Respect for User Privacy — Keep it User-Centric
Privacy by Design

10/27/2014
26
o FTC
Baseline Principle: Companies should
Privacy by Design
Baseline Principle: Companies should
promote consumer privacy throughout their
organizations and at every stage of the
development of their products and services.
“In calling for privacy by design, staff
advocated for the implementation of
substantive privacy protections – such as
data security limitations on data collectiondata security, limitations on data collection
and retention, and data accuracy – as well
as procedural safeguards aimed at
integrating the substantive principles into a
company’s everyday business operations.”

10/27/2014
27
Agile Software Development
“Privacy by Design advances the view that the future
of privacy cannot be assured solely by compliance
with regulatory frameworks; rather, privacy assurance
must ideally become an organization’s default mode
of operation.”
Dr. Ann Cavoukian, Information & Privacy Commissioner Ontario, Canada
o How can the iterative and continuous
improvement Agile “mindset” help
privacy by design become
o Privacy is the responsibility of everyone,
not just the “security guy”
not just the security guy
Proactive
Use the iterative and flexible approach to
build security into the design on an iterative
and continuous basis
Always ask
Can my code be more secure?
Can I build in additional protections?
Do I need to protect user’s from themselves?
Is the default setting yes? Should it be no?
Do I really need to collect and store that information
or am I doing it because it’s ‘interesting’?

10/27/2014
28
o Addressing privacy and security is hard
Don’t underestimate the amount of work
required to make technology “secure” and
“functional”
Working with your customers and users
is key
Industries moving towards integration with
partners = many moving pieces
“functional”
is key
© mhealthtalk.com

10/27/2014
29
“functional”
is key
© Continua Health Alliance, http://continuaalliance.org
o Critical issues:
Team must be able to understand
the business needs (e.g., healthcare delivery,
regulatory framework and privacy issues)
+
the technical requirements (e.g., data
it d ti li )accuracy, security and timeliness)
+
for data partners and end-users

10/27/2014
30
o Goal of Agile methodology – respond quickly
to change
to change
Security is always changing
But, how does that align with the goal of
developing software more quickly?
o Value - Working software over comprehensive
documentation
Is there a need to produce documentationIs there a need to produce documentation
regarding security?
YES!
How else do you demonstrate that you took the time to
implement “reasonable and appropriate security”
In the regulatory world, if you didn’t document, you
didn’t do it….
o Consider your most private secret…
Two Final Thoughts…
What if what you just designed
stored that information? Would
you use that technology?
What if your employer treated your
social security number the same way
you treat other peoples’ data?

10/27/2014
31
This slide presentation is informational only
and was prepared to provide a brief overview
Disclaimer
and was prepared to provide a brief overview
of enforcement efforts related to data privacy
and security. It does not constitute legal or
professional advice.
You are encouraged to consult with an attorney
if you have specific questions relating to any ofif you have specific questions relating to any of
the topics covered in this presentation, and
Melnik Legal PLLC would be pleased to assist
you on these matters.
Any Questions?
Tatiana Melnik
Attorney, Melnik Legal PLLC
Based in Tampa, FL
734 358 4201734.358.4201
tatiana@melniklegal.com

1
122 3049
UNITED STATES OF AMERICA
FEDERAL TRADE COMMISSION
COMMISSIONERS: Edith Ramirez, Chairmanwoman
Julie Brill
Maureen K. Ohlhausen
Joshua D. Wright
)
In the Matter of ) DOCKET NO. C-4406
)
HTC AMERICA Inc., )
a corporation. )
)
)
COMPLAINT
The Federal Trade Commission, having reason to believe that HTC America, Inc.
(“respondent”) has violated the provisions of the Federal Trade Commission Act, and it
appearing to the Commission that this proceeding is in the public interest, alleges:
1. Respondent HTC America Inc. (“HTC”) is a Washington corporation with its principal
office or place of business at 13920 SE Eastgate Way, Suite #400, Bellevue, WA 98005.
2. The acts and practices of respondent as alleged in this complaint have been in or affecting
commerce, as “commerce” is defined in Section 4 of the Federal Trade Commission Act.
3. Respondent is a mobile device manufacturer that develops and manufactures smartphones
and tablet computers using Google Inc.’s (“Google”) Android operating system and
Microsoft Corporation’s (“Microsoft”) Windows Mobile and Windows Phone mobile
operating systems.
ANDROID’S PERMISSION-BASED SECURITY MODEL
4. Google’s Android operating system protects certain sensitive information (e.g., location
information or the contents of text messages) and sensitive device functionality (e.g., the
ability to record audio through the device’s microphone or the ability to take photos with
the device’s camera) through a permission-based security model. In order to access
sensitive information or sensitive device functionality, a third-party application must
declare the fact that it will access such information or functionality.

2
5. Before a user installs a third-party application, the Android operating system provides
notice to the user regarding what sensitive information or sensitive device functionality
the application has declared it requires. The user must accept these “permissions” in
order to complete installation of the third-party application.
HTC’S FAILURE TO EMPLOY REASONABLE SECURITY IN THE
CUSTOMIZATION OF ITS MOBILE DEVICES
6. HTC has customized its Android-based mobile devices by adding and/or modifying
various pre-installed applications and components in order to differentiate its products
from those of competitors also manufacturing Android-based mobile devices. HTC has
also customized both its Android and Windows Mobile devices in order to comply with
the requirements of certain network operators, such as Sprint Nextel Corporation
(“Sprint”) and AT&T Mobility LLC (“AT&T”). Since the customized applications and
components are pre-installed on the device, consumers do not choose to install the
customized applications and components, and the device user interface does not provide
consumers with an option to uninstall or remove the customized applications and
components from the device.
7. Until at least November 2011, respondent engaged in a number of practices that, taken
together, failed to employ reasonable and appropriate security in the design and
customization of the software on its mobile devices. Among other things, respondent:
(a) failed to implement an adequate program to assess the security of products it shipped
to consumers; (b) failed to implement adequate privacy and security guidance or training
for its engineering staff; (c) failed to conduct assessments, audits, reviews, or tests to
identify potential security vulnerabilities in its mobile devices; (d) failed to follow well-
known and commonly-accepted secure programming practices, including secure practices
that were expressly described in the operating system’s guides for manufacturers and
developers, which would have ensured that applications only had access to users’
information with their consent; and (e) failed to implement a process for receiving and
addressing security vulnerability reports from third-party researchers, academics or other
members of the public, thereby delaying its opportunity to correct discovered
vulnerabilities or respond to reported incidents.
8. As a result of its failures described in Paragraph 7, HTC introduced numerous security
vulnerabilities in the process of customizing its mobile devices. Once in place, HTC
failed to detect and mitigate these vulnerabilities, which, if exploited, provide third-party
applications with unauthorized access to sensitive information and sensitive device
functionality. The following examples in paragraphs 9 to 15 serve to illustrate the
consequences of HTC’s failure to employ reasonable and appropriate security in the
design and customization of the software on its mobile devices.
PERMISSION RE-DELEGATION
9. HTC undermined the Android operating system’s permission-based security model in its
devices by introducing numerous “permission re-delegation” vulnerabilities through its
custom, pre-installed applications. Permission re-delegation occurs when one application

3
that has permission to access sensitive information or sensitive device functionality
provides another application that has not been given the same level of permission with
access to that information or functionality. For example, under the Android operating
system’s security framework, a third-party application must receive the user’s permission
to access the device’s microphone, since the ability to record audio is considered
sensitive functionality. But in its devices, HTC pre-installed a custom voice recorder
application that, if exploited, would provide any third-party application access to the
device’s microphone, even if the third-party application had not requested permission for
that functionality.
10. HTC could have prevented this by including simple, well-documented software code -
“permission check” code - in its voice recorder application to check that the third-party
application had requested the necessary permission. Because HTC failed in numerous
instances to include permission check code in its custom, pre-installed applications, any
third-party application exploiting these vulnerabilities could command those HTC
applications to access various sensitive information and sensitive device functionality on
its behalf -- including enabling the device’s microphone; accessing the user’s GPS-based,
cell-based, and WiFi-based location information; and sending text messages -- all without
requesting the user’s permission.
11. Malware could exploit these vulnerabilities to, for example, surreptitiously record phone
conversations or other sensitive audio, to surreptitiously track a user’s physical location,
and to perpetrate “toll fraud,” the practice of sending text messages to premium numbers
in order to charge fees to the user’s phone bill. These vulnerabilities have been present
on approximately 18.3 million HTC devices running Android v. 2.1.x, 2.2.x, 2.3.x, and
3.0.x.
APPLICATION INSTALLATION VULNERABILITY
12. Relatedly, HTC pre-installed a custom application on its Android-based devices that
could download and install applications outside of the normal Android installation
process. Again, HTC failed to include appropriate permission check code to protect this
pre-installed application from exploitation. As a result, any third-party application
exploiting the vulnerability could command this pre-installed application to download
and install any additional applications from any server onto the device without the user’s
knowledge or consent. Because this would occur outside the normal installation process,
the user would not be presented with a permission screen that explained what sensitive
information or sensitive device functionality the additional application being installed
would be able to access. In effect, this vulnerability undermines all protections provided
by Android’s permission-based security model. This vulnerability has been present on
approximately 18.3 million HTC devices running Android v. 2.1.x, 2.2.x, 2.3.x, 3.0.x and
certain devices that were upgraded to Android v. 4.0.x.
INSECURE COMMUNICATIONS MECHANISMS
13. HTC failed to use readily-available and documented secure communications mechanisms
in implementing logging applications on its devices, placing sensitive information at risk.

4
Logging applications collect information that can be used, for example, to diagnose
device or network problems. Because of the sensitivity of the information, as described
below, communications with logging applications should be secure to ensure that only
designated applications can access the information. Secure communications mechanisms
-- such as the Android inter-process communication mechanisms expressly described in
the Android developer guides, or secure UNIX sockets – could have been used to ensure
that only HTC-designated applications could access the sensitive information collected
by the logging application. Instead of using one of these well-known, secure alternatives,
HTC implemented communication mechanisms (e.g., INET sockets) that could not be
restricted in a similar manner. Moreover, HTC failed to implement other, additional
security measures (e.g., data encryption) that could have secured these communications
mechanisms. Because the communications mechanisms were insecure, any third-party
application that could connect to the internet could communicate with the logging
applications on HTC devices and access a variety of sensitive information and sensitive
device functionality, as described below.
a. HTC Loggers. Beginning in May 2010, HTC installed its customer support and
trouble-shooting tool HTC Loggers on approximately 12.5 million Android-based
mobile devices. Because HTC Loggers could collect sensitive information from
various device logs, it was supposed to have been accessible only to HTC and
certain network operators, and only after the user had consented to its use by
manually entering a special code into the mobile device. Moreover, the Android
permission-based security model normally requires a third-party application to
obtain the user’s consent before accessing the device logs. Because HTC used an
insecure communications mechanism, however, both of these intended protections
were undermined, and any third-party application on the user’s device that could
connect to the internet could exploit the vulnerability to communicate with HTC
Loggers without authorization and command it to collect and transmit information
from the device logs. This information could include, but was not limited to,
contents of text messages; last known location and a limited history of GPS and
network locations; a user’s personal phone number, phone numbers of contacts,
and phone numbers of those who send text messages to the user; dialed digits;
web browsing and media viewing history; International Mobile Equipment
Identity (“IMEI”) or Mobile Equipment Identifier (“MEID”); and registered
accounts such as Gmail and Microsoft Exchange account user names.
b. Carrier IQ. Beginning in 2009, HTC embedded Carrier IQ diagnostics software
on approximately 10.3 million Android-based mobile devices and 330,000
Windows Mobile-based mobile devices at the direction of network operators
Sprint and AT&T, who used Carrier IQ to collect a variety of information,
described in subparagraph (i) below, from user devices to analyze network and
device problems. In order to embed the Carrier IQ software on its mobile devices,
HTC developed a “CIQ Interface” that would pass the necessary information to
the Carrier IQ software. The information collected by the Carrier IQ software
was supposed to have been accessible only to the network operators, but because
HTC used an insecure communications mechanism, any third-party application on

5
the user’s device that could connect to the internet could exploit the vulnerability
to communicate with the CIQ Interface, allowing it to:
i. Intercept the sensitive information being collected by the Carrier IQ
software. This information could include, but was not limited to, GPS-
based location information; web browsing and media viewing history; the
size and number of all text messages; the content of each incoming text
message; the names of applications on the user’s device; the numeric keys
pressed by the user; and any other usage and device information specified
for collection by certain network operators; and
ii. In the case of HTC’s Android-based devices, perform potentially
malicious actions, including, but not limited to, sending text messages
without permission. As described in Paragraph 11, malware could exploit
this vulnerability to perpetrate toll fraud. Moreover, in this case, the sent
text messages would not appear in the user’s outbox, making it impossible
for the user to verify that unauthorized text messages had been sent from
the device.
DEBUG CODE
14. During the development of an application, developers may activate “debug code” in order
to help test whether the application is functioning as intended. When developing its CIQ
Interface for its Android-based devices, HTC activated debug code in order to test
whether the CIQ Interface properly sent all of the information specified by the network
operator. The debug code accomplished this by writing the information to a particular
device log known as the Android system log, which could then be reviewed. However,
HTC failed to deactivate the debug code before its devices shipped for sale to consumers.
As a result of the active debug code, all information that the CIQ Interface sent to the
Carrier IQ software from a consumer’s device, including the information specified in
Paragraph 13(b)(i), was also written to the Android system log on the device. This
information was supposed to have been accessible only to the network operators, never
written to the system log. Because it ended up in the system log, this sensitive
information was:
a. Accessible to any third-party application with permission to read the system log.
Although users may provide third-party applications with permission to read the
system log for certain purposes -- for example, to trouble-shoot application
crashes -- those applications never should have had access to all the sensitive
information, such as the contents of incoming text messages, that the Carrier IQ
software was collecting.
b. Sent to HTC. The information in the system log is sent to HTC when a user
chooses to send HTC an error report through its “Tell HTC” error reporting tool,
described in Paragraph 20. Accordingly, in some cases, HTC also received this
sensitive information, including users’ GPS-based location information.

6
15. HTC could have detected its failure to deactivate the debug code in its CIQ Interface had
it had adequate processes and tools in place for reviewing and testing the security of its
software code.
CONSUMERS RISK HARM DUE TO HTC’S SECURITY FAILURES
16. Because of the potential exposure of sensitive information and sensitive device
functionality through the security vulnerabilities in HTC mobile devices, consumers are
at risk of financial and physical injury and other harm. Among other things, malware
placed on consumers’ devices without their permission could be used to record and
transmit information entered into or stored on the device, including financial account
numbers and related access codes or personal identification numbers, medical
information, and personal information such as text messages and photos. Sensitive
information exposed on the devices could be used, for example, to target spear-phishing
campaigns, physically track or stalk individuals, and perpetrate fraud, resulting in costly
bills to the consumer. Misuse of sensitive device functionality such as the device’s audio
recording feature would allow hackers to capture private details of an individual’s life.
17. In fact, malware developers have targeted the types of sensitive information and sensitive
device functionalities that potentially are exposed through the security vulnerabilities in
HTC mobile devices. Text message toll fraud, for example, is one of the most common
types of Android malware. Security researchers have also found Android malware that
records and stores users’ phone conversations and that tracks users’ physical location.
18. Had HTC implemented an adequate security program, it likely would have prevented, or
at least timely resolved, many of the serious security vulnerabilities it introduced through
the process of customizing its mobile devices. HTC could have implemented readily-
available, low-cost measures to address these vulnerabilities – for example, adding a few
lines of permission check code when programming its pre-installed applications, or
implementing its logging applications with secure communications mechanisms.
Consumers had little, if any, reason to know their information was at risk because of the
vulnerabilities introduced by HTC.
HTC’S PRIVACY AND SECURITY REPRESENTATIONS
19. Since at least October 2009, user manuals for HTC’s Android-based mobile devices
contained the following statements, or similar statements, regarding Android’s
permission-based security model:

7
. . .
20. Since at least June 2011, HTC has, in many of its Android-based mobile devices,
included the Tell HTC error reporting tool. The error reporting tool provides the user
with an opportunity to send a report to HTC when there is an application or system crash.
The report includes the information in the Android system log. The Tell HTC user
interface provides the user with the additional option of submitting location information
with the report by checking the button marked “Add location data,” as depicted below:
Through this user interface, HTC represents that the user’s location data will not be sent
to HTC if the user does not check the button marked “Add location data.”
HTC’S UNFAIR SECURITY PRACTICES
(Count 1)
21. As set forth in Paragraph 7-18, HTC failed to employ reasonable and appropriate security
practices in the design and customization of the software on its mobile devices. HTC’s
practices caused, or are likely to cause, substantial injury to consumers that is not offset
by countervailing benefits to consumers or competition and is not reasonably avoidable
by consumers. This practice was, and is, an unfair act or practice.

8
HTC’S DECEPTIVE ANDROID USER MANUALS
(Count 2)
22. As described in Paragraph 19, HTC has represented, expressly or by implication, that,
through the Android permission-based security model, a user of an HTC Android-based
mobile device would be notified when a third-party application required access to the
user’s personal information or to certain functions or settings of the user’s device before
the user completes installation of the third-party application.
23. In truth and in fact, in many instances, a user of an HTC Android-based mobile device
would not be notified when a third-party application required access to the user’s
personal information or to certain functions or settings of the user’s device before the
user completes installation of the third-party application. Due to the security
vulnerabilities described in Paragraphs 8-15, third-party applications could access a
variety of sensitive information and sensitive device functionality on HTC Android-based
mobile devices without notifying or obtaining consent from the user before installation.
Therefore, the representation set forth in Paragraph 22 constitutes a false or misleading
representation.
HTC’S DECEPTIVE TELL HTC USER INTERFACE
(Count 3)
24. As described in Paragraph 20, HTC has represented, expressly or by implication, that, if a
user does not check the button marked “Add location data” when submitting an error
report through the Tell HTC application, location data would not be sent to HTC with the
user’s error report.
25. In truth and in fact, in some instances, if a user did not check the button marked “Add
location data” when submitting an error report through the Tell HTC application, location
data was nevertheless sent to HTC with the user’s error report. Due to the security
vulnerability described in Paragraph 14, in some instances, HTC collected the user’s
GPS-based location information through the Tell HTC error reporting tool even when the
user had not checked the button marked “Add location data” in the Tell HTC user
interface. Therefore, the representation set forth in Paragraph 24 constitutes a false or
misleading representation.
26. The acts and practices of respondent as alleged in this complaint constitute unfair or
deceptive acts or practices in or affecting commerce in violation of Section 5(a) of the
Federal Trade Commission Act, 15 U.S.C. § 45(a).

9
THEREFORE, the Federal Trade Commission this twenty-fifth day of June, 2013, has
issued this complaint against respondent.
By the Commission, Commissioner Ohlhausen recused.
Donald S. Clark
Secretary

Privacy and Data Security: Minimizing Reputational and Legal Risks

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to Privacy and Data Security: Minimizing Reputational and Legal Risks

Similar to Privacy and Data Security: Minimizing Reputational and Legal Risks (20)

More from TechWell

More from TechWell (20)

Recently uploaded

Recently uploaded (20)

Privacy and Data Security: Minimizing Reputational and Legal Risks