privacycg / meetings Goto Github PK
View Code? Open in Web Editor NEWAgenda and minutes of meetings of the Privacy Community Group
Home Page: https://privacycg.github.io
Agenda and minutes of meetings of the Privacy Community Group
Home Page: https://privacycg.github.io
I would like to talk about Invasive Fingerprinting Protection in Chrome at W3C TPAC 2023.
I'd like to request some privacycg time at TPAC to discuss the current state of bounce tracking in chrome and other browsers. Would be great for each browser to present their current status and enhancements they think might be worth investing in.
There are numerous definitions of privacy right now, some even vary form proposal to proposal. Some companies claim aggregate is the future of privacy and single identity is a threat by design, while others claim that aggregate is worse for privacy causing hidden data leaks and loss of user control. I could list entire pages with each groups' cons of the other and the risks they pose. Then within each camp there are sub-camps that disagree on type of data or another technology is privacy preserving or privacy threatening.
Everyone is approaching a solution from their perspective of the problem. If we can't agree on one definition of the problem, we should at least agree on what definitions exist, and honestly look at the objections to each one.
Solutions that fix one privacy threat in one model may cause one in another model. Lets acknowledge what the models are. Lets make it clear what kind of data in what kind of transit systems are threats.
An open conversation about this is needed to create a truly private web
@privacycg/chairs Did we request time on this year's TPAC schedule? It's likely we'll have topics to discuss. We should also do a call for topics with the group.
At Chrome we've recently been in contact with the Google Workspace team (@lghall) about their potential use cases for SAA and they shared some great feedback with us that we encouraged them to discuss publicly in the Privacy CG instead. They filed and commented on a number of issues in storage-access.
Instead of marking all of them as agenda+
separately I'd love to see a consolidated presentation of their developer use case and learnings from their explorations at the (next) regular call, which they are happy to do!
I think Nov 10 works for them but will update this issue pending final confirmation.
cc @annevk @bvandersloot-mozilla @cfredric @martinthomson @erik-anderson @hober @johnwilander
We'll be having our second F2F in September!
Given the ongoing global situation and in light of W3C guidance, this will be a virtual meeting just like our initial F2F.
Start | End | Location |
---|---|---|
00:00 (Midnight next day) | 04:00 | Tokyo |
01:00 (next day) | 05:00 | Sydney |
08:00 | 12:00 | San Francisco |
11:00 | 15:00 (3 PM) | Boston |
16:00 (4 PM) | 20:00 (8 PM) | London |
17:00 (5 PM) | 21:00 (9 PM) | Brussels |
Anyone can request that specific issues or PRs be added to the F2F agenda by adding the agenda+F2F
label to the issue or PR. Here's a list of every issue and PR that currently has this label.
I'd like to request some overlapping time between the fedidcg and privacycg sessions so we can share 30 minutes to compare notes at the upcoming TPAC meeting (12-16 September 2022).
We'd like to discuss at TPAC how and when we can move Storage Access API out of Privacy CG :)
Browsers that block 3P cookies by default appear to have a number of heuristics to re-enable 3P cookie access in certain scenarios to improve web compat. For example, certain patterns of popups, redirects, etc that map to certain types of authentication flows used on the web.
We would like a session to discuss these heuristics to better understand use cases, challenges, plans, etc.
@privacycg/chairs sorry for the last minute request, @arichiv and I were wondering if we could spend just a few minutes at TPAC discussing the problems and potential solutions for privacycg/proposals#7, as Ari recently published a new proposal on Chromium side.
I'd like to discuss the state and outlook of some of the various improvements and additions to the Storage Access API (after graduation), such as:
We'll probably not get to all of those, would be good to know if folks are interested in covering anything in particular.
As discussed here, a few folks are interested in an ad-hoc meeting dedicated to Bounce Tracking.
As per the most recent call, i would like to organize a meeting regarding the https://github.com/privacycg/js-membranes proposal. Thanks!
We'll be having our first F2F in May of this year!
We had hoped to have an in-person meeting, but current global situation and in light of W3C guidance, we will have a virtual meeting instead.
Start | End | Location |
---|---|---|
00:00 (Midnight next day) | 04:00 | Tokyo |
01:00 (next day) | 05:00 | Sydney |
08:00 | 11:00 | San Francisco |
11:00 | 15:00 (3 PM) | Boston |
16:00 (4 PM) | 20:00 (8 PM) | London |
17:00 (5 PM) | 21:00 (9 PM) | Brussels |
Anyone can request that specific issues or PRs be added to the F2F agenda by adding the agenda+F2F
label to the issue or PR. Here's a list of every issue and PR that currently has this label.
Hi, I'd like to request a meeting focused on discussion about what a standard, cross-browser First-Party Sets acceptance process and policy might look like. We have an initial proposal that I'd like to use as a starting point.
If possible, I'd like to suggest scheduling the discussion for the hour after the CG telcon on August 12, 2021 (10am-11amETPT). I can share materials and agenda a week in advance if this time is confirmed.
In the FedID CG, we have, as a group, identified that it may be possible to preserve (in the absence of third party cookies) some of the deployment of identity federation through the use of CNAMEs and SameSite cookies.
We would like to know if what we have in mind is: (a) recommended by the browser community as a viable option long term - e.g. no mitigation / intervention planned - and if not (b) recommendations on where to go from here.
The pattern
- A company, say
rp.com
, hires the services of another company, sayidp.com
, to host and manage its authentication system, typically giving them arp.idp.com
subdomain. @hlflanagan did I get this right?- When users navigate to
rp.com
they get redirected torp.idp.com
rp.idp.com
, hosted and controlled byidp.com
, handles the user's authentication torp.idp.com
and setsrp.idp.com
first party cookiesrp.idp.com
navigates the user back to rp.com with the user's identity in the URL parameters.rp.com
takes the user's identity from the URL parameters and logs the user inrp.com
embeds iframes pointing torp.idp.com
to continue managing the user's sessions (e.g. logging out)
The Problem
- Step (4) embeds a user identifier in URL parameters
- Step (6) depends on third party cookies
The Proposal
What's being suggested, and what we are looking for guidance is:
- As part of step (1), the RP can change its DNS configuration to point
login.rp.com
to an agreed upon IDP IP address, to be used in replacement ofrp.idp.com
.- Step (5) and (7) are no longer a problem because
rp.com
andlogin.rp.com
are SameSite.This has desire property of being fairly compatible with the current deployment, requiring a few configuration
changes (rather than using new APIs).
It doesn't seem like that would introduce any new surface that would be able to be abused for cross-site tracking, because it would seem that, even if the traffic is served by the IDP, the cookies would be partitioned by SameSite/RPs.
- Say tracker.com asks websites to add CNAMES pointing to it.
- tracker.a.com points to the tracker.com's IP address
- tracker.b.com points to the tracker.com's IP address too
- When tracker.com gets the two requests, the cookies are partitioned by site, so it can't
join traffic between the two requests
Alternatives considered
There a few alternatives that were considered here, along the lines of First Party Sets, Storage Access API and FedCM.
It is unclear to us if there are security (e.g. DNS not being secured, are there network attacking vectors?) and privacy considerations (e.g. can this be abused? and if so, can we distinguish abuse from federation?) we are underestimating, so looking for overall directional guidance.
We would like to know:
I'm specifically interested in learning more broadly from browser vendors, but specifically from WebKit on CNAME cloaking and bounce tracking:
https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/
Per previous discussions, I would like to organize a meeting regarding the GPC proposal: privacycg/proposals#10 . More info here: https://globalprivacycontrol.org/faq .
Perhaps there's time after the next PrivacyCG meeting: Thursday Dec 10 @ 10-11am?
Hello, at Mozilla we're interested in moving the Storage Access API forward in the standardization process and resolving the existing interop issues to that effect specifically. We would also like to discuss the current state of developer experience and potential ways to improve documentation/examples for using the Storage Access API.
So we'd like to call for an ad-hoc meeting on Storage Access API. I can compile the agenda in advance based on the above topics and any other things people might want to discuss (happy to take suggestions).
cc @englehardt, @annevk, @johnwilander, @erik-anderson, @Brandr0id
I don't expect to be able to hold this meeting in 2020 still, so maybe some time in January?
@samuelgoto and I would like to discuss the future of the Login Status API (nee isLoggedIn) as outlined in his PR here: privacycg/is-logged-in#54
As discussed in the last call it would be good to sort out our collective story around cookies. Tentative agenda for a dedicated meeting:
requestStorageAccess()
, or something else?SameSite=None
.I'd like to present an overview of Chrome's experiments in bounce tracking and our initial MVP implementation in Chrome.
I've done some triage to figure out if there are additional items that warrant discussion. Building on #16 and what did not get addressed in yesterday's meeting, that gives:
SameSite=None
.(Obviously open for further additions, but I figured I'd file this directly to keep track of it.)
Edit: I moved what is now 6 to the end as it's somewhat unrelated to cookies.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.