Web Browser Privacy and Security Part II

advertisement
Web Browser Privacy and
Security
Part II
Outline
 Overview
 Browser Privacy and Security Research
 HCISec Bibliography
 Trusted Paths for Browsers
 Zishuang Ye, Sean Smith, Denise Anthony
 Informed Consent in the Mozilla Browser:
Implementing Value-Sensitive Design
 Batya Friedman, Daniel C Howe, Edward Felten
 Doppelganger: Better Browser Privacy Without the
Bother
 Umesh Shankar, Chris Karlof
 Discussion and Activity
Overview
 The web browser serves as a doorway to
the Internet for much of a typical user’s
online activity
 Browsers have the potential to impact on
the privacy and security of any action they
are used to complete
 Some of the most interesting areas are
where there is no clear cut answer
 Technology that has functionally beneficial uses
but gives up something in return
 Can (or should) these decisions be automated?
Web Browsers and Online Privacy
 Common privacy concerns come up when
simply browsing the web
 Sometimes, users are getting something in
return for the loss of privacy
 Personal information given to websites (creating
accounts/completing real world transactions)
 Cookies (remember usernames/preferences)
 Other times, no value is returned to the user for
their loss of privacy
 Tracking cookies
 Web bugs
 Traffic logs
Cookies
 Because cookies can be used
beneficially, disallowing their use is
not an acceptable solution
 People claim to want the browser to
seek their consent before giving up
information in this manner
 Asking every time is too intrusive and
annoying, and leads to users clicking
through without paying attention
Problems with Cookie Management
 Accept/Reject decision is not clear in
all cases
 Because the perceived risks are low,
very little action can be required on
the part of the user or they will
simply avoid using the tool
 Two proposed solutions later
Web Bugs and Traffic Logs
 Loading of remote image that doesn’t
impact visual layout of page
 Set 3rd party cookie
 Remote server can log event of image load
even if cookie is rejected
 However, there are lots of cases where we
want our browsers to load images and
display them to us
 Can be difficult to tell when this action is
beneficial and when it isn’t
Web Browsers and Online Security
 Confidentiality
 You should be able to exchange data
with the server without an eavesdropper
being able to intercept it
 Integrity
 No third-party should be able to modify
or corrupt your communications with the
server
 You must be able to correctly identify
the server you are interacting with
Web Browsers and Online Security
 Browsers provide common tools
enabling users to interact with remote
servers in a secure fashion
 Encrypted sessions (SSL)
 Signed Certificates
 However, the browser must then
communicate about these tools to the
end user
Trusted Path for Web Browsing
 Trusted Path
 From the remote web server to the user
 Malicious websites or third party
attackers should not be able to use your
browser to trick you
 Many common indicators needed to
establish the identity of the server can
be spoofed
Certificates
 Talked a lot about signed certificates
as an important part of creating a
Trusted Path to the user
 Goals
 Confidentiality and Integrity
 Establishes identity of remote server
 Does it accomplish these goals?
 Tuesday’s lecture
Web Browser Security
 Trusted Paths for Browsers
 Evaluation of browser methods for
establishing a trusted path to the
user
 Ability to masquerade as a site with a
different identity
 Ability to “spoof” the existence of a SSL
connection
Misleading website identity in
browsers
 Malicious sites trying to use a forged
identity are often related to phishing
attacks
 Simple impersonation attacks in the URL
itself
 www.paypai.com
 http://www.bloomberg.com@1234567/
 From a technical standpoint, there is
nothing wrong with these addresses, yet
they are intended to mislead
Misleading website identity in
browsers
 More elaborate impersonation attacks are
also possible using JavaScript
 Link appears to go to one site, but goes to
another instead
 New window with standard toolbars disabled,
replaced with spoofed ones displaying inaccurate
information
 Imposter site with JavaScript created interface
elements looks very similar to legitimate site
 Again, all technically legitimate JavaScript
commands, used with the intention of
misleading the user
Why does this work
 Browsers don’t make enough of a
distinction between site content and
browser status information
 A clear distinction needs to exist
 Users need to be able to easily perceive
this difference
 Status information should never be empty
 Status elements should be difficult to
impersonate
Approaches
 No Turnoff
 Make it impossible to disable elements
such as the location and status bars
 Overly restrictive of site display
 Customized Content
 Clearly label status material by using
customized styles or information that
would be difficult to spoof
 Requires some effort from user
 May not be noticed
Approaches – cont
 Metadata Titles
 Push some important status data into
the window title bar where it is more
difficult to modify
 Would users notice?
 Still vulnerable to window in window
 Metadata Windows
 Separate dedicated window for metadata
 Easy to Ignore
 Difficult to correlate with content elements
Approaches – cont
 Boundaries
 Use large colored boundaries to indicate
“trusted” status information from the
browser
 Window in window
 Compartmented Mode Workstation Style Approach
 Uses combination of metadata windows
and boundaries
Prototype
 Separate metadata window always open
 Displays color matching the security level of
the focus window
 Color mismatch of spoofed window will
warn users
 Synchronized random dynamic borders
switch all windows between inset and
outset shading styles at once to further
make window in window spoofs easier to
identify
Prototype – cont
 All windows labeled
 Colored boundaries are easy to
recognize
 Minimal user work required
 Minimal level of intrusiveness,
content unaffected
 Modified version of Mozilla browser
User Study
 Security signal was noticeable and
easy to learn to understand
 Presence of the reference window
made it easier to observe the
synchronization
 Dynamic boundaries much easier to
notice than static ones
 Displaying security signals without
requiring user action is more reliable
Value-Sensitive Design
 Informed Consent in the Mozilla Browser:
Implementing Value-Sensitive Design
 Shares work with Informed Consent by
Design – Chapter 24
 Many sites collecting information about
users do not explicitly inform them that
they are doing so
 Your browser is implicitly giving consent on
your behalf when accepting cookies
Informed Consent
 88% of users expressed that they wanted
sites to explicitly get their consent
 Elements of Informed Consent






Disclosure
Comprehension
Voluntariness
Competence
Agreement
Minimal Distraction
Minimal Distraction
 Why is this important?
 If overwhelmed with queries with low
perceived benefits and risks, attention to
each will become low
 After some threshold, users will simply
seek to disable the mechanism to avoid
the annoyances it presents
 In either of these cases, it is impossible
to maintain the other 5 properties
Prototype
 Iterative design, rapid prototyping,
user evaluations
 Enhancements to cookie manager
tool
 Additional cookie information
 Just-in-time interventions for cookie
events
 Difficult to tell which are actually
important to a user
Prototype – cont
 Instead of interrupting current work with
decisions, give peripheral notification
 Users can then identify themselves which events
are important and need their attention
 Cookie information box displays currently
set cookies on side of browser area
 Color and formatting in cookie information
dialog box make cookies easier to identify
 3rd party cookies in red
 Long cookie expiration durations bolded
 Cookie expiration durations for current session
in italics
User Study
 Increased awareness of cookie events
 More likely to respond to cookie
events
 More likely to make cookie
management actions
Web Browser Privacy
 Making decisions about the tradeoff of
privacy and functionality
 Most automated methods make mistakes
when compared to actual user
preferences
 Asking the user every time is annoying
 They will stop paying attention and make
mistakes themselves
 Who is better equipped to make the
decision? The user or the browser
Doppelganger
 Doppelganger: Better Browser Privacy
Without the Bother
 More fun with cookies!
 When deciding to accept a cookie or not,
users would like to compare the privacy
cost to the functionality benefit but are ill
equipped to do so
 Doppelganger aims to assist the user in
making these decisions and learn and make
simple generalizations of these rules to
remove later instances of repeated prompts
Goals
 Create a cookie policy that
 Protects privacy
 Maintains functionality
 Doesn’t hassle the user
 Doppelganger
 Firefox extension
 Mirrors session in hidden window
 Detects differences in sessions
Doppelganger
 Maintains “forked” session
 If there is no detected difference, cookies
are assumed to have no benefit and are
ignored
 If there is a difference, present it to the
user, give them information relevant to the
cookie and let them decide to accept or
reject
 Now has information necessary to make
informed functionality vs. privacy decision
Doppelganger
 “Fix Me” button for user-initiated repair
 Attempts to rewind and replay sequence of
actions with cookies on
 Needed incase no difference was detected and
cookies were automatically rejected
 Learns policies per domain
 Configuration modes allow for automatic
acceptance of 1st party session cookies
 Other modes allow for different trade off of
privacy and intrusiveness
Evaluation
 Simulated User
 Willing to give up privacy at some sites
 Yahoo!, Netflix, GMail
 Not willing to give up privacy at sites which they had
no relationship
 CNN, PCMagazine, etc
 5 Conditions
 All cookies enabled
 Reject 3rd party cookies
 Reject 3rd party cookies + Reject persistent cookies
 Ask user for every cookie
 Doppelganger
Measurements
 Number of sites whose cookies were
accepted
 Grouped by persistence and context
 Doesn’t directly measure privacy loss
 Inconveniences suffered by user
 Dialog boxes and prompts
 Lost functionality
 Looking for low values both times
 Set of common tasks was repeated three
times
Results
 Doppelganger had the best fit for accepted
cookies vs. lost functionality
 More prompts than the conditions that never
prompt
 Fewer prompts than the condition that always
prompts
 After the 2nd visit to any given site, no further
prompts were required for any of the test scripts
 After navigating prompts, there was no lost
functionality
 Required use of “Fix Me” button once upon
returning to a site that needed a persistent
cookie for functionality
Alternatives
 Most browsers allow users only very
coarse-grained control
 Allowing or blocking all cookies by category
 Session, 3rd party, All
 Allowing too many has negative privacy
implications
 Blocking too many has negative
functionality implications
 There are ways around the 3rd party blocks
 Redirect links
 IFrames
Alternatives – cont
 Many existing extensions and addons to
enhance cookie management






Cookie Button
Cookie Toggle
Permit Cookies
Add N Edit Cookies
Cookie Culler
View Cookies
 But they still focus on the low level task of
cookie management
Alternatives – cont
 Acumen
 Social Approaches to End-User Privacy
Management – Chapter 25
 Social Recommendations
 Simple threshold rules
 Makes some steps in the right direction
to move action away from low level tasks
Firefox Extensions
164 Extensions in the Security and
Privacy Section at mozilla.org
Site Identity
Site Identity
Privacy
Privacy
Why Extensions?
 Why aren’t these built into the default
behavior of browsers?
 Chances are, users won’t take the proactive
action required of going out to acquire these
tools
 Highest risk users likely not aware of their
existence
 They all make tradeoffs
 User effort
 Distractions
 Blocking use of often-abused functionality
 But potentially useful functionality
Summary
 Interesting questions arise with technology
that trades off privacy for functionality
 What is the best way to give users a good level
of control over this
 The less a tool requires of the user, the
more effective it is
 Can often make better decisions than the user
 User will avoid repetitive decision making tasks
Discussion
 What do you think?
 Firefox and the Worry-free Web –
Chapter 28
 Do it for them
 When there are functionality
tradeoffs, it is often not clear what to
do
Activity
 Group discussion
 What do you think is the right amount of
interaction for cookie management?
 Does it work for everyone?
 Would you use it yourself?
 Would a novice computer user be able to
use it?
Download