<wseltzer> present=

<wseltzer> https://github.com/shivanigithub/fenced-frame/blob/master/README.md

<wseltzer> https://w3c.github.io/web-advertising/dashboard/

<scribe> scribe: Karen

Wendy: Looking at our agenda today
... Agenda curation and intros
... Intro to Fenced Frame
... Intro of Turtledove JS implementation
... Discussion of agenda planning for TPAC F2F and breakouts
... Dashboard highlights
... and any other business

Agenda-curation, introductions

Wendy: Do we have any introductions; anyone new to the call?

Michal from RTB House...hello (spelling?)

Fenced Frame

Wendy: Thank you Shivani to talk about the Fenced Frame
... came up in context of PTEROSAUR
... Shivani, the floor is yours

Shivani: Thank you Wendy

<wseltzer> https://github.com/shivanigithub/fenced-frame/blob/master/README.md

Shivani: I work in Google Chrome on Fenced Frames; glad to be here today
... Let's dive into the motivation
... the embedded docs
... traditional iFrames
... will move to where storage is acceptable and partioned
... aligned with web privacy model
... since we don't want cross-site tracking
... good example is turtledove
... requires user data not partitioned
... other examples

<wseltzer> https://github.com/shivanigithub/fenced-frame/blob/master/README.md#introduction

Shivani: lift studies, portals
... and so on
... We are looking for a primitive that is embedded doc
... that has access to user data
... the key point here
... is such embedded docs should not communicate with their embedders
... key point is
... these embedded docs have access to user data
... not allowed to communicate to embedding page
... and same for other direction

<wseltzer> [[The fenced frame enforces a boundary between the embedding page and the cross-site embedded document such that user data visible to the two sites is not able to be joined together.]]

Shivani: not pass on user ID to the embedded cos
... not correlate on embedded site
... restrictions here
... communications, access
... come to that in detail more
... There is still some info that will need to be communicated

<wseltzer> https://github.com/shivanigithub/fenced-frame/blob/master/README.md#design

Shivani: between the main page and the frame
... some of that is required
... like the size info or the embedders top level site
... the post message is very explicit comm channel
... will be restricted
... also worry about side channels such as resizing
... repeat resizing could provide a communication side-channel
... take those into consideration
... network side channels from server end as well
... This was a summary of the Frame concept
... Frame works normally like a tab, but does not work as a normalized frame
... I am going to talk about turtledove as primary use case
... how things will flow using a fenced frame

<wseltzer> https://github.com/shivanigithub/fenced-frame/blob/master/README.md#use-caseskey-scenarios

Shivani: The track model for TD is that adv can show interest based ads but not show the provenance of user
... keeping these privacy threats in mind
... FF helps keep these in control
... TD in two steps; one is on-device auction, other is rendering of ad
... Google requires some isolated environment to work in
... looking at on-device auction, requires a JS environment
... has access to some contextual info from surrounding page
... and the interest of the user
... can involk the TD APIs
... any questions?

Wendy: will you take questions after?

Shivani: yes

Wendy: keep going

Shivani: the on-device auction is process that needs contextual information
... is there a question?

hober: I can wait and ask it later

Shivani: the on-device auction is flow that has access to embedded contextual info and the TD info
... Based on interest group, browser has downloaded ad; JS environment will find which is the winning ad
... doesn't have access to storage
... cannot join data to the two contexts
... data it can output is a URL
... one of web bundles downloaded earlier
... a new concept of opaqueness
... can give away the interest group
... environment is opaque and can be taken as input to a fenced frame
... a common URL

<wseltzer> https://github.com/shivanigithub/fenced-frame/blob/master/README.md#design-2

Shivani: since it is inside a web bundle it does not need access
... that's good because network timing site channel is taken care of
... ad gets rendered
... when the rendering frame is getting some good activation
... that is the point at which we can allow network access
... there are video ads that may need network access
... video ads may not be in web bundle a priori
... after user activation
... that is another key point of the fenced frame
... that is what I had; I can take questions now

Wendy: Thank you very much
... People who have been on earlier calls there were discussions of blind rendering

<Zakim> hober, you wanted to ask about <fencedframe src=third.party/first-party-identifier>

Wendy: Sounds like it could be a fleshing out of how that works

Hober: My question was
... the idea is to

<lukwlodrczyk> +q

Hober: prevent embedded identifiers
... from being joined from the embedder site
... one thing is...URLs
... seems like as soon as frame has any storage access it has joined those identifiers
... Have I missed something?

Shivani: Link-decoration of the URL coming into the frame
... is a comms channel, depends upon the use case
... example of TD, the URL allowed to go into the fenced frame is not related to the embedding page
... this is a use case where URL has to be verified
... that was downloaded prior to when the schedule was loaded

Hober: So I think what you are saying is that this depends upon web packaging
... Fenced frame has to be loading a web package

Shivani: A web bundle, and a web package is downloaded irrespective....
... this requires that

Hober: let me ask clarifying question
... the browser
... would note a priori
... that there is these web bundles that pages might want
... browser pre loads regardless of user navigation
... source attribute of FF has to match exactly one of the precanned packages th browser knows about

Shivani: That's right
... TD APIs are taking care of that
... other part of question, if URL is from the page
... there is this third page, one of result is trying to render in a FF
... that is case where URL is dynamically generated
... possible for URL to be placed in identifier
... in those scenarios
... have a link-decoration detection technique before putting FF into those scenarios
... figure out it's not a tracking vector for URLs

Hober: FF source equals blah and if blah is not preknown to browser, FF does nothing...

Shivani: yes, those kinds of mitigations
... so FF does not get access

lukwlodrczyk: Thank you for that write up
... see these proposals and other Google proposals
... one thing that we will be willing to
... in design you mentioned a new on-device opaque computation result
... but it is not described in the repository
... is this an element of this proposal, or we should expect further details?

Shivani: This will come in a separate proposal and will be linked from here

Bleparmentier: Small remarks
... when we proposed SPARROW that relies on such frames
... that will be defined one day
... we said browser could check if PII was in the URL
... surprised that this will necessitate that you do it
... at the time
... I thought you did not want to do something like that; was there a change of mind?

Shivani: I missed first part of question about the change

Michael: I think I can answer

<Zakim> kleber, you wanted to answer Basile

Michael: the difficult problem that came up in discussion of sparrow was browser looking at URL and decide if browser contained PII
... that is not same question that Shivani mentioned earlier in link decoration
... check for browser to load a frame
... question is does this URL communicate any specific information about this user at all
... or is it a URL common to many users
... not if URL contains any PII which is hard to recognize, encrypt or disguise, or is this a generic URL
... or a URL specific to this user, situation or page view
... that is a much more approachable question

Bleparmentier: As soon as you check the number of users on URI...not clear
... small point
... this would be issue for small publishers or new product pages, new article where there is not that much at first
... might be an issue at first
... not as developed as much as you want
... something to consider; maybe there are solutions here
... being sure it's common URL
... might be a challenging requirement

Wendy: Thanks, any other questions or comments on this proposal?
... Thank you for sharing that explanation Shivani. Where do you anticipate discussion of this proposal to take place?

Shivani: Not sure if there is a specific platform
... definitely the turtledove repository, but that is just one use case
... others from Google want to chime in here?

Wendy: you are welcome to come back for further discussions, questions of the advertising use cases and interests from the advertising and measurement use cases
... We look forward to watching; put a pointer to this repository and on the tracking dashboard and watch issues that are raised here and invite you back for further discussion as things develop

Charlie: keeping feedback inherent to the FF mechanism on the FF Github and FF issues is the right move

<wseltzer> https://github.com/shivanigithub/fenced-frame/issues

Charlie: if there is an issue that is very specific like TD use case
... that could go into the TD repo as an issue there
... and we can cross-link
... issues on the FF repo would be good for providing feedback and discussions

Shivani: thanks

bmilekic: FF and broader proposal
... noticed when it comes to video, it is treated as an edge case
... especially when video is loaded...
... what is Google's take on video in general
... will video be addressed at a later time; do you have some mechanism in mind to handle the video ad case?

Shivani: definitely have to dive into more
... starting bytes could start without user activation
... once activation from FF it can go and get more bytes from the network

Bleparmentier: this is one of point I wanted to make with Gatekeeper proposal in sparrow
... everything in browser
... a lot of optimization
... to a lot of good use cases
... that exist in the
... if we need user to interact... after two seconds...don't think that is an improvement for user privacy
... @ would solve a lot of issues
... just to say we have wide discussion
... something in browser or server, or maybe I missed something
... have impression where putting everything inside the browser might pose some issues that might not benefit privacy
... I think it's important for video; may be an issue

Wendy: Michael?

Michael: I agree that there are some things that are hard to do something entirely inside the browser
... and to trust server to not do some things; different pieces to pick up that approach
... willful IP blindness is an approach for doing that
... a server has been certified in some way to not do IP based tracking
... separates IP based part of stack from business logic part of stack
... risk in loading ads over network is a timing attack
... if you load video in same moment there is this risk of recognizing user based on time page loads and time video is requested
... would be resolved by a video server that is not correlated to time videos when served
... servers that deliberately renounce the ability to do a side channel attack
... could be a help for some privacy use cases

Bleparmentier: [the Gatekeeper is proposed to keep confidentiality to address]
... sparrow avoids this timing attack
... you do agree there is some merit

Michael: Yes, sparrow fits into that paradigm also

Wendy: thank you again for this conversation

turtledove-js implementation

Wendy: next up we have turtledove-JS implementation

<wseltzer> https://github.com/dervan/turtledove-js

Michal: I want to say a few words about what we did at RTB House
... how TD could work on web so we created a simple implementation and pushed it into a public github repository
... could be a drop in replacement until TD is implemented in browser
... navigator object methods
... use the TD itself
... all you need is just one ....code to enable it
... enable TD to get a better understanding how it works in future
... or to add some new feature
... or adtech, publishers, advertiser wants to build proof of concept with TD
... then you can just use our TD-JS
... include this one TD JS file
... called init
... and you are good to go
... simply use the fetch function
... and join the interest group
... and future browsers will be transmitted
... we don't recommend it just yet
... but you can run a small test in production
... we want to modify browers; based on existing technologies
... local storage and embedded iframes and post messages
... stored locally inside browser
... and main hosting files
... TD in proposal
... keeps private info private
... Along the code we implemented...
... everything available on the internet; you can play with our demo

<wseltzer> https://github.com/dervan/turtledove-js#sample-testing-scenario

Michal: code is not limited to the demo
... everyone can write
... advertiser can put in readers field
... publisher integrated with same ad network
... can check out more details about our simulation in the github repository
... you will find links to the web site
... add yourself to sample user groups and see some apps
... we encourage you to play with it
... align your vision; hope demo will be useful
... for discussions on TD
... not a reference implementation
... but we hope together we will reach some better understanding and clearer vision for how it may look
... invite you to look at this
... find link on irc
... thank you

<Zakim> kleber, you wanted to say how great this is!

Michael: Hi, so first of all, thank you very much
... this is really wonderful, playing around with it yesterday
... seeing summary ads; watched state of browser change in test site
... really very smooth; impressed
... TD is in relatively flexible state
... dozens of issues and ways people are talking about how it can be changed
... as Michal said, nothing should be taken as a decision has been made
... more details for explainer from January
... we are not dismissing ideas since then
... one missing thing is difficult questions about how multiple ad networks interact with each other
... what happens with real time bidding situations
... whoever is making ad buying decisions; not same company
... origiinal TD proposal was vague
... if different adtech cos want to extend and try out different possibilities for how shared info among two ad networks could work smoothly, I would love to see that in this demo environment
... thank you so much

Michal: thank you for your comments, Michael
... this topic is one of our main interests in this demo, too
... we will be looking at the public [contributions]

Wendy: any other questions or comments?
... assume people will raise comments or questions in your repository?

Michal: exactly; welcome to open issues and to contribute to repositories

James: hi there
... not related to the tech
... this seems like a lot of work
... and well received by other participants
... how long did it take you and were there any challenges you can share?

Michal: about two months of one programmer
... and with holidays included
... it was not very much time
... a lot of things are not final of course
... a lot of work to do
... to use it in production
... the main thing was in two months

Bleparmentier: I just wanted to thank you also
... it is a lot of work and we will all benefit from having something we can touch
... very impressive what you did
... a lot of things are not here, but you had to make some choices
... I will like to work on it
... similar things for reporting
... we have clearer proposals from TD and Sparrow
... we all benefit from having real stuff
... maybe work and file issues
... I appreciate it, thank you

Wendy: Excellent
... enjoy making your choices among cats and dogs, planes and bicycles and watch how the ads...
... next
... on the agenda

Agenda planning for TPAC vF2F and breakouts

Wendy: a little bit more planning for TPAC virtual f2f and breakouts
... I sent out a time zone poll, asking people to indicate where you are
... especially those who don't join these calls regularly so we schedule the meeting in times that are as effective to capture the full global set of participants
... from that we will select four-hour blocks of time to meet
... and we will work to fill out an agenda
... about 7 hours of breaks and discussion times
... let's think about where we want to hear about more in-depth conversations
... might get some reporting back of some proposals that have been incubating in repositories
... we can also go back to
... higher level brainstorming questions
... are there categories of use cases to reconsider or consider anew
... we have seen a lot of advertising and presentation of ad selection
... use cases
... we might think about measurement
... and go back to some of the hard questions we asked on cross-device measurement and non-user based tracking
... so think about that
... and if you have ideas
... submit them in the Github repository or raise them here for our consideration
... Another area of possible interest
... is gathering the support for the necessity of use cases
... we have proposals sometimes with some degree of implementer interest
... and various participants who might be users of those APIs giving expression of interest
... where would you like to be able to use an API and record that interest

<angelina_TechLab> p+

Wendy: give that input to potential implementers
... and as we plan out the agenda
... we can find places to invite specific participants from other groups
... as well to join the conversation

Angelina: I would like to add
... taboo around cross-site tracking
... but we need to address how marketers are using domains and sites
... they have multiple URLs or different sytems for the conversion flow
... for example, credit card application goes through one site, then use another site for conversion
... I worked at MoganStanley where this was the case
... having some sort of solution for multiple domains would be ideal

Wendy: ok, thinking about the multiple cross-domain conversion
... that doesn't lead to generalized cross-domain tracking
... maybe you can frame that as a question or use case in an issue
... get thinking about what might solve that

Angelina: Thanks

Wendy: other thoughts, provocations, comments
... I have noticed that our calls often work well when we have presentation of a proposal or an update and Q&A
... virtual F2F is a chance
... we have a couple of months
... think about if there is something you would like to present to the group
... we have seen tech proposals, explainers, detailed use cases explaining how some piece of the ecosystem works
... to help group think through what might replace pieces or facilitate replacement of cross-site tracking

Robert_Stratton: We would like to propose a couple of measurement applications
... in a couple of weeks
... would we be better to bring concepts first?
... and think about how concepts are working

Wendy: That sounds great

<dialtone> that's not me :)

Robert: better to go in with a fully developed proposal, or better to lay out the principals, get feedback and adjust

Wendy: from my perspective, both are useful steps
... welcome the concepts when ready to share
... I see Michael queued up

Michael: What has worked well for this group in the past is describing the use cases first
... having a clear doc that talks about the business need; how it is met today as first step
... then have useful discussions
... on ways to meet that business need based on current proposals, or introduce new proposals if it is not well met by other things

Robert: start with use case, current functionality

Michael: that is not the only way, but it has been the most successful [with this group]

Valentino: not so much of a suggestion of topic, but F2F would be good place to have a summary of the overall proposals
... work through devleoping some form of summarization and have some discussion on state of progress
... like TD routing of requests at product level; reporting; all happen in different places
... not sure everyone is up to date on the latest conversations

Wendy: yes, fantastic; a roadmap of where discussions are and where they are proceeding sounds helpful

James; not related to tech proposals, we talked about UK CMA reports

scribe: is this TPAC an opportunity to present their findings?

Wendy: I have suggested that getting a
... frame of use cases and requirements
... could be helpful
... not sure hearing a report from competition and markets authority per se is the right approach for this group
... we are not the people interfacing with them
... even though some orgs have been part of the process
... are there takeaways?

James: they have a use case well defined; have remedies; and seems it could be structured in the format you describe

Wendy: ok, thanks
... let's talk more about that
... if we can take that into conversation

James: thank you

Wendy: That takes us to the end of our hour
... thanks for the great proposals and discussion today
... keep up the agenda requests and topics for future discussions
... I heard a few of those raised in this call
... Look forward to talking with you this week

<wseltzer> [adjourned]

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Anjieu/Michal/
Succeeded: s/Pteradacktyl/PTEROSAUR/
Succeeded: s/user data/that has access to user data/
WARNING: Bad s/// command: s/doc
Succeeded: s/resizing frame can be a challenge/repeat resizing could provide a communication side-channel/
Succeeded: s/auction/on-device auction/
Succeeded: s/@/hober/
Succeeded: s/The/Link-decoration of the/
Succeeded: s/in/is a/
Succeeded: s/linked @/link-decoration detection/
Succeeded: s/Bleparmentier/lukwlodrczyk/
Succeeded: s/@/on-device opaque computation/
Succeeded: s/if @ was/if PII was/
Succeeded: s/same user/the number of users/
Succeeded: s/proven/common/
Succeeded: s/@/bytes from the network/
Succeeded: s/...sparrow/ Gatekeeper proposal in sparrow/
Succeeded: s/missed/the Gatekeeper is proposed to keep confidentiality to address/
Succeeded: s/@/init/
Succeeded: s/Dialtone/Robert_Stratton/
Succeeded: s/@/UK CMA/
Succeeded: s/* Fenced Frame/Fenced Frame/G
Succeeded: s|s/doc||
Succeeded: s/proposed @/proposed SPARROW/
Succeeded: s/linked @/link decoration/
Succeeded: s/@ requirement/a challenging requirement/
Succeeded: s/WE/We/
Present: lbasdevant dialtone wseltzer krischapman mlerra Karen wbaker ionel bleparmentier DiarmuidGIll br-rtbhouse sharkey jeff_burkett_gannett kleber dinesh-pubmatic pbannist robarm bmilekic pl_mrcy Jordan_M mjv Chapell jrosewell hober imeyers joshua_koran ddabbs ajknox Rotem_eyeo scottlow AramZS dkwestbr
Found Scribe: Karen
Inferring ScribeNick: Karen
Agenda: https://lists.w3.org/Archives/Public/public-web-adv/2020Aug/0012.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Possible internal error: join/leave lines remaining: 
        <scribe> ...seems like as soon as frame has any storage access it has joined those identifiers



WARNING: Possible internal error: join/leave lines remaining: 
        <scribe> ...seems like as soon as frame has any storage access it has joined those identifiers



WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)