├── .gitignore ├── meetings ├── readme.md ├── 2023-09-tpac │ └── breakout │ │ ├── agenda.md │ │ ├── proposal.md │ │ └── slides.html ├── 2021-06-29-agenda.md ├── 2023-07-26-minutes.md ├── 2023-01-11-minutes.md ├── 2023-05-17-minutes.md ├── 2023-08-23-minutes.md ├── 2024-05-22-minutes.md ├── 2023-05-31-minutes.md ├── 2022-12-14-minutes.md ├── 2024-02-28-minutes.md ├── 2023-08-30-minutes.md ├── 2022-06-01-minutes.md ├── 2024-01-31-minutes.md ├── 2024-11-13-minutes.md ├── 2021-10-06-minutes.md ├── 2021-09-22-minutes.md ├── 2022-06-22-minutes.md ├── 2024-02-14-minutes.md ├── 2023-09-20-minutes.md ├── 2023-07-05-minites.md ├── 2023-01-25-minutes.md ├── 2023-11-29-minutes.md ├── 2022-04-13-minutes.md ├── 2023-07-12-minutes.md ├── 2024-01-17-minutes.md ├── 2024-04-24-minutes.md ├── 2022-02-23-minutes.md ├── 2023-08-02-minutes.md ├── 2024-01-10-minutes.md ├── 2022-06-08-minutes.md ├── 2024-03-13-minutes.md ├── 2022-12-07-minutes.md ├── 2023-07-19-minutes.md ├── 2023-12-06-minutes.md ├── 2021-08-18-minutes.md ├── 2022-11-16-minutes.md ├── 2022-06-15-minutes.md ├── 2022-04-20-minutes.md ├── 2023-04-26-minutes.md ├── 2022-07-20-minutes.md ├── 2022-09-07-minutes.md ├── 2023-11-15-minutes.md ├── 2023-02-01-minutes.md ├── 2022-09-28-minutes.md ├── 2022-11-30-minutes.md ├── 2023-01-04-minutes.md ├── 2023-06-28-minutes.md ├── 2024-03-breakouts │ └── slides.html ├── 2023-09-06-minutes.md ├── 2022-08-03-minutes.md └── 2023-04-05-minutes.md ├── .pr-preview.json ├── LICENSE.md ├── CODE_OF_CONDUCT.md ├── .github ├── workflows │ └── auto-publish.yml └── dependabot.yml ├── Makefile ├── README.md └── i18n-checklist-response /.gitignore: -------------------------------------------------------------------------------- 1 | build/ 2 | *~ 3 | -------------------------------------------------------------------------------- /meetings/readme.md: -------------------------------------------------------------------------------- 1 | Task force meeting agendas and minutes. 2 | -------------------------------------------------------------------------------- /.pr-preview.json: -------------------------------------------------------------------------------- 1 | { 2 | "src_file": "index.html", 3 | "type": "respec" 4 | } 5 | -------------------------------------------------------------------------------- /meetings/2023-09-tpac/breakout/agenda.md: -------------------------------------------------------------------------------- 1 | # Agenda 2 | 3 | * What is the Privacy Principles document? 4 | * A few of our favorite parts 5 | * What do you think? 6 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All documents in this Repository are licensed by contributors 2 | under the 3 | [W3C Software and Document License](https://www.w3.org/Consortium/Legal/copyright-software). 4 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code, communication and discussion in this repository are covered by the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/). 4 | -------------------------------------------------------------------------------- /meetings/2021-06-29-agenda.md: -------------------------------------------------------------------------------- 1 | # Privacy Principles Task Force Call 06-29-2021 2 | 3 | ## Agenda 4 | 5 | * Welcome and intros 6 | * Making the repo public 7 | * Working process 8 | * Starting point document 9 | * Merge PR: https://github.com/w3ctag/privacy-principles/pull/4 10 | * Open issues: https://github.com/w3ctag/privacy-principles/issues 11 | * Call schedule going forward 12 | -------------------------------------------------------------------------------- /.github/workflows/auto-publish.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | on: 3 | pull_request: {} 4 | push: 5 | branches: [main] 6 | jobs: 7 | main: 8 | name: Build, Validate and Deploy 9 | runs-on: ubuntu-latest 10 | permissions: 11 | contents: write 12 | steps: 13 | - uses: actions/checkout@v6 14 | - uses: w3c/spec-prod@v2 15 | with: 16 | GH_PAGES_BRANCH: gh-pages 17 | BUILD_FAIL_ON: everything 18 | -------------------------------------------------------------------------------- /.github/dependabot.yml: -------------------------------------------------------------------------------- 1 | # See the documentation at 2 | # https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates 3 | version: 2 4 | updates: 5 | # Update actions used by .github/workflows in this repository. 6 | - package-ecosystem: "github-actions" 7 | directory: "/" 8 | schedule: 9 | interval: "weekly" 10 | groups: 11 | actions-org: # Groups all Github-authored actions into a single PR. 12 | patterns: ["actions/*"] 13 | -------------------------------------------------------------------------------- /meetings/2023-07-26-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 26 July 2023 2 | 3 | Present: Dan, Jeffrey, Wendy 4 | Regrets: Sam, Don, Pete, Amy, Christine, Nick 5 | 6 | ## [Add identifiers to sensitive data list](https://github.com/w3ctag/privacy-principles/pull/338) 7 | 8 | Jeffrey: we could merge... 9 | 10 | Dan: looks ok? 11 | 12 | **merged** 13 | 14 | ## [k-anonymity](https://github.com/w3ctag/privacy-principles/pull/337) 15 | 16 | Jeffrey: Nick should review? 17 | 18 | Dan: I think Nick was in the room when we agreed this so... 19 | 20 | **merged** 21 | 22 | *we adjourn early* 23 | -------------------------------------------------------------------------------- /meetings/2023-09-tpac/breakout/proposal.md: -------------------------------------------------------------------------------- 1 | # Session description 2 | 3 | An open discussion of the [TAG privacy principles draft](https://w3ctag.github.io/privacy-principles/) with its authors. 4 | 5 | # Session goal 6 | 7 | Spread awareness of what's in the document, and gather feedback. 8 | 9 | # Additional session chairs (Optional) 10 | @torgo 11 | 12 | # IRC channel (Optional) 13 | #privacy-principles 14 | 15 | # Who can attend 16 | Anyone may attend (Default) 17 | 18 | # Session duration 19 | 60 minutes 20 | 21 | # Other sessions where we should avoid scheduling conflicts (Optional) 22 | 23 | 24 | # Estimated number of in-person attendees 25 | Don't know (Default) 26 | 27 | # Instructions for meeting planners (Optional) 28 | *No response* 29 | 30 | # Agenda, minutes, slides, etc. 31 | * Agenda: @@ 32 | * Slides: @@ 33 | * Minutes: @@ 34 | -------------------------------------------------------------------------------- /meetings/2023-01-11-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 11 January 2023 2 | 3 | Present: Dan, Jeffrey, Pete, Don, Christine, Nick, Amy, Tess 4 | 5 | Regrets: Robin 6 | 7 | ## [issue triage](https://github.com/w3ctag/privacy-principles/issues) 8 | 9 | Jeffrey: which block us for asking for wide review? We talked about 2 levels of wide review. 10 | 11 | *mark which issues block wide review* 12 | 13 | 71 - closed based on 186 14 | 15 | ## [Fake consent]https://github.com/w3ctag/privacy-principles/issues/192) 16 | 17 | Don: informed consent (legal) vs. "fake consent" which is what most people think of when they think of consent. 18 | 19 | ## Editorial 20 | 21 | Amy: working on an editorial PR - will reference the analysis Robin put together (reading level). Also working on consolidating princples: exactly one principle per section (integrating prose, putting principle at the top). Section-by-section for easier review. 22 | 23 | 24 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | # How to snapshot the Privacy Principles document -*- makefile-gmake -*- 2 | 3 | # This Makefile expects respec and doctoc to be installed, both of which 4 | # may be installed with NPM. Additionally, respec requires you to have 5 | # Google Chrome installed. This Makefile checks for Chrome in the 6 | # default install locations on macOS and Linux. TODO: make this work on 7 | # Windows too. 8 | 9 | .PHONY: all clean update-toc 10 | 11 | all: build/index.html update-toc 12 | 13 | clean: 14 | rm -rf build *~ 15 | 16 | build: 17 | mkdir -p build 18 | 19 | # There has got to be a cleaner way to do this. 20 | PUPPETEER_SKIP_DOWNLOAD = 1 21 | export PUPPETEER_SKIP_DOWNLOAD 22 | CHROME_ON_MAC="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" 23 | CHROME_ON_LINUX="/usr/bin/google-chrome" 24 | build/%.html: %.html Makefile build 25 | if [[ -f $(CHROME_ON_MAC) ]]; then \ 26 | export PUPPETEER_EXECUTABLE_PATH=$(CHROME_ON_MAC); \ 27 | respec --src $< --out $@; \ 28 | fi 29 | if [[ -f $(CHROME_ON_LINUX) ]]; then \ 30 | export PUPPETEER_EXECUTABLE_PATH=$(CHROME_ON_LINUX); \ 31 | respec --src $< --out $@; \ 32 | fi 33 | 34 | update-toc: 35 | doctoc README.md 36 | -------------------------------------------------------------------------------- /meetings/2023-05-17-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Minutes - Wed, 17 May 2023 2 | 3 | * Present: Jeffrey, Robin, Pete 4 | * Regrets: Dan, Amy, Don, Wendy, Sam 5 | 6 | Jeffrey: Can we approve anything with just us 3? 7 | 8 | Merged: 9 | 10 | * https://github.com/w3ctag/privacy-principles/pull/267 11 | * https://github.com/w3ctag/privacy-principles/pull/266 12 | * https://github.com/w3ctag/privacy-principles/pull/265 13 | * https://github.com/w3ctag/privacy-principles/pull/264 14 | 15 | ## [Make it clearer that disloyalty must be detrimental to people #269](https://github.com/w3ctag/privacy-principles/pull/269) 16 | 17 | Jeffrey brings up the https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md holdback option as an example of a browser refusing to provide some information, where providing that information would be in the user's interest, but potentially against the interest of other users or the web overall. Is this disloyal, and is it something browsers should avoid doing? 18 | 19 | Robin suggests filing an issue about using the document to analyze this complicated case. 20 | 21 | ## [Clarifying identity vs legal identity #270](https://github.com/w3ctag/privacy-principles/pull/270) 22 | 23 | Jeffrey: Is eye color part of a legal identity, or is legal identity just the lookup keys? 24 | 25 | Robin: Everything recorded on identity documents is part of the legal identity. 26 | -------------------------------------------------------------------------------- /meetings/2023-08-23-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Task Force - Wed, 23 August 2023 2 | 3 | Present: Dan, Wendy, Don, Jeffrey, Tess 4 | Regrets: Nick, Christine, Amy 5 | 6 | ## [recognition of techniques](https://github.com/w3ctag/privacy-principles/pull/340) 7 | 8 | Jeffrey: the techniques websites use - aren't necesarilly principles - might move to threat model. Also - makes the doc shorter and removes a term Martin objected to. 9 | 10 | Dan: I like short things 11 | 12 | Dan: I'm ok with this. 13 | 14 | *out of band, Nick has said he's good with merging* 15 | 16 | **we decide to merge** 17 | 18 | ## [harrasment](https://github.com/w3ctag/privacy-principles/pull/328) 19 | 20 | *We discussed Nick's comment, split the new principle in 2 and agreed to merge based on that* 21 | 22 | **we decide to merge** 23 | 24 | ## [TPAC Session] ... 25 | 26 | AC ethical documents presentation: Jeffrey will present. 27 | 28 | *Breakout session: Let's brainstorm titles on the Slack and file and issue* 29 | 30 | ## [Sensitive Info & Vulnerability](https://github.com/w3ctag/privacy-principles/pull/326) 31 | 32 | *we go back through the discussion and agree to accept Robin's suggestion with re-ordering and active voice added from Jeffrey* 33 | 34 | ## https://github.com/w3ctag/privacy-principles/pull/324 35 | 36 | *looking at this we agreed we need some time with Amy to walk back the consolidation of principles* 37 | -------------------------------------------------------------------------------- /meetings/2024-05-22-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Task Force Call - 22 May 2024 2 | 3 | Present: Dan, Don, Wendy, Christine, Nick, Robin, Jeffrey 4 | 5 | DKA: Transition requested, with consensus of the TAG. 6 | 7 | Any other business? 8 | 9 | ## Data Portability Threat Model 10 | 11 | Jeffrey: [Data portability threat model issue](https://github.com/w3ctag/privacy-principles/issues/424)... 12 | 13 | Jeffrey: if portability is too easy then hackers can port your data to their systems and get everything at once.. should we say anything about that in the doc? 14 | 15 | Wendy: Lisa is working at the data transfer initiative... https://dtinit.org/about 16 | 17 | Christine: one way to quick-fix is to add "secure"... which was intendned... 18 | 19 | Nick: caveats or details could apply to every data right, but we don't generally go into much detail on how to provide these capabilities in a reasonable way. 20 | 21 | Jeffrey: if they've got a document about this would cite that document... 22 | 23 | Dan: do we need to say secure ... seems out of scope? 24 | 25 | Christine: privacy principles for data portability... maybe we need this - maybe it should be added to the security & privacy questionnaire? 26 | 27 | Jeffrey: my suggestion would be to ask for a citation and then add that to [this part of the doc](https://w3ctag.github.io/privacy-principles/#data-rights). 28 | 29 | Dan: that sounds right. 30 | 31 | *Jeffrey to reply to the issue* 32 | 33 | DKA to handle any questions about the transition request. 34 | -------------------------------------------------------------------------------- /meetings/2023-05-31-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 31 May 2023 2 | 3 | Present: Robin, Don, Pete, Dan, Wendy, Jeffrey, Sam, Tess 4 | 5 | ## [processing is sensitive](https://github.com/w3ctag/privacy-principles/pull/242) 6 | 7 | Robin: only comment that may be contentious is the last one... 8 | 9 | Jeffrey: we say something very similar in the disloyalty PR so this is redundant. 10 | 11 | **no objections to Jeffrey's amendments** 12 | 13 | Pete: privacy labour shhould be mentioned here. 14 | 15 | Jeffrey: good point but separate PR... we can mege and improve further. 16 | 17 | **merged** 18 | 19 | ## [disloyalty](https://github.com/w3ctag/privacy-principles/pull/269) 20 | 21 | Robin: Jeffrey says it's an improvement if not perfect... 22 | 23 | Sam: my eyes getting caught by "in the person's interest" and "potentially conflicts" - lack of parallelism? 24 | 25 | Robin: I think it's intentional. If there's a risk it conflicts the person's interest you're already in hot water. 26 | 27 | Don: you don't know what your downstream interests are with personal information - if this info about me is collecteed and process it may be used to my advantage later, or not. No way to tell if your information is being used in your interest downstream. So we need "potentially" 28 | 29 | Pete: I think we need - 2nd change - previously that said "users" - right? 30 | 31 | Robin: nnnnnn yes. 32 | 33 | Jeffrey: "a person" is too vague. .. responding to Sam's concern - this sentence doesn't define disloaytly - that's 2 sententences before. It says "think about". 34 | 35 | Wendy: unconvoluted ... 36 | 37 | *discussion* 38 | 39 | **merged** 40 | 41 | ## [Clarifying identity vs legal identity](https://github.com/w3ctag/privacy-principles/pull/270) 42 | 43 | **no objections heard** 44 | 45 | ## Wide Review 46 | 47 | Robin: ICO are coordinating to provide feedback... 48 | 49 | ... we're getting close the bottom of the wide review issues. At some point soon we should be comfortable enough to say we have done wide review... 50 | 51 | 52 | -------------------------------------------------------------------------------- /meetings/2022-12-14-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Taskforce - 14 December 2022 2 | 3 | Present: Jeffrey, Pete, Robin, Christine 4 | Regrets: Amy, Dan, Don, Nick, Sam 5 | 6 | ## [missing ref on harassment](https://github.com/w3ctag/privacy-principles/pull/206) 7 | 8 | Trivial addition to the bibliography. 9 | 10 | **merged** 11 | 12 | ## [Guardians](https://github.com/w3ctag/privacy-principles/pull/203) 13 | 14 | Jeffrey: did everything we discussed last week... one suggestion from DON... 15 | 16 | Dan: looks good 17 | 18 | Robin: looks good 19 | 20 | Don: thumbs up 21 | 22 | Peter: thumbs up 23 | 24 | **merging** 25 | 26 | ## [Device owner / user rights](https://github.com/w3ctag/privacy-principles/pull/202) 27 | 28 | Jeffrey: little bit of further change to have these cross-ref eathother... but we should merge first. 29 | 30 | Robin: [i think it's good] 31 | 32 | Jeffrey: a little bit of editing to incorporate the cross-references. 33 | 34 | *agreement to merge* 35 | 36 | **merging** 37 | 38 | ## [Identity](https://github.com/w3ctag/privacy-principles/pull/201) 39 | 40 | Robin: I took all of jeffrey's changes... or made equiv changes... 41 | 42 | Jeffrey: looks good... 43 | 44 | Dan: lgtm 45 | 46 | **merging** 47 | 48 | Robin: closing https://github.com/w3ctag/privacy-principles/pull/186 49 | 50 | ## [Try to explain how new APIs can or can't be justified based on old ones.](https://github.com/w3ctag/privacy-principles/pull/182) 51 | 52 | Jeffrey: I made changes i think it's ready to merge, 53 | 54 | Christine: *wording change on principle* - access to the information acceptable... 55 | 56 | Robin: this looks good. 57 | 58 | **merged** 59 | 60 | 61 | ## Agreement to publish a draft to TR 62 | 63 | **so resolved** 64 | 65 | https://www.w3.org/TR/privacy-principles/ 66 | 67 | Dan: proposal is that we issue a draft in 1st week of Jan... 68 | 69 | Robin: maybe do review pass before updating TR? 70 | 71 | Dan: I think we should do it now and then again in Jan... 72 | 73 | **general agreement to put it on auto-update** 74 | 75 | -------------------------------------------------------------------------------- /meetings/2024-02-28-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Minutes - Wed, 28 February 2024 2 | 3 | Present: Dan, Jeffrey, Robin, Christine, Nick, Pete 4 | Regrets: Don 5 | 6 | ## Working on a session proposal for the [W3C Breakouts Day](https://github.com/w3c/breakouts-day-2024) 7 | 8 | *We work on and submit a session proposal https://github.com/w3c/breakouts-day-2024/issues/16* 9 | 10 | ## PRs 11 | 12 | ### https://github.com/w3ctag/privacy-principles/pull/403 13 | 14 | *agreed to merge* 15 | 16 | ### https://github.com/w3ctag/privacy-principles/pull/407 17 | 18 | Robin: I agree it was intentional but I think the sentence is better without it... 19 | 20 | Jeffrey: we could rephrase or we could just take the PR... 21 | 22 | Robin: I think taking the PR makes it clearer. 23 | 24 | Dan: +1 25 | 26 | *some wordsmithing* 27 | 28 | *we agree to merge* 29 | 30 | ### https://github.com/w3ctag/privacy-principles/pull/408 31 | 32 | *We agree to make some of this - specifically the oxford commas* 33 | 34 | ## https://github.com/w3ctag/privacy-principles/issues/406 35 | 36 | Jeffrey: not sure we can do better.... 37 | 38 | Robin: we can be more formal... however that doesn't help (as will be more complex). 39 | 40 | *Jeffrey will work on a PR* 41 | 42 | ## https://github.com/w3ctag/privacy-principles/issues/405 43 | 44 | Jeffrey: I feel that we *do* focus on opt out... The basic idea is that everything should be in context... we do say that... We could ask "what sentences do you think have this problem"? 45 | 46 | Nick: Don provided good context here, and I do think there's been an attempt at trying to support in-context opt-in style engagement. so there's a good chance for overlap here and worth asking for more suggestions. 47 | 48 | *Jeffrey to engage* 49 | 50 | ## https://github.com/w3ctag/privacy-principles/issues/401 51 | 52 | Jeffrey: I replied.. I think we're good here... 53 | 54 | *we agree to put off closing it and seek chris's feedback* 55 | 56 | ## Wide review 57 | 58 | *we note that we've done wide review, documented in issue 217* 59 | -------------------------------------------------------------------------------- /meetings/2023-08-30-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 30 August 2023 2 | 3 | Present: Dan, Jeffrey, Nick (& Forest), Don, Robin 4 | 5 | ## TPAC breakout 6 | 7 | https://github.com/w3ctag/privacy-principles/pull/342 8 | 9 | ## TPAC presentation 10 | 11 | * Part of https://www.w3.org/2023/09/TPAC/ac-agenda.html / Values-based documents. 12 | * Jeffrey presenting 13 | * 6 minutes; I'll send slides by next week. 14 | 15 | ## https://github.com/w3ctag/privacy-principles/pull/334 16 | 17 | Robin: agree with the comments.. next step is to 18 | 19 | *Robin to go through it and clean it up* 20 | 21 | ## https://github.com/w3ctag/privacy-principles/pull/326 22 | 23 | Jeffrey: noting a conflict ... "revoked" - martin complained that information can't be revoked... 24 | 25 | Dan: Yes I think that makes sense... 26 | 27 | Nick: ...does it remove separate principle text of guardaians & wards?... I guess it's fine. 28 | 29 | **no objections noted to squashing** 30 | 31 | **so squashed** 32 | 33 | ## https://github.com/w3ctag/privacy-principles/pull/325 34 | 35 | Don: I'm concerned we're leaving the surevillance advertising industry an out because they can claim that surveillance advertising / relevant advertising is in the user interest. You can claim that cross-context behavioral advertising raises web sites' revenue so therefore it's in the user's interest (because they receive more ad-supported content than they would without it) 36 | 37 | Jeffrey: sometimes we have to balance different user interests... 38 | 39 | Robin: Some people will always make claims about indirect user benefits and use potentially dubious research in support of that. We can't pre-emptively address bad faith. 40 | 41 | Dan: is there something we can say about "direct vs. indirect user benefit"... 42 | 43 | Don: cross-site tracking has multiple effects on the market for web ads, some of the literature only captures one side (higher revenue where a cookie is present than not present) and not the other side (cross-site tracking artificially increases supply of ad inventory by making sites that are harmful to users monetizable) 44 | 45 | Jeffrey: all of this is separate from the changes in 325... 46 | 47 | -------------------------------------------------------------------------------- /meetings/2022-06-01-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Call - Wed, 01 June 2022 2 | 3 | Present: Wendy, Nick, Pete, Don, Tess, Robin 4 | Regrets: Dan 5 | 6 | ## Agenda 7 | 8 | Where we're going, we don't need agendas… 9 | 10 | 11 | ### deployability and monitoring: https://github.com/w3ctag/design-principles/issues/368 12 | 13 | PS: We should chat to Yoav about whether that might make more sense here. 14 | 15 | RB: I'll suggest that in the issue. 16 | 17 | Nick: it could be reasonable that there might be some kind of measurement data that people would be okay with, or might consent to, or even some collective governance. There is plausibly some data that could be shared under some conditions. 18 | 19 | Pete: I don't disagree with any of that, but should and conditions are doing a lot of work there. So long as there is a significant group of people who don't want this it shouldn't be the default and we should be doing the work to figure out what the conditions are that constrain the principle. 20 | 21 | Nick: I agree that something should be written about this. 22 | 23 | Pete: Jeffrey took an action on this I think. 24 | 25 | Robin: We should be mindful of not letting editors take on too much work. 26 | 27 | Nick: I can take a stab at it. 28 | 29 | Pete: We should ask Shubie's input too. Nick: +1. 30 | 31 | Robin: This issue connects well with our discussion of whether telemetry should be permissible. 32 | 33 | ### Feedback 34 | 35 | Robin: not a lot of feedback, some tone/structure conversation via mnot 36 | 37 | generally positive review from patcg, useful foundation for other work there 38 | 39 | Nick: Do we want to be more active? 40 | 41 | Robin: I think the question is at what point we reach out to constituencies that aren't the usual ones? 42 | 43 | Nick: I want to do it but we might need it to be more fleshed out. 44 | 45 | Robin: That might be a way to pare down the issues list and prioritise what we should do. 46 | 47 | Nick: I think a good focus would be to write the sections that aren't written. We need better than "we know that's an issue." particularly, for example, on vulnerable people 48 | 49 | ### Vulnerable People 50 | 51 | Nick: Is anyone working on this? 52 | 53 | Tess: I'm doing a lot of research and at some point I will write something! 54 | -------------------------------------------------------------------------------- /meetings/2024-01-31-minutes.md: -------------------------------------------------------------------------------- 1 | # W3C TAG Privacy TF - Wed, 31 January 2024 2 | 3 | Present: Don, Pete, Dan, Robin, Nick, Wendy, Amy 4 | 5 | Regrets: Jeffrey 6 | 7 | ## FYI on privacy-related changes to the design principles from last week's TAG F2F 8 | 9 | Nick: how to decide when to include a privacy principle in the design principles? 10 | Dan: some seem particularly fundamental, and so use those in an abbreviated form in the design principles, with references to longer text in privacy principles document. 11 | 12 | every-other week TAG plenary calls, which will alternate with privacy taskforce calls. 13 | 14 | ### [Data minimization](https://github.com/w3ctag/design-principles/pull/465) 15 | 16 | https://w3ctag.github.io/design-principles/#data-minimization 17 | 18 | Link to privacy principles from design principles. "Minimize user data", and picked font enumeration api as an example where data minimization came up with a different solution. Also links to "personal data" definition in privacy principles. 19 | 20 | Pete: Tess article about how to introduce data to a web page ... (group is unclear on where exactly that was.) 21 | 22 | Pete: data minimization is also already in the design principles, in device enumeration. 23 | 24 | ### [identity](https://github.com/w3ctag/design-principles/pull/396) 25 | 26 | PR from Amy, still working/reviewing. 27 | 28 | ### [devices etc..](https://github.com/w3ctag/design-principles/pull/470) 29 | 30 | Dan: use care when exposing identifying information about devices, don't distinguish between not having the capability and the user rejecting it. 31 | 32 | Don: a lot of web developers already know which devices have which sensors. maybe just say 'don't design for a specific device' (or avoid collecting any info on what device the user is using?) 33 | 34 | Dan: there are concepts about progressive enhancement, like feature detection, or supporting all devices 35 | 36 | ## [edit to privacy principles data minimization](https://github.com/w3ctag/privacy-principles/pull/399) 37 | 38 | Just removed repeated text, that Dan noted while working on design principles/minimization. 39 | 40 | Nick and wseltzer: +1 41 | 42 | **merged** 43 | 44 | ## next steps 45 | 46 | Dan to email AC before end of the week. hope to get some good feedback. 47 | 48 | -------------------------------------------------------------------------------- /meetings/2024-11-13-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Call - Wed 13 November 2024 2 | 3 | Present: Dan, Tara, Jeffrey, Don, Yves, Wendy 4 | 5 | Regrets: Pete, Nick 6 | 7 | https://github.com/w3ctag/privacy-principles/issues/431 collects all the PRs we need to review. 8 | 9 | ### https://github.com/w3ctag/privacy-principles/pull/432 10 | 11 | *we review and agree to merge* 12 | 13 | ### https://github.com/w3ctag/privacy-principles/pull/444 14 | 15 | *we leave it unmerged* 16 | 17 | ### https://github.com/w3ctag/privacy-principles/pull/441 18 | 19 | Jeffrey: the objection is broad - but in the conversation it seemed like they wanted us to point out that people should consult local regulations... instead of assuming that we described everything. 20 | 21 | *we agree to wendy's [suggestion](https://github.com/w3ctag/privacy-principles/pull/441/files#r1813083399)* 22 | 23 | *and agree to merge* 24 | 25 | ### https://github.com/w3ctag/privacy-principles/pull/442 26 | 27 | Don: giving users ability to tag info as sensitive is not especially useful (because it is possible to infer sensitive information from data that appears non-sensitive) 28 | 29 | *noting Martin's [comment](https://github.com/w3ctag/privacy-principles/pull/442/files#r1779902987) that this implies privacy labor* 30 | 31 | *consensus not to do this for various reasons including above* 32 | 33 | ### https://github.com/w3ctag/privacy-principles/issues/449 34 | 35 | Jeffrey: we've had discussions in the GPC context of whether a global opt-out overrides specific agreements. Consensus may be emerging in privacy CG that if you have a specific agreement that this should override the global signal. (https://github.com/privacycg/gpc-spec/issues/80) Should we therefore make a change in the privacy principles? My sense is to leave it for this version. 36 | 37 | Dan: agree with not doing anything... Also I don't think this will make our lives easier in council. 38 | 39 | Tara: I would leave it in the understanding that this is going to be revisited... (once GPC is further developed.) 40 | 41 | ### Agreement to "send this to council" 42 | 43 | Yves: the issue with the documentation included is good... 44 | 45 | *Yves to pursue the objector.* 46 | 47 | *Yves to shuttle the current editors' draft out to /TR space.* 48 | 49 | *Jeffrey to fix something in the summary by end of today.* 50 | -------------------------------------------------------------------------------- /meetings/2021-10-06-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF 2 | 3 | 6 October 2021 4 | 5 | Present: Wendy, Dan, Tess, Robin, Don 6 | 7 | [pr30](https://github.com/w3ctag/privacy-principles/pull/30) 8 | 9 | Robin: jeffrey had a bunch of comments to discuss... not ready to merge... 10 | 11 | [pr57](https://github.com/w3ctag/privacy-principles/pull/57) 12 | 13 | **merged** 14 | 15 | [pr56](https://github.com/w3ctag/privacy-principles/pull/56) 16 | 17 | Dan: I don't think this meme works very well in an august document. Let's remove it, and bring back a meme when we find one that fits better. 18 | 19 | Don: Can open an issue to translate the whole document to memes. https://github.com/w3ctag/privacy-principles/issues/58 20 | 21 | **agreed no meme for now, sorry robin** 22 | 23 | [pr55](https://github.com/w3ctag/privacy-principles/pull/55) 24 | 25 | Tess: agree this is more readible. 26 | 27 | Jeffrey: it looks good but would like time to read it. 28 | 29 | **jeffrey to merge it if he's happy with it** 30 | 31 | [pr38](https://github.com/w3ctag/privacy-principles/pull/38) 32 | 33 | DA: Still need updates from Pete 34 | 35 | [pr40](https://github.com/w3ctag/privacy-principles/pull/40) 36 | 37 | DA: We looked at this last week, any updates? 38 | 39 | JY: I think things are ready, I didn't get new review from CR but I think I got the changes she wanted done. 40 | 41 | DA: In the interest of moving things along, should we review this and merge. 42 | 43 | TO: Jeffrey if you review Fiduciary, we review this, and that moves it all along. 44 | 45 | Group: great idea (discussed directly in GH) 46 | 47 | **PR 40 Merged** after approval of editorial changes from group. 48 | 49 | [pr53](https://github.com/w3ctag/privacy-principles/pull/53) 50 | 51 | Obviousness of identity as seen by a site 52 | 53 | DM: Make it clear to a user if their identity is known to a site. We discussed this last week. 54 | 55 | JY: I'm uncomfortable putting should requirements on a UA when it can't because it doesn't know about the consent. 56 | 57 | DM: What if the user provided consent out of band, the UA has no way of knowing and reminding the user. We could open an 58 | issue to make sure that the UA is not responsible to search for consent of which it is not aware and merge as is? 59 | 60 | JY: I'm OK with with that. There's an ongoing project in that document of separating the truth from what the UA knows 61 | about. 62 | 63 | RB: I like putting it that way, we should write that. 64 | 65 | DA: Merge? 66 | 67 | DM: Yes, let's merge and issue. 68 | 69 | DA: Any other issues? We have some new issues to look at. 70 | 71 | WS: Noting conversation in the Improving Web Advertising BG: https://www.w3.org/2021/09/14-web-adv-minutes.html 72 | 73 | Group discusses potential future work on Contextual Integrity. 74 | -------------------------------------------------------------------------------- /meetings/2021-09-22-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Taskforce Minutes - 22 September 2021 2 | 3 | Present: Dan, Sam, Don, Christine, Robin, Jeffrey 4 | 5 | Regrets: Amy, Jonathan, Peter 6 | 7 | ## Minutes 8 | 9 | ### [PR on personal data](https://github.com/w3ctag/privacy-principles/pull/30) 10 | 11 | Robin : inconstency in def of personal data - the def listed identifiers, but forgot to say "data attached to one of those identifiers" - which is important. That's where the weirdness came from... I'd like people to look at it before we merge it. It's fraught and complicated to define personal data but we shouldn't do it lightly. 12 | 13 | [group to review] 14 | 15 | ### Parties 16 | 17 | [PR44](https://github.com/w3ctag/privacy-principles/pull/44) 18 | 19 | Christine: i looked at it again - i don't think i can form an oponion until i see how it plays out in the document? 20 | 21 | Robin: I like it - but also this is a new way of looking at party... I would be comfortable taking it and flagging it as something to review to see if it fits... 22 | 23 | Don: Accept it but open up an issue to read through the whole doc to see how this definition of party flows with everything else we're saying. 24 | 25 | Jeffrey: this sounds fine to me. 26 | 27 | Tess: it seems good to me. 28 | 29 | Dan: Let's merge it, then open up a new issue where we explicitly give ourselves a task to re-review it in 2 months' time or somehting... Should we ask for community feedback? 30 | 31 | Robin: [merges] 32 | 33 | Don: First party sets ongoing debate will be looking at this itently. That might be an inetresting community. 34 | 35 | Jeffrey: [closes the 32 and 43] 36 | 37 | ### [Rewrite SotD according to style guide #45](https://github.com/w3ctag/privacy-principles/pull/45) 38 | 39 | Tess: question - the first change - isn't it the TAG that publishes draft findings? Task force provides text to the TAG. 40 | 41 | [we wordsmith the SotD] 42 | 43 | Christine: No normative content? 44 | 45 | Tess: that sentence is a term of art in spec land - could we rework it to be not confusing? 46 | 47 | Robin: this doc does not contain any RFC-2119 content? 48 | 49 | Christine: I imagine we'll be recommending best practices - some of those will be "this is a good idea" - some will be "you should do this" or "you should never do this" - but the expectation is that they will be followed. 50 | 51 | Tess: reminds me of the rendering section of the HTML spec - it has to say a bunch of normative things without using normative terms. we can do the same thing here. If the best practice says "never do x" we can say it in a way that doesn't use 2119 terms - but there are more natural ways to say it. Proposal "This documennt does not contain any normative statements in the RFC2119 sense." 52 | 53 | Sam: just use normative. 54 | 55 | Christine: we need to signal - even if it's not normative in a technical sense, spec authors will be expected to follow this guidance... 56 | 57 | Dan: process of TAG review 58 | 59 | Tess: we also will be elevating this to a w3c statement - not just the tag's moral authority behind it. 60 | 61 | Robin: let's nuke that sentence. 62 | 63 | [sold] 64 | 65 | **merged** 66 | 67 | ### [46](https://github.com/w3ctag/privacy-principles/pull/46) 68 | 69 | [wordsmithed] 70 | 71 | **merged** 72 | 73 | 74 | 75 | -------------------------------------------------------------------------------- /meetings/2022-06-22-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG privacy TF Call - 22 June 2022 2 | 3 | Present: Dan, Don, Wendy, Nick, Pete, Sam, Jonathan, Robin 4 | Regrets: Christine, Shubhie, Amy 5 | 6 | 7 | 8 | ## https://github.com/w3ctag/privacy-principles/pull/167 9 | 10 | Pete: we discussed changes to those - and I discussed them with Kyle. I was on the hook to ask him to make those changes. I think the current text is good. If we're happy let's hit merge. 11 | 12 | Don: I thinl 167 is good as is... 13 | 14 | Robin: Yeah - I would add a comma before the "or". 15 | 16 | Dan: Ok let's go ahead and merge? 17 | 18 | **merged** 19 | 20 | ## https://github.com/w3ctag/privacy-principles/pull/166 21 | 22 | Don: also looks good - I like getting it into the doc - Yes you do have the right to surf the web as if you are [another persona]. 23 | 24 | Nick: it says "it should assume by default"... looks like intended to be a principel but not sure it's a good assumption. 25 | 26 | Nick: i think it's intended to be a principle about data minimisation - i'm not sure it's a good way to describe it. 27 | 28 | Robin: I agree with what he's trying to say - but a lot riding on "by default". I also want the ability to share more. Probably a way to say that differently. 29 | 30 | Nick: maybe cut and paste that text in whatever we do about data minimization? 31 | 32 | Robin: tempted to cut and paste a piece we like and reject the PR. 33 | 34 | Nick: suggesting we copy and paste the other piece just so we don't lose it? 35 | 36 | Robin: I make an issue of the bottom thing - and I will cut and paste the thing we like and reject the PR but [in a nice way]. 37 | 38 | Dan: can you mark your PR as having provenance from Kyle so that he gets "credit" as a contributor? 39 | 40 | Robin: yes. 41 | 42 | ## https://github.com/w3ctag/privacy-principles/pull/170 43 | 44 | Nick: we discussed data minimisation - the motivating context for pete's text - and should be a general strategy - and there was previous work in the TAG - never formally a finding - about data minimisation. I thought we should take out the API design principles from that and put it here. Might make it more actionable for API designers. 45 | 46 | Dan: I'm supportive. 47 | 48 | Robin: that sounds like a good plan. 49 | 50 | Nick: this is in the personal data section... do we want to keep it there or have data minimisation as a separate thing? 51 | 52 | Robin: I think it's worth breaking it out... I'm trying to walk through this doc as a typical standards editor looking for something to reference... looking at principles I would not think of going to personal data for that. Strategies ... ? 53 | 54 | Nick: I had [Issue 118](https://github.com/w3ctag/privacy-principles/issues/118) - mitigations... I think having "data minimisation" in the ToC would be good. 55 | 56 | Robin: The idea of having principles discussed and strategies - might work well - could be some reshuffling there... having a section on very concrete things you can do with APIs... is good. For example a principle "support people's autonomy" and strategy for implementing. 57 | 58 | Dan: design principles - as an example as document web api designers have engaged with and had good feedback on. 59 | 60 | ## Issues Triage 61 | 62 | Robin: we need to do some issues triage... 63 | 64 | Dan: can we tick through those in next week's call. 65 | -------------------------------------------------------------------------------- /meetings/2024-02-14-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 14 February 2024 2 | 3 | Present: Dan, Jeffrey, Don, Nick, Wendy 4 | 5 | Dan: breakout session on Privacy Principles could be useful 6 | 7 | Dan: at AC meeting, will provide a TAG update, including Privacy Principles and statement track 8 | 9 | Dan: noting https://undocs.org/en/A/HRC/53/42 that highlights how technical standards bodies need to consider human rights implications... 10 | 11 | Nick: some recommendations about getting more inclusive participation .. and actively reviewing... and direct human rights obligations for SDOs, as well as businesses and states 12 | 13 | Don: also covering algorithmic discrimination... 14 | 15 | Don: the whole web advertising problem... if you have one step that discriminates then all the steps learn that ... 16 | 17 | Dan: so ML can amplify discriminitory behaviour (if one person on the path to making a sale is making decisions based on prejudice, the ML steps before the sale will "learn" to optimize for that person's decision-making, so the prejudice in effect spreads to ML that was not intentionally trained to discriminate) 18 | 19 | ## [vulnerable people](https://github.com/w3ctag/privacy-principles/pull/402/files) 20 | 21 | Jeffrey: worried about how to apply the fact that an actor might not know if someone is vulnerable... 22 | 23 | Don: Since you don't know if a person might be vulnerable you might have to code on the safe side--you can't prove that a person is not a vulnerable person. 24 | 25 | Wendy: at least 2 contexts - one is deliberately taking advantage of a person because of known vulnerability and another is across the board taking advantage of everyone... the principles should warn against the first... and help us think through for the 2nd... we don't want to recommend age verification everywhere... which is one recommendation that some regulators make against that problem. 26 | 27 | Jeffrey: I'd like to elaborate on the 2nd category... a lot of companies will write their systems to get the most benefit to themselves... for vulnerable counterparty they will accept more... so there might be something about "try to do what's right and don't just get the most advantage for yourself"... 28 | 29 | Nick: I noticed that.. you can't guarantee that an actor will know - but some may read that and say they can skip this section... 30 | 31 | Dan: do we need an additional principle here? 32 | 33 | Don: might go back to a previous point on power imbalances... if you're in position to develop a system to exploit a power imbalance then don't do that. That's ambitious but there still might be a principle on "not coding to increase power imbalance"... 34 | 35 | Nick: there are some principles that talk about vulnerable people... it seems find to merge though... but maybe there is some additional principle to data min, etc... but those are already related... 36 | 37 | **merged** 38 | 39 | ## [honesty](https://github.com/w3ctag/privacy-principles/issues/401) 40 | 41 | Dan: I agree with losing the try 42 | 43 | Jeffrey: yes but ... e.g. the user agent could give the user lots of info about the TLS conbection.. but most users will not understand that .. so probably not a good idea for the UA to give them that info... 44 | 45 | *we discuss a potential response* 46 | 47 | Jeffrey: also i want to mention this section on UA's could stand alone as a dedicated document... 48 | -------------------------------------------------------------------------------- /meetings/2023-09-20-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Minutes - Wed, 20 Sep 2023 2 | 3 | * Present: Christine, Wendy, Jeffrey, Pete, Robin, Nick (& Forest), Don 4 | * Regrets: Dan 5 | 6 | ## Add privacy principles to charters? 7 | 8 | Christine: The ethical principles are still a draft note, so referring to draft notes must be ok. 9 | 10 | Pete: Resolve the concern about ancillary data first. 11 | 12 | Jeffrey: Let's give it to the TAG and let them make this call. But then we still have to decide when to give it to the TAG. 13 | 14 | Christine: As a group, could we aim to do that by the end of the year? That'll give us a deadline. 15 | 16 | Jeffrey: I even said we'd do that in my AC talk. Any other considerations beyond ancillary data? 17 | 18 | Nick: what's the holdup on ancillary data 19 | 20 | Pete: I think we're waiting for more from Yoav on his concerns 21 | 22 | Jeffrey: I'm going to set up a meeting with Yoav 23 | 24 | Nick: Issue? 25 | 26 | Pete: [220](https://github.com/w3ctag/privacy-principles/issues/220), [273](https://github.com/w3ctag/privacy-principles/issues/273), and a PR. I'll try to consolidate the references 27 | 28 | 29 | ## [PRs](https://github.com/w3ctag/privacy-principles/pulls?q=is%3Aopen+is%3Apr+sort%3Acreated-asc) 30 | 31 | ### [transparency section #288](https://github.com/w3ctag/privacy-principles/pull/288) 32 | 33 | Nick: In response to questions about ambiguity and passive voice, I changed the principle to "sites should provide relevant infomration, and UAs should help people consume relevant information". Clarified that relevant explanatory information is different from the information that's consumed. Not sure there's anything remaining. Jeffrey had a question about whether this required browsers to present information in the permission prompt, but we agree it doesn't require that. 34 | 35 | Jeffrey: haven't re-reviewed, but it was pretty close already 36 | 37 | Pete: a few minor wording changes 38 | 39 | Nick: feel free to wordsmith in the PR 40 | 41 | Jeffrey: can we agree to merge after a set of people approve? Pete and me? Any objections. 42 | 43 | [no objections] 44 | 45 | Jeffrey: also note the merge conflicts. Maybe it got moved. 46 | 47 | ## Post TPAC 48 | 49 | Jeffrey: noted at TPAC, we should mark which sections apply to which audiences. That's probably an edit to Robin's JS. 50 | 51 | Robin: Separating by target audience needs some data 52 | 53 | Jeffrey: we can set a class on each for audiences. I can draft a PR 54 | 55 | Robin: if you do that, I can work on a script 56 | 57 | Jeffrey: or data. [discussion of how to accomplish the listing at the top] 58 | 59 | Nick: anything else as feedback from TPAC 60 | 61 | Robin: it's too complicated 62 | 63 | Don: The IAB makes long industry standards PDFs and also implementers' guides. We could consider an implementers' guide. 64 | 65 | Nick: This isn't really for implementers, but maybe a summary version. 66 | 67 | Robin: There's some translation to something like a TAG questionnaire that could be interested. Wouldn't make it as a document, but rather a decision tree. With links to know more. 68 | 69 | Don: Guides for different audiences. Like for site maintainers. Browser side probably needs to read the whole document. Focus on what website maintainers need to know about privacy principles. 70 | 71 | Nick: I could see that. 72 | 73 | Jeffrey: Glad Don has volunteered to write it. 74 | -------------------------------------------------------------------------------- /meetings/2023-07-05-minites.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 5 July 2023 2 | 3 | Present: Dan, Jeffrey, Don, Nick, Christine, Amy 4 | Regrets: Robin, Pete 5 | 6 | ## https://github.com/w3ctag/privacy-principles/pull/290 7 | 8 | Don: I think I addressed all of robin's comments .. should match up. 9 | 10 | Nick: looks more in line... 11 | 12 | Jeffrey: looks good. 13 | 14 | Dan: I'm good. 15 | 16 | **agree to merge** 17 | 18 | ## https://github.com/w3ctag/privacy-principles/pull/322 19 | 20 | Nick: not sure if it's "just as much" - i think it is "also" 21 | 22 | Don: users are not aware of corporate M&A news... Expecting people to read techcrunch to understand how their personal data is used.. is not reasonable. 23 | 24 | Amy: that was in the original thing. 25 | 26 | Nick: I think the re-ordering seems good. 27 | 28 | Don: I'll make a note that we cover contexts and not companies or parties... 29 | 30 | **noting robin approval** 31 | 32 | **agree to commit suggestions and merge** 33 | 34 | ## https://github.com/w3ctag/privacy-principles/pull/323 35 | 36 | *need review* 37 | 38 | ## https://github.com/w3ctag/privacy-principles/pull/324 39 | 40 | **noting robin approval** 41 | 42 | Amy: changed a principle to explanatory text - "seek to understand" - 43 | 44 | Nick: I think the reason we had it separate was that we wanted to affirmatively say "you shouldn't seek this out" - not just do something in alignment with goals... Problem we're coming up against here... everyone has their own view - we can say "yes you can go ask them". 45 | 46 | Amy: worthsmithed ... sentennce to try to address. 47 | 48 | Dan: If it can be colapsed into one principle then it could be a good thing at this point for simplicity. 49 | 50 | Jeffrey: removes some text that pete liked so don't want to merge without Pete's eyes on it. Immediate goals... I want Pete to have the chance to look over it. 51 | 52 | Amy: will do another edit pass. 53 | 54 | Nick: I'm ok with it... 55 | 56 | *candidate for async merger based on reviews* 57 | 58 | ## https://github.com/w3ctag/privacy-principles/pull/328 59 | 60 | Nick: I think it's good consolodate... I think we should still have separate defintiions... 61 | 62 | Jeffrey: if we say abuse the folks who handle abuse of servers - may think it applies to them. 63 | 64 | Amy: would a definition help? 65 | 66 | Jeffrey: probably - people need to see it. We could title it "abuse of users" 67 | 68 | Don: I like that. Abuse is overloaded. 69 | 70 | Amy: I've thought of editing the titles to be more actionable. 71 | 72 | Dan: totally agree with making things more actionable. 73 | 74 | Amy: "protecting users"... 75 | 76 | ## https://github.com/w3ctag/privacy-principles/pull/326 77 | 78 | Amy: merge these sections maybe? Sensitive info didn't have a principle. I created one. Seems an important principle - we come across it when doing TAG reviews as well... "actors should know that..." 79 | 80 | NicK; if inn many reviews we're going to point this out... then it can be cited. Not sure if that makes it a principle... 81 | 82 | Amy: because of this principle don't do this... 83 | 84 | Jeeffrey: don't design features assuming that particular info is not sensitive 85 | 86 | Amy: assuming some info is sensitive / not sensitive... 87 | 88 | Don: you can't say in advance what data points are going to be picked up on as sensitive by downstream actors 89 | 90 | Nick: still not sure if this needs to be a principle. 91 | 92 | Amy: feel strongly this should be a principle... 93 | 94 | 95 | -------------------------------------------------------------------------------- /meetings/2023-01-25-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 25 January 2023 2 | 3 | present: Dan, Pete, Robin, Don, Christine, Nick, Jeffrey, Sam, Wendy, Tess 4 | Regrets: Amy 5 | 6 | ## Progress on the milestone 7 | 8 | ## https://github.com/w3ctag/privacy-principles/pull/214 9 | 10 | JY: changes a citation ... should be straightforward 11 | 12 | ## https://github.com/w3ctag/privacy-principles/pull/215 13 | 14 | DM: We discussed at the last meeting - UA has an obligation to act on behalf of the user - even regarding aggregated data. If sharing the data would advance the interest of the user then UA should do it - but not act against the interest of the user. 15 | 16 | Pete: some overlap with #216 17 | 18 | Sam: looks good on its own, though I wish it had an Oxford comma 19 | 20 | Nick: not sure I follow the example... if we want to say something about web advertising maybe we get into that in more detail? what do we conclude from this? actionable example? 21 | 22 | DM: if we could do a seperate advertising-related doc we could start that but not sure we have the mandate. Still concerned that UAs would filter ... either act on the interest of the user or.. apply math that conceals the user's identity. I think it's important that "always acting in the interest of the user" is a must. 23 | 24 | Pete: I think the principle is already expressed.. I think we need to tweak it a little.. necessary but not sufficient condition. Also I don't think advertising should be part of this doc. 25 | 26 | JY: I like the overall idea of the para but I think we can make it shorter - and shorter would be worth having. 27 | 28 | DM: I understand ... implied from the rest of the docs .. but intense set of commercial interests... trying to push the limits of what client softwate can do in the interest of other parties.. implied is not enough, needs to be clear. 29 | 30 | ## https://github.com/w3ctag/privacy-principles/pull/216 31 | 32 | Pete: Don's point ... only in the user's inetrest. Also effort to remove text that isn't vital to the section... also browsers should only share in line with user's interest. 33 | 34 | JY: I like the new principle. 35 | 36 | RB: I like the principle too... 37 | 38 | Nick: Not persuaded that rewrite is necessary... I don't mind the additional principle but I think it restates things elsewhere.. We have an open issue on aggregate data #165 - but these edits are not about 165. These are more about 150 and 182. 39 | 40 | *we agree not to merge right now but to work in the PR* 41 | 42 | Sam: propose to merge #215 now and rebase #216 43 | 44 | Jeffrey: I just proposed a big change to #215. Would rather merge 215 into 216. I'm not sure people will support that change. 45 | 46 | Don: I'm fine with Jeffrey's change to 215 47 | 48 | Dan: so bring that into 216? 49 | 50 | Don: Sure. reject 215, move to 216. 51 | 52 | ## Closing issues 53 | 54 | Robin: close 187 and 165 and 98? 98 is from an old MNot issue; text has been changed, maybe not enough? 55 | 56 | ## 98 57 | 58 | Nick: I'm not sure I share the original objection. I'm fine closing. 59 | 60 | Robin: originally could have been read two ways; this was to clarify. 61 | 62 | Jeffrey: I agreed with the complaint. I agree the changes fix things. 63 | 64 | *discussion on fruit* 65 | 66 | *consensus to close* 67 | 68 | ## 187 69 | 70 | RB: A pr that has been merged. (#177) 71 | 72 | JY: I made a comment in 177 that some things were removed that were useful so this issue is about getting them back. 73 | 74 | Nick: expand? 75 | 76 | RB: I think we fixed this another PR 77 | 78 | JY: section bounderies - got taken - so maybe not a problem any more. 79 | 80 | RB: yeah that's a change I made after Amy's change #177. 81 | 82 | JY: I will go through it pffline and close if appropriate. 83 | 84 | 85 | -------------------------------------------------------------------------------- /meetings/2023-11-29-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Call - Wed, 29 November 2023 2 | 3 | Present: Dan, Don, Sam, Christine, Robin, Wendy, Jeffrey, Nick 4 | Regrets: Amy, Pete 5 | 6 | ## [#369 Copy-edit the Common Concepts section, except for the Recognition sub-section.](https://github.com/w3ctag/privacy-principles/pull/369) 7 | 8 | ### Vegas Rule 9 | 10 | Dan: it's cutesey 11 | 12 | Don: the real world vegas has a lot of surveillance ... co-ownership of apparently independent hotels, cross-property data sharing agreements -- new web developers attending their 1st trade show in real Las Vegas might not get the reference to an idealized cool or historic Las Vegas 13 | 14 | Christine: I also suspect it's a western idea... - US centric idea - can we do it without using that terminology? I agree with Don. 15 | 16 | Wendy: might make more sense for a presentation or educational overview, rather than in the detailed principles document 17 | 18 | Nick: is there a better way to communicate the idea of separation of behavior in different place-like things? No strong feelings. 19 | 20 | Robin: I can live with it - but for the record I think this is part of a trend to make this doc blander and less relatable. In teaching this stuff it gets someone's attention... in my mind I think we should go more in that direction... 21 | 22 | Jeffrey: I wil re-word... 23 | 24 | ### [GDPR](https://github.com/w3ctag/privacy-principles/pull/369/files#r1409521635) 25 | 26 | *we agree to undo the change* 27 | 28 | Robin: "for legal background on personal data consult xyz" 29 | 30 | ### [budget](https://github.com/w3ctag/privacy-principles/pull/369/files#r1402468424) 31 | 32 | *considering Wendy's suggestion* 33 | 34 | Dan: looks fine to me.. 35 | 36 | **provisionally we agree to land this, with Jeffrey's upcoming changes to the first section** 37 | 38 | ## Sending this to the TAG 39 | 40 | Jeffrey: I suggest we send this to the TAG. 41 | 42 | Robin: I agree. 43 | 44 | **we agree we can send it to the TAG for review** 45 | 46 | "We're asking the TAG to review this document as we will soon be asking you to publish this as a note on Statement track... The intention is to get AC approval for W3C Consensus as a W3C Statement. Note that there will still be some editorial PRs pending but there are no substantial changes currently pending. Issues flagged as [Wide Review](https://github.com/w3ctag/privacy-principles/issues?q=+is%3Aissue+label%3A%22wide+review%22+) are evidence that there has been wide review. Some of these issues are still open but most of those are deemed editorial in nature. 47 | 48 | Issues 332 and 333 are both flagged as back burner, which means the task force has deemed that these can wait for a future revision. 49 | 50 | In essence, we're asking the TAG to say 'the TAG stands behind the substance of this document' - especially the principles themselves. 51 | 52 | Assuming the TAG achieves consensus that the substance of the document is good, we're asking the TAG to re-publish this as a draft note. We acknowledge that there are some open issues - in particular, 335 through 378, that need to be addressed and closed. The task force will continue to address these issues in the coming weeks with the intention to finalize any changes before the end of the year." 53 | 54 | Nick: are we handing over change control? or asking for review, adoption, publication but task force continues to be responsible for working through remaining issues? 55 | 56 | Dan: not handing over change control, but confirming consensus of the TAG 57 | Jeffrey: which would mean agreement to publish as a Note 58 | 59 | ## [Issue-279](https://github.com/w3ctag/privacy-principles/issues/279) 60 | 61 | Jeffrey: we still have a sentence which falls under this issue.. I think it's worth adding the example. 62 | 63 | 64 | -------------------------------------------------------------------------------- /meetings/2022-04-13-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Task Force Minutes - Wed, 13 April 2022 2 | 3 | Present: Dan, Jeffrey, Robin, Don, Pete, Tess, Amy, 4 | Regrets: Christine 5 | 6 | ## Publicaiton of Public Draft 7 | 8 | Covered in TAG call today - we're OK to issue a draft. 9 | 10 | ## [Refine and clarify the definitions of first and third parties., PR 139](https://github.com/w3ctag/privacy-principles/pull/139) 11 | 12 | Robin, Dan, Tess: LGTM 13 | 14 | Don: Slight refinement, the party that controls how a user's interactions are processed. We want to make sure that it's not the people who put together the server or VPS. 15 | 16 | Jeffrey: I don't have a great way to say it, the people who made the VPS don't control the content. 17 | 18 | Don: Let's say 1P is an RPG and the users are creating the content. The Controller is who controls the logs. It's not the VPS provider, it's not the gamemaster, it's the entity controlling the logs. 19 | 20 | Jeffrey: They would also control complaints, take-downs. They have the power. Happy to wait a few days for you to suggest better words. 21 | 22 | Robin: Can we merge and get better words later if they happen? 23 | 24 | Group Yeah. 25 | 26 | `Jeffrey has clicked the button.` 27 | 28 | ## [Non-retaliation principle, PR 141](https://github.com/w3ctag/privacy-principles/pull/141) 29 | 30 | Robin: I was retaliated against recently and I thought we should say something about that. 31 | 32 | Pete: I like this text, but what about the other way around, services that will only offer a service if you give over your data. 33 | 34 | Don: I have seen this more broadly in terms of adding tracking to your blog and how it gets listed in an unrelated context. 35 | 36 | Jeffrey: We should keep thinking about the question of services that charge the user in data. 37 | 38 | Robin: I completely hear the conceptual relationship between pay with data, pay for data, and retaliation. I think 39 | 40 | Pete: cookie polict where if you reject then they tell you to [go away] 41 | 42 | Robin: I think that's retaliatory. 43 | 44 | Dan: notice from a web page that you must disable your (ad/tracking) blocker? 45 | 46 | Robin: if the ad blocker is just a privacy blocker but you're stioll seeing ads which monetize then I think that's not retaliatory - if you're removing the ads from a web page then it's maybe a different story. 47 | 48 | **agreed to merge and then open up a new issue for user-on-user retaliation** 49 | 50 | ## 133 51 | 52 | JeffreY: find to merge - Pete can add some more text back in and then make it mergeable. Feel free to merge it next week since I won't be there. 53 | 54 | Robin: i think we're rougly aligned - in terms of direction I think this is good. I wouldn't want to ship FPWD with the text you removed still removed. 55 | 56 | Pete: I can work the text back in - 57 | 58 | Dan: I'd suggest you do that and then send a notification to us and we can +1 and then you can merge. Then we really have something to discuss on wednesday. I can send around what we have to a few people to flag we're about to do this so we don't blindside anybody. 59 | 60 | ## administrivia 61 | 62 | Dan: let's think about issuing a fpwd next week... 63 | 64 | Robin: I gave a brief overview of the work we've done, focused on how it could be extended, to the CG.. we've been going at this long enough that everyone should know it's coming. Feedback was positive. 65 | 66 | Jeffrey: went well, group appreciated the principles, treated them as authoritative. One question about our use of unwanted recognition - filed the issue. 67 | 68 | Robin: a lot also comes down to the fact that privacy proves hard to pin down and people wh want to write code want to have something authoritiative, want to know what's fine, acceptable. Some of that was emerging. Okay someone put their foot down, I don't care what they said as long as I can work with it. Industry is feeling bruised. 69 | -------------------------------------------------------------------------------- /meetings/2023-07-12-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Call - Wed, 12 July 2023 2 | 3 | Present: Dan, Jeffrey, Pete, Robin, Wendy, Tess, Sam, Wendy, Don, Nick 4 | Regrets: Christine, Amy 5 | 6 | ## [302 edit identity](https://github.com/w3ctag/privacy-principles/pull/323) 7 | 8 | Jeffrey: not sure it makes sense to put recognition in the Common Concepts but makes sense to mvoe it out of the main body of the text so don't object. 9 | 10 | Jeffrey: big thing is avoiding partitions... we don't want to make people click through a def... wishes/when necessary 11 | 12 | *we wordsmith...* 13 | 14 | Jeffrey: on [this](https://github.com/w3ctag/privacy-principles/pull/323/files#r1255053743) we shouldn't block this PR but we should look at it again. 15 | 16 | Robin: feels like automated to just say implemented... 17 | 18 | *issue raised* 19 | 20 | **we agree to merge** 21 | 22 | ## [Editorial: data minimization, fixes #303.](https://github.com/w3ctag/privacy-principles/pull/324) 23 | 24 | Pete: I left a comment - passive voice as confusing... also broader question - this splits types of data into data that achieves goals vs fwds peoples' interests.. 25 | 26 | *discussion of goals vs interests and being more specific about what we're talking about* 27 | 28 | Pete: we can merge this and have the larger discussion about data collection with a future PR (from Yoav and Jeffrey will work on). 29 | 30 | Nick: concerned about merging these into one principle... 31 | 32 | **bumped to next week** 33 | 34 | ## [Editorial: Information Access, fixes #304](https://github.com/w3ctag/privacy-principles/pull/325) 35 | 36 | *appropriate vs acceptable* 37 | 38 | Jeffrey: we shouldn't use *appropriate* here... 39 | 40 | Nick: agree - appropriate has a special meaning in this context. 41 | 42 | Wendy: condensing for readability may have lost some particularity... 43 | 44 | Jeffrey: my last suggested workding 45 | 46 | **we agree we also need to bump** 47 | 48 | ## [Editorial for Sensitive Information and Vulnerability](https://github.com/w3ctag/privacy-principles/pull/326) 49 | 50 | *discussing [comment](https://github.com/w3ctag/privacy-principles/pull/326/files#r1260848895)* 51 | 52 | Tess: this puts onus on implementers... 53 | 54 | Robin: it should go back to the stanfards... 55 | 56 | Pete: standard should be ... made to offer better degredation... 57 | 58 | Tess: standard is just a piece of paper.. 59 | 60 | Pete: spec author should design so code flows can work the same way ... e.g. use an async instead of sync api 61 | 62 | Jeffrey: onus is on the API design and site... default to degrade gracefully... sites can detect - we should be telling them not to do that. 63 | 64 | Tess: we should take a new change that clarifies that. 65 | 66 | Don: spec should facilitate a responsible UA protecteding the UA from sites - also responsible site protecting the user from violations by the UA 67 | 68 | Robin: we should do it in reverse order from the prioritty of constituencies... theoretical purity, spec designes, site authors... should ... Some sites will break on purpose.... Ideall this should be handled by the standard but sometimes it's not possible.... 69 | 70 | *we agree we need to revisit with Robin's new suggseted wording* 71 | 72 | ## [Editorial: Device Owners and Administrators, fixes #309.](https://github.com/w3ctag/privacy-principles/pull/327) 73 | 74 | Tess: ...guardians and wards... easy for a user to miss the link... It would help if that were brought forward in the section... 75 | 76 | Dan: colapses 2 into 1 77 | 78 | Jeffrey: in this case they are roughly the same thing... 79 | 80 | 81 | 82 | ## [Harrasment, for #310 and #311](https://github.com/w3ctag/privacy-principles/pull/328) 83 | 84 | Nick left comments on the PR. 85 | 86 | 87 | ## transparency 88 | 89 | https://github.com/w3ctag/privacy-principles/pull/288 90 | 91 | additional promises to review the proposed transparency principles. 92 | -------------------------------------------------------------------------------- /meetings/2024-01-17-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 17 January 2024 2 | 3 | Present: Dan, Wendy, Pete, Nick, Jeffrey, Don, Christine 4 | Regrets: Amy 5 | 6 | ## Admin 7 | DKA: will be meeting bi-weekly, dates TBD as TAG calendar settles 8 | 9 | DKA: asked Yves to publish new draft. Mentioned that on the w3c member call, with positive feedback. In response to questions, indicated we plan to go W3C statement track. Will send announcement, probably after TAG F2F. 10 | 11 | ## Issues 12 | 13 | ### Vulnerable People, https://github.com/w3ctag/privacy-principles/issues/373 14 | 15 | DKA: we noted that we talk about vulnerable people in many places, it's probably reasonable to have a definition. Last week, thought we didn't want to remove the def, also consider Pete's Nov. comment. Should we revise? 16 | 17 | Pete: If we mean basically anybody, we should say so. 18 | 19 | Don: The most vulnerable people are those who don't know they are, e.g. those with a child in the army vulnerable to a scam they're unaware of. I like that the def points at unawareness, on both the person and the sites inability to tell whether they're dealing with a vulnerable person. 20 | 21 | DKA: we do say anyone can become vulnerable. 22 | 23 | Nick: not everyone all the time. It's context-dependent, anyone could become vulnerable. 24 | 25 | DKA: since Pete said he wouldn't hold out, should we close? Don, if you want to write an intro sentence. 26 | 27 | Don: sure. (Don to post a PR adding this text) 28 | 29 | Jeffrey: link from vuln section to defn. 30 | 31 | Nick: +1 32 | 33 | Don: I'll also link from word "vulnerability" to 1.2 where it makes sense 34 | 35 | # PRs 36 | ## 392 https://github.com/w3ctag/privacy-principles/pull/392 37 | 38 | Jeffrey: Defining abuse of individuals, not of corporate systems 39 | 40 | Nick: right, spam wouldn't fall under this (harassment) type of abuse, but do we also need to make note of the spam type of system abuse? 41 | 42 | DKA: if we drop the word "cruel," to "mistreatment of someone through digital means" then it covers spam 43 | 44 | DKA: suggeested change from "cruel treatment" to "mistreatement". Any disagreement? 45 | 46 | [no disagreement] 47 | 48 | Merged 49 | 50 | Nick: we are defining harassment as a particular kind of abuse, but not making explicit principles that are exclusively about harassment. 51 | [scribe missed some discussion of spam, in or out of privacy considerations] 52 | 53 | Jeffrey: Seems like the right balance to me. Explanatory text about harassment as particularly severe and reasons to pay more attention to those. 54 | Nick: fine with me too. 55 | 56 | ## https://github.com/w3ctag/privacy-principles/pull/393 57 | 58 | Jeffrey: we said we'd look for should/must and say we weren't being strictly RFC 2119. Robin wrote a conformance section. I disagreed with one "must" 59 | 60 | DKA: can you add a comment. If there's not consensus, keep the existing text 61 | 62 | Nick: re conformance section, I think we shouldn't say "ignored" 63 | 64 | Jeffrey overridden? 65 | 66 | Jeffrey: I'll merge the suggestions. Shall we merge the PR? 67 | 68 | [thumbs up] 69 | 70 | ## 394 71 | 72 | https://github.com/w3ctag/privacy-principles/pull/394 73 | https://pr-preview.s3.amazonaws.com/w3ctag/privacy-principles/pull/394.html#deidentified-data 74 | 75 | Wendy: should they link to a filtered view? 76 | 77 | Jeffrey: I like them 78 | 79 | DKA: +1 80 | 81 | Wendy: no objection to this form 82 | 83 | Nick: are the categories right, e.g. should non-retaliation apply to user-agents as well as websites? 84 | 85 | Jeffrey: welcome additional categories. Shouldn't block the PR 86 | 87 | DKA: merge? I'll make sure Yves knows we made updates. 88 | 89 | Jeffrey: I'll file a bug suggesting linking the principles tags to list by audience. 90 | 91 | DKA: I'll send a note to the AC. Then we'll figure out the statement track. This will (maybe) be the first thing going on the Statement track. 92 | 93 | DKA: adjourned. See slack for next meeting. 94 | -------------------------------------------------------------------------------- /meetings/2024-04-24-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Task force - 24 April 2024 2 | 3 | Present: Dan, Jeffrey, Pete, Robin, Don 4 | Regrets: Christine, Wendy 5 | 6 | ## Wide review feedback 7 | 8 | Dan: I reached out to the UN... 9 | 10 | Robin: I reached out to Heather F. to ask for feedback as well re: identity & identifiers 11 | 12 | https://github.com/w3c/i18n-request/issues/227 13 | 14 | Robin: the send a note is completed in IRC... 15 | 16 | Dan: I [asked](https://github.com/w3c/i18n-actions/issues/85#issuecomment-2075315160) for feedback... 17 | 18 | A11y: https://github.com/w3c/a11y-request/issues/74 19 | 20 | Dan: so far nothing there - I will ping Matthew Atkinson - 21 | 22 | Dan: any other wide review feedback? 23 | 24 | ## [Reconcile browser funding with Loyalty](https://github.com/w3ctag/privacy-principles/issues/414) 25 | 26 | Jeffrey: this is about - any processing that's detrimental to the user's interests... 27 | 28 | Robin: I don't see how it's detrimental... 29 | 30 | Jeffrey: if you look only at the first half of the exchange, it's detrimental... 31 | 32 | Dan: I think maybe adding more complexity wouldn't really help... 33 | 34 | Robin: I think the the principles benefit from being simple and clear... if we try to pre-program possible misinterpretations then ... 35 | 36 | Don: the companies that do this kind of stuff already explain this kind of value to end users (like renting out your GPU) I don't think that's an exception to "detrimental to a user's interest" if the user has an interest in making some kind of trade. 37 | 38 | Jeffrey: our sense is that these kinds of exchanges are not violations of loyalty... I think responding "we think these exchanges are not violations" would be a reasonable way to close the issue. 39 | 40 | Pete: this is several abstractions away ... but for v2 we need slimmer document... 41 | 42 | *jeffrey to write up* 43 | 44 | ## Credentials 45 | 46 | *we discuss possible shape of work on credentials in w3c...* 47 | 48 | Jeffrey: how do we mitigate - discourage sites from asking for too much... Trade-offs ... We need to ask the working group "what are those trade-offs" and that's against the backdrop of digital identities... and phone 49 | 50 | Dan: we can learn from the payments work... 51 | 52 | Jeffrey: we should discourage that outcome... 53 | 54 | Dan: there's open wallet work going on in linux foundation... https://openwallet.foundation/ 55 | 56 | Jeffrey: could be a good suggestion for the charter... 57 | 58 | Nick: coercion ... we don't want to enable wide scale discrimination... ethical principles that are privacy relevance... I'd like some commitment at the chartering stage [of fedid] that there will be joint work - joint work that we can address these harms... 59 | 60 | Jeffrey: is that something that could go into the proposed charter? 61 | 62 | Nick: have the TAG convene a task force and have the wg charter include some committment to that... 63 | 64 | Pete: a place where we could look: the crypto space .. you have the ability to spin up temporary credentials... worries me : single sign-on with drivers' license... 65 | 66 | Don: "how can we use this to stop account sharing" 67 | 68 | Jeffrey: an argument for regulation... in our spec we can say "you must not do this" 69 | 70 | Don: and done in a web environment where you can choose what info is passed (not arbitrary info that could create more risks) 71 | 72 | Jeffrey: putting browser in the middle - we can ban them from accessing the API... 73 | 74 | Nick: started this draft https://github.com/w3cping/credential-considerations/blob/main/credentials-considerations.md in ping... 75 | 76 | Discussion of a task force to do 3 things: 77 | * finding at the beginning 78 | * review body jointly with ping 79 | * a document ... such as the one above ... 80 | 81 | Nick: a human rights impact... 82 | 83 | Dan: societal impact questionnaire https://w3ctag.github.io/societal-impact-questionnaire/ could be part of a human rights assessment... 84 | 85 | Jeffrey: having the experts on human rights etc... in the working group.. might be the best way to do it... 86 | 87 | -------------------------------------------------------------------------------- /meetings/2022-02-23-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Call - Wed, 23 February 2022 2 | 3 | Present: Dan, Nick, Don, Pete, Wendy, Sam, Tess, Christine 4 | Regrets: Robin, Jeffrey 5 | 6 | Fewer folks today, may have a shorter conversation. 7 | 8 | ## [pr 133](https://github.com/w3ctag/privacy-principles/pull/133) 9 | 10 | Pete: effort to simpligy personal data section - and restructure this to an enumeration of specific principles. 11 | 12 | Dan: move the definitions into section 1? 13 | 14 | [general agreement to do that] 15 | 16 | Dan: make more actionable principles for section 2: what should someone do based on this; active voice; normative statements 17 | 18 | Pete to modify PR to move definitions to previous section as well as those changes 19 | 20 | ## [pr 136](https://github.com/w3ctag/privacy-principles/pull/136) 21 | 22 | [discussion on automated decision making and whether we should include some speicifc examples] 23 | 24 | Nick: ...opting out of profiling... 25 | 26 | Tess: I have an email provider - with automated spam filtering.. and there's a risk with misclassification that I might miss some important info. Missing that could impact my credit rating.. but we don't mean "email providers shouldn't provide automanted spam filtering" 27 | 28 | Nick: no - more making decisions based on data about me... 29 | 30 | Tess: in some cases it does use info about you... 31 | 32 | Don: Spam filters - in order to be effective they need to be not disclosed - to make them less gameable... 33 | 34 | Nick: i think the motivation for the laws - - if you're making a judgement about me - e.g. drawing inferences based on an algorithm's decision about the person - I should be able to object. Credit worthiness, etc... 35 | 36 | Nick: comes up in advertising contexts - making offers to people based on some data about them... potentially impactful decision. 37 | 38 | Tess: **price discrimination** based on what device you have https://www.bbc.com/news/technology-18595347 39 | 40 | Christine: an office supply store changed price based on your location... https://venturebeat.com/2012/12/24/staples-online-stores-price-changes/ 41 | 42 | Dan: too far towards the world vs. on the web? 43 | 44 | Pete: not just bad because thee are under rights.... 45 | 46 | Nick: in some legal contexts they described it as a person's right. 47 | 48 | Dan: what principles can we draw out? 49 | 50 | Nick: if we have data on a system or access data about ones-self - would need to implement things like "see this data about you" or "deletion request" - principles like new features developed collaboratively. 51 | 52 | Don: related - discussion came up in FLoC. [Is this thing revelant to dynamic pricing](https://github.com/WICG/floc/issues/105) ? FLoC no longer being discussed but [I filed an issue](https://github.com/jkarlin/topics/issues/34) on Topics API which is related. 53 | 54 | [discussion on price discrimination] 55 | 56 | Don: Price discrimination can be considered as a harm to the user, related principle is **sharing info about a person in a way that's not clear to that person.** 57 | 58 | Dan: it has something to do with primary use / secondary use as well... 59 | 60 | Pete: we have that ... 61 | 62 | Nick: how about: **parties and user agents should provide access and ability to delete data stored about them on client and server.** 63 | 64 | Dan: if a feature (like Topics API) makes inferences and stores data on the user agent perspective, users should be able to inspect/audit and delete 65 | 66 | Sam: automated decisions vs non-automated decisions - both can be harmful. 67 | 68 | Nick: saying there's a right to be free from automated decision making is not saying that's the only way to implement privacy, just providing some after-the-fact data rights (in addition to controls about collection, etc.) 69 | 70 | 71 | [pR 132 ](https://github.com/w3ctag/privacy-principles/pull/132) 72 | 73 | Nick: example of pop-up blockers - implemented by all browsers - as an example of something browsers needed to do to fix the problem of intrusive use of a web technology 74 | 75 | are there references on the history and motivations of pop-up blocking as a collectively-developed browser feature to protect against intrusion? 76 | -------------------------------------------------------------------------------- /meetings/2023-08-02-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Minutes - Wed, 2 Aug 2023 2 | 3 | * Present: Nick, Jeffrey, Don, Pete 4 | * Regrets: 5 | 6 | ## [PRs](https://github.com/w3ctag/privacy-principles/pulls?q=is%3Aopen+is%3Apr+sort%3Acreated-asc) 7 | 8 | ### [transparency section #288](https://github.com/w3ctag/privacy-principles/pull/288) 9 | 10 | Nick: Happy to make or have the editors make the editorial changes. On the comment about browsers not showing explanation while asking for permission, I am arguing that browsers should change their minds. We have enough evidence now that not showing relevant explanation with permissions requests is not working. Not sure principles document needs to say it directly. But the principle is that we should consider ways for browsers to show relevant information. 11 | 12 | Jeffrey: doesn't prescribe what you need to put in the perf dialog, so maybe this isn't so diff from current policy. Happy to let it through if others don't disagree 13 | 14 | Pete: I'll take a look ASAP and report back on slack or on the next call i can attend (i wont be on the next call) 15 | 16 | Nick: other concerns? 17 | 18 | Jeffrey: Info means two diff things, can we change one phrase to "helpful explanation"? 19 | 20 | Nick: good pt that it seems confusing, not sure, but explaination seems promising 21 | 22 | Jeffrey: I'll be gone next 2wks, someone else should suggest new text 23 | 24 | ### [local granularity #339](https://github.com/w3ctag/privacy-principles/pull/339) 25 | 26 | Jeffrey: is this good to review? 27 | 28 | Nick: Not sure if this will address MT's concern. We can cite the RFC and note it as useful but not necessarily sufficient. 29 | 30 | Don: I like this change, relevant to jury use case (general location + "other relevant information" can identify a likely juror in a large government facility) 31 | 32 | Jeffrey: should we merge or ask MT to review. Im happy to merge and see if MT is happy 33 | 34 | Pete, Nick: +1 35 | 36 | ### [move list of recognition techniques to a new doc #340](https://github.com/w3ctag/privacy-principles/pull/340) 37 | 38 | Jeffrey: Nick, you asked if this should go in the privacy threat model. That seems good if imperfect. 39 | 40 | Pete: No preference at all. Seems fine. Are people good with removing it? 41 | 42 | Nick: I'm fine with removing it. I thought it fit here, but since we're concerned about length, and we don't make lots of references, I'm fine moving it. 43 | 44 | Pete: I think we could get rid of the section afterwards too. Separate PR. "Summary of the principles" 45 | 46 | Jeffrey: That's probably worth keeping as an index. 47 | 48 | Nick: High level threats section. RFC6973. Not sure if we added anything. 49 | 50 | Jeffrey: Think we did add something, but I agree that it might not be useful. 51 | 52 | Nick: Could move to a threat model, as these are useful listing of threats but not extensively used in our principles text. Colleagues gave feedback to remove that. 53 | 54 | Pete: I'll create an issue to do that and then do it. folllow up issue: https://github.com/w3ctag/privacy-principles/issues/341 55 | 56 | Jeffrey: For #340, we should let the rest of the group weigh in, but I'm generally positive. 57 | 58 | Pete: Dan seemed most unsure, +1 to wait for him 59 | 60 | ## Misc attempts to move pieces of this document elsewhere. 61 | 62 | Pete: We could move A.5 to a threat model too. 63 | 64 | Nick: I think people are going to be looking here for recognition. 65 | 66 | Pete: Server-side actors? 67 | 68 | Jeffrey: We have a hierarchy of documents, and it'd be good for this document to mostly use definitions from itself and higher documents. Threat model is lower, so I'd hesitate to move important definitions there. 69 | 70 | Pete: How about Acting on Data? Several terms are only used within this section. I will brain on it more and either give up or come back with a PR 71 | 72 | Jeffrey: Especially the GDPR terms like "service provider". 73 | 74 | Nick: we might be at the end of what we can do today. Once we address current PRs, remaining issues seem like editoral and similar. Seems good! 75 | 76 | Jeffrey: still two issues for me, 279 and 280, will address when i get back in 2 wk 77 | 78 | Pete: I also wont be here next wk 79 | 80 | Jeffrey: the end 81 | -------------------------------------------------------------------------------- /meetings/2024-01-10-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Web 10 Jan 2024 2 | 3 | Present: Dan, Wendy, Robin, Christine, Jeffrey, Sam 4 | 5 | ## Editorial Pass 6 | 7 | DKA: No status changes since last year. TAG consensus for the document, modulo editorial updates. Amy is doing some editorial fixes. We need to figure out if there are others. Sangwhan raised lots of questions around plain language, e.g. the term "agency" needs more explanation. 8 | 9 | Robin: can we get a list of words/issues? top 10? 10 | 11 | DKA: I'll go back and request more specific feedback. We should also do an editorial pass trying to simplify. 12 | 13 | Robin: What is blocking? 14 | 15 | DKA: nothing blocking. Some editorial work is expected. I will make a request to Yves this week to republish draft. How will we work most effectively to conclude workstream? 16 | 17 | Robin: 27 non backburner issue... several have progress already... With a concerted push we could close most of them... We could try to have a rythym of closing them and getting to zero... 18 | 19 | Robin: searching backwards, excluding `backburner`. 20 | 21 | ## [add def of abuse](https://github.com/w3ctag/privacy-principles/issues/330) 22 | 23 | Robin: We use abuse a fair bit but don't define it... 24 | 25 | Dan: Do we need to? 26 | 27 | Robin: we define harassment and unwanted info but don't define abuse.. In 2.9 we could almost replace with harassment .. 28 | 29 | Sam: Amy renamed that section to Abuse... 30 | 31 | Robin: I'd be comfortable just saying we won't define it... 32 | 33 | Christine: I'm looking at this in a different way - I've been looking at trends in countries to introcuce new protection on internet intermediaries - against bullying, hate speech, etc... This section might get more interest than we thought it would. I'm starting to see ideas about protecting web users - offering users more control - control features to filter, etc... This section we may want to have another look at it.. 34 | 35 | Jeffrey: Age verification also falls into this... 36 | 37 | Jeffrey: if we tighten this to harassment then that might avoid some of those problems... 38 | 39 | Robin: Abuse is broader than harassment - so i like keeping the broader 40 | 41 | Jeffrey: worried about not defining abuse... 42 | 43 | Robin: "Online abuse is using digital means to treat people with cruelty and violence regularly and repeatedly... Harassment is a kind of abuse." 44 | 45 | Jeffrey: "Abuse is the improper usage or treatment of a thing, often to unfairly or improperly gain benefit." from https://en.wikipedia.org/wiki/Abuse 46 | 47 | Wendy: I think 2.9 is focused on harassment against the person (versus other uses in the doc that refer to abuse of services). So I would go towards what robin suggested. 48 | 49 | **Robin agrees to do a PR on this** 50 | 51 | ## [de-identified data](https://github.com/w3ctag/privacy-principles/issues/307) 52 | 53 | Robin: this is because it's passive voice, etc... 54 | 55 | Dan: I can take this ... 56 | 57 | ## [2119](https://github.com/w3ctag/privacy-principles/issues/371) 58 | 59 | Sam: I'm on board with not using 2119 - pulling out 2.14 non-retaliation ... 60 | 61 | Jeffrey: I think we should use 'Should is "there may exist valid reasons in particular circumstances to ignore a particular item"' Usually we don't use must.. But I think must not retaliate is actually reasonable... 62 | 63 | Robin: if we convert any of these to upper case the spec will cite it... right now we're not using it. 64 | 65 | Robin: do we need to do this though? They're mostly correct... I think we mostly use it the way we intend to... I think it's a relatively short PR to fix and review it... 66 | 67 | Robin: either everything should be SHOULD - and not use 2119 ... OR ... we do draw distinctions (e.g. non-retaliation) and then we should reference 2119. 68 | 69 | Wendy: leaning against 2119 capitalization - because it implies a degree of bindingness that principles don't have... We don't have measuring conformance... We wont people to take these as helping their development... 70 | 71 | Dan: +1 72 | 73 | Jeffrey: we could also write our own conformance section... "should means xxx, must means yyy" 74 | 75 | Robin: if we draw a distinction. 76 | 77 | **Robin to do a PR** 78 | 79 | ## [vulnerable people](https://github.com/w3ctag/privacy-principles/issues/373) 80 | 81 | *we discuss whether to remove definition* 82 | 83 | ## Moving to a fortnightly call schedule starting this week - so no call next week. 84 | -------------------------------------------------------------------------------- /meetings/2023-09-tpac/breakout/slides.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Privacy Principles 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 22 | 23 | 24 |
25 | 26 | 30 |
31 | 32 | 33 | 34 | 35 |
36 |

Privacy Principles

37 | 38 |

★ W3C TPAC 2023, Seville, 11–15 September ★

39 |
40 | 41 |
42 |

What?

43 | 49 |
50 | 51 |
52 |

These are a few of our favorite things

53 |
54 | 55 |
56 | Robin's highlight 57 |
58 | 59 |
60 |

1.3 User Agents

61 | 68 |
69 | 70 |
71 | Dan's highlight 72 |
73 | 74 |
75 |

2.2 Data Minimization

76 |
77 | 78 |
79 | Jeffrey's highlight 80 |
81 | 82 |
83 |

2.8 Device Owners and Administrators

84 | 90 |
91 | 92 |
93 | Nick's highlight 94 |
95 | 96 |
97 |

2.9 Protecting web users from abusive behaviour

98 |
99 | 100 |
101 | Don's highlight 102 |
103 | 104 |
105 |

A.2: Common concepts: Contexts

106 | 114 |
115 | 116 |
117 |

Questions and Comments

118 | What do you think? 119 |
120 | 121 | 122 | 123 | -------------------------------------------------------------------------------- /meetings/2022-06-08-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Task Force Call - 8 June 2022 2 | 3 | Present: Dan, Wendy, Don, Shubhie, Pete, Nick, Amy, Sam 4 | 5 | Regrets: Robin, Christine 6 | 7 | ## Minutes 8 | 9 | ### Feedback on the Draft 10 | 11 | *...discussion...* 12 | 13 | ### Pulls 14 | 15 | https://github.com/w3ctag/privacy-principles/pulls 16 | 17 | https://github.com/w3ctag/privacy-principles/pull/158 18 | 19 | Wendy: I last commented that this document should contribute to conversations elsewhere.. . i was favouring leaving the second-order effects and predictions to discussions that follow from this document, rather than includint them in this doc itself. 20 | 21 | **meta point** 22 | 23 | Shubhie: I'm also curious if there has been feedback / round of PRs... for a spec writer what are useful points 24 | 25 | Pete: I don't think it's good to do future prediction... should avoid... 26 | 27 | https://github.com/w3ctag/privacy-principles/pull/166 28 | 29 | Dan: from Kyle 30 | 31 | Pete: (whos from Brave) 32 | 33 | Nick: "the browser should present something without characteristcs" seems like confusing advice. I think having randomness could be useful. Something we're learning about. I don't think it's feasible to present no characteristics. 34 | 35 | Pete: remove "no characteristics" ? 36 | 37 | Nick: .. last part about no identifiable characteristics. More fine with the MAY statement - it's true, in order to hide identity or provide privacy, browsers may try lots of things like false characteristics> Skeptical about prsenting nothing but I get it. 38 | 39 | Dan: what's a false characteristic? Eg. sending windows as the UA string generically even though no matter what the architecture is? that kind of thing? 40 | 41 | Pete: yes. Sometimes brave will report 8 cores instead of 16 to mess with fingerprinting. 42 | 43 | Don: Or languages or fonts. 44 | 45 | Dan: right. And this gets back to general editorial feedback - sometimes the document is too high level. We should be clear about what we're talkinga bout as an example of characteristics. We know this. Not an exhaustive list, but. 46 | 47 | Pete: I'd be happy to work to add a for example bullet points section 48 | 49 | Dan: Nick, would modifying the text in the area that you drew attention to be more 'wishes to present an identity without .. ' to 'whilst minimising identifiable characteristics' or something like that be acceptable? 50 | 51 | Nick: I'm not sure it's needed at all. Part of users having control is not never presenting any identity. A browser respecting a user's wishes.. i'd just delete that addition. 52 | 53 | Pete: the change sounds fine to me, to delete 'no characteristsics or' and the third paragraph altogether? 54 | 55 | Dan: and maybe include an example of characateristics 56 | 57 | Pete: if that's satisfactory that's fine with me 58 | 59 | https://github.com/w3ctag/privacy-principles/pull/167 60 | 61 | Dan: he's suggesting to "browsr fingerprint identity" 62 | 63 | Nick: I think it's confusing to put it together "browser fingerprint which could be another identifer" as a seperate bullet point. 64 | 65 | Dan: Leave as a comment or suggeted change? 66 | 67 | 68 | https://github.com/w3ctag/privacy-principles/pull/162 69 | 70 | Nick: this was an attempt to address the concerns about browsers sending reporting data that the user is not explicitly intending.. Maybe the user could reasonably understand. I suggested I would write some text on that.. And follow up with Shubhie... and that text would build... 71 | 72 | Shubhie: also text around user intentions - will chat about whether that's useful. .. one point raised in the PR is user's goals... user doesn't have one goal. Sometimes they are discovering links - they don't want to engage with the website. In other cases they have an ongoing brief engagement... when we say "user's goals" what do we mean? 73 | 74 | Nick: we also got the suggestion from M. Thompson that aggregated type things might be things the browser might do on the user's behalf -- low risk and good from the ecosystem. Do others think that might be OK? Aggregated stuff. 75 | 76 | Don: I don't think we can say that aggregated is always less of a privacy concern... we have a section on vulnerable people... even something seeming innocuous might facilitate persecurtion. Let's not go too far in the direction of "aggregated is better that individual". 77 | 78 | Dan: is aggegated data always for the public good? Is it open data? It's clearly good for the browser developer. 79 | 80 | Don: If you're asked to take a survey on how well these features work for you would you do it? A user would not manually write down how long sites take to load, but they might say yes, I want my browser developer to have this information so the sites I like will work better for me. 81 | 82 | Pete: should we say it's ok to send this information without being asked? 83 | 84 | Nick: will write down a better suggestion. 85 | -------------------------------------------------------------------------------- /meetings/2024-03-13-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Call - Wed, 13 March 2024 2 | 3 | Present: Dan, Don, Robin, Pete, Nick, Jeffrey, Wendy 4 | 5 | ## Some discussion on digital identity... 6 | 7 | Nick: https://github.com/w3cping/credential-considerations/issues/8 8 | 9 | ## [one pager](https://github.com/w3ctag/privacy-principles/pull/412) 10 | 11 | *discussion on one-pager* 12 | 13 | Robin: it seems worth doing... I welcome people stepping up and doing the work... What Ian has produced is a good start... 14 | 15 | Nick: like any good straw men this isn't good text but it demonstrates that we should have text like this... I don't think copying the secondary titles is a good way.. Jeffrey had a one-sentence version of many things... 16 | 17 | Jeffrey: I don't feel strongly... but I think we should make this the intro of the doc itself rather than a separate document... 18 | 19 | Dan: tzviya mentioned showing and hiding things... 20 | 21 | Don: so everything beyond section 1 could be hidden... 22 | 23 | Nick: I understand that it could get out of date but I don't think the intro should be a summary of the whole doc. I think people who would print out just a friendly version of numbered principles that they would actually read and point to. 24 | 25 | Dan: agree on having a 1-pager that's simple... 26 | 27 | Pete: i think where all the text is load bearing... it would be nice if things are shorter but we don't think it can be shorter and still be accurate... Not strongly against it... 28 | 29 | Wendy: I think the table of contents serves as this... 30 | 31 | Jeffrey: I like the suggestion of a printable thing... MDN has professional writers that are good at stuff like this... 32 | 33 | Jeffrey: maybe we need 3 one-pagers? 34 | 35 | Don: maybe one for web developers (standards authors would read longer documents?) 36 | 37 | Dan: we could just say it's not in scope for us... 38 | 39 | Nick: the reason I think it would be useful to have a short version is that we could get more people to read it... and engage with it... For example a translation it could make more sense.. 40 | 41 | Jeffrey: concrete suggestion: take the presentation I made with 1-sentence summaries and split up between the audiences and then see if that's the right thing to be translated... 42 | 43 | Robin: and maybe take something from Ian's introduction? 44 | 45 | Jeffrey: sure. 46 | 47 | Robin: i can write code. 48 | 49 | ## [which is personal data?](https://github.com/w3ctag/privacy-principles/pull/410) 50 | 51 | *we review* 52 | 53 | Wendy: ...uniquely identifying in combination with generic?... 54 | 55 | Jeffrey: this is the definition that the laws are using... If you have a uniquely identifying piece of data and combine it with a generic piece of data then they identify you. 56 | 57 | Nick: ... only if they are combined ... But if you have 2 sets of data that have no linkages, then it doesn't really seem combined, just concatenated... 58 | 59 | Jeffrey: the way to fix it right could be "through"... 60 | 61 | *we agree we don't need to get it perfect - we agree to merge* 62 | 63 | ## any other business? 64 | 65 | Nick: translations? An important part of getting more feedback might be versions in other languages... 66 | 67 | Dan: yes. Maybe get chapters to help? We could also get a Japanese translation for the upcoming AC meeting in Japan. 68 | 69 | Robin: most experienced person is Ivan ... we could reach out to him... Translation is one thing but we could get better feedback from global community even if in english... We could ask the public interest technology group... 70 | 71 | Nick: I'd be happy to ask for that not waiting on translation... but there are latam specific orgs... and having more people looking at it when it's in Spanish... 72 | 73 | *discussion on when to translate* 74 | 75 | Robin: reasonable cases to be made for both options... i would suggest to ship when it's good enough and then if we get feedback we ship a second version... easier to go to a translator if it's a stable 76 | 77 | *Wide review link: https://www.w3.org/TR/2024/DNOTE-privacy-principles-20240226/* 78 | 79 | Jeffrey: if we hire a translator then I think we should wait but for volunteer we should do it now. 80 | 81 | Peter: might be uncomfortable with just asking for translations of a summary document... 82 | 83 | Nick: people are going to give feedback at different levels... we should welcome feedback even if it's just "i read the headings, and this is missing"... 84 | 85 | Dan: translated summary could be useful in terms of getting people to decide that they want someone with language and expertise to review the full document in more detail 86 | 87 | Nick and Dan to look into potential, and come back to this group. 88 | 89 | Nick to message PITG, and some individuals. 90 | 91 | Dan: wide review requests have gone out for [i18n](https://github.com/w3c/i18n-request/issues/227) and [a11y](https://github.com/w3c/a11y-request/issues/74) 92 | 93 | 94 | -------------------------------------------------------------------------------- /meetings/2022-12-07-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Taskforce - 7 December 2022 2 | 3 | Present: Dan, Don, Nick, Sam, Jeffrey 4 | Regrets: Amy, Peter, Christine 5 | 6 | ## [Guardians](https://github.com/w3ctag/privacy-principles/pull/203) 7 | 8 | Dan: not sure about conflating parent/child and employer/employee... 9 | 10 | Don: malware protection is a shared interest between employer and employee. It's more complicated if the employer is a defense contractor - and the employee might gtve up info about their browsing in return for access to ad-supported content, but that conflicts with the interest of the employer in not revealing technologies being researched for company projects. 11 | 12 | Jeffrey: good example of how it lines up with the parent/child relationship... 13 | 14 | Nick: I definitely see the analagous situation - however even thought it's analagous I don't think we should use the same terminology. 15 | 16 | Dan: maybe 2 separate sections? 17 | 18 | Don: guardian puts the interests of the child ahead of theirs - but the employer puts interest of customers and investors ahead. 19 | 20 | Nick: I think this is a good laying out of the problem but I don't know what we're recommending. 21 | 22 | Jeffrey: leaning on the other PR - on device owners... 2 principles on what user agents should do on behalf of device owners. 23 | 24 | ## [Device owner / user rights](https://github.com/w3ctag/privacy-principles/pull/202) 25 | 26 | Nick: not sure we should say spy on... 27 | 28 | Jeffrey: surveil instead of spy. 29 | 30 | Sam: related to Automotive people conversation. ... priority of constituencies - manufacturer vs driver... vehicle owner vs vehicle driver... This applies outside of web context. 31 | 32 | Nick: an owner of a car might want to know where the car is - but it should be clear to the driver that this is in operation. 33 | 34 | Dan: maybe take it out of a table? 35 | 36 | Nick: not that "i own the phone that my wife uses" but "i have access to the settings"... 37 | 38 | Jeffrey: change device owner to device adnimistrator. 39 | 40 | Nick: not just administator - with the elder family member example you could say "this child" - 41 | 42 | Jeffrey: the ability to adminsistrate a device is not always consensual and not always formal. 43 | 44 | Nick: do we have employer/employee principles? or only administators? 45 | 46 | Don: there may be some interesting info on this from American Library Association - honor code on data. Can take a look at what the librarians say about policies for administration of computers that are used by library visitors but are administered by them. 47 | 48 | Nick: we should have the device administator section which talks about employers and have the guardian section that shouldn't reference employees. 49 | 50 | Jeffrey: i can do that. UAs do have special features for guardians... it'd be nice to come up with some kind of guidance for this. Think of the guardian having responsbiloty rather than having rights... 51 | 52 | Nick: subj matter experts... 53 | 54 | Dan: Is there anything we can say to content providers / about content providers? 55 | 56 | Jeffrey: covered in the vulnerable people section... 57 | 58 | Nick: there is some interest in some websites - special web sites for people escaping malicious guardians. 59 | 60 | Jeffrey: trevor project - dseigned for people trying to evade their guardians. 61 | 62 | Nick: that's a use case for clear site data... 63 | 64 | Jeffrey: tension is that the guardian gets to choose the browser that the ward gets to use. The user agent needs to be able to refuse if necessary... i think having the warning you're being surveiled is as much as we can do. "there should be a private browsing mode that guardians can't surveil" but it's hard to balance that with legit interest of preventing kids from browsing violent or extremist sites... 65 | 66 | Nick: maybe allow-list certain sites? 67 | 68 | Jeffrey: I think we can useful say "pay attention to both of these needs"... 69 | 70 | Jeffrey: I'm not convinced about changing the table... 71 | 72 | Don: source for terminology on people's relationships? https://www.ipvtechresearch.org/ we could be consistent with their usage to make things hopefully clearer 73 | 74 | ## [Identity](https://github.com/w3ctag/privacy-principles/pull/201) 75 | 76 | ## [Harassment](https://github.com/w3ctag/privacy-principles/pull/195) 77 | 78 | Nick: there were comments from Robin & Jeffrey - and I've tried to address... other important change : talk about the disparity of impacts ... not just lgbtq and women but other marginiised groups... 79 | 80 | Nick: most of the citations are specific to western countries... kind of feel like that's a problem... 81 | 82 | *discussion of reporting vs enforcement* 83 | 84 | Dan: enforcement might be out of band 85 | 86 | Jeffrey: provided by other systems... 87 | 88 | Nick: having a reporting mechanism with no enforcement - that wouldn't be good. But not much we can do to specify. 89 | 90 | Dan: suggest we merge - including dismissing Robin's review. 91 | 92 | *resolved to merge* 93 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Web Privacy Principles Task Force 2 | 3 | ## Table of Contents 4 | 5 | 6 | 7 | 8 | - [Charter](#charter) 9 | - [Privacy Task Force Members](#privacy-task-force-members) 10 | - [Input documents](#input-documents) 11 | - [Related documents](#related-documents) 12 | 13 | 14 | 15 | ## Charter 16 | 17 | The purpose of the Privacy Model Task Force is to bring together a small group of people to draft a set of privacy principles for the web. This document is to include definitions of key privacy concepts on the web, enabling us to use common language as we work together on new web technologies that have an impact on user privacy. It would also consolidate some of the work already done to define a privacy threat model. 18 | 19 | This effort will look at privacy from a **web architecture** point of view, fitting together with the TAG's Ethical Principles, Design Principles, and the Privacy & Security Questionnaire jointly worked on between TAG and PrivacyWG (and previously, PING). 20 | 21 | This effort will operate as a TAG-sponsored task force together with the Privacy Interest Group with participants invited by the TAG chairs and the PrivacyWG chairs (which can include current or former members of each group). There will be a maximum of 10 participants in the task force. The task force will run for 6 months and the final product will be a report which can be published as a TAG Finding (which can be subsequently elevated to a W3C statement) with some additional acknowledgement that the document has been produced jointly between PrivacyWG and TAG. 22 | 23 | We will be building on the work of the Ethical Web Principles which lays down an ethical framework for the web. The goal of a privacy model for the web should be aligned with the goal of that document: to ensure that the web provides **a net positive social benefit to humanity**. 24 | 25 | Periodically, and before working drafts are published, the task force will check in with an oversight group consisting of the TAG and PrivacyWG chairs and team contacts for approval and comment. 26 | 27 | This effort will happen in a public repo and with public comments. 28 | 29 | We will be staying away from legal and regulatory material. 30 | 31 | This effort will operate under the W3C's CEPC and as such we will maintain a respectful discourse. This effort will operate under anti-trust guidance from W3C. 32 | 33 | Possible names : Architectural Principles for Web Privacy; Architectural Considerations for Web Privacy; Privacy Architecture for the Web (PAW). 34 | 35 | We will strike a balance between working on the web as it is and also not being constrained by existing approaches if those approaches contravene privacy principles. 36 | 37 | e.g. 38 | > As a target threat model, it describes not the current state of the Web including all current maybe-unwise APIs, but rather an end state that we hope to migrate to, and that new APIs should be held to. This is meant to be a plausible threat model: it doesn’t expect to remove any APIs or browser behavior that is deemed essential to the viability of the Web. 39 | 40 | ## Privacy Task Force Members 41 | 42 | * Daniel Appelquist (Invited Expert, TAG, formerly Samsung) 43 | * Robin Berjon (Invited Expert, formerly The New York Times, TAG alum) 44 | * Nick Doty (Center for Democracy & Technology, PrivacyWG) 45 | * Amy Guy (Digital Bazaar, TAG) 46 | * Don Marti (CafeMedia, PrivacyWG) 47 | * Jonathan Kingston (DuckDuckGo) 48 | * Theresa O'Connor (Apple, TAG, PrivacyCG) 49 | * Christine Runnegar (W3C Invited Expert, PrivacyWG) 50 | * Wendy Seltzer (Invited Expert) 51 | * Pete Snyder (Brave, PrivacyWG) 52 | * Sam Weiler (W3C) 53 | * Jeffrey Yasskin (Google, PrivacyWG) 54 | 55 | …with support from W3C Team. 56 | 57 | Constituencies we want to represent 58 | 59 | * Browsers 60 | * Publishers / Web Sites 61 | * Civil society 62 | * Adtech intermediaries 63 | * Advertising buyers 64 | * People fighting abuse and fraud 65 | * Web developers 66 | * Members of marginalized communities who use the web 67 | * Other people who use the web 68 | 69 | Experts we need input and review from: 70 | * Privacy advocates 71 | * Privacy theorists and legal scholars 72 | * Behavioral economists 73 | * Those working on emerging Web tech such as WebXR and new device APIs 74 | * User researchers 75 | * TAG and PrivacyWG chairs and team contacts 76 | * WhatWG steering board 77 | 78 | ## Input documents 79 | 80 | * https://w3cping.github.io/privacy-threat-model/ 81 | * https://darobin.github.io/pup/ 82 | 83 | ## Related documents 84 | 85 | * https://w3ctag.github.io/ethical-web-principles/ 86 | * https://w3ctag.github.io/design-principles/ 87 | * https://w3ctag.github.io/security-questionnaire/ 88 | * Definition of origin: https://html.spec.whatwg.org/multipage/origin.html#origin 89 | * https://www.w3.org/Consortium/cepc/ 90 | * https://datatracker.ietf.org/doc/html/rfc6973 91 | -------------------------------------------------------------------------------- /meetings/2023-07-19-minutes.md: -------------------------------------------------------------------------------- 1 | 2 | # TAG Privacy TF Minutes - Wed, 19 July 2023 3 | 4 | Present: Wendy, Dan, Don, Nick, Sam, Christine, Robin, Pete 5 | Regrets: Amy, Jeffrey, Tess 6 | 7 | ## [editorial pass](https://github.com/w3ctag/privacy-principles/pull/334) 8 | 9 | Robin: too long for off the cuff but people should look at it 10 | 11 | ## [transparency section](https://github.com/w3ctag/privacy-principles/pull/288) 12 | 13 | Nick: I'm working on this based on comments from Jeffrey & Robin. 14 | 15 | Nick: I think "sites" should provide and "UAs" should consume it... Correct? 16 | 17 | Robin: I think it's whoever doing the processing - generally the site. The question of UA.. I do like the idea of making things machine readable - as a principle it should be possible ... 18 | 19 | **we will review next week** 20 | 21 | ## [potential small group privacy examples](https://github.com/w3ctag/privacy-principles/pull/289) 22 | 23 | Nick: can we merge? 24 | 25 | Pete: should we use "example" markup? Happy with the text. 26 | 27 | Nick: Happy for editors to make it an example.. 28 | 29 | Robin: I'll merge and then make a new issue about being consistent about examples. 30 | 31 | https://github.com/w3ctag/privacy-principles/issues/335 32 | 33 | 289 merged. 34 | 35 | Nick closed corresponding https://github.com/w3ctag/privacy-principles/issues/251 36 | 37 | **so moted** 38 | 39 | ## [self-governing](https://github.com/w3ctag/privacy-principles/pull/291) 40 | 41 | Robin: in my editorial pass (334) i got rid of this... 42 | 43 | Dan: so close 291? 44 | 45 | **agreed to close** 46 | 47 | ## [global opt-out](https://github.com/w3ctag/privacy-principles/pull/296) 48 | 49 | **agreed to merge on Jeffrey's approve** 50 | 51 | Pete: some vagueness - I can do another PR... Interaction -- with who? 52 | 53 | Robin: the site? 54 | 55 | *discussion* 56 | 57 | *we agree to slightly modify it to be "interaction with the site." 58 | 59 | ## Wide Review Comments 60 | 61 | ### https://github.com/w3ctag/privacy-principles/issues/276 62 | 63 | Pete: I think these could be moved to the privacy threat model document... 64 | 65 | Robin: I'd be comfortable moving it somwhere... 66 | 67 | Dan: let's just remove the reference to supercookie... 68 | 69 | Pete: happy with that 70 | 71 | Nick: I'd like to move this somewhere ... I disagree that nobody talks about it. It's a concept that comes up. We should have it defined. 72 | 73 | Pete: I can creat a new document in the Ping repo somewhere... 74 | 75 | ### https://github.com/w3ctag/privacy-principles/issues/277 76 | 77 | Nick: Same ... 78 | 79 | Pete: I will incoporate... I will create a new markdown doc in a new repo in ping space as a desintation for this text... (and 276) 80 | 81 | ### https://github.com/w3ctag/privacy-principles/issues/278 82 | 83 | Robin: we fixed this. **will close** 84 | 85 | ### 279 86 | 87 | Nick: suggest assigning to Jeffrey. 88 | Dan: just about clarity of example, we think. 89 | 90 | ### https://github.com/w3ctag/privacy-principles/issues/280 91 | 92 | Pete: this has come up in WebGPU... I take the comment to say this is a good principle but not good examples... I agree. Lines of code not useful. 93 | 94 | Nick: a separate argument that making it expensive to get to... may not be useful because sometimes the attacker may be able to spend that cost. but making attacks expensive is definitely still a benefit that we care about. 95 | 96 | Dan: Happy to assign to Jeffrey - do we have other guidance for Jeffrey? 97 | 98 | ### https://github.com/w3ctag/privacy-principles/issues/281 99 | 100 | Nick: I think Martin is familiar with this - I think there is a distinction on granularity - however we should reference... 101 | 102 | ### https://github.com/w3ctag/privacy-principles/issues/282 103 | 104 | Dan: Martin would like to include identifiers... Feels right that we should include it... 105 | 106 | Dan: **will make PR** 107 | 108 | ### https://github.com/w3ctag/privacy-principles/issues/283 109 | 110 | Nick: where did this come from? 111 | 112 | Wendy: the conversation was - it's low cost if the user can change their mind.. 113 | 114 | Nick: cases where information is like that? 115 | 116 | Robin: something that's only valuable if it's live...? 117 | 118 | Robin: I don't mind removing it. 119 | 120 | ### https://github.com/w3ctag/privacy-principles/issues/284 121 | 122 | Pete: I think we can remove the clause in both sections. 123 | 124 | Nick: just k-anonymonity? 125 | 126 | Pete: I'm not sure what's most notable about timing attacks ... or... 127 | 128 | **we agree to remove both** 129 | 130 | ### https://github.com/w3ctag/privacy-principles/issues/285 131 | 132 | Nick: there are lots of caveats -- but our section contains lots of caveats... 133 | 134 | Robin: feedback isn't super clear... 135 | 136 | Pete: i think martin shares my concerns about anciallry data - we can point him to that issue... 137 | 138 | Robin: I think that might make sense... 139 | 140 | ### We agree to merge #336 141 | 142 | -------------------------------------------------------------------------------- /i18n-checklist-response: -------------------------------------------------------------------------------- 1 | This short review is for the following spec: [Spec_name](url_of_the_spec). 2 | 3 | 1. [ ] _If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc),_ **ensure that there’s metadata about and support for basic things such as language and text direction**. Also check the detailed guidance for [Language](https://www.w3.org/TR/international-specs/#resource) and [Text direction](https://www.w3.org/TR/international-specs/#text_direction). 4 | 5 | Comments_go_here. 6 | - [X] Not applicable 7 | 8 | 2. [ ] _If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics._ **take into account the different typographic styles used around the world (for things such as line-breaking, text justification, emphasis or other text decorations, text selection and units, etc.)** Also check the detailed guidance for [Typographic support](https://www.w3.org/TR/international-specs/#typography). 9 | 10 | Comments_go_here. 11 | - [X] Not applicable 12 | 13 | 3. [ ] _If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc._ **make allowances for the ways different scripts handle units of text**. Also check the detailed guidance for [Text-processing](https://www.w3.org/TR/international-specs/#operations). 14 | 15 | Comments_go_here. 16 | - [X] Not applicable 17 | 18 | 4. [ ] _If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers_ **understand the implications of normalisation, case folding, etc**. Also check the detailed guidance for [Text-processing](https://www.w3.org/TR/international-specs/#operations). 19 | 20 | Comments_go_here 21 | - [X] Not applicable 22 | 23 | 5. [ ] _If the spec (or its implementation) sorts text_ **ensure that it does so in locally relevant ways**. Also check the detailed guidance for [Text-processing](https://www.w3.org/TR/international-specs/#operations). 24 | 25 | Comments go here. 26 | - [X] Not applicable 27 | 28 | 6. [ ] _If the spec (or its implementation) captures user input_ **ensure that it also captures metadata about language and text direction, and that it accommodates locale-specific input methods**. 29 | 30 | Comments go here. 31 | - [X] Not applicable 32 | 33 | 7. [ ] _If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries_ **ensure that it will represent time as expected in locales around the world, and manage the relationship between local and global/absolute time**. Also check the detailed guidance for [Local dates, times and formats](https://www.w3.org/TR/international-specs/#locale). 34 | 35 | Comments go here. 36 | - [X] Not applicable 37 | 38 | 8. [ ] _If the spec (or its implementation) allows any character encoding other than UTF-8._ **make sure you have a convincing argument as to why, and then ensure that the character encoding model is correct**. Also check the detailed guidance for [Characters](https://www.w3.org/TR/international-specs/#characters). 39 | 40 | Comments go here. 41 | - [X] Not applicable 42 | 43 | 9. [ ] _If the spec (or its implementation) defines markup_ **ensure support for internationalisation features and avoid putting human-readable text in attribute values or plain-text elements**. Also check the detailed guidance for [Markup & syntax](https://www.w3.org/TR/international-specs/#markup). 44 | 45 | Comments go here. 46 | - [X] Not applicable 47 | 48 | 10. [ ] _If the spec (or its implementation) deals with names, addresses, time & date formats, etc_ **ensure that the model is flexible enough to cope with wide variations in format, levels of data, etc**. Also check the detailed guidance for [Local dates, times and formats](https://www.w3.org/TR/international-specs/#locale). 49 | 50 | Comments go here. 51 | - [X] Not applicable 52 | 53 | 11. [ ] _If the spec (or its implementation) describes a format or data that is likely to need localization._ **ensure that there’s an approach in place which allows effective storage and labelling of, and access to localised alternatives for strings, text, images, etc**. 54 | 55 | Comments go here. 56 | - [X] Not applicable 57 | 58 | 12. [X] _If the spec (or its implementation) makes any reference to or relies on any cultural norms_ **ensure that it can be adapted to suit different cultural norms around the world (ranging from depictions of people or gestures, to expectations about gender roles, to approaches to work and life, etc)**. 59 | 60 | The document has had input from and has been reviewed by people from multiple cultures but we would be more than open to any feedback on how to make it more widely applicable and understood. 61 | - [ ] Not applicable 62 | 63 | Short i18n review checklist is [here](https://www.w3.org/International/i18n-drafts/techniques/shortchecklist.html) 64 | -------------------------------------------------------------------------------- /meetings/2023-12-06-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 6 December 2023 2 | 3 | Present: Jeffrey, Robin, Amy, Dan, Nick, Pete, Wendy, Sam 4 | 5 | Regrets: Don 6 | 7 | ## TAG Call Readout 8 | 9 | Dan: last week, asked TAG to come to consensus on the meat of the privacy principles document, per the text we agreed on last week. not full TAG consensus on the current document. agreed we would shoot for next week; on track. feel like we're getting there. lots of editorial feedback, general support for the substance. noted that the document was long. 10 | 11 | ...outlined that we would plan to wind down the activity of this task force over coming months. continue editorial work more asynchronously. next year at some point we can officially wind down the task force. not sure how that fits with the process of moving to W3C Statement. 12 | 13 | Jeffrey: would like issues on words needed to look up. 14 | 15 | Nick: were there no substantive comments? 16 | 17 | Dan: not all reviewed in detail, but generally positive on substance. 18 | 19 | ## https://github.com/w3ctag/privacy-principles/pull/369 20 | 21 | Jeffrey: I checked with people... i think we can merge... 22 | 23 | Pete: the idea of a vulnerable person being almost anyone on the planet waters down what we're trying to say about vulnerable people... 24 | 25 | Jeffrey: i filed [373](https://github.com/w3ctag/privacy-principles/issues/373) to keep thinking about that... 26 | 27 | Peter: fine with merging this and having that conversation. 28 | 29 | Robin: yes I think it's good. 30 | 31 | Dan: +1 32 | 33 | **merged** 34 | 35 | ## https://github.com/w3ctag/privacy-principles/pull/379 36 | 37 | *lower case web* 38 | 39 | Jeffrey: I think this ready to merge... 40 | 41 | **merged** 42 | 43 | ## https://github.com/w3ctag/privacy-principles/pull/380 44 | 45 | Robin: it's not just about prevention... 46 | 47 | *we agree to take jeffrey's change* 48 | 49 | **merged** 50 | 51 | ## https://github.com/w3ctag/privacy-principles/pull/381 52 | 53 | Nick: *suggests an editorial change*, but it's not necessary. 54 | 55 | Dan: wfm. 56 | 57 | **merged** 58 | 59 | ## https://github.com/w3ctag/privacy-principles/pull/382 60 | 61 | Jeffrey: in response to Yoav's question... felt we should be precise... also noticed that the user agent principle is almost the same... 62 | 63 | Nick: I like the idea of consolidating... I do think this loses the "needed to satisfy goals" or "is aligned with the user's interests"... I think what's necessary to achieve the user's interests is unclear. 64 | 65 | Jeffrey: "either necessary to achieve the user's goals or what aligns with their wishes and interests"... 66 | 67 | Dan: interests has 2 meanings... 68 | 69 | Jeffrey: worth addressing. 70 | 71 | Nick: I think "wishes and interests make it pretty clear"... 72 | 73 | Jeffrey: [suggested change](https://github.com/w3ctag/privacy-principles/pull/382/files#r1417714994) 74 | 75 | Dan: lgtm 76 | 77 | Nick: this removes "loyalty" re-statements and I'm ok with that. 78 | 79 | Pete: is this restricting ... still fine for privacy if UAs are still sending non-private data? 80 | 81 | Jeffrey: could broaden it to "restricted data they transfer"... 82 | 83 | Nick: we do say that minimization applies to all personal data even if it's not identifiable... it could be all the relevant datat that you could transfer... 84 | 85 | Pete: for the sake of brevity just say data rather personal data 86 | 87 | Nick: because personal data has a definition... 88 | 89 | *we agree to say data and it links to the def of personal data* 90 | 91 | **merged** 92 | 93 | ## https://github.com/w3ctag/privacy-principles/pull/384 94 | 95 | Pete: I'm OK although i feel processing time and bandwidth are important... 96 | 97 | Jeffrey: I feel they're only tangentially related to privacy... and it's not clear that these APIs use undue processing time or bandwidth... 98 | 99 | Nick: users might want to configure their agents to save processing time & bandwidth... related to privacy... not sure what's what we're saying here... 100 | 101 | Dan: *example of low bandidth high latency network* 102 | 103 | Jeffrey: the UA often prioritizes these kinds of APIs outside of the critical path... 104 | 105 | Amy: I think all of this is captured by "may know something" therefore the change is fine. 106 | 107 | Nick: I agree about separating the decision... I suggest we remove the text and open a new issue about resource minimization and control. Doesn't need to be in v1. 108 | 109 | **merged** 110 | 111 | ## https://github.com/w3ctag/privacy-principles/pull/385/ 112 | 113 | Dan: wfm 114 | 115 | **merged** 116 | 117 | ## https://github.com/w3ctag/privacy-principles/issues/377 118 | 119 | Jeffrey: yoav says the mitigation one webperf api is using is to add noise - it's posssible that they could allow users to turn the knob way up... either backburner or say we're not doing anything about it. 120 | 121 | Robin: fine either way 122 | 123 | Wendy: ...these are considerations having read the principles... 124 | 125 | ## https://github.com/w3ctag/privacy-principles/issues/378 126 | 127 | Jeffrey: I think this is covered by all the caveats in the introduction... 128 | 129 | -------------------------------------------------------------------------------- /meetings/2021-08-18-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Meeting Minutes 2 | 3 | 18 Aug 2021 4 | 5 | Present: Tess, Christine, Jonathan, Pete, Robin, Sam, Wendy, Jeffrey 6 | 7 | Scribe: Robin 8 | 9 | Chair: Jeffrey 10 | 11 | ## Pull Requests 12 | 13 | ### [Define party by accountability, not ownership? #32](https://github.com/w3ctag/privacy-principles/pull/32) 14 | 15 | JY: This overlaps with #26, you talked about this last week. Is there more? 16 | 17 | RB: We generally agreed that this seemed like a good idea. 18 | 19 | JY: We had a question in Google about whether we should use "data controller" to define this, but we weren't sure. 20 | 21 | CR: We spent time on terminology in general. 22 | 23 | ### [Identity and boundary](https://github.com/w3ctag/privacy-principles/pull/28) 24 | 25 | JY: Ready to merge? 26 | 27 | PS: Is this talk later or controversial forever? 28 | 29 | JY: It's talk later. 30 | 31 | RB: We should try to get to the consensus thing. 32 | 33 | ### [Logo discussion](https://github.com/w3ctag/privacy-principles/pull/20) 34 | 35 | TO: We should probably leave it unmerged for now. 36 | 37 | ### [Update the Status](https://github.com/w3ctag/privacy-principles/pull/17) 38 | 39 | JY: I think this is good? 40 | 41 | RB: Yeah. 42 | 43 | Tess to merge #17. 44 | 45 | TO: Merged! 46 | 47 | ## Issues 48 | 49 | ### [Issue #35: Opt-in consent / Opt-out Global Control](https://github.com/w3ctag/privacy-principles/issues/35) 50 | 51 | CR: `First sentence: Change “control” to “express a preference for what processing is done to their data”.` 52 | 53 | RB: Agreed. 54 | 55 | CR: `Second sentence: “uses” would seem more relevant in this context than “purposes”, or perhaps “uses and/or purposes”.` 56 | 57 | RB: I'm trying to parse out what `use` is if it's not processing/means or purpose. 58 | 59 | CR: Consent is to the means of the purposes. 60 | 61 | RB: I think we agree, it's a question of mapping the definitions. 62 | 63 | JY: I think it makes sense but we'll need to define `use` or figure out the definition. 64 | 65 | WS: Do we really want to define opt-in/out in this way? 66 | 67 | CR: We need to consider that, yes. 68 | 69 | Group — let's see what we all think next week. 70 | 71 | CR: great site for dark patterns 72 | 73 | CR : Also thought about tiers, interesting approach. But should vulnerable people have to opt out, that is a problem. Also there are issues about choosing to opt out. 74 | 75 | RB: Yes, vulnerable people should be out automatically, though it incentivises not knowing. And choice is problematic. 76 | 77 | JY: The names optin/out are problematic, we should change that. 78 | 79 | CR: Permissions are important, we should bring them in. 80 | 81 | JY: You're right that we should try, not sure how but yes. 82 | 83 | RB: Agreed. 84 | 85 | JY: Similar to privacy goals vs how browser can enforce them. 86 | 87 | ### [Unwanted same-site recognition #34](https://github.com/w3ctag/privacy-principles/issues/34) 88 | 89 | CR: The document suggests that users will be recognised but users might not expect that their whole behaviour is kept. 90 | 91 | RB: I think there's a third thing which is profiling. 92 | 93 | CR: Yes, but I think that there is a fine line between behaviour and profiling, we have to be careful about that. 94 | 95 | RB: Agreed. 96 | 97 | JY: I'm nervous about blanket saying "do not expect tracking of previous interactions", also recommending content is a form of profiling. 98 | 99 | CR: Users might expect maintenance of state for different purposes (cart, identity) but not others. But I agree we might need to revisit the section. This opens the question of whether we need a section on same-site tracking. 100 | 101 | JY: I think yes. 102 | 103 | CR: We might want to have recommendations for this section, we don't have them now. Nick's work does have some best practices for "unwanted same-site" and for tracking. 104 | 105 | JY: Right, we can't just subsume this into the identity section, fingerprinting belongs here. 106 | 107 | RB: I wonder how far we can go with guidance but it would be interesting to grapple with it. 108 | 109 | CR: There is something already in the @@? 110 | 111 | JY: I can take a stab at some of that, I'd appreciate someone else taking a stab at same-site. 112 | 113 | PS: I can dot that. 114 | 115 | ### ["Pseudonymous" with respect to whom? #33](https://github.com/w3ctag/privacy-principles/issues/33) 116 | 117 | WS: While reading the doc from the perspective of somebody controlling data rather than the user, a solve might be as simple as "pseudonymous with respect to the first party" 118 | 119 | RB: That works for me! 120 | 121 | JY: Pseudonymous data and pseudonymous _for a party_ (which may be the first) might be usefully distinguished. 122 | 123 | RB: Agreed, ongoing rewrite. 124 | 125 | ### [Privacy principles by category (high level privacy threats) #27](https://github.com/w3ctag/privacy-principles/issues/27) 126 | 127 | JY: We might not have anything new? 128 | 129 | CR: Section of document that pulled out privacy issues from the IETF document. It's been a while since that doc was created, we might want to define and describe them in W3C space. The doc talks about stored data compromise — I think we could expand that to data compromise at large, including in transit. 130 | 131 | JY: SGTM. I will PR. 132 | 133 | ### [Definitions #26](https://github.com/w3ctag/privacy-principles/issues/26) 134 | 135 | RB: Nothing new since the meeting, it's all stuff I have to do. 136 | -------------------------------------------------------------------------------- /meetings/2022-11-16-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Call - 16 November 2022 2 | 3 | Present: Nick, Dan, Don, Christine, Jeffrey, Robin 4 | 5 | Regrets: Amy, Sam, Peter, Tess, Wendy 6 | 7 | ## https://github.com/w3ctag/privacy-principles/pull/193 8 | 9 | Dan: I reviewed. should apply to web standards beyond W3C. (others: yes!) 10 | 11 | Jeffrey: last paragraph could be shorter, suggested different wording. 12 | 13 | Christine: also for people ... ... who want to know about principles for web privacy. web developers 14 | 15 | Nick: applicable to the end user who cares about privacy? 16 | 17 | Jeffrey: I think it's dangerous... if a user reads this and thinks "i'm prottected because this doc" - false sense of security. 18 | 19 | Nick: people can read this doucment even 20 | 21 | Dan: others can read it. 22 | 23 | Robin: it's context... 24 | 25 | Dan: merge, modulo changes. 26 | 27 | Jeffrey: putting web developers in primary audience... 28 | 29 | Don: will move to primary audience. 30 | 31 | Jeffrey: then no obkjection to merging after the fixes are in. 32 | 33 | Don: **to merge** 34 | 35 | ## https://github.com/w3ctag/privacy-principles/pull/195 36 | 37 | Nick: 2 related things - there was already a section on unwanted info - it's very useful. A lot of things about online harassment will be in that section.. there can be online harassment that's not just communicated to the person that's being harassed. Wanted to provide some citations. On principles: "Systems that allow for communicating on the Web must provide an effective capability to report abuse." ... that's the summary... Would welcome more detailed principles... 38 | 39 | Robin: left a few small notes 40 | 41 | Jeffrey: we can't just call out lgbtq and women without other groups... maybe just "any disadvantaged / more likely to be a victim of harassment"... 42 | 43 | Nick: the citation has info on those groups... I'm also fine with just making the claim about "marginilized". 44 | 45 | Robin: we can cite that study as indicating.. but also more... There's a way of citing the.. 46 | 47 | Jeffrey: the study lists race as well... 48 | 49 | Dan: more impactful to provide a longer listing of impacted groups, with "and other marginalized groups" 50 | 51 | Christine: and note that anyone can encounter harassment 52 | 53 | Don: also people who didn't know they were in a group 54 | https://www.courts.ca.gov/documents/dv500info.pdf <- info on domestic violence restraining order.. People in a domestic violence situation and immediately need protection from privacy violation from people who used to be trusted people. and this is a hard problem. 55 | 56 | Dan: also disabled... neurodivergent.... 57 | 58 | Nick: One other question i'd like feedback on - should we have a principle that we need to make it possible to establish rules... 59 | 60 | Nick: if you're going to develop a new protocol for sending messages you should have ways to provide a link to the code of conduct... 61 | 62 | Jeffrey: whatever app has a privacy policy linked... 63 | 64 | Nick: mailing lists are a good example.... 65 | 66 | Jeffrey: they all have a sign up page and a unsub page -- could have a CoC. 67 | 68 | Robin: email RFCs require to be a report@ and abuse@... maybe not effectve but they have it... 69 | 70 | Nick: good example of practice... 71 | 72 | Christine: ability to block harasser is useful 73 | 74 | Jeffrey: +1 75 | 76 | Nick: +1 77 | 78 | Nick: you need some way to share the blocking... 79 | 80 | Dan: we need to keep it high level 81 | 82 | Nick: on sharing blocklists - we could make it more high level like "pooling mitigations" - if you were to design a protocol in such a way tha someone can send messages en masse and no way to link the sender -- that would be a bad design for harassment. 83 | 84 | Nick: i won't add the CoC thing but will make changes on impacted groups... and on pooling blocklists and mitigation - there's a bullet point in unwanted info is that oK? 85 | 86 | Jeffrey: I think what is there is fine. 87 | 88 | Jeffrey: it's hard for us to require enforcement as protocol designers... 89 | 90 | Christine: i am in favor of enforcement - however in this case we should not speak to the requiement of enforcement unless it's technical enforcement (e.g. encryption to enforce confidentiality). 91 | 92 | Dan: +1 93 | 94 | Don: comes back to the idea of enabling parties to share their own policies... if you're a party then you put a file in .wellknown and say that's our policy - if it's enforced by law that's out of our space. If there's a web standard... document how a party can share its policies with users and with other parties 95 | 96 | **agreed to merge** 97 | 98 | Nick to revise, share asynchronously and get it resolved/merged in lieu of a meeting next week 99 | 100 | ## Vulnerability 101 | 102 | *christine to do a PR based on text she's been working on* 103 | 104 | Nick: principle? 105 | 106 | Christine: principle of "degrade gracefully" 107 | 108 | Dan: **Feature detection and graceful degration should take into account the idea that some functionality might be traded for increased privacy.** maybe? 109 | 110 | **Christine to write PR** 111 | 112 | Nick: Should there be guidance for people designing features that "you should make it safe". Even for people in vulnerable situations... 113 | 114 | Christine: design as if all your users are vulnerable... 115 | 116 | Don: or "your users don't know that they're going to become vulnerable due to a family crisis" 117 | 118 | Dan: let's start with this and then iterate. 119 | -------------------------------------------------------------------------------- /meetings/2022-06-15-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Call - June 15 2022 2 | 3 | Present: Dan, Don, Shubhie, Jonathan, Nick 4 | 5 | Regrets: Christine, Pete, Sam, Wendy 6 | 7 | ## [Nick's PR](https://github.com/w3ctag/privacy-principles/pull/170) 8 | 9 | Nick: the request was - we have had this issue a few times - sometimes browsers do share data that is not for the immediate need - some questions of whether this was consistent with privacy principles and if it is what makes it acceptable / how does it fit together with data minimisation. Suggestion is to have a general principle of minimization ... added a citation to the TAG document ... after some basic minimsation added a list of ways browsers send data that is not strictly necesasary - e.g. telemtry, updates, prefetching, etc... A few different justifications. In some cases browsers do it because if they dont then there could be a more intrusive mechanism. In some cases users would understand what's happening - and would be fine with it. Aggregation - aggregating or deientifing data - is liekly to shift that balance - people would be more likely to see it as aligned with their goals. There will be some people who won't want that and the best way to establish that is to ask users their own preferences and goals. Finally - minimization should apply even if you don't think there is harm to the data colleciton - you don't know how it might get re-used later. 10 | 11 | Dan: minimization was only a draft finding https://www.w3.org/2001/tag/doc/APIMinimization 12 | 13 | Jonathan: should we make it part of this task force/document? 14 | 15 | Dan: informative reference is okay, but could also copy/paste if there are key or specific recommendations we want to make. it could have more weight if included in the privacy principles. 16 | 17 | Nick: could integrate top 3 recommendations and then cite draft finding for background literature. 18 | 19 | Don: On this PR - it would give reviewers of new specs a principle to cite when you do the review - not just the reviewer's judgement. 20 | 21 | Shubhie: overall I like the direction of this PR. Appreciate the flow of it. Makes sense to me. Question on scope and audience - API design has the right audience - the next one "ua's should directly ask.." don't know who the audience is. If this is aimed at web site developers we need to be careful - or is this aimed at UAs? 22 | 23 | Nick: I don't think this is guidance for site developers - I think it's useful to describe responsibility - some things will not be the responsibility of the browser. Browser can't do everything. We should note thta sites also have responsibilities - and that could be future guidance for API design. Just need to note the shared responsibility. 24 | 25 | Shubhie: either just remove sites or what nick was suggesting. "APIs should be designed so that sites can..." 26 | 27 | Jonathan: removing sites from the bullet points - removing sites broadens the scope of the telemetry. 28 | 29 | Nick: i think we should include sites ... List of bullet points is "this is things that browsers to today"... Including site debugging purposes. Some people think that's bad. But this just records this fact. 30 | 31 | Jonathan: I think data browser collects for itself vs. data it exposes via APIs to web sites are different. 32 | 33 | Nick: e.g. CSP violation - sent to an endpoint on the site for reporting. Auditing. 34 | 35 | Dan: worth splitting apart the 2 different types of data... Don't think it changes the conclusion though... 36 | 37 | Nick: any more examples for the list - where browsers are sharing data - but not to enable a navigation... 38 | 39 | Don: PATCG - a bunch of early-stage proposals that this would definitely apply to... 40 | 41 | Dan: safe browsing use cases...? 42 | 43 | Nick: i think that's pre-downloaded 44 | 45 | Jonathan: telemetry is shared... reporting of sites vs debugging issues... DNS ... https... TLS another non site related things. COnnecting pooling. Telemetry is shared. 46 | 47 | Shubhie: focus on APIs... in that case, I'm looking at .. if a site wants to beacon .. timing data ... are we asking them put up a user prompt? 48 | 49 | Nick: Some browsers might say it's a violation of privacy for browsers to send telemetry; some might say no. One apperoach might be to have it in the [first use] set-up as a question. 50 | 51 | Shubhie: In the context of APIs like timing APIs... The browsers should seek user preference on behalf of all web sites? 52 | 53 | Nick: yes - it user says they're OK with site telemtry. .. 54 | 55 | Jonathan: user agent choice... if you're using a certain browser it might ... Could that be part of the principle? 56 | 57 | Don: Login Status API in Safari and Site Enagement Service in Chromium/Chrome... the browser can tell if the user is interacting with a site they're comfortable with... we could say that when the browser is in a higher trust relationship then it can automatically make decisions... not hard to tell a site user goes to and never goes to again apart from a site that they show engagement with (signing in, time on site, visits, submitting a form) 58 | 59 | Dan: I think we do have the cocept of sites that have more engagement.... 60 | 61 | Nick: yes - we could have Yes/No, asking user on first use, asking every time... don't think we should proscribe one method. 62 | 63 | Shubhie: instead of "asking" could we rephrase UAs should seek to understand and act / respect users' desires / engagement level ... 64 | 65 | Dan: makes sense to me. 66 | 67 | Nick: yeah. I can take a pass at that. We can say "one example is you can ask about telemetry - but not the only option". 68 | 69 | Shubhie: i think this supercedes #162 70 | 71 | Nick: yes if this has consensus... 72 | -------------------------------------------------------------------------------- /meetings/2022-04-20-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Minutes - Wed, 20 April 2022 2 | 3 | Present: Robin, Dan, Wendy, Sam, Nick, Tess, Don, Christine 4 | Regrets: Jeffrey 5 | 6 | ## [PR147](https://github.com/w3ctag/privacy-principles/pull/147) 7 | 8 | Robin: PR to a PR - overall pretty straightforward... 9 | 10 | Tess: part of the original PR ... 11 | 12 | [discussion on where to put the Pew study showing people are unhappy] 13 | 14 | Dan: i think we should have it... 15 | 16 | Christine: advocating for privacy - for other people as well... 17 | 18 | Dan: the PR works for me. 19 | 20 | Sam: thinking of ... cases where business would want to retain data - e.g. preventing abuse by retaining data - or "this is a bad customer"... 21 | 22 | Robin: that's a real-world concern - not sure how to address it at a principle level... 23 | 24 | Dan: maybe out of scope? 25 | 26 | Don: a car service records number of rides you took - and a different figure for number of rides you took where you didn't barf. (If you access "all the data your company has on me" you might not get everything that feeds into their decision making) Negative space. 27 | 28 | Nick: [would like to save the reference to the Pew thing] 29 | 30 | Robin: [works that in while we discuss] 31 | 32 | ## [143](https://github.com/w3ctag/privacy-principles/pull/143) 33 | 34 | Don: trying to exclude the first party being the vps or content editor - role playing game where a game master uploads content and players play... splitting out the control of site content - user who's the game master - vs control of system administration of the hardware on which the site runs -- or are you that party in the middle. Contract with that company - who's in control. 35 | 36 | Dan: masto-host example - 37 | 38 | Don: can you look at a list of users and decide to kick someone off? 39 | 40 | Dan: yes. 41 | 42 | Don: then you're the 1st party and the host would be the service provider. 43 | 44 | Robin: it's not clear to me that the user who controls ... is the 1st party. a case where .. decided that the 1st party handed over control to a 3rd party... If you inject a fb pixel into your site then you've transfered control to someone else. 45 | 46 | Don: it's the party that should have legal control not whatever party managed to peek at the data. 47 | 48 | Robin: legally in terms of control - fb considered a controller despite being a 3rd party... 49 | 50 | Christine: don't think we should be talking about what the law is or is not... 51 | 52 | Robin: some legal cases 3rd parties have been identified... as controller. 53 | 54 | Wendy: and the law may vary by jurisdiction 55 | 56 | Christine: as far as we can go.... 57 | 58 | Robin: dom't think we should include legal concerns here... 59 | 60 | Don: ideal controler in principle... based on user's perception of what site they're on. re-write based on "the understanding of the user"... 61 | 62 | Robin: *party that controls the origin* makes sense to me. *party who controls the use of information on an origin* .. broadens the information to too many other parties... 63 | 64 | Don: I'd like it to be narrower. A person on medium.com is in control of their channel - but they don't have access to info on who their users are. Your hosing service is not your first party. Instead of *control of the information* maybe it's *party the user believes they are interacting with*. (Not everyone who can get a pixel onto a page is a first party) 65 | 66 | Robin: i think the original text is better... 67 | 68 | Pete: i think it should be narrower. We need something tied to the application itself - not who is pulling the levers. 69 | 70 | Nick: we're not going to get a 1 sentence def... I share pete's privacy concern but don't think it needs to be in the def of first party to an interaction... 71 | 72 | [discussion on the origin vs the URL bar] 73 | 74 | Tess: Is there anyone who can't live with the current text for FPWD? 75 | 76 | Don: i can live with the current text if there is an issue opened (I will open the issue) 77 | 78 | Tess: let's have a red box right there - I'd be happy with that. 79 | 80 | ## [144](https://github.com/w3ctag/privacy-principles/pull/144) 81 | 82 | Don: has come up in FPS proposal - corporate structure - makes it difficult to figure out who the "owner" of a site is - the doc should be independent of figuring this out (In general, more transparent ownership of transnational companies and better compliance with tax laws would be good things, but out of scope for this document) 83 | 84 | Christine: LGTM 85 | 86 | Robin: +1 87 | 88 | **consensus to merge** 89 | 90 | ## [133](https://github.com/w3ctag/privacy-principles/pull/133) 91 | 92 | Robin: i think yes we should merge 133. 93 | 94 | Nick: I raised some issues... Jeffrey had some questions - don't feel it needs to be settled. But we should have an issue - could lead to confusion because we don't have consensus. Could we have an issue box on what we do about the cases beyond the immediate goal... 95 | 96 | Pete: Waiting for feedback from Jeffrey. 97 | 98 | Nick: I can come up with issue text. 99 | 100 | Robin: we should proabbly also merge pr 14 from tess and reject ... as overtaken. 101 | 102 | 103 | 104 | Tess: marged 14. 105 | 106 | Robin: i will update the sotd. 107 | 108 | **consensus to go to fpwd with changes and updates described above** 109 | 110 | Robin: everyone go through the draft please. 111 | 112 | Tess: alphabetize the definitions in high level threats? 113 | 114 | **general agreement** 115 | 116 | Peter: align "principles" 117 | 118 | Robin: prefer we not use "principle" on each principle. 119 | 120 | Tess: what if we just moved appendix C to the top? Ethical web princople style? 121 | 122 | Dan / Robin: can we do it later? 123 | 124 | Tess: OK. 125 | 126 | -------------------------------------------------------------------------------- /meetings/2023-04-26-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 26 April 2023 2 | 3 | Present: Dan, Jeffrey, Don, Wendy, Nick, Pete 4 | Regrets: Sam 5 | 6 | ## 3rd party cookie finding 7 | 8 | Discussion on [3rd party cookie](https://w3ctag.github.io/web-without-3p-cookies/) finding and "design for purpose" 9 | 10 | Nick: maybe this concept should go into the privacy principles doc itself... 11 | 12 | ## [People's Agents](https://github.com/w3ctag/privacy-principles/issues/255) 13 | 14 | Jeffrey: U suspect we should go back to user agents. 15 | 16 | Nick: agreed. "people" is generally a good direction, but "user agent" is just the clear term that we need to keep using. 17 | 18 | Dan: I agree. 19 | 20 | *Jeffrey to do a PR* 21 | 22 | Jeffrey: on "principle" definition... 23 | 24 | *Jeffrey to do a PR* 25 | 26 | ## [Suggestions on Introduction](https://github.com/w3ctag/privacy-principles/issues/253) 27 | 28 | Jeffrey: on point 1 I disagree - ... Mention of the whole web - emphasizes the world wide nature of the web... 29 | 30 | Dan: I'm ok to leave it alone. 31 | 32 | Jeffrey: 2nd one I think is correct. 33 | 34 | Dan: agree. 35 | 36 | Jeffrey: [on point 3] yes I think hes' right I suggest we ask him to write the PR for the improvement... 37 | 38 | ## [collective governance](https://github.com/w3ctag/privacy-principles/issues/254) 39 | 40 | Dan: I agree with his points. 41 | 42 | Pete: if i understand his first para correctly - if it's not violating ... 43 | 44 | Nick: I think it's already covered ... 3rd parties ... I think our current text covers it. 45 | 46 | Don: with self-dealing ... around the question of noise that's introduced, in some cases where a user agent introduces noise, you need to have a certain scale in order to get reasonable signal... Issue in web-without-3rd-party-cookies... If a privacy mitgation requires adding noise, an extremely widely used 3rd party could be able to get usable signal (and build user profiles) ... If a 3rd party knows they operate at a given scale... then it's effectively self-dealing 47 | 48 | https://github.com/w3ctag/web-without-3p-cookies/issues/2 49 | 50 | Nick: I understand the concern but I don't think it's self-dealing... 51 | 52 | Jeffrey: I think it is self dealing. A browser could tune the browser so only they could extract the data... which would be bad. I think it's too specific to say "in particular"... 53 | 54 | Don: maybe we can just mention it in the self dealing section.. i can come up with some wording. 55 | 56 | Jeffrey: I think it is but it's very specific... the people designing web standards can also self-deal. 57 | 58 | Don: if you talk to end user - what comes up - when end users have privacy concerns they mention a few specific large companies. if we want this document to be relevant to privacy concerns users have we should say something about the scaling issue. 59 | 60 | Pete: I agree that the current text does it. but i agree with Don to make sure the concern is addressed. 61 | 62 | Don: problem comes when you have standards discussed with knowledge of what's required to overcome certain levels of noise. 63 | 64 | Wendy: that's across-temporal dealing that doesn't fit within neatly the discussion of self dealing... It's a possible problem but a separate problem. Suggest rejecting Chris's change. 65 | 66 | Don: if not under self-dealing then where? Happy to put it another area.... (new issue: 67 | https://github.com/w3ctag/privacy-principles/issues/261 ) 68 | 69 | Nick: I do think we should talk about centralization... i'd be fine to put it in the private ad document... 70 | 71 | Dan: what in 254 are we saying yes to? 72 | 73 | Wendy: removing the s from scales 74 | 75 | Jeffrey: more citations 76 | 77 | ## [PR on the EWP](https://github.com/w3ctag/ethical-web-principles/pull/93) 78 | 79 | Jeffrey: just FYI ... 80 | 81 | Nick: this is a patch to the verify information... 82 | 83 | ## [Mention limitations on data rights](https://github.com/w3ctag/privacy-principles/issues/252) 84 | 85 | Nick: my intial reaction -- we talk about this isn't absolute several other places in the document -- i don't know if we need to have that kind of caveat included in every subsequent principle... We could say "solutions could come into tension with other principles"? 86 | 87 | Jeffrey: talking about "rights" tends to make them more important... general text says principles here conflict with other principles elsewhere... i don't know that we've written "the publuc have a right to know certain things"... 88 | 89 | Pete: I like Nick's point - I think just having a caveat on the top of the doucment is more appealing.. 90 | 91 | Nick: in the principle we say these rights should be facilicated - that doesn't sound super absolute. 92 | 93 | Dan: we don't say "must be enforced". 94 | 95 | Nick: UAs should facilitate erasing data. that seems in line with what we want to ask... 96 | 97 | Jeffrey: we're also writing a principle about the services... services should facilitate the use of these rights. 98 | 99 | Dan: I'm leaning towards Nick's view that we already have enough caveats... 100 | 101 | Pete: also it seems far ... 102 | 103 | Jeffrey: Brad would be happy if we deleted statement about other actors... 104 | 105 | Nick: I think to accomplish most of the privacy things we talk about - will require facilitation by other actors. 106 | 107 | Jeffrey: i suspect we lose important things if we delete the other actors part. 108 | 109 | "we think this worry is covered by the other limitations on the whole document" 110 | 111 | Nick: e.g. 1.4 - is intented to apply to that section as well.. I don't think there needs to be a change but if so maybe something that says the rights section is not different from the other sections... 112 | 113 | Jeffrey: we can ask... 114 | 115 | Pete: i am kind of against adding negative statements into the doc... 116 | 117 | -------------------------------------------------------------------------------- /meetings/2022-07-20-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Call Minutes - 20 July 2022 2 | 3 | Present: Dan, Wendy, Christine, Nick, Shubhie, Don 4 | 5 | ## https://github.com/w3ctag/privacy-principles/pull/170 6 | 7 | Dan: this [tag review](https://github.com/w3ctag/design-reviews/issues/739) for *Back/forward cache NotRestoredReasons API* - 8 | an example of site developers looking for performance telemetry, and it's a case where TAG would love to have established principles on telemetry to point to. 9 | 10 | Nick: some people want browsers can have different heuristics -- some wanted "no, no heuristics are appropriate". 11 | 12 | Dan: look for wording that encourages browsers to seek user consent, but also enable 13 | ... has the user affirmatively agreed at some point (first use) to share telemetry with web sites? 14 | 15 | Shubhie: treating all web sites equally.. we talked about... should there be an elevation of privilege - a gate with access to powerful capabilities after that. e.g. bluetooth... powerful capabilities should be gated. Native apps have a natural places for that - installation. On the web we don't have such a thing. 2nd thing is user choice of not sharing. Some browsers have private motes. We need to help the user in both directions. 16 | 17 | ..."thresholds" for different access/permissions 18 | 19 | Nick: **to write text** 20 | 21 | ## https://github.com/w3ctag/privacy-principles/pull/173 22 | 23 | Shubhie: supporting user choice - in 2 directions - in sign-in it starts to become that signal - elevation of privilege. There might be other ones such as installing the app - should be a user's choice and browsers should suppor that. Should not be coerced - not consuming the content enough but being asked to sign in. If the user is choosing not to share identity - it can be implicit or it can be using a private mode - that deserves protection. Web sites blocking private modes can be another type of coercion. 24 | 25 | Dan: related to [https://w3ctag.github.io/design-principles/#do-not-expose-use-of-private-browsing-mode] 26 | 27 | Nick: for private mode we had a concern about how it's being deployed - we have a suggestioon that user agents shouldn't reveal it. what mitigations from user agents on coersive signin? 28 | 29 | Shubhie: user agents ... auto-fill... sso. If there was a first class API 30 | 31 | Dan: such as FedCM... 32 | 33 | Nick: it could be explicit - but what does the browser do? You can't hide from the web site whether the user is logged in... 34 | 35 | Shubhie: it's more that the browser has an explicit insight .. signed in and signed out... But what power do we have over web sites? 36 | 37 | Nick: do we want to have a principle about "web sites shouldn't do this" but if we have a UA guidelines then what would that be? 38 | 39 | Shubhie: it would would be a elevation of privilege signal... if the user has signed out... first party cookies... partitioning... storage access... gets into tracking as well... IP address... 40 | 41 | Don: don't know if it's just when the user does not *want* to present an identity. Sometimes the site has a reason to require an identity. If we're going to talk about not requiring an identity it should be about not requiring a user to present an identity in order to enable a site to do "bad things" 42 | 43 | Dan: need to account for first visits where you want to sign on, e.g. you just read about a new movie service and know you want to join 44 | 45 | Don: sites that just give you the summary and then require login to get the full info / article. A lot of users are used to this practice - it's common enough going back to the days of business reply mail postcards (and a long history of a business practice is imho a good sign that it's widely accepted) 46 | 47 | Dan: ...marginalised communties... 48 | 49 | Nick: maybe it's fine to give that guidance to web sites... we can give some reasons. Valuable to have the web experience - something useful if logged out. More than a sign-up form. Analogue is that we think user agents should help users present different accounts and help them protect their identities... such as *anonymous remailers*... 50 | 51 | https://relay.firefox.com/ 52 | https://duckduckgo.com/email/faq 53 | 54 | 55 | Don: we already cover something relevant - cross-context recognition. Just because you fill in your info to get info on one thing don't correlate to another thing. A user reflects different identities in different contexts.(b2b purchasing responsibilities are separate from family health care) Respnsibility of the site not to use info for cross-context recognition. "sites can ask the user for info relevant to context that they're in - but if you try to take that info and connect it outside the scope of what the user would choose to share then that's outside the principles." 56 | 57 | Shubhie: i think the private email discussion... presenting choice... missing... also notion of what are you actually agree to when you sign up or sign in. users don't understand that... maybe some text. 58 | 59 | Dan: [fedcm](https://github.com/w3ctag/design-reviews/issues/718) 60 | 61 | ### 2 announcements about fb encrypting tracking paremeters - and a research paper on timing attacks 62 | 63 | Nick: timing attacks: web site opens another window to see if the user is logged in and find account identifier for other web sites. Should either be addressed explicitly in privacy principles... Maybe just in privacy IG call and come back with a recommendation.. 64 | 65 | https://www.ghacks.net/2022/07/17/facebook-has-started-to-encrypt-links-to-counter-privacy-improving-url-stripping/ 66 | 67 | 68 | 69 | Wendy: useful addition to a collection (elsewhere) of examples of 2nd order privacy effects... ecossytem reactions to initial moves to protect privacy have rebound reactions. 70 | 71 | Nick: the paremeters one we expected but didn't expect it so quickly 72 | 73 | https://www.wired.com/story/web-deanonymization-side-channel-attack-njit/ 74 | 75 | Nick: timing attacks to see if you can find the user's email address... 76 | -------------------------------------------------------------------------------- /meetings/2022-09-07-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 7 September 2022 2 | 3 | present: Don, Jeffrey, Robin, Peter, Dan, Nick 4 | 5 | regrets: christine, amy, wendy, shubhie, tess 6 | 7 | 8 | ## Add a principle to support deception #181 9 | 10 | [discussion on balance] 11 | 12 | Jeffrey: anti-fraud people won't like "deception"; do you want me to ask them to propose a compromise 13 | 14 | Nick: we discussed not explicitly talking about deceoption if we talk aboUT APIs not being used to assert truth. 15 | 16 | Pete: I like ... thinking through the legalcy APIs. 17 | 18 | Robin: i think we can come up with a [balanced] approach. 19 | 20 | ## 177 21 | 22 | Pete: seems to say UAs might help ... current version says UAs *will* seems unappealing from a privacy perspective. I still think it is the case after a close read. 23 | 24 | Jeffrey: I think going back to *should* or *can* is totally fine here. UAs can make different decisions. 25 | 26 | *going through some editorial comments from Robin* 27 | 28 | Dan: Timing attacks... 29 | 30 | Robin: kind of attack I'm worried about - you click on their site to exit it and it loads a page with whatever code .. matches the timing and it uses 1st party cookies... 31 | 32 | Jeffrey: correlating timestamps ... timing attacks is really broad... 33 | 34 | Dan: So add a parenthetical? 35 | 36 | Pete: ephemeral fingerprinting... larhe list of ways... 37 | 38 | Nick: I agree that it's a good reference and an overloading of the term... 39 | 40 | Robin: in the editorial pass we link - in the section we say it's a type of timing attack and we also reference the doc from Pete. 41 | 42 | ## 170 43 | 44 | Nick: haven't split it up.. Jeffrey has made some comments about relational governance...? 45 | 46 | Jeffrey: my understanding ... data has effects across multiple people... use of that data can be either good or bad. Privacy people focus on the bad aspects. there are places where collecting data -- where collecting it is good enough for society that we want to do it. Telemetry data is I think an example of that. Most of the time it doesn't harm an individual user... but enough collective benefit ... 47 | 48 | Don: ...one of those rare examples where consent appropriate... 49 | 50 | Jeffrey: bugging users every time weant to send to telemetry might be causing harm.. Some input from users. The W3C .. we can get input from the right groups. We could say "when there is a collective benefit you should go to an open standards body" and "users should still have control over it - this is for the default" 51 | 52 | Don: I was thinking of browser telemetry and browser assisted mutliparty computation... "Yes I want to provide aggregated QA data and willing to give it to sites that follow this cryptographic telemetry protocol - might consent to it once when i set up my new browser - but any thing beyond that would require more consent" (example: Prio) 53 | 54 | Jeffrey: plausable. 55 | 56 | Pete: Just because these exist doesn't imply this is one of those cases... a mismatch - users pay the cost of benefiting the collective of sites... I suggested a checkbox when you install the browser.. some way of ensuring consent seems important. Not pushing a particular flow - just want to ensure users agree. I don't agree w3c is a proxy for a democratic collective... the user's voice. would feel a lot less worried if there was some language about what the bounds are. how much can people be conscripted for a collective benefit? "things users want their browsers to do" as an example. 57 | 58 | Nick: I think 2 potential areas - 1. we have a collective governance section... seems like a similar point. some decisions individuals aren't in a good position to make or some collective benefit or some cases where the individual who could be harmed isn't in the decision flow. could we integrate that into that section. That seems separate from 2. there can be a duty of loyalty for users but because users don't take the time to understand the details.. users don't make a case-by-case decision. So how can you have a duty of loyalty to users without bothering them? Let's try to get text on that that's separate from the collective [governance] question. 59 | 60 | Jeffrey: that makes sense... I will double check with performance people... asking telemetry to the install process makes sense... there is some collective governance that needs to happen. List of ancilary usses seems like a good starting point. 61 | 62 | Nick: I'll need to clarify ... the types of data... 63 | 64 | Robin: lots of good points... we need a balancing test. What you use when you make decisions on behalf of data subjects. A lot of what goes into balancing tests is what Pete is talking about... e.g. under GDRP you look at risks to the data subjects... what controls you have, etc... e.g. you should never have access to an IP address for telemetry... some things we can enforce at the browser level and some not. One thing to explore: is there a world in which we ... 65 | 66 | Dan: brittle to build policy into code... 67 | 68 | Robin: not necessarilly... balancing test result might lead to minor harm... 69 | 70 | Dan: design principles implications for APIs that collect telemetry 71 | 72 | Don: consent implies that you know the party you're consenting to.. not sure if you can have consent to a party to be determined later. or could be a browser preference. "I have a preference to allow my info to be used in such a way that it's cryptomagically prevented from being sale or processing of my data... but still technical consent" but realize this consent is not *legal* consent. Bigger issue of a legal / standards interaction issue. Consent has a specific meaning under GDPR. 73 | 74 | Nick: useful to avoid "consent" .. "consented data" is not a thing. More fruitful direction is purpose specification.. maybe we accept that it was right to say policy shouldn't be with data ... but APIs can have a purpose. We make sure it's focused on the use case and not have alt functionality which can be abused. Maybe a purpose specification concept in addition to data minimization. Maybe APIs should be more purpose specific and these will be concepts that help protect privacy... 75 | 76 | -------------------------------------------------------------------------------- /meetings/2023-11-15-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Minutes - Wed, 15 November 2023 2 | 3 | Present: Dan, Don, Nick, Jeffrey 4 | Regrets: Pete, Amy, Wendy 5 | 6 | ## [device admins](https://github.com/w3ctag/privacy-principles/pull/368) 7 | 8 | Jeffrey: removes assumption that admins are admins to the whole device... we may not be able to enforce... but still worth saying it. Most admins want the UA to have an implementation of the thing they want to do - but ... 9 | 10 | Don: most admins won't modify the core UA code, so a notice to users that the UA is administered will be useful (even though an administrator with enough time and skill could remove it) 11 | 12 | Nick: I still think it's useful ... however it's not a guarantee. 13 | 14 | Dan: I feel it could be stronger... 15 | 16 | Jeffrey: merge and then continue to edit? 17 | 18 | ...even when disclosure to administrator is reasonable, user must be made aware 19 | 20 | *some editing ensues* 21 | 22 | *looks good, merging.* 23 | 24 | ## [Ancillary Data](https://github.com/w3ctag/privacy-principles/pull/361) 25 | 26 | Nick: I think I still have some open items in here... I don't know the particular benefit over the existing text... Exhausted. 27 | 28 | (Asking Pete for asynchronous review, as some of us thought that was the next step.) 29 | 30 | Jeffrey: We could ask the TAG to pick among multiple versions... we can make this as good as we can make it before giving it to them... I think I would be fine with not changing the text at all.. but Pete doesn't like the heuristics - reasonable objection. There was request to the web perf folks for more percise text. This is what came back. 31 | 32 | Nick: I think the TAG is the next stop anyway, so that seems reasonable; what does the TAG chair think? 33 | 34 | Dan: seems clearer than last time I read through this section. don't prefer the "disagreement/lack of consensus" sections. 35 | 36 | Jeffrey: [Web Perf group starting to employ the proposed text]( https://docs.google.com/document/d/1hsAx_VLCKyr2I0u22vdDvo-9liF8CxAo5VC2jcOEqQw/edit#heading=h.7zk49ci3rj0f), and mitigating additional data with differential privacy 37 | 38 | Dan: I think this wording is clearer. 39 | 40 | Nick: my substantive concern... distinguishing between novel and non-novel is a harmful pattern... 41 | 42 | Jeffrey: I made some chanegs in that direction... Happy to keep re-wording in that direction... 43 | 44 | Don: Is it about novel vs. non-novel or intended vs unintended? [The Mozilla anti-tracking policy refers to "unintended identification techniques"]( https://wiki.mozilla.org/Security/Anti_tracking_policy#3._Tracking_via_unintended_identification_techniques). There are some APIs where the user has control - others where the control isn't exposed to the user... Whether or not a user actually changes those controls, the theoretical "is this something you could turn off" might be a better dividing line. 45 | 46 | Nick: we couldn't get agreement on "users should be able to turn these off"... 47 | 48 | Jeffrey: (eg) even if you can't turn off geoloc .. 49 | 50 | ... most of their stuff is "you got a DOM event about this image loading and when did that happen?" "when did you get animation frames and did you miss any of them?" you can't turn that off as a user and that's the kind of thing they are summarizing most of the time. 51 | 52 | Dan: we can encourage API developers to fix their issues for subsequent versions and notify them that they will be asked about it for future TAG review... 53 | 54 | ## https://github.com/w3ctag/privacy-principles/pull/369 55 | 56 | Jeffrey: Robin should review it... 57 | 58 | ## RFC 2119 language? 59 | 60 | Nick: sometimes we say must and sometimes should... do we mean to use 2119 terms? 61 | 62 | Jeffrey: I have been thinking ... almost all of this is appropriately shoould. Places that we say must we should double check. Worth checking. 63 | 64 | *nick to open an issue and we can do a review* 65 | 66 | ## data minimization https://github.com/w3ctag/privacy-principles/issues/370 67 | 68 | Nick: Yoav opened an issue... 69 | 70 | *issue of sensitive data vs non-sensitve data* 71 | 72 | Jeffrey: don't know what we can do about considering the general agreement that all data might be sensitive. 73 | 74 | Nick: we have wording "don't assume that data isn't sensitive" - we do explain how to determine if data is sensitive. We also explain that data min is important because we don't know... how sensitive. 75 | 76 | Jeffrey: we say "don't send info that doesn't meet the user's goals"... Yoav is pointing out that web perf often needs data apart from data that directly meets user's goals... 77 | 78 | Don: as soon as we have parties that can infer one piece of data from another, trying to tag as sensitive/non-sensitive is not going to work. Machine learning could reconstruct sensitive data points from non-sensitive ones, and if a data point is both sensitive and valuable, parties have an incentive to improve ML. 79 | 80 | Jeffrey: when we talk about "send only data that serves user needs" then perf folks will say "this data is necessary to serve a user need of performance..." There is an argument to serve a user need... 81 | 82 | Don: some of this make assumptions of the composition of a site as the user sees it as first and third parties together... *troubleshooting performance problem where you don't know which 3rd party code is going to be on the page at the time you design the page* 83 | 84 | Nicl: I understand the concern about the get-out ... that's the actual decision we want users and their agents to be making... How much benefit do I get out of [the extra data]? Big benefit then OK. Not so big than maybe not. Let the agent decide... The reason that minimization is important beyond the user's interest is the justification... there can be risks of data being exposed / misused / over-collected and that can be beyond the particular decision that the user is trying to make about whether they want to take a particular action. 85 | 86 | Jeffrey to propose some text in Slack to explain that we believe the motivation is described as best we can, for review by Dan and others. 87 | 88 | We may meet next Wednesday for those who are available. 89 | 90 | [adjourned] 91 | -------------------------------------------------------------------------------- /meetings/2023-02-01-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Minutes - Wed, 1 Feb 2023 2 | 3 | * Present: Jeffrey, Robin, Pete, Don, Nick, Wendy 4 | * Regrets: Dan, Christine 5 | 6 | ## [PRs](https://github.com/w3ctag/privacy-principles/pulls?q=is%3Aopen+is%3Apr+sort%3Acreated-asc) 7 | 8 | ### [Discovery](https://github.com/w3ctag/privacy-principles/pull/219) 9 | 10 | Nick: responding to an external reviewer, clarifying that right to access includes both the data and the actors who have data. 11 | 12 | Jeffrey: any objections? hearing none, let's merge 13 | 14 | Nick: original commenter also approved 15 | 16 | ### [Simplify and remove redundant text in the Identity section](https://github.com/w3ctag/privacy-principles/pull/218) 17 | 18 | Jeffrey: this is mine. Read through identity section and shortened. Comments? Got through 2.1.2 19 | 20 | Robin: we've reviewed recognition methods a few times 21 | 22 | Pete: intended as clean-up or substantive change? 23 | 24 | Jeffrey: meant to clean-up, but it departs from "only tighten partition boundaries" to refer to user context. e.g. if we think user understands google.com and googleusercontent.com as same context, it's ok to treat them as the same partition. 25 | 26 | Pete: are there places where that doesn't turn on first-party sets? 27 | 28 | Robin: 1p sets is a mechanism. I might disagree with mechanism but can agree with the understanding. 29 | 30 | Pete: are there places where we're not talking about domain boundaries? 31 | 32 | Jeffrey: maybe if a user logs in to the same site on two devices, and the site gives notice to combine. It's up to the UA to respect user's idea of context boundaries. 33 | 34 | Don: appreciate context vs. site or domain. (A domain can have multiple contexts and a context can span domains) 35 | 36 | Pete: maybe say more about what kinds of signals browser should use to know what's acceptable? 37 | 38 | Jeffrey: Think that belongs in the threat model doc. We want UAs exploring how to do that 39 | 40 | Pete: I'm concerned it might be empty set. Would be useful to have some idea what those signals could be 41 | 42 | Nick: is another example sign-in scenarios? e.g. it looks as though user is trying to use login from one domain/site on another 43 | 44 | Jeffrey: that's something password managers can do (not warning if you're using the same password across known-related domains), I don't know about browsers. Re sign-on, we're encouraging people to move toward FedCM 45 | 46 | Pete: I'm not yet ready to approve this change, want to think about it more. Other changes look good. 47 | 48 | Jeffrey: we won't merge if not consensus. 49 | 50 | Nick: on another point, you had text that giving the same email address is not consent for merging. use of "identity" may be confusing with relation to our definition in the doc. 51 | 52 | Jeffrey: I've been using "presentation of self/attributes". 53 | 54 | Nick: We might want to say user doesn't intend to be recognized, not just whether or not they have the same identity. 55 | 56 | Jeffrey: tried to say both. Any suggestions? 57 | 58 | Pete: I'll take a look. Anything else you want eyes on? 59 | 60 | 61 | ### [Revisions and concisions around ancillary data use](https://github.com/w3ctag/privacy-principles/pull/216) 62 | 63 | Pete: Sam's first change seems good. 64 | 65 | Nick: wishes? 66 | 67 | Jeffrey: we use "intends" in may other places? 68 | 69 | Pete: change user's wishes and interests to user's intent 70 | 71 | Don: +1 to intent. (If you were a Mentat doing web standards in your head, would you do this or skip it?) 72 | 73 | Jeffrey: want to be clear that we're not banning performance measurement. 74 | 75 | Don: I'd rather have telemetry be at the fuzzy boundary than surveillance marketing, rather than telemetry clearly allowed and surveillance potentially so. 76 | 77 | Pete: we should make sure user wants to participate in telemetry before it's enabled. 78 | 79 | Jeffrey: we wouldn't go against a user's request not to perform telemetry, but do we make all users go through the privacy labor of thinking whether they agree a site may record performance? 80 | 81 | Pete: I also made a recommendation to remove the concept of privacy labor; I recognize we disagree. 82 | 83 | Nick: try to write toward what we agree, more than malicious interpretations. Though we had something elsewhere re duty of loyalty, which can accommodate UA doing something it thinks is in user's interest 84 | 85 | Robin: that can align with what you do in picking a UA: as with a broker, you pick one that you believe aligns with your interests, even as all are bound to be loyal 86 | 87 | Jeffrey: trying in this document to lay the groundwork for future arguments. Want to include "users' interests" as one of those points. 88 | 89 | Pete: want us to be more cautious about inferring user's interests. "immediate intent" 90 | 91 | Don: UA does what user would do if they had enough time 92 | 93 | Pete: If I were a different person, I'd do a different thing 94 | 95 | Pete: I'm ok with intents and interests 96 | 97 | Pete: removed a list of examples of ancillary uses, as they seemed like invitaiton to confusion on their purpose. (not endorsements) 98 | 99 | Nick: we need some guidance for readers, either examples or definition 100 | 101 | Jeffrey: add some we hate, to make clear they're not all permitted? 102 | 103 | Pete: if we add toxic uses, we should label them 104 | 105 | Robin: ancillary opposition of essential or necessary, but that's hard to define too. Look at EDPD. more grey areas around intent: load balance, ddos mitigation 106 | 107 | Nick: that was original intent: ancillary is outside what's necessary to load and display the page 108 | 109 | Jeffrey: we're not trying to forbid, as regulators are, but to introduce considerations 110 | 111 | Pete: +1 to remove the list and reintroduce definition (as Nick pointed out in previous paragraph) 112 | 113 | Nick: examples can be helpful 114 | 115 | Jeffrey: maybe include a few that are generally agreed to be beneficial 116 | 117 | Pete: thanks, helpful conversation. I'll revise 118 | 119 | ## AOB 120 | 121 | Robin: I made a list of [suggestions](https://github.com/w3ctag/privacy-principles/issues/217) for wide-review outreach. Please add or comment. 122 | -------------------------------------------------------------------------------- /meetings/2022-09-28-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG privacy tf - 28 September 2022 2 | 3 | Present: dan, don, nick, wendy, christine, pete, jeffrey, jonathan 4 | Regrets: robin, amy 5 | 6 | 7 | new apis and justification based on old ones: Jeffrey: no updates on that this week yet. 8 | 9 | deception cannot be discussed without robin 10 | 11 | 177/178 delayed since amy isn't here 12 | 13 | 170: 14 | 15 | Nick: I split the section as suggested and tried to describe telemetry and analytics as a cluster of uses for choices. and also noted the fingerprinting implications of both data in telemetry and revealing a user preference about telemetry 16 | 17 | Pete: 18 | 19 | **... splitting up 170 into a few different PRs:** 20 | 21 | https://github.com/w3ctag/privacy-principles/pull/183 22 | 23 | Adds section 2.2 Data minimization... 24 | 25 | Don: people can take action on it 26 | 27 | Jeffrey: I love this. 28 | 29 | Dan: I like it. 30 | 31 | Jeffrey: we should cite data minimization ... 32 | 33 | Pete: it was noted that it was not a finding... 34 | 35 | Jeffrey: we can cite it as a web page. 36 | 37 | Christine: the way I read the text it seems to be applying mimization to person data. Do we want a larger scope statement. There's work in IETF to reduce metadata and noise. I'm wondering whther we should make the principle a bit broader. Data that's not clearly personal data... but could pose a risk. 38 | 39 | Dan: i think it is out of scope for the taskforce... but could be part of a revamped finding. We can look at it more broadly in reference to the IETF work you mentioned. 40 | 41 | Nick: I think it's broad enough... We define personal data broadly as well... 42 | https://pr-preview.s3.amazonaws.com/w3ctag/privacy-principles/pull/183.html#dfn-data 43 | 44 | Christine: it's a good def of personal data but ... recoginize this may be oiut of scope for the doc. 45 | 46 | **consensus to merge 183** 47 | 48 | https://github.com/w3ctag/privacy-principles/pull/184 49 | 50 | Nick: around the idea of having a cluster of choices... writing a new spec that has telemetry or analytics ... should be a flag - so it's easier to have a clustered choice when users want to make a decision about telemetry & analytics... and maybe we could get to the point where we should say to spec authors: this is how you can be sure this is just for telemetry and this is how you should define that flag. 51 | 52 | Pete: I can re-reaise this to privacy CG... 53 | Nick: hope browsers can use it even without standardization at privacycg, but if privacycg wants to discuss then great 54 | 55 | dan: editorially, principles should be moved higher. 56 | 57 | dan: I like this. needs dialog with spec authors 58 | 59 | jeffrey: this comes out of discussion with webperf. this has gone in circles for a long time, but this might help. not exactly clear what browsers will do with it. sense within chrome that this mode might not be used, or only used for new features, might not want to present users with an option to turn off this kind of functionality. 60 | nick: always the case that browsers might not take advantage of it. 61 | 62 | *discussion on possible Privacy CG work* 63 | 64 | dan: this is the kind of discussion we need to have. TAG is getting more review requests about telemetry-type APIs. good to have it grouped, even if it won't always be used. 65 | 66 | Pete: if this becomes part of ongoing conversation - reviews - labeling telemetry - this principle implies that specs need to define what the spec'ed functionality does when the user doeesn't want to share the info. 67 | 68 | Don: point came up at TPAC - running personal info through a privacy-preserving system would give you a user tracking system that could be made default: on. So when talking about the type of thing users would choose to turn on if they understood it. I don't have confidence that these systems would pass that test. I like the draft that we have better than the direction of patcg discussions of privacy preserving attributution. 69 | 70 | *discussion on the need for user research* 71 | 72 | Nick: "if the browser reveals"... I think generally the APIs should just be null when the functionality is turned off. 73 | 74 | Dan: can't be prescriptive, but API designers should on case by case basis make it more difficult to reveal whether users have turned off telemetry or turned on a private browsing mode 75 | 76 | Jeffrey: on pete's comment - what to do when the user decides not to send ... some browsers may decide based on user research to make the decision that users generally would decide to send ... on hard to tell if users turn off: we can try but it's likely to be difficult. 77 | 78 | Dan: suggest to land this as is and iterate. 79 | 80 | **consensus to land this PR as is and then iterate** 81 | 82 | Nick: do we want to have a more general principle about not revaling private modes, not revealing... maybe larger? 83 | 84 | Dan: we have text in the design principles on private modes and assistive tech so probably we don't need more text here. 85 | 86 | https://github.com/w3ctag/privacy-principles/pull/177 87 | 88 | Specifically: https://github.com/w3ctag/privacy-principles/pull/177#pullrequestreview-1116206748 89 | 90 | Pete: on same site recognition... don't think it's correct. 91 | 92 | Jeffrey: you go to a site you log in you close your browser you go back to the site you're still logged in.... That's benign but it's still same site recognition. 93 | 94 | Nick: same site recognition across clearing data... I think that's an unintuitive use of cross-partition... 95 | 96 | Christine: Aren't we also concerned if they are recognised even if "not logged in"? 97 | 98 | Jeffrey: yes though sites also save preferences... might not be a full identity but... still recognized. 99 | 100 | Christine: I want to be careful that we recognize that... 101 | 102 | Dan: distinction between "logging out" which is a functional use case and clearing site data. 103 | 104 | Jeffrey: right. browser doesn't know when you've clicked log out.. but does know when you clear data. 105 | 106 | Nick: is this trying .. in the *fingerprinting mitigation* guidance we're trying to list the types of things that could be used as a fingerprint. Is this identity section re-creating. 107 | 108 | -------------------------------------------------------------------------------- /meetings/2022-11-30-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Task Force Minutes - Wed, 30 November 2022 2 | 3 | Present: Dan, Don, Sam, Pete, Wendy, Nick, Pete, Jeffrey, Robin 4 | 5 | Regrets: Amy, Christine 6 | 7 | ## Discuss schedule... 8 | 9 | DKA: as far as I know, December is the last month of the year. Are we ready for a transition request or similar call for review? 10 | 11 | Wendy: First we publish a note - and go through the mechanics for getting group to agree - then request wide review and get the group's consensus to publish as a proposed w3c statement, then send to AC for review. So if we're at the beginning stage - what we do we need to do to get the doc into its complete status that we're confident publishing it as a note. We can have multiple iterations of candidate notes. 12 | 13 | [W3C Process: .4.3. Elevating Group Notes to W3C Statement status](https://www.w3.org/2021/Process-20211102/#memo) 14 | 15 | Jeffrey: TAG to agree to publish as note 16 | 17 | Dan: What's the process we want? 18 | Proposed: 19 | 20 | 1. TF Agrees it's read to publish as note -> 21 | 2. TAG agrees this -> 22 | 3. TAG publishes as a note 23 | 24 | If we envision multiple revisions, where does statement publication fit? is that compatible? 25 | 26 | Nick: the step is the wide review... Not that we'd say "we're publishing a note and ready to approve as a statement" we can say "the TAG says it's good enough to be a note and now we would like wide review" 27 | 28 | Jeffrey: step 4 is get the AC to review... Step 5 is to publish another note - step 6, a statement. 29 | 30 | Nick: I'd encourage wide public review, not just w3c typical wide review... not just AC. 31 | 32 | Dan: so, where are we on step 1, TF agreement on readiness? 33 | 34 | Jeffrey: While we can always spend more time refining, I think we're near ready to hand off to TAG. 35 | 36 | Robin: +1, editors will always want more time, but we need to move forward. Should we try to land a few PRs before? 37 | 38 | Dan: I'd like to land some PRs. Amy has been working on an edit pass as well, of which I'd like to land some. 39 | I can commit to working with Amy on some of the editorial simplification. 40 | 41 | ## [vulnerability](https://github.com/w3ctag/privacy-principles/pull/198) 42 | 43 | Don: Christine wrote it - ... I've raised the PR. 44 | 45 | Jeffrey: some editorial tweaks. 46 | 47 | Pete: to my mind it says anyone can be vulnerable... seems to dilute the usefulness... 48 | 49 | Don: People sometimes believe themselves to be in a stable situation and then become vulnerable. Also applies to refugees. 50 | 51 | Jeffrey: but to Pete's point, then they end up in a vulnerable group... I think Pete's right that we don't want to say anyone can be vulnerable - just that there are groups that people could be surprised to find themselves in... 52 | 53 | Don: but data processing decisions are made in the time before they became vulnerable. 54 | 55 | Pete: great point - the principle text should be "give people control" i think the right principle could be "assume that people are always vulnerable or could become vulnerable and design accordingly." 56 | 57 | [discussion] 58 | 59 | Nick: I think we're getting at a challenging part of the text... proactive principle is harder. I think the graceful degredation thing is useful but doesn't capture everything... 60 | 61 | Jeffrey: we need an extra principle... the thing about children - being able to delegate decisions about privacy protections ... we can add those in seperate PRs... 62 | 63 | Pete: we should avoid ... we should design APIs with all data is very sensitive... 64 | 65 | Robin: is it "UAs and sites should be designed with the assumption that their users are vulnerable." 66 | 67 | Jeffrey: don't use slides to let the user configure whether they are vulnerable... Because if they become vulnerable then they won't be able to reset all the sliders... Default of the app is the respect vulnerability. 68 | 69 | Nick: default safe - and graceful degredation.. 70 | 71 | Jeffrey: maybe a space for a panic button in UIs... It happens when you go viral on twitter or when you get doxxed. All of a sudden you need to lock things down. Having the app assume vulnerabiltiy might mean "never make anything public" which I don't think is what we mean. 72 | 73 | Wendy: It may be that this PR assumes a piece of the argumnent without stating it - vulnerable people need more protections... But then it's saying "anyone can become vulnerable" - so protections need to be available for all ... maybe a little bit more signaling of what this is responding to. 74 | 75 | Pete: Can take it on as a to-do for next week. Ok to merge this and I will work on it. 76 | 77 | Nick: can we work on parenting/ guardianship... assigned to jeffrey and christine... 78 | 79 | Jeffrey: I can take a stab at that by next week. 80 | 81 | *merged* 82 | 83 | ## [harassment](https://github.com/w3ctag/privacy-principles/pull/195) 84 | 85 | *bumped to next week* 86 | 87 | ## [Cross-Device Comms](https://github.com/w3ctag/privacy-principles/pull/186) 88 | 89 | Nick: Editorial changes - section changed dramatically - identity on the web. So it's hart to add this additional example. 90 | 91 | Robin: still worth it? 92 | 93 | Nick: yes. just don't know ... the PRs that got merged for Identity - have made that more confusing... 94 | 95 | 96 | [reviewing 2.1] 97 | 98 | Robin: maybe an additional framing intro paragraph: "There are multiple threats to user privacy ... " 99 | 100 | Wendy: it could use a reference to anonymity and pseudonimity... [added PR](https://github.com/w3ctag/privacy-principles/pull/199) 101 | 102 | Robin: i could do an *edit pass* - i don't think it's extensive... 103 | 104 | ## [new apis based on old ones](https://github.com/w3ctag/privacy-principles/pull/182) 105 | 106 | *bumped to next week* 107 | 108 | ## [Anonymity](https://github.com/w3ctag/privacy-principles/pull/199) 109 | 110 | Wendy: added this... 111 | 112 | Jeffrey related to [#166](https://github.com/w3ctag/privacy-principles/pull/166/). 113 | 114 | Dan: maybe that was too complex? 115 | 116 | Wendy: sometimes people don't want a continuous identity attached - "i want to see what this search page looks like without these characteristics"... 117 | 118 | Jeffrey: i have no objections 119 | 120 | Robin: Ship it. 121 | 122 | ## [harassment](https://github.com/w3ctag/privacy-principles/pull/195) 123 | 124 | *bumped* 125 | 126 | -------------------------------------------------------------------------------- /meetings/2023-01-04-minutes.md: -------------------------------------------------------------------------------- 1 | # Privacy TF Call - 4 Jan 2023 2 | 3 | Present: Robin, Don, Dan, Wendy, Amy, Jeffrey, Nick, Christine 4 | 5 | Regrets: Pete 6 | 7 | ## [Robin's editorial PR](https://github.com/w3ctag/privacy-principles/pull/208) 8 | 9 | Robin: took all of jeffrey's changes except one... 10 | 11 | *discussion* 12 | 13 | Dan: I've left a comment that when we jump right into section 1, we're leaving unsaid that before we get into the technical guidelines that spec developers might be looking for, we're going to spend some time explaining the context and what we need when we say privacy. I don't know how to say that tersely. If you're looking for technical guidelines just jump to section 2, but to understand them you really need to have this conceptual framework in mind. including things like privacy labour and things like that. Trying to figure out how to sugar coat it a bit so people realise why they need to read this. 14 | 15 | Robin: the two sentences you put in the comment work. I don't think it needs more. 16 | 17 | Dan: and after we land this PR I think I have an idea of doing a subsequent simplification edit that may make things ... one of the feedbakc points I've had from people, especially not native english speakers... this PR already does a lot to simplify. After that i want to do another simplification readthrough. 18 | 19 | Robin: Agreed 20 | 21 | Dan: to make sure we're not bombarding people 22 | 23 | Wendy: +1 to merge 24 | 25 | Amy: +1 to merge 26 | 27 | Nick: +1 to merge 28 | 29 | Dan: +1 30 | 31 | *we agree to squash and merge the PR* 32 | 33 | ## [PR: Tension within anti-profiling designs](https://github.com/w3ctag/privacy-principles/pull/158) 34 | 35 | Jeffrey: adds an example that I think is useful but if the group thinks it's not a good idea we should just close it 36 | 37 | Don: I'd say leave mention of IPA out of this if we want to get it reviewed on a reasonable timeframe because IPA has a lot of complexity to it and there are aspects I still don't understand so this is nerdsniping people into taking too much time to read this if they have to understand IPA. Preventing profiling being not a good thing in general but tying it to a specific math/game theory problem makes it harder to review the document 38 | 39 | Jeffrey: I can make that mention more general if that helps to merge 40 | 41 | Robin: making it clear that IPA is an example.. I see what Don is saying, I feel a less strong version of the same thing. I personally like IPA but if you have to understand IPA to understand the point that's going to take time> I think it's a good thing to include, but making it something like for an example an attribution API... you could list several.. 42 | 43 | Jeffrey: even the most privacy respecting conversion API will still reveal a limited amount of information. Will try to genericise it 44 | 45 | Robin: suggest that Jeffrey gets leeway to genericise it and then land it. I don't feel the need to re-review it. 46 | 47 | Jeffrey: drafted.. 48 | 49 | Nick: that's the feedback Wendy and I got into back in May.. I'd tend to leave it out, I wouldn't want to make it a primary part of this document, making privacy decisions based on how people are going to react and move to other apps.. 50 | 51 | Jeffrey: primary to remind people designing systems that they should be thinking about second order effects even if they don't know what they are going to be 52 | 53 | Nick: Wendy, does that make sense? 54 | 55 | Wendy: I like the rewrite in toning down the attention. I don't feel strongly. Probably if it gets a lot of response in feedback, it might be better to take it out than to go into all of the layers. 56 | 57 | Nick: sounds fine to me 58 | 59 | Jeffrey: will rebase, incorporate change, and merge it 60 | 61 | ## The Wide Review Plan 62 | 63 | Dan: request for wider review - AC-Forum and Chairs mailing lists; PING group; 64 | 65 | Jeffrey: collection of CGs - anti-fraud; privacy; Private Advertising Technologies 66 | 67 | Wendy: web performance and devices & sensors folks... 68 | 69 | Don: prebid.org ? 70 | 71 | Robin: ICO? 72 | 73 | Dan: civil society groups? EFF? CDT? 74 | 75 | Nick: I would like to more than traditional audiences.... 76 | 77 | Dan: was thinking about writing an intro to send to w3c working groups. Would it be helpful top ublish that as well as a TAG blog post? Which links to the draft? 78 | 79 | Amy: will we send it out to different groups at different times, or ask for all feedback all at once? 80 | 81 | Dan: I don't think we have bandwidth to design a staged approach. Key is the wording - it's preliminary, we're open to suggestions and want to get this right 82 | 83 | Amy: be clear we are asking for a middle level of feedback - not high level fundamentals or detailed/editorial but like missing topics, glaring errors, etc... 84 | 85 | Jeffrey: and we want to hear about it now if we're going to get FOs, even about fundamental things 86 | 87 | Don: The [Clinic to End Tech Abuse](https://www.ceta.tech.cornell.edu/) could be a good group to get review from relating to vulnerable people 88 | 89 | Nick: I think that's a good idea, that outreach to civil society orgs plan, and have contacts there. I do think the blog post part there with context would be extremely important for non w3c regulars. These documents should be written in such a way that there is context at the top and github and ways to send feedback, but for people who aren't familiar with that process they're going to need a blog post to say what is this, why does it matter, what are you looking for, would be a lot less intimidating. 90 | 91 | Dan: I'll draft. Would like to do this async before next week's call. 92 | 93 | Nick: the readiness, or stages of review... I like the idea of saying we're asking for early feedback, but also if we can fix more things first it will help the reviewers not to get confused 94 | 95 | Amy: risk of reviewer burnout, if there's feedback that it's hard to follow, then we ask them for review again they might be less willing 96 | 97 | Dan: we can update ac forum to let them know how we're doing and say we're open to feedback, but it's still going through editorial review 98 | 99 | Jeffrey: Amy's right that we can't ask people multiple times, we should be sure we're asking the right thing. depends how quickly we can get it into a good editorial shape. Will we be able to get it into shape and then ask for review? 100 | 101 | Robin: makes sense 102 | -------------------------------------------------------------------------------- /meetings/2023-06-28-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Minutes - 28 June 2023 2 | 3 | Present: Robin, Don, Nick, Pete, Jeffrey, Amy 4 | 5 | ## [Remove the statement about a general opt-out overriding a specific opt-in.](https://github.com/w3ctag/privacy-principles/pull/238) 6 | 7 | Robin: Discussion in 238 or 231 - prvoided an alternative in https://github.com/w3ctag/privacy-principles/pull/296 8 | 9 | Pete: in last sentence - maybe preference instead of decision? 10 | 11 | Robin: goal is to clarify the conceptual part. "as if the user were constructing the ua to do this for this purpose" and removing the regulatory language. 12 | 13 | Jeffrey: want to run this by Michael Kleber. User has instructed the browser... if a site thinks they have a reason where maybe the user's pref doesn't apply then can ignore but site does nead that reason. 14 | 15 | Robin: yes ... don't want to go down a full path of mapping out all the cases. 16 | 17 | Jeffrey: will make suggestions to tweak the wording. 18 | 19 | Jeffrey: been thinking about cookie consent into the browser... what would that look like? needs the ability for the site to say "wait, i'm special". I feel like this text does align. But I want to review. 20 | 21 | Robin: Idea is to be compatible with ADPC. https://www.dataprotectioncontrol.org/ 22 | 23 | ## [Fingerprinting](https://github.com/w3ctag/privacy-principles/pull/274) 24 | 25 | Robin: yes 26 | 27 | Nick: yes 28 | 29 | Pete: what's he concerned about? Exposing one bit in session one and one in session 2? 30 | 31 | Nick: more trying to explain to the reader how fingerprinting is accomplished. 32 | 33 | Dan: yes looks good. 34 | 35 | **agree to merge** 36 | 37 | ## [no excuses for fingerprinting](https://github.com/w3ctag/privacy-principles/pull/275) 38 | 39 | Nick: change might be reasonable... We don't need to get into the size... 40 | 41 | Dan: I like it. 42 | 43 | Robin. +1 44 | 45 | Pete: +1 46 | 47 | Nick: we could move it to a specific document... 48 | 49 | **agree to merge** 50 | 51 | ## [principle for non-user privacy, to be able to access and remove data uploaded by others](https://github.com/w3ctag/privacy-principles/pull/287) 52 | 53 | Nick: adds a principle but pretty short otherwise... 54 | 55 | Robin: [some editorial] 56 | 57 | Robin: I like the overall thing. 58 | 59 | Robin: if people like the general thing i'm happy with nick making exec decision and merging. 60 | 61 | Jeffrey: +1 62 | 63 | **agreed to merge** 64 | 65 | ## [transparency](https://github.com/w3ctag/privacy-principles/pull/288) 66 | 67 | Nick: adds a section of principles on transparency... Included citations... Requesting review. 68 | 69 | **we agree to review and return to this next week** 70 | 71 | ## [small group privacy examples](https://github.com/w3ctag/privacy-principles/pull/289) 72 | 73 | Nick: small changes but I want feedback... Is targeting messages to a small group inappropriate in a privacy way? The last time we had general targetting to demographics we had objections... 74 | 75 | Dan: concern about adding material to the doc which has been criticized for being too long. 76 | 77 | Jeffrey: I think this is new and useful. I will run this by the privacy sandbox folks... i think this is compatible. 78 | 79 | Don: I'm not sure about "small" - e.g. targetting a message to everyone in town who did not go to lunch in Ramadan.. that could be large but still sensitive... 80 | 81 | Robin: that's a sensitive - religious addiliation - category. I think flagging the small group - even for things that aren't considered sensitive.. is the issue. 82 | 83 | Robin: +1 84 | 85 | Don: are we including data from which a sensitive characteristic can be inferred? Will re-check and make sure it is covered 86 | 87 | Don: +1 88 | 89 | Dan: +1 90 | 91 | **agree to merge** 92 | 93 | ## [fake consent](https://github.com/w3ctag/privacy-principles/pull/290) 94 | 95 | Robin: editorial... 96 | 97 | Robin: last sentence... on time spent on reading privacy policy... 98 | 99 | Don: we don't want people to do unsustainable amounts of privacy labour - but some sites might have unavoidable personal data processing... 100 | 101 | Nick: Agree with the intent - but the 2nd principle just elaborates... 102 | 103 | Jeffrey: sometimes the site should just not ask... ? If we could work it under the first section that would be better. 104 | 105 | Don: will do a new version that moves this to explanatory text for the first principle... and remove numbers of minutes 106 | 107 | Jeffrey: also on the same page as Robin that a 30 min privacy policy is too much for any site... 108 | 109 | ## [self-governing](https://github.com/w3ctag/privacy-principles/pull/291) 110 | 111 | Robin: +1 112 | 113 | Jeffrey: I want to let Michael have a chance to review. 114 | 115 | **we can merge async based on that review** 116 | 117 | ## [style](https://github.com/w3ctag/privacy-principles/pull/292/files) 118 | 119 | Robin: editorial... 120 | 121 | **agree to merge** 122 | 123 | ## [Add centralization section](https://github.com/w3ctag/privacy-principles/pull/293) 124 | 125 | Pete: agree to Robin's changes.... 126 | 127 | Nick: agree with general idea - but concerned with adding that to this document... 128 | 129 | Jeffrey: I think this is an EWP rathr than a privacy principle... 130 | 131 | Robin: I like the part that gives the articulation... 132 | 133 | Dan: suggest we close - and open an issue on EWP. 134 | 135 | Pete: will do. [pes: https://github.com/w3ctag/ethical-web-principles/pull/95] 136 | 137 | **agree to close and close 261 but file issue in EWP** 138 | 139 | ## [registries](https://github.com/w3ctag/privacy-principles/pull/294) 140 | 141 | Robin: we agreed on this .. 142 | 143 | Nick: I like this though concerned about the length... 144 | 145 | Pete: could we state in a positive form? 146 | 147 | Jeffrey: we could merge and do an editing pass... 148 | 149 | ## Editing Pass 150 | 151 | Robin: I can take intro... Let's split stuff up. 152 | 153 | Don: I can open an issue per section .... 154 | 155 | Amy: top level sections... 156 | 157 | Robin: x.x 158 | 159 | Don: **to make issues** (including for text not in a numbered section) 160 | 161 | ## [Purpose-built API](https://github.com/w3ctag/privacy-principles/pull/295) 162 | 163 | Nick: I'm supportive... 164 | 165 | Dan: +1 166 | 167 | Pete: we could lose the first 2 sentence ... to cut length. 168 | 169 | **We agree to leave it to robin and lose first para to merge** 170 | -------------------------------------------------------------------------------- /meetings/2024-03-breakouts/slides.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | Privacy Principles 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 22 | 23 | 24 |
25 | 26 | 30 |
31 | 32 | 33 | 34 | 35 |
36 |

Privacy Principles

37 | 38 |

★ W3C Breakouts Day, 12 March 2024 ★

39 |
40 | 41 |
42 |

What?

43 | 49 |
50 | 51 |
52 |

Why? (1)

53 |

Human Rights

54 |

"...the ethical web principles of the World Wide Web Consortium Technical Architecture Group emphasize that internationally recognized human rights need to be placed at the core of the web platform"

55 |

https://digitallibrary.un.org/record/4031373

56 |
57 | 58 |
59 |

Why? (2)

60 |

More Human Rights

61 | 67 |

https://www.un.org/en/about-us/universal-declaration-of-human-rights

68 |
69 | 70 |
71 |

Why? (3)

72 |

Ethical Web Principles

73 |

The web must "continue to be beneficial to society."

74 |

https://www.w3.org/TR/ethical-web-principles/

75 |
76 | 77 |
78 |

These are a few of our favorite things

79 |
80 | 81 |
82 | Robin's highlight 83 |
84 | 85 |
86 |

1.3 User Agents

87 | 94 |
95 | 96 |
97 | Dan's highlight 98 |
99 | 100 |
101 |

2.2 Data Minimization

102 | 108 |

See also: https://www.w3.org/TR/design-principles/#data-minimization

109 |
110 | 111 |
112 | Jeffrey's highlight 113 |
114 | 115 |
116 |

2.8 Device Owners and Administrators

117 | 123 |
124 | 125 |
126 | Nick's highlight 127 |
128 | 129 |
130 |

2.9 Protecting web users from abusive behaviour

131 |

When we're building the web, let's mitigage:

132 | 136 |
137 | 138 |
139 | Don's highlight 140 |
141 | 142 |
143 |

A.2: Common concepts: Contexts

144 | 152 |
153 | 154 |
155 |

Questions and Comments

156 | What do you think? 157 |
158 | 159 | 160 | 161 | -------------------------------------------------------------------------------- /meetings/2023-09-06-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy Task Force Call - 6 September 2023 2 | 3 | Present: Wendy, Amy, Dan, Don, Nick (& Forest), Jeffery, Christine, Robin 4 | Regrets: Sam 5 | 6 | ## https://github.com/w3ctag/privacy-principles/pull/324 7 | 8 | Amy: I think it's fine. 9 | 10 | Dan: we unconsolidated some of the consolidations and wanted to make sure Amy was fine with that. 11 | 12 | Pete: Defining minimization - seems backwards - user agents should send as little data as necessary to achieve user goals. 13 | 14 | Jeffrey: there are two principles. ONe is about data transfer, one is for designing apis. You have to design apis to support that 15 | 16 | Pete: web apis should be designed to minimize data sites need to request.. doesn't seem to do that for me.. 17 | 18 | Dan: I think it does. From the perspective of web api design that come up for design review and we want to be able to point those people at something. it may need additional wording.. otherwise we don't have something to point spec designers at that says they need to design for data minimization 19 | 20 | Amy: I think there's a high-level principle about data minimization.... There's a high level principle. And these are implementation details... 21 | 22 | Dan: uas and other actors should minimize the amount of personal data they transfer is the first one. Web apis should be designed to... that's the thing that helps us make reviews better because we can say hey web api designer to design your api such that it adheres to this principle. And then UAs should share [...] wishes and interests. 23 | 24 | Amy: i agree but we can point API designers when it's one principle that covers all caes... 25 | 26 | Dan: Nick suggesteds the principles should be on one actor 27 | 28 | Nick: it seemed likely to get confused that a principle starting with sites and UAs would get missed as something that spec authors should do, and having that as a princple seems valuable 29 | 30 | Dan: that resonates with me. It gives people explicit instructions. 31 | 32 | Pete: that's not my concern, targeting towards the author vs the UA. Just seems awkward to me to say that you have to minimize the amount of information that sites need to reuqest. Is this an aesthetic concern or a substnative one? Is another way of saying the same principle - web apis should only return the minimal amount of information needed? What is it to minimize the amount sites need to request? 33 | 34 | Nick: a common situation that the api is designed to return the entire address book, or ... we say don't do that, just request the one thing 35 | 36 | Pete: seems like good advice. But that we should say apis should only return to a site the information needed to carry out the user's goals 37 | 38 | Nick: that is what the earlier text said but it got shortened 39 | 40 | Jeffrey: how does the browser know what the user's goal is? The site has to tell it. The user wants me to have all this data and the site only wants a tiny piece of that, the site needs to communicate that, so the site can accurately represent the user's goals to the browser 41 | 42 | Pete: I don't disagree but I don't see how that hooks into this 43 | 44 | Jeffrey: when the site is representing the users goals to the browser the web api is designed so that the site requests data that matches what the site says the user needs> We often design apis that make the site request too much data, more than the site wants or the user needs the site to have, and so this is trying to say don't design it that way so the site can request the minimal amount of data. 45 | 46 | Nick: previous version was longer, maybe we should revert to it 47 | 48 | Dan: I'm happy with that 49 | 50 | Don: the site's representation of the user's goal may not be correct.. users do visit a certain % of sites they didn't intend to. The site may claim the user wants to share a bunch of information with me when actually the user clicked on something by mistake 51 | 52 | Jeffrey: web api design can't help with lying sites, but we can allow the honest sites to request what they need 53 | 54 | Don: we need to make sure that we can't 100% trust that what the site says about the user's goals and the user's actual goals are the same 55 | 56 | Pete: do we consider ancilliary data as personal data in this document? 57 | 58 | Nick: yes 59 | 60 | Pete: good 61 | 62 | Jeffrey: it may be amibiguous 63 | 64 | [merged] 65 | 66 | ## https://github.com/w3ctag/privacy-principles/pull/325 67 | 68 | Jeffrey: Yoav's comments are on the original version of the text, not this PR - I need to sit down with him to address those comments, but we can merge the PR without dealing with that yet 69 | 70 | [working through editorial suggestions] 71 | 72 | [merged] 73 | 74 | ## https://github.com/w3ctag/privacy-principles/pull/334 75 | 76 | Jeffrey: merge conflict... 77 | 78 | Jeffrey: the change to definition of automation asymmetry would require other changes as it collides with another 79 | 80 | Robin: I agree that the definition in the consent section could be worked on. I do think it's closer than this one though. I'd suggest we make an issue to improve the definition of automation asymmetry but don't make this change 81 | 82 | Jeffrey: that works for me 83 | 84 | Robin: [makes issue](https://github.com/w3ctag/privacy-principles/issues/346) 85 | 86 | [discussion of editorial changes] 87 | 88 | 89 | Jeffrey: can we remove the bit about FIPS? 90 | 91 | Pete: agree 92 | 93 | Robin: experience with lawyers and lawmakers think this is fine and a good framework.. 94 | 95 | Dan: can it be compressed to half the size? 96 | 97 | Don: I think there are going to be some readers skimming this document so if we have extra mentions of FIPs as being inadequate (or inappropriate) that's not going to be wasted. Looking at some of the day to day privacy compliance stuff, from the point of view of someone who is doing privacy compliance as a checklist task then avoiding doing that on the basis of FIPs is a huge win 98 | 99 | Robin: FIPS are the state of the art outside of computer research labs, and they're very bad 100 | 101 | Jeffrey: suggest keeping a lot of the discussion and make it an example. But don't want to block this PR on that discussion 102 | 103 | Robin: I've created [issue #347](https://github.com/w3ctag/privacy-principles/issues/347) to compress the discussion 104 | 105 | Nick: I think the FIPS are fine, the text should say implementation is bad... 106 | 107 | [ready to merge when git conflicts are resolved] 108 | 109 | 110 | 111 | 112 | -------------------------------------------------------------------------------- /meetings/2022-08-03-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF - Wed, 3 August 2022 2 | 3 | Present: Dan, Don, Pete, Nick, Christine, Shubhie, Wendy 4 | Regrets: 5 | 6 | ## [Ethical Principles Tweak](https://github.com/w3ctag/ethical-web-principles/pull/85) 7 | 8 | Dan: TAG f2f (dinner with timbl): Amy, Hadley, and I worked on a change to the ethical web principles. Changing the name of the principle, for consistency, to active voice. "The web must be secure, and respect peoples' privacy" vs "Security and privacy are essential." Want to make sure it doesn't appear to be lowering TAG's emphasis on S&P. Please leave review comments. 9 | 10 | Nick: Sounds good. I like the introduction of the word "respect." From a standards perspective, MUST is as strong as it gets. 11 | 12 | Wendy: Sounds good to me. 13 | 14 | Dan: we welcome other feedback 15 | 16 | Don: +1 to must in the standards context. 17 | 18 | ## [ancillary uses](https://github.com/w3ctag/privacy-principles/pull/170) 19 | 20 | Dan: Anything to talk about re ancillary uses? 21 | 22 | Nick: Apologies, no revised text yet. Any thoughts on how we might come toward agreement? 23 | 24 | Shubhie: point of contention - being vague about using the UA make decision on behalf of the user. 25 | 26 | Nick: "UA should seek to work on behalf of the user / UA could use heuristics to make decisions" vs. "no vagueness / very driven by the particular action that the user is taking and consent" 27 | 28 | Peter: Framing ... UAs should work on behalf of the user. Question is what counts on behalf of the user vs. on behalf of the site. 29 | 30 | Don: one feedback we will get : there are actions taken by sites on behalf of users based on info that those users would have chosen to share if they understood it. Long advertising history of publisher media kits making claims to advertisers about audiences for an ad-supported medium. If a site can infer that a user rides the bus, then they can get a nearby advertiser such as Starbucks to advertise on that site based on number of bus riders in the audience, and use the ad revenue to create more content that benefits the user. I want to have this document become not just a set of philosophical principles but reflect long-held information sharing norms that people have in markets that have advertising and publishing. 31 | 32 | Nick: different types of telemetry - performance telemetry .. browsers could ask users "do you want to give telemetry back to websites" - I think that's just an update that needs to happen. 33 | 34 | Shubhie: +1 to treating them as seperate betwee telemetry and advertising... the other point: a way to bridge this is :if you say every time you ask the user it's too specific - if it's bit more general - users being able to opt out. Adding these specific ways how the UA is supporting. 35 | 36 | Don: any time we mention asking the user - we need to tag in the concept of privacy labour. UA is not acting on behalf of the user when it's interrupting or distracting them to ask for consent to something that they don't understand or are unlikely to consent to. 37 | 38 | Pete: i kind of disagree we need a special case for telemtry... not connected to the user's goals... user should be informed and make it one of their goals... you can imaging other types of data that are not telemetry. 39 | 40 | Pete: visibility and consent are connected - is it connected to what the user want to do. Does the user want to participate? Don't think [purely] opt out. If it's a consent model I'm ambivelent if it's ... return visits to site in order to use telemtry seems wrong to me.. 41 | 42 | Shubhie: yes - gets into the privacy labour point. 43 | 44 | Pete: avoiding unnecessary privacy labour - we shouldn't do things that require onerous consent. 45 | 46 | Shubhie: UAs are a primary audience... what would be more useful for a UA is - how do I participate in this? 47 | 48 | Don: some of the browsers are doing summary notifications like "we blocked 96 trackers" - at that point the user has an opportunity .. "96 opportunities to connect and share with brands that I missed? Better change that setting" 49 | 50 | ## [PR on role of sign-in](https://github.com/w3ctag/privacy-principles/pull/173) 51 | 52 | Shubhie: feedback I heard - what can the UA do? What I'm going to do is re-write it as "UA should help user to present the identity they want to present to the site. A site-specific-identity and not have to give away PII." 53 | 54 | Christine: wanted to clarify - yes, whilst one of the primary audiences is the UA - and where appropriaye we should include principles that apply to other parts of the ecosystem including web sites. 55 | 56 | Shubhie: i framed it as web sites should not have undue influence in that... my proposal is web sites shouldn't be forcing users to sign in - but not buy-in on that. 57 | 58 | Nick: I do think part of the audience is the UA - another part of the audience is spec authors... new feature design... to christine's point I don't mind saying "this is the expectation we have for websites". We can say "websites shouldn't coerce users" and that means browsers should provide features o protect users from coersion and APIs should be designed to resist coersion... Also wouldn't like to use "PII". 59 | 60 | Dan: +1 to spec authors as audience. 61 | 62 | Don: we need to be careful about requiring forcing users to log in - we need to handle all kinds of web sites - could be sites that only make sense with specific info - e.g. a trouble ticket web site that needs to show the appropriate tickets to the appropriate service reps -- we have to be aware of web applications that only make sense in the context of a specific user - "not coerce people to log in purely for data collection". 63 | 64 | Dan: or unless there's a "user need" 65 | 66 | Don: e.g. Netflix would say there is a user need. 67 | 68 | Shubhie: sounds like there should be wording - but not super specific - and adding things like the reason... related to a user need. 69 | 70 | Dan: web site should not know what e.g. credentials you have before you choose one... 71 | 72 | Shubhie: user agent ... email 73 | 74 | Nick: we're not just providing guidance "don't do this" but affirmitavely ask "we want features that do this"... features for users to be able to delet these features... 75 | 76 | Dan: probably we should / do focus on features that are either in development or are already implemented - but giving - giving positive reinforcement to stuff going in the right direction. 77 | 78 | Christine: this document is supposed to be also aspirational - not just the status quo. 79 | 80 | Don: all the user data practices that you can trace back through centuries of use, pre-Web, are more likely to persist longer -- the more we can reflect what people have arrived at over time the more relevant the doc will be 81 | -------------------------------------------------------------------------------- /meetings/2023-04-05-minutes.md: -------------------------------------------------------------------------------- 1 | # TAG Privacy TF Minutes 2 | 3 | Present: Don, Dan, Jeffrey, Pete, Wendy, Sam, Christine 4 | Regrets: Nick 5 | 6 | ## Ancillary Data 7 | 8 | ### [243](https://github.com/w3ctag/privacy-principles/pull/243) 9 | 10 | J: feedback I got is that it's just after GPC but doesn't explain GPC... So just adding the preference about data sale to this list would fix it. 11 | 12 | Dan: can we do that and ask Robin to review? 13 | 14 | Don: i like removing GDPR as mention of a specific law... people mistake the current state of GDPR semienforcement for what is actually required by GDPR... not future proofed... (document should not refer to one particular level of enforcement of a particular law at one specific time) 15 | 16 | Don: i feel we can imply that's likely GPC will be recognized as objection to processing (in places that have such a thing) without mentioning specific jurisdiction or the state of enforcement at any time 17 | 18 | Pete: move GPC to an example section? 19 | 20 | J: it's an example - we have GPC as an example ... but we have list of things GPC might do doesn't overlap. They are in different paragraphs... might break the flow to move it to another section. 21 | 22 | J: can be read to imply that the next paragraph describes GPC. But adding something about sale to this list woulf fix the problem. 23 | 24 | Don: realistically it's more likely that regulators that enforce GDPR will enforce GPC as an Art. 21 objection than that they'lll continue to allow you to ignore it -- we want this to be useful for many years, so cover principles and not what you can get away with in a particular country at the present time. 25 | 26 | ### [fiduciary](https://github.com/w3ctag/privacy-principles/issues/240) 27 | 28 | Jeffrey: Wendy suggested one... I think it needs a PR... 29 | 30 | Wendy: the piece of literature (Jack Balkin) that started the conversation about information fiduciaries. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3700087 Seems to satisfy the need we're addressing. It has started a bunch of debate over concept of fiduciary ... we're far from saying "this is the solution" - but it's useful and generally acknowledged as a good branch... 31 | 32 | Jeffrey: I will swap it in. 33 | 34 | ### [print advertising](https://github.com/w3ctag/privacy-principles/issues/235) 35 | 36 | Jeffrey: discussion on issue - a lot of it is yes... We're requiring things of the web that print doesn't do but not acknolwedging it - are we holding the web to a higher standard? I think saying "offline ads violates these principles sometimes" might fix. 37 | 38 | Don: I'm not convinced. You can go to a newsstand and pay cash for a magazine and do research... The area where the web is substantially different from print is in the terms of service as contracts and the effect of most website ToS is to prohibit the kind of investigation that would make it easier to discover deceptive ads. 39 | 40 | J: Enforceable? 41 | 42 | Don: depends on jurisdiction (CFAA enforcement seems to be in flux in the USA, not sure about elsewhere?) 43 | 44 | J: seems like the kind of research you'd do in print vs the web ... those seem similarly difficult... 45 | 46 | Wendy: i agree with Don - the ToS and degrees of individualized targetting and lack of an easily closed loop on print adv. make it different in terms of the user's relation to it. 47 | 48 | J: in print only targeting you get is by demographic of readers of the magazine... On the web you have another option... 49 | 50 | Dan: maybe we do need to hold to a higher standard 51 | 52 | Don: much of the way web adv is designed is optimized for delivering scam ads -- if you're doing a precious metal scam ad in print - it's more likely that other members of the household would see it, but it's extremely easy to target senior citizens on the web 53 | 54 | Wendy: I'll try to add to the PR commentary. I think we might be getting beyond privacy per se - sure print can collectively discriminate but it may not be as tied to our privacy as other societal goals... 55 | 56 | Jeffrey: might be something - a change to the section about discoverability mitigates these group harms... if people outside the group can easily seen what is being targetted towards the group that might be good... and that could inform the design of web apis... 57 | 58 | Don: brings it back to ToS - ToS on large platforms designed to forbid practices to research which deceptive ads are delivered to you (NYU/Facebook drama) 59 | 60 | Don: a publisher tried to put a ToS in a printed book - however that was ruled invalid by a court (see First Sale Doctrine in the USA) 61 | 62 | Jeffrey: will come up something about discoverability. 63 | 64 | 65 | ### [Clarify uses of "self-governing"](https://github.com/w3ctag/privacy-principles/issues/233) 66 | 67 | J: some experts don't like us using this word... removing would improve compliance with TAG styleguide... 68 | 69 | Dan: I'm sympathetic to removing it ... someone else interested in re-wording these 3 spots... 70 | 71 | Dan: to make PR 72 | 73 | ### [avoid endorsing cookie banners](https://github.com/w3ctag/privacy-principles/issues/230) 74 | 75 | J: Michael's last [comment](https://github.com/w3ctag/privacy-principles/issues/230#issuecomment-1488790780) in the issue is useful. We talk about "vivid" and "explciit and deliberate specfic action". Robin is saying that to authorize some kind of data use you should click something that approves.. just clicking on a link is not that. We're overstating or being vague. 76 | 77 | Pete: He gives the option of prompting for cookies as a bad example... but it leads to browsers having more controls and users having more controls which is a good thing. Cookie notifications... have given user's controls... 78 | 79 | J: we want more systematic controls... our text says "a deliberate specific action" 80 | 81 | Pete: depends on what you mean by specific... 82 | 83 | J: it doesn't refer to the particular use... seems more general than a cookie banner.. 84 | 85 | J: might convince michael to suggest text for this... 86 | 87 | Dan: can this simplify language? 88 | 89 | J: I suspect so... 90 | 91 | Don: I think we're confused about indicators and cookie banners... people are assuming that a banner is a dialog that requires some action from a user... I added another example of animated characters that remind people of govt. surveillance... An easy way to show the user that there's a data collection practice... there's got to be a clear distinction between an indicator and requiring clicking through on a dialog. 92 | 93 | ### [other docs](https://github.com/w3ctag/privacy-principles/issues/228) 94 | 95 | **agreed to close** 96 | 97 | ### [who is processing?](https://github.com/w3ctag/privacy-principles/issues/225) 98 | 99 | J: i think we can close. [don wrote something explaining why](https://github.com/w3ctag/privacy-principles/issues/225#issuecomment-1461312522) 100 | 101 | Dan: Happy to close on that basis. 102 | 103 | --------------------------------------------------------------------------------