W3C

- DRAFT -

Privacy Interest Group Teleconference

10 Sep 2018

Attendees

Present
wseltzer, npdoty
Regrets
Chair
SV_MEETING_CHAIR
Scribe
npdoty

Contents


<blase> The slides are also available at the following link if anyone has trouble seeing them in webex: https://docs.google.com/presentation/d/1YhrJK6DC_NemwzWcmvV_EtdM__j44e4zNWz8LclIrAc

<scribe> scribenick: npdoty

tara: introducing our research series, looking at papers that are relevant to PING, especially interested in private browsing modes and fingerprinting

MirandaWei and YuxiWu presenting, work from WWW2018

MirandaWei: might use a private browsing mode in a computer in a public location to look up a piece of information, and prevented others who used the computer later from knowing what you looked at
... users have misconceptions that private browsing modes (pbm) protect them from third-party tracking, IP geolocation, malware
... separate what users think pbm does and what pbm does, and how browser UI communication affects this
... generally pbm is protection from local privacy threats, users who share the machine. typically not protecting from remote privacy threats
... disclosures vary in Chrome Incognito Mode, Brave's Private Mode (longer texts), Opera (short text), Firefox (bullet points)
... mobile apps all have very short disclosures
... survey methodology, of different conditions
... control condition is a "meaningless vague" description

<wseltzer> [slide 13]

yuxi: presenting results of the survey, answers to questions comparing to standard modes

[weiler will record presentation]

yuxi: participant demographics (a typicaly mturk sample, younger than most)

<wseltzer> [slide 16]

yuxi: users correctly identified that history was not saved and that photos were not cached and that downloaded files were still downloaded

<wseltzer> [slide 17]

yuxi: 56% of users thought private mode would separate search queries from a logged in account (incorrectly)
... 25% believed (incorrectly) that IP address was protected as a pbm feature
... 40% believed (incorrectly) that geolocation was prohibited (some because of assumed IP address blocking)

<wseltzer> [slide 18]

yuxi: 27% believed (incorrectly) that virus protection was different

<wseltzer> [slide 19]

<wseltzer> [slide 20]

yuxi: surveyed participants were sometimes incorrect about who could track their online activity in both standard and private browsing mode, but especially likely to believe that pbm protected them from tracking by employer or government

<wseltzer> [slide 21]

yuxi: most real world disclosures were not significantly different from the vague disclosure

<wseltzer> [slide 22]

yuxi: Chrome 59 and Chrome 60 (bullet points) were very slightly more correct

<wseltzer> [slide 24]

yuxi: users answered mostly correctly in areas where they could observe on their own computer without any understanding of the Internet

<wseltzer> "Understanding comes from interaction"

<wseltzer> [slide 25]

yuxi: users provide answers based on the text from the pbm disclosure

<wseltzer> [slide 26]

<wseltzer> [slide 27]

yuxi: users might become habituated to the disclosure, but disclosure is consistently seen and has some significant impact on answers

<wseltzer> [slide 28]

yuxi: future work, explore different (interactive?) ways to explain private browsing mode; what tradeoffs would be in more extensive pbm features

questions?

<wseltzer> [slide 29]

tara: any questions for study folks for w3c folks?

blase: planning to do some followups (on more tangible interpretations of pbm for users). any thoughts?

wseltzer: standards work limited, but could include best practices or in API design
... any useful best practices that could be followed across industry on presentation?

blase: hoping to identify language that works *better*
... some pbm's work differently than others -- features are different, not just language
... Firefox blocks some third-party tracking, but misinterpreted by users
... Opera has an opt-in VPN service
... should we have a consistent "private mode" across browsers
... and then we could identify better language for disclosure across browsers

MirandaWei: the more abstract, the more likely it is to be misinterpreted -- viruses and malware, for example, because they're hard to know when you have them

yuxi: more specificity is better than being vague ("you're protected")

<tara> npdoty: thanks for the data + talk

<tara> npdoty: want to find a baseline of comprehension. People better with things on their computer (visible)

<tara> npdoty: How much is miscomprehension with private mode and how much with general misunderstanding of the internet?

<tara> MirandaWei: we did compare how users understand the browsers in standard vs PBM modes

<blase> If anyone is curious, our paper is at: https://www.blaseur.com/papers/www18privatebrowsing.pdf

<tara> npdoty: in what ways did they get the basic concepts *more* wrong in one mode, for instance?

<tara> MirandaWei: more details in WWW paper

<tara> Blase: you can look at # of people who got concept wrong in standard

<tara> Blase: e.g. -"geolocation can be estimated," (Table 5)

<tara> Blase: designers need to communicate things in a way that doesn't require basic knowledge of the internet technical concepts

jnovak: to what extent do users expect sites to know whether the user is in private browsing mode?

MirandaWei: users could be disturbed -- they shouldn't be able to tell what I'm doing. but not studied in these surveys

weiler: what about the distinction/standardization of terms "incognito" or "private browsing" or "tracking protection"?
... USENIX/SOUPS discussions of cultures where supervision of use on devices was common and circumvention of local observation through pbm was happening

<jnovak> I think that this is the paper that Sam is referring to -- https://www.usenix.org/system/files/conference/soups2018/soups2018-sambasivan.pdf

panyagupta: have not seen work comparing those named modes, although "private" is certainly overloaded in different languages and cultures
... "incognito" is not as commonly used so could be less overloaded, but also less familiar/approachable

yuxi: people may associate "incognito" with google chrome, which could influence answers to questions in the study. that would be a good reason for standardization of what these terms mean

<jnovak> https://www.nytimes.com/2018/06/23/technology/smart-home-devices-domestic-abuse.html

panyagupta: technology and its use in domestic violence; automated locks to exert control, for example
... lots of ways technology can be used to hurt, and monitoring web browsing would be one part of that
... important to be aware of how technology can be used either to cause or combat violence

<weiler> ... There could be negative impacts from making this use case more obvious/clear in the naming.

blase: would "shared device mode" help address the confusion, and in fact prevent the stigma of a private mode, which could be justified for performance rather than an explicit surveillance-protection step

<weiler> ... If the surveillers/controllers before come aware of the the technology and that it can be use to circumvent their efforts.

<MirandaWei> https://petsymposium.org/2018/files/papers/issue4/popets-2018-0029.pdf

MirandaWei: research asked an audience to draw privacy, saw differences in social contexts, including family

<Zakim> wseltzer, you wanted to discuss standardizing around consistent expectations?

wseltzer: would be interested to know what users think private browsing modes *should* do
... privacy community could use help in demonstrating user demand for particular features

yuxi: what users are expecting could be a sign of what users want it to do

blase: user expectations is an imperfect proxy of what users want. early on, how do you frame private mode, maybe seeing an even-more-private mode would help users see what is happening and what they want

<Zakim> npdoty, you wanted to comment on functionality differences and breaking the page

<tara> npdoty: when we have talked PBM and new privacy features, we often talk about tradeoffs

<tara> npdoty: introducing new privacy feature might break/degrade something else

<tara> npdoty: research could help us understand how users see that tradeoff: to what extent are users willing to accept certain tradeoffs (in what contexts)

<tara> npdoty: what users are willing to give up, for instance, for something else

<blase> https://blog.mozilla.org/data/2018/01/26/improving-privacy-without-breaking-the-web/

yuxi: a firefox study for turning on all privacy features and seeing when users turned it off
... there is a point, but it might be a fairly high threshold

tara: glad you have lots of research questions and look forward to seeing in the future
... if standardized, what would it mean to have a standardized core set of features

panyagupta: how often do people actually read the disclosure page?

<tara> weiler: Maybe Mozilla metric might catch that?

[hard to measure]

tara: pleased to have the research presented, thanks!

<blase> Thanks everyone!

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/09/10 19:04:00 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: wseltzer npdoty

WARNING: Fewer than 3 people found for Present list!

Found ScribeNick: npdoty
Inferring Scribes: npdoty

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 10 Sep 2018
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]