Privacy Interest Group Teleconference -- 15 Jan 2015

<trackbot> Date: 15 January 2015

<moneill2> hi Simon

<tara> Just giving people a few more minutes...

<scribe> scribe: chaals

<rigo> => Darth Doty

<tara> Thanks chaals!

<tara> 1. Welcome and introductions

<tara> 2. Article 29 WP Opinion regarding device fingerprinting [1]

<christine> Regrets, Frank Dawson

<Joanne> aaee is Rebecca

<tara> Thanks for tip!

<npdoty> moneill2: Mike O’Neill

MO'N: Mike O'Neill, normally on TPG group and can't do these calls

<wseltzer> s/Mark/Mike/

CMN: I am chaals, and that is a more or less unique personal identifier so you can find more about me. This is first call

SR: Simon Rice. Group manager of technology team in data regulator in UK

<wseltzer> mkwst: Mike West, Google chrome security team

… Advise the people who make the regulations, so we hope they are technically sound.

Welcome / intros

Article 29

<npdoty> the decision

SR: This is about device fingerprinting. In 2011 the European directive came into force.

… article 5.3 says accessing or storage on the user's device requires consent of the user - the so-called cookie law

… SO now in Europe there is improved attention to this, and to Do Not Track. But it is about information being stored on terminals, not just user data.

<Ryladog> When there is time Simon, what is the name of the DPA in the UK where you work?

… In the last couple of years attention hass been drawn to device fingerprinting. Since it doesn't require storing information as a cookie, the cookie-law is thought not to apply.

… But our case is that this covers any storage, not just HTTP cookies

… So our intent is to clarify that device fingerprinting does require consent.

… The practice is perhaps even more intrusive or anti-user than cookies - at least cookies have a discoverable trace and can be changed.

… It is hard to change a device fingerprint. And it can be generated by different parties.

… So we see fingerprinting being perhaps more intrusive than tracking.

… There are valid exemptions to the requirement for consent under this bit of law. If the use is strictly necessary for something the user asked to do.

… We construe that very narrowly. E.g. If you use a cookie for a shopping basket, that is strictly necessary - and has been explicitly requested.

<moneill2> Simon, logging in (authentication) strictlt nec. also?

… Another exemption is if the storage is for the sole purpose of doing what people have asked to do.

… So we have put out a paper giving some practical guidance, both to site operators and people interested in the policy.

… We highlight things such as Mac addresses of network controllers being necessary and therefore exempt from consent requirements.

… Or if there is a specific requirement for identifying a specific user, such as a bank account.

… And there are categories where we see requirements for consent, such as tracking for online behavioural advertising.

… Under the strict reading, the advertising isn't explicitly requested by the user, so consent is required.

… With Cookies there isn't a huge real risk in the case of 1st party tracking and analytics. Not clear if it is worse in the case of using device fingerprinting.

… So what might be interesting to this group?

… How cookies, fingerprinting, etc can not be misused - how can we provide greater control for the users?

… The browser is a good place to manage cookie preferences. They are difficult to manage, if you have lots of them, but fingerprinting is still far less transparent.

… If we look at geolocation API, and you're asked if you want to let a site get location at will, that's an example of how we can help put users back in control of what is exported.

Tara: Thanks for that overview.

MO'N: Wanted to ask how embedded 3rd parties are viewed. Is it the websites responsibility to get consent for fingerprinting done by the 3rd party?

… And how do you characterise Google analytics, which uses a 1st party cookie then transmits it to another server. Does that require consent?

SR: On the first one, the advice is like the ITO's cookie guidance. It is the party who is processing teh data that has the legal requirement to get the consent, i.e. generally the 3rd party.

… But in most cases the 1st party will share responsibility because they have the interaction with the user.

… So you expect them to say who the 3rd party is...

… If the 1st party incoroporated the 3rd party, it vbecomes the 1st party's responsibility.

… 1st and 3rd parties are not clear terms. Analytics we would view as being done by the website operator.

… It can be the case that Google Analytics does analysis of a single site, but if it is shared across sites we would treat it as a 3rd party.

<Zakim> wseltzer, you wanted to ask if licensing needs to be disclosed

WS: Interested in the second exception - use for licensing or security purposes. Is there required disclosure to the user that the fingerprint will be used?

SR: It is clear in the legislation that the exemption is from the requirement for consent, but the user must still be informed that this is taking place.

KHS:

… Who is the DPA you work for?

<SimonRice> Info commissioner's office

KHS: Couldn't the first party use an SLA with a 3rd party?

SR: It's possible.

… But the legislation isn't about a controller/processor relationship, anyone getting information has the obligations.

CR: We're working on guidance for web spec authors about device fingerprinting.

<Zakim> npdoty, you wanted to ask about header enrichment

ND: Especially interested in the opinion that accessing data on the device for fingerprinting would be the same as storing a cookie.

… My specific question was another way to accomp;ish this - there has been a lot of discussion about header enrichment, inserting data into outgoing traffic.

… which is then read by the webpage, who can correlate it with information stored by the ISP inserting it…

… is that covered?

SR: It isn't accessiing or storing information on the device, but it is interfering with the communications and changing the message.

… So it depends how you read the legislation. There may well be valid exemptions that can be applied there to allow such an operation - the most likely being with the consent of the user.

… But doing it without the user knowing, I suspect is in breach although I can't point to one off-hand in section 5.3 - think it would be in other parts of the legislation.

Hannes: Wondering about enforcement actions for cookie laws.

… Are there any examples of enforcement action?

SR: On the cookie side there have been some fines issued, I believe in Spain.

<npdoty> I’m curious about that too. especially if fingerprinting is also considered under the same directive

… Not the same level as for other privacy infringements, but there has been enforcement action. We have also written strongly-worded letters to website operators and worked with them on making a sufficient effort to get it right.

… So far the softer approach has had the right effect for us.

… Could also happen with device fingerprinting, but it is more difficult when things are done on the server to get evidence of what is happening.

<moneill2> +q

… You can view the traffic leaving the device, but is a screen resolution to optimise layout or fingerprint the device? You need to look into the server to find out, but it hasn't been ruled out.]

<Zakim> rigo, you wanted to ask how would one collect consent for fingerprinting and whether this is covered by the cookie banners

RW: If fingerprinting gets through the 5.3 rule, how is consent handled? Is it sufficient to have it in general usage rules? And how will this change in the new regulation?

SR: In terms of practically getting consent, we don't want a banner to accept cookies, then another for a fingerprint, and another for some more fingerprinting...

… But there is no reason wy a website cannot include device fingerprinting in the same step as consent for cookies - e.g. by increasing the amount of information and scope of the existing request.

<wseltzer> [why shouldn't it be a more onerous exercise, given the greater difficulty of clearing a device fingerprint?]

… In the new regulation, in the ePrivacy directive (europe), the commission are looking at that and may well start a review.

<npdoty> I guess it depends whether we expect “device fingerprinting” to be a common activity for web sites

… Once the data protection directive has gone through its reform process.

MO'N: Just pointing to detecting fingerprinting.

<tara> Sorry, my phone just cut off! Christine, can you step in until I show up again?

… Headers normally don't give enough to detect an individual. Normally you have Javascript in the page doing the work, and normally using cookies.

<npdoty> there is research being done on detecting fingerprinting (a lot in Belgium, for example, I think)

<npdoty> and we consider detectability of fingerprinting a level of success in mitigation

… So that comes clearly under the existing rules. If they didn't use cookies they would have to use e.g. XHR or send the data with a POST. Each of which is detectable.

<mkwst> moneill2, npdoty: Passive fingerprinting techniques (p0f, for example) are fairly advanced.

SR: Sure. You see the traffic going across the wire, or the processing in the browser. It isn't completely covert, but is more complex than looking for a cookie.

… Tying that to processing to determine if it is exempt is therefore also more complicated.

CR: Timecheck.

<wseltzer> p0f -> http://lcamtuf.coredump.cx/p0f3/

<npdoty> I guess it’s harder for us to measure whether purely passive fingerprinting is taking place as frequently :)

CMN: Finding out whether outbound traffic is for legitimate or exempt tracking is orders of magnitude harder than finding cookies

<mkwst> npdoty: harder -> impossible. :)

Tara: Thanks Simon. ANy questions from you to us?

SR: I have been lurking for a while, and wondering about the future. We should get a little more involved. Is there anything we can do there?

Tara: Yes, please participate further.

Article 29 WP Opinion regarding device fingerprinting

Privacy Security questionnaire draft

<tara> the draft questionnaire

MW: Believe you talked about this. It's a strawman questionnaire spec authors should read to understand some possible privacy/security issues their spec might run into.

… haven't touched this since November.

… Seems necessary when we write specs to do a better job reviewing specs early on.

… On Chromium we sometimes find we haven't seen a feature until it has already been implemented which is very late to successfully get changes made.

… Same applies to specs in working groups.

… So we are trying to help groups "self-evaluate" with the questions we would ask if we were doing the review.

<npdoty> are there examples of features that have been rejected for privacy reasons because of that too-late-in-the-process-to-change status? that is a sad outcome for all of us, I think

… The goal isn't to block features, but to help spec authors who aren't privacy experts think about issues.

… This often obviates the need for a review, because the developers figure out the issue before we get there, and ask us the right questions in advance.

… There are a couple of documents floating around with similar ideas. I am not bound to this document, but looking to collaborate, and get a feel for work happening and how we can get together to produce better understanding of impact of features put in specs, and getting the discussion/analysis to happen early in the process rather than when it is too late...

ND: Think this is great work - thanks. Agree that the early review is good, and this is similar to work we have been doing here and collaborating would be good. Hannes has worked on a privacy considerations document.

… Frank Dawson was looking at process implications, and you talk about how to identify topics before the reviewers come along.

<rigo> mkwst: Have you looked into http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/privacy-and-data-protection-by-design ?

[+1 to Nick]

<mkwst> rigo: I haven't. But I will!

MW: Are there specific features that have ???

<npdoty> rejected for implementation because of privacy issues

… There are. In the middle of last year, since blink has ?? mailing list blink-dev we ????. They proposed a feature network service discovery, that gave too much access to network an device info, useful for fingerprinting and targetting specific devices.

<npdoty> Network Service Discovery

<Hannes> My first impression was that the ENISA document is unfortunately not very relevant for this work. It is more a list of PET, which are not necessarily easy to apply at the level of what the W3C does in the specification work

… A mitigation we asked for was a CORS pre-flight check to ensure the device was explicitly participating and *wanted* to be discovered.

… That was a good example of how this was meant to work.

ND: Think we talked to the network service discovery group about these concerns too.

<rigo> Hannes: in the second half of the document, it becomes very concrete and asks the right questions

CR: To reiterate, we decided this call would not have specific discussion of ongoing work items. In February we want to get back onto privacy considerations document and others. It would be useful to have you on that call Mike.

Hannes: I looked at Mike's document - has some good examples that would improve our document.

… happy to work together on stealing his ideas^W^W^W collaborative improvements.

Tara: We were hoping to have Mnot here, but not today.

<npdoty> +1, thanks mkwst and SimonRice

TAG draft finding on HTTP and HTTPS.

<mkwst> I'd also suggest that folks take a look at https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the context of Mark/TAG's document.

CR: Maybe Mark will be available for next call, There has been a lot of discussion on the email list - would be nice if someone can try to gather a summary and work to developing a consensus view...

<npdoty> what is the timing on the TAG item?

WS: Believe the TAG wants to wrap this document before the next PING call. Would urge individuals with comments to share them directly with Mark and the TAG.

MW: TAG document is a relatively high-level position statement.

… Technical implications are being outlined in the Requirements for Powerful Features doc in teh WebApSec document, which will take more time to finish - and feedback on that would be welcome too.

<npdoty> but the HTTPS transition is going to important for privacy, not just on JavaScript APIs

<moneill2> +q

Hot items in the last minute?

<mkwst> npdoty: certainly. but there are certainly privacy implications of APIs like geolocation, which feeds into the desire to restrict them to secure connections.

MO'N: Connected to HTTPS everywhere, there seems to be something going on with a clash between a need for security/privacy and the need for police etc to be able to detect bad things happening.

… can see a train coming through the tunnel

<mkwst> moneill2: In order to monitor a device's communications, the device's owner should exert administrative control and install a trusted root certificate.

<mkwst> (imho)

<tara> Yes, I saw that (Cameron)!

ND: Thinking about related things - Cameron talking about outlawing certain types of encryption out of security fears.

… TAG has talked about this, but there is a question of integrity as well as confidentiality.

… It's also useful for e.g. Header enrichment and the like. Had the discussion in DNT where people are worried about headers being introduced that way.

<npdoty> chaals: social/society making their own decisions, rather than enforced by technologists externally

<npdoty> … important to look at what different societies are trying to achieve, and not make decisions that limit their ability to do so

Next call…

<npdoty> wise words to wrap up for us, chaals

Tara: In about a month, end of February? I am not available mid-Feb. Last week of Feb?

<npdoty> February 19?

<mkwst> wseltzer: "Requirements for Powerful Public Servants"?

<wseltzer> mkwst++

<mkwst> wseltzer: Perhaps we can add a quick deliverable to the webappsec charter? :)

<npdoty> February 26?

CR: Any objections to 26 Feb?

<moneill2> bye

<kboudaou> bye

<npdoty> trackbot, end meeting

- DRAFT -

Privacy Interest Group Teleconference

15 Jan 2015

Attendees

Contents