Privacy Engineering Sarah Spiekermann & Lorrie Faith Cranor DIMACS Workshop, Rutgers University

advertisement
Privacy Engineering
Sarah Spiekermann & Lorrie Faith Cranor
DIMACS Workshop, Rutgers University
January 2007
Institute of Information Systems, Humboldt University, 2006·
Privacy Engineering
•
Privacy Threats arising through IS activities
•
User Privacy Concerns and 2 Layers of Responsibility for Privacy Engineers
•
“Privacy by Policy” vs. “Privacy by Architecture”
•
Designing Privacy by Architecture
– Client centricity
– Identifiability
•
Forms of Trust created through Fair Information Practices
•
Implementing Fair Information Practices
•
Recognizing Responsibility for Data Sharing Networks
Institute of Information Systems, Humboldt University, 2006·
User Privacy Concerns and 2 Layers of Responsibility for Privacy
Engineers
2-Layer
Responsibility
Framework
Data Recipient
Control
of personal
data collected
User Privacy
Concerns
Layer II
internal
unauthorized
2nd use
external
unauthorized
2nd use
IS activities
with regards to
personal data
improper
access
errors
Processing
Transfer
reduced
judgments
combining
data
Service Edge
1
2
Network Edge
unauthorized
collection
Access
Control
unauthorized
execution
Layer I
exposure
Attention/inflow of data
Client Side
Institute of Information Systems, Humboldt University, 2006·
Storage
Fair Information Practices are the typical short-cut
approach to privacy engineering.
•
(1) Notice: Data collectors should provide consumers with clear and conspicuous
notice of their information practices, including what information they collect, how they
collect it (e.g., directly or through non-obvious means such as cookies), how they use
it, how they provide Choice, Access, and Security to consumers, whether they
disclose the information collected to other entities, and whether other 3rd entities
besides themselves are collecting information about consumers as part of the
service.
•
(2) Choice: Data collectors should offer consumers choices as to how their personal
identifying information is used beyond the use for which the information was provided
(e.g., to consummate a transaction). Such choice would encompass both internal
secondary uses (such as marketing back to consumers) and external secondary uses
(such as disclosing data to other entities).
•
(3) Access: Data collectors should offer consumers reasonable access to the
information which is collected about them, including a reasonable opportunity to
review information and to correct inaccuracies or delete information.
•
(4) Security: Data collectors should take reasonable steps to protect the security of
the information they collect from consumers.
Institute of Information Systems, Humboldt University, 2006·
Fair Information Practices are the typical short-cut
approach to privacy engineering.
2-Layer
Responsibility
Framework
Privacy
Engineering
Focus
Data Recipient
Control
of personal
data collected
Layer II
Security
Access
Service Edge
2
1
Access
Control
Network Edge
Layer I
Client Side
Institute of Information Systems, Humboldt University, 2006·
Choice
Notice
“Privacy by Policy” vs. “Privacy by Architecture”
non-identified
data
collection
Privacy by
Architecture
Privacy by
Policy
through
FIPs
identified
data
collection
network centric
architecture
Institute of Information Systems, Humboldt University, 2006·
client centric
architecture
Designing Privacy by Architecture: Client Centricity
Network Centricity
Client Centricity
services
services
Network
Client
requests
Institute of Information Systems, Humboldt University, 2006·
requests
Client
Designing Privacy by Architecture: Identifiability
Identification
Continuum
System’s
Privacy
Friendliness
identified
Strategic
Linkability
Choices
linked
privacy
by
policy
anonymous
• unique identifiers across databases
• contact information stored with profile
information
Necessity
to provide
for FIPs
0
yes
linkable with
reasonable&
automatable
effort
• no unique identifies across databases
• common attributes across databases
• contact information stored separately
from profile or transaction information
1
yes
not linkable
with
reasonable
effort
• no unique identifiers across databases
• no common attributes across databases
• random identifiers
• contact information stored separately
from profile or transaction information
• collection of long term person
characteristics on a low level of
granularity
• technically enforced deletion of profile
details at regular intervals
2
no
unlinkable
• no collection of contact information
• no collection of long term person
characteristics
• k-anonymity with large value of k
3
no
pseudonymous
privacy
by
architecture
System Characteristics
Stages of
Privacy in
System
Design
Institute of Information Systems, Humboldt University, 2006·
Fair Information Practices create Knowledge-based Trust
• Knowledge-based Trust: the
more someone knows about
somebody else, the more
behavior becomes predictable
and understandable
• Structural Assurance: safety
nets, legal recourse,
guarantees
• Calculative Trust: rational
assessment of the other
party’s benefits and costs of
cheating
Institute of Information Systems, Humboldt University, 2006·
 Fair Information Practices
 Privacy Policies & Agents
(i.e. Privacy Bird)
 Privacy Seals (i.e. TRUSTe)
Implementing Fair Information Practices: Information About What?
User concerns
Notice should be given about…
Marketing Practices
Combining Data
Notice about data combination practices
• external data purchases?
• linking practices?
Reduced Judgment
Notice about segmentation practices
• type of judgments made?
• personalization done?
• what does personalization lead to for the customer?
• sharing of segmentation information?
Future attention consumption
• contact plans (i.e. through newsletters, SMS)
IS Practices
External unauthorized transfer
• is data shared outside the initial data recipient?
• if yes, with whom is data shared?
External unauthorized processing
• is data processed externally for other purposes than initially specified?
• if yes, for what purposes?
Internal unauthorized transfer
• is data transferred within a company conglomerate?
• if yes with whom within the comglomerate?
Internal unauthorized processing
• is data processed internally for other purposes than initially specified?
• if yes, for what purposes?
Unauthorized collection of data from client
• use of re-identifiers (i.e. cookies, stable IP address, phone number, EPC)
• collection of information about device nature (i.e. browser, operating system, phone type)
• collection of information from the device (i.e. music library, cache information)
Unauthorized execution of operations on
client
• installation of software?
• updates?
Exposure
• cached information (i.e browser caches, document histories)
Institute of Information Systems, Humboldt University, 2006·
• collection of information from the device (i.e. music library, cache information)
Recognizing Responsibility for Data Sharing Networks (I)
external parties:
government/
litigation related parties
peers
content/service
provider
3rd party
3rd party
access
provider
Main User
3rd party
data sharing
always exists
secondary
user
application/
system provider
Institute of Information Systems, Humboldt University, 2006·
3rd party
data sharing
could exist
Recognizing Responsibility for Data Sharing Networks (II)
Party X should inform about party Y
Y
System
Provider
Network
Provider
Service
Provider
3rd parties
Peers
X
System
Providers
Network
Provider
Service
Provider








Peers
Institute of Information Systems, Humboldt University, 2006·

()
Thank you for your attention!
For more information, please contact the authors:
Sarah Spiekermann, Humboldt University Berlin; sspiek@wiwi.hu-berlin.de
Lorrie Faith Cranor, Carnegie Mellon University; lorrie@cs.cmu.edu
Institute of Information Systems, Humboldt University, 2006·
Download