Skip to content

Commit

Permalink
Create 2024-02-14-minutes.md
Browse files Browse the repository at this point in the history
  • Loading branch information
torgo authored Feb 16, 2024
1 parent 75a3e3d commit d896df9
Showing 1 changed file with 47 additions and 0 deletions.
47 changes: 47 additions & 0 deletions meetings/2024-02-14-minutes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# TAG Privacy TF - Wed, 14 February 2024

Present: Dan, Jeffrey, Don, Nick, Wendy

Dan: breakout session on Privacy Principles could be useful

Dan: at AC meeting, will provide a TAG update, including Privacy Principles and statement track

Dan: noting https://undocs.org/en/A/HRC/53/42 that highlights how technical standards bodies need to consider human rights implications...

Nick: some recommendations about getting more inclusive participation .. and actively reviewing... and direct human rights obligations for SDOs, as well as businesses and states

Don: also covering algorithmic discrimination...

Don: the whole web advertising problem... if you have one step that discriminates then all the steps learn that ...

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)

## [vulnerable people](https://github.com/w3ctag/privacy-principles/pull/402/files)

Jeffrey: worried about how to apply the fact that an actor might not know if someone is vulnerable...

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.

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.

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

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

Dan: do we need an additional principle here?

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

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

**merged**

## [honesty](https://github.com/w3ctag/privacy-principles/issues/401)

Dan: I agree with losing the try

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

*we discuss a potential response*

Jeffrey: also i want to mention this section on UA's could stand alone as a dedicated document...

0 comments on commit d896df9

Please sign in to comment.