SV_MEETING_TITLE -- 31 Oct 2012

<npdoty> is someone available to scribe this session?

<npdoty> also, we better get started pretty soon here

<npdoty> bhill2: Brad Hill, one of the chairs of the Web App Sec Working Group

<npdoty> ... a while back when taking our spec to CR, received some feedback that it was unacceptable from a privacy point of view because it was detectable from JS, would give away characteristics about the browser

<annevk> scribe: Josh_Soref

<annevk> scribenick: annevk

bradh: there's a view that preventing fingerprinting is a lost cause
... and it quickly became apparent that there isn't such a consensus

<dbaron> bradh: ... and that we should move to alternatives like do not track

bradh: to look at some of the past
... what are we talking about
... we aren't talking about cookies
... we're talking about passive detection
... panopticlick is the best example of this

<bradee-oh> http://panopticlick.eff.org

bradh: there are 70/80 tests that can identify quirks about you

<bradee-oh> http://browserspy.dk

bradh: and academic projects that do microbenchmarks
... to identify memory+speed
... is this a problem we can solve
... there's a number of asymmetries here
... User constituency v. author constituency
... more users, fewer authors
... obligation to users

<npdoty> I saw a project around the fingerprinting of graphics cards from using WebGL to render an image

bradh: asymmetry to make progress
... how easy is it to undo that progress

<fluffy> http://cseweb.ucsd.edu/~hovav/dist/canvas.pdf

bradh: once characteristics are findable, it's easy to monetize
... there's a paradox of user control/privacy
... opt in features to preserve privacy
... the act of turning them on make them more unique
... that makes them more unique
... there are ladders
... how much bandwidth
... do these singals give

<Josh_Soref> scribenick: Josh_Soref

bradh: within useragent, plugins,
... whitelist of noscript
... user specific data inferable from application running in ua
... there are things we advertise deliberately
... apis for feature detection
... browser is a code execution environment
... thousands of api points
... paradox, public things
... major version of browser
... plus IP address
... = unique fingerprint
... where do we draw the line
... privacy impact of things that maintain state
... this is an IETF spec
... HSTS
... an HSTS super cookie
... of one bit
... think about explicitly as state
... how do we realistically draw these lines
... what's our adversary look like?
... an individual commercial site, trying to act w/ good intent
... allow things to work ok
... but commercial tracking sites
... have an incentive to de-anonymize
... then there are state-level actors
... different consequences for these cases
... targeted ads. v. Syrian dissident
... WebAppsSec WG didn't agree w/ the UC threat
... we were presented w/ a bad actor
... but it ignored all existing ways bad actor could ask
... if you're going to ask WGs to consider these
... those kinds of norms matter
... ietf has taken this on to some degree
... Presence protocols
... context matters
... when designing a "new" protocol
... we never really do that
... we have a high bandwidth high functionality
... this is very much like a Covert Channel
... Lampson's "Confinement Problem"
... we found it's difficult to minimize bandwidth
... even when it's an explicit design criteria
... we're trying to retroactively remove covert channels w/ 20+ years of history
... the Private User Agent CG was chartered
... not sure how approachable it is
... there's also DNT effort
... deal with it at Layer 9
... commerce, agreements, policy, regulation
... there's Incognito
... this is more where the adversary is your Mom
... there are UAs
... designed to avoid selective fingerprint

<drogersuk> selective minuting on the "mom" problem there josh ;-)

bradh: there's an approach to create a standard fignerprint
... NSA using an out of date Firefox UA

<wseltzer> [Torbutton design document: https://www.torproject.org/torbutton/en/design/#adversary]

[ slide of feedback from twitter ]

<npdoty> "it's impossible, we should try anyway" "the bread and butter of the security community"

<bradee-oh> http://www.techpolicy.com/Blog/Featured-Blog-Post/Users-Cannot-Win-in-a-Tech-Race-with-Advertisers-A.aspx

bradh: distinction between passive and active
... i'll open the floor

Feedback

<Zakim> npdoty, you wanted to comment on some client-side fingerprinting being easier to detect/block in the browser and to comment on "profiles" or standard configurations

npdoty: thanks bradh
... i want to follow up on a couple of points
... distinction you're pointing out re: active v. passive
... it's relatively easy to detect when a web page is trying to access all of my fonts
... a browser could clamp down on that
... but when we add an identifiable header
... they're hard to detect
... and very easy to use for finger print
... maybe we can make a substantial difference
... i like standardized configurations
... i've heard the move to mobile browsers
... standardized screen sizes
... updated browsers
... have actually reversed the distinguishability bits
... on DNT
... rather than engaging in an Arms Race
... DNT allows for a cooperative solution
... it's explicitly focused on Cooperative
... we understand there are attackers who won't
... that's why i think it's worth persuing

<Zakim> wseltzer, you wanted to ask what threat models we're using

wseltzer: i wanted to go a bit further into questions
... the threat model
... and the user we're trying to defend
... a user who is taking steps to protect privacy
... could be aided by extra features for privacy
... even if passive user is exposing too much data to protect

<annevk> FWIW, the way I approached this problem was by tackling small things. Removing Accept-Charset, removing bits from User-Agent, making the format of Accept-Encoding more normalized accross browsers, etc. There's a lot of bits unfortunately :/

wseltzer: users vary from passive user, to incognito, to Tor in a dedicated VM
... i'm interested in

drogersuk: great presentation
... i agree on threat models
... in Web Crypto, and DAP
... everyone avoids the difficult questions around where's the threat from
... and risk quantification

<fwagner> is the great presentation somewhere available ?

drogersuk: if user is taking technical measures
... it's a different user than child browsing internet

bradh: even users interested in anonymity and privacy
... needs a browser that works
... you could take the NSA route
... "used to browse the web w/ JS off"
... but that makes the web unusable
... how do we keep moving?
... create a profile that tries to hide things
... but have that profile move forward

<npdoty> does the profile need to be static? or does a rotating and updating profile actually help as a defense?

dbaron: after speaking to various groups
... i don't think we can solve this from a technical perspective
... not even w/ fancy new tech
... w/ tech from a long time
... http-cache, redirect, cookies
... give huge opportunities for tracking users
... go into a room asking about fingerprinting users
... they'll come up w/ more things
... if we want to fix it for really privacy concerned users
... but i can't think of how to do it w/o significant degredation to UX

bradh: so, is it a lost cause that spec authors shouldn't consider?

<tlr> I think active tracking has become part of the architecture.

dbaron: the first casual category is relevant and worth considering
... i don't think there's a realistic approach for serious attackers and average users

<tlr> (i.e., there's client-side state that can be written and read back)

<Zakim> dom, you wanted to ask to hear from non-privacy advocates

dom: in many of the WGs i've been in, this question comes up, again and again
... the question comes back, do we need to care or not?

<npdoty> it may be easy, but if it's SO easy, then we wouldn't make advances towards anonymity, and it seems like we occasionally do (clearing Flash LSOs)

dom: we've heard plenty of people who says "yes it matters"
... but the cost of making it happen is so high
... for the platform
... maybe we won't have an answer today
... what i'm hoping is we'll have a better understanding today, to how to go
... if the answer is, "it's complicated"
... i'd like to document various answers/things to consider

rigo: first of all
... when we talk about creativity of those fingerprinting
... we should talk about creativity of those trying to prevent fingerprinting
... we should actually
... the more info you expose, the better fingerprinting works
... the better fingerpinting adaptation works
... privacy in my European thread is
... "is it really necessary"

<npdoty> I'm not sure the privacy position here is "no bits of entropy are allowed in new specs"; just that we should balance the fingerprinting risk and not do so egregiously since we can do better or worse on this problem

rigo: if it's necessary in the context, then that may justify the risk
... but i have some trouble w/ PeterXX's tool
... if i'm one in 126k
... v. 1 in 576k
... what is it hindering/doing

dom: every WG when they hear about Fingerprinting
... they say, yeah, let's think
... but then we can't do this/this/that
... the problem is calculating cost-benefit
... if you ask WG, to think, they'll say yeah
... but we can't do anything

<npdoty> dom, +1 on creating better metrics for calculating costs/benefits

rigo: WG puts its shoes of user
... because it wants to decide if exposing info is good or not
... after 8 years of privacy research
... some sites i want to expose full details
... but other sites, i'd like to expose less

<burn> rigo, +1 on this being about trust

rigo: ok consider risk
... ok lose functionality
... ok ask user
... that last one is a four letter word to browser vendors

<bblfish> agree with rigo

fjh: business driver
... solutions may not be available technically today
... but maybe tomorrow
... and regulatory may appear
... just saying you can't deal w/ it and discard isn't right
... but try to document things
... so at least you understand where things are at
... and legal/regulatory catches up

ekr: there's an interaction between security and non-security
... security says these are the unpleasant facts
... and non-security says "why can't you do better"?
... on WebGL fingerprinting, it's impossible
... or malware/software vulnerability
... attackers have way too much of an advantage
... you'd need to come up w/ a plausible solution to secure existing browsers

<npdoty> I'm not sure I understand the analogy; we aren't always constantly suffering from malware even though it's a tough problem to solve entirely

ekr: there's a line in the sand between active and passive

<scribe> ... new passive vectors need justification

<scribe> ... new active don't worry about

bblfish: agree w/ rigo
... from identity space

<wseltzer> npdoty, but if the attacker can exploit security flaws, he can often win a super-fingerprint

<fjh> specs should indicate the risks and fingerprinting threats even if no technical solution obvious as there is a legal, regulatory ands social dimension that should be understood

bblfish: transparency of identity to user
... safari - cert once, you never see you're sending it
... i think it should be clear in UI to show what identity you're sending
... color coding
... browser doesn't tell you that you're setting cookies

Josh_Soref: note that browsers once did show cookies
... and it failed miserably

bblfish: this is only solvable w/ ui designers
... and crypto people, etc

<fjh> thus when the demand for a solution results in corresponding regulation/legal mechanisms it will make it clear where technologies are impacted

bblfish: aza raskin did some demos
... i want more transparency

<fjh> so it is not a lost cause

fluffy: i love the idea of having a mode
... where i could run a browser in a way where i could lose some functionality

<bblfish> so that was relevant because it is feasible perhaps if you make it transparent what level you are in as a user

fluffy: but i have some functionality
... protect against script kiddie
... not against NSA
... how do we build it
... minimal functionality against weakest attacks
... no one knows how to protect against timing attacks
... it's a long term research problem

<fjh> I liked nick's point that a browser could disallow large scale info collection

fluffy: solve simplest attack against simplest cases

burn: as an individual user, i want privacy
... but i agree w/ rigo, issue here is trust
... if we want open web platform to be the platform for applications
... same as if downloading apps for platform
... for my phone, i get to look up information before i choose to download+install
... am i safe? no
... and once i install, it can finger print me completely

<npdoty> can we be clearer about that attack, fluffy? do we know that it's being used frequently in the wild? is it the kind of attack that works over long periods of time? why do sites still use cookies if it's so trivial?

burn: but i made a trust distinction first
... i'm not sure how we do it
... i'd like to see a way to indicate your trust level in a web site
... i trust X not to be bad to me

<fjh> one approach has been reputation management

burn: i don't trust the rest
... maybe the default is that i go through tor except for ones i trust
... maybe i go through Tor for them

christine: i'm from the Internet Society, co-chair of the Privacy Interest Group
... this is difficult
... i'd be very upset if the answer is "yes, it's a lost cause"
... i don't think it's a lost cause
... we may not solve it completely today
... there's been a suggestion about developing a workshop

<bblfish> my earlier point summarised was: that was ( agreeing with Rigo I think ) that the user should be able to see his privacy level ( there is not even something for cookies currently) - there should be a principal of transparency of identity in the browser. This could allow the browser to understand how much of such passive fingerprinting could be going on.

hsivonen: commenting on WGs deciding if it's worth it
... to decide if it's worth it
... to make tradeoff
... i think it's rather worthless
... even if we started from 0 bits
... after a few WGs decide they get to disclose a few bits

<npdoty> there is a tragedy of the commons problem

hsivonen: then at some point we reach "enough identifiable bits"
... at which point the next WG say "why bother"
... since each user is identifiable
... so they will just expose
... on the idea of using Tor for everything you don't trust
... who wants that UX?
... if you want to put some traffic through Tor to keep it separate from the browser
... you need to put tor in a VM
... that's a shared VM image
... that everyone using Tor uses the same image

<caribou> it's precisely because a WG said "why bother" that we are in this room

hsivonen: and reset everything
... every few minutes
... you lose everything there
... no bookmarks

<dbaron> or every cross-domain redirect

hsivonen: and if you run JS

<wseltzer> TAILS: https://tails.boum.org/ (Tor on a liveCD VM)

hsivonen: potential attackers can see how fast your CPU is
... and see your screen size
... for the thing where you don't
... where attacker can't run JS

<dbaron> or every cross domain link (anchor or embedding)

hsivonen: it might not be futile
... so for everyone who tries to fingerprint may get caught
... if you get caught, it's possible to apply legal solutions
... but if you fingerprint through http headers
... and send back results
... there's no way to audit from outside
... i think it's futile to try to make JS non fingerprintable
... but it might make sense to make pure server side fingerprinting
... make sure there's a risk to get caught
... with social/legal consequences

<bblfish> +1 sounds interesting

<Zakim> wseltzer, you wanted to ask can we ID the features, so a user can choose privacy even at the cost of breakage?

hsivonen: for cache attacks, you need keys by referer origin

<npdoty> I think the detectable client-side fingerprinting also provides the possibility that a concerned user agent could detect or disable it in real-time

wseltzer: i wanted to make more concrete the privacy user UC
... tor provides a browser bundle
... with fingerprintable elements stripped out
... it's based on Firefox
... it's patched to remove features
... Tails liveCD is a VM to load the preconfigured browser+tor
... for users willing to accept a degraded experience
... not the rich web platform
... features depending on Flash Video, scripting
... but anonymous allowing them to post text to a blog
... i'm hardly suggesting it be made a default
... no rich video, no fonts, no user media
... but are there ways we could help Tor developers and others
... to make the anonymous experience
... and give users the experience?

<martin> we're more likely to be informed by those people

wseltzer: could it be recommended that the feature be disablable?
... rather than them having someone decide for them that the rich experience is too good to pass up

burn: this is more about the user be able to say
... there may be ways for specs to provide a way for untrusted sites to get something
... to avoid users getting a 0 experience in that case

hhalpin: a year ago at identity workshop
... the various anonymous browsing modes were brought up
... and their various weaknesses
... it might make sense to get anonymous surfing on browsers stronger
... i've used Tails
... but for many users, the cost is too high

bradh: sounds like we have a higher resolution definition of the problem set
... and questions that need to be dealt with
... if we want to ask spec authors
... realistic profiles of users, and threat models
... that's a lot of work to do
... hope people are passionate to make this possible
... i'll try to make the slides available
... thanks everyone

dom: who would think this is a lost cause?

fluffy: with current research?

<caribou> does browsers' privacy mode change the browser's fingerprint?

dom: is the state of fingerprinting in the browser with the current state so bad, tha making it is futile?
... who doesn't know?

<hta> .... for the case where the attacker gets to run JS in your browser....

tlr: my question is, which question are you asking?
... hsivonen distinguished between active and passive
... they're lost/non-lost in different ways
... is the ability to store data on the client included/compartmentalized?
... there's a few questions here that depending on scope create different answers

dom: thanks for the discussion
... hope there's followup in PIG

bradh: thanks Josh_Soref for scribing

[ applause ]

<tanvi> not sure if the rest of the people weren't answering, or dont think its a lost cause.

<npdoty> +1, suggest that we continue discussion in PING, as it sounds like there are some possible valuable work items related

<caribou> tanvi, or not completely lost

<bhill2> RRSAgent make minutes

<caribou> already done, Brad

- DRAFT -

SV_MEETING_TITLE

31 Oct 2012

Attendees

Contents

Feedback

Summary of Action Items

Scribe.perl diagnostic output