privacycg / meetings Goto Github PK

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?

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:

• DOM Storage support
• Top-level Storage Access as proposed by Chrome and Firefox and how to converge these
• Forward-Declared SAA
• Login Status integration
• Request Header integrations for SAA

We'll probably not get to all of those, would be good to know if folks are interested in covering anything in particular.

cc @bvandersloot-mozilla @helenyc @cfredric @annevk

@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

cc @johnwilander @bvandersloot-mozilla @annevk

As discussed in the last call it would be good to sort out our collective story around cookies. Tentative agenda for a dedicated meeting:

1. Are the usual cross-site cookies "blocked" or "partitioned"?
2. Do we need opt-in partitioned cookies? And if so, through CHIPS or requestStorageAccess(), or something else?
3. How do we organize standardization?
4. Interaction of cross-site cookies and SameSite=None.
5. Ephemeral partitioned third-party storage (including cookies) by Brave: privacycg/proposals#18.

As discussed here, a few folks are interested in an ad-hoc meeting dedicated to Bounce Tracking.

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'd like to discuss at TPAC how and when we can move Storage Access API out of Privacy CG :)

cc @annevk @bvandersloot-mozilla

@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'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:

4. Interaction of cross-site cookies and SameSite=None.
5. Adding more contextual information to requests: w3c/webappsec-fetch-metadata#56 & w3c/webappsec-fetch-metadata#80 (see privacycg/CHIPS#2 for context).
6. Ephemeral partitioned third-party storage (including cookies) by Brave: privacycg/proposals#18.

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

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.

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?

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.

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

1. A company, say rp.com, hires the services of another company, say idp.com, to host and manage its authentication system, typically giving them a rp.idp.com subdomain. @hlflanagan did I get this right?
2. When users navigate to rp.com they get redirected to rp.idp.com
3. rp.idp.com, hosted and controlled by idp.com, handles the user's authentication to rp.idp.com and sets rp.idp.com first party cookies
4. rp.idp.com navigates the user back to rp.com with the user's identity in the URL parameters.
5. rp.com takes the user's identity from the URL parameters and logs the user in
6. rp.com embeds iframes pointing to rp.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:

1. 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 of rp.idp.com.
2. Step (5) and (7) are no longer a problem because rp.com and login.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.

1. Say tracker.com asks websites to add CNAMES pointing to it.
2. tracker.a.com points to the tracker.com's IP address
3. tracker.b.com points to the tracker.com's IP address too
4. 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:

1. Can / should the FedID CG use CNAMES as a recommendation, or would we run into a wall long term?
2. And if so, where should we go from here?

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/

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.

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

Logistics

• When: 13–14 May, 15:00–19:00 UTC

Agenda

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.

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.

Logistics

• When: September 16-17, 15:00–19:00 UTC

Agenda

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 present an overview of Chrome's experiments in bounce tracking and our initial MVP implementation in Chrome.

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

I would like to talk about Invasive Fingerprinting Protection in Chrome at W3C TPAC 2023.

As per the most recent call, i would like to organize a meeting regarding the https://github.com/privacycg/js-membranes proposal. Thanks!