This document discusses privacy and security issues related to web browsers. It outlines research on establishing trusted paths for browsers to prevent spoofing of website identities. Approaches for separating status information from website content are proposed, such as using dedicated metadata windows or colored boundaries. A prototype uses synchronized random borders and labeling to make spoofed windows easier to detect. User studies found the security signals were noticeable and effective. The document also discusses approaches for managing browser cookies in a way that balances privacy, functionality, and usability.

1. Web Browser Privacy and
Security
Part II

2. 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

3. 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?

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. User Study
 Increased awareness of cookie events
 More likely to respond to cookie
events
 More likely to make cookie
management actions

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

39. Firefox Extensions
164 Extensions in the Security and
Privacy Section at mozilla.org

40. Site Identity

41. Site Identity

42. Privacy

43. Privacy

44. 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

45. 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

46. 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

47. 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?