-
Notifications
You must be signed in to change notification settings - Fork 162
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
003305b
commit 0f63ec8
Showing
1 changed file
with
71 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,71 @@ | ||
| ### Notes | ||
|
|
||
|
|
||
|
|
||
| * Blog Post on developers.chrome.com List of changes: | ||
| * Please join this mailing list for announcements & discussion: https://groups.google.com/a/chromium.org/g/topics-api-announce/c/iNYk69wKnJs | ||
| * v2 Taxonomy (349 -> 469 topics, removed several from v1 if found to be less valuable. Will be available in Chrome 116 release. | ||
| * Per-caller filtering | ||
| * User controls (announced intention for the changes) | ||
| * Speed improvements / decrease latency. | ||
| * Special Topics Provider Sites (github issue # 206) - Don Marti | ||
| * Niche site that covers one or few topics can disproportionately feed more information (as opposed to Youtube, which may provide a larger number of topics but is only classified as one set of topics). | ||
| * What are the technical directions we can go ahead to address this? | ||
| * [kleber] | ||
| * Niche sites contribute to that one or few topics, where as YT has content on a larger number of topics | ||
| * Imbalance is however not true - since a site such as YT already has enough information and may not greatly benefit from the Topics API, but the smaller niche site will definitely benefit from topics api. It inherently balances the benefit based on the data we have. | ||
| * [don marti] | ||
| * We are able to see from only from the niche site perspective, If data is available across both, to some other party, these will help substantiate the statement (reported in an aggregated way that does not reveal individual user data) | ||
| * [karlin] | ||
| * These not about niche vs larger sites, it is about with-topic-of-value versus topic-with-not-much-value | ||
| * This is not just about niche or not.. But if they contribute to value and this imbalance will continue to exist | ||
| * [don marti] | ||
| * We have highlighted this issue since day-1, and it would be good to address how to solve for the imbalance. | ||
| * [kleber] | ||
| * Would be good to address how to improve the Topics API in a manner that will be for all sites (niche or large/general sites) | ||
| * [leeron] | ||
| * Many of these were internally discussed internally | ||
| * Is the technical solution suggested on how the sites can directly contribute to the topics? | ||
| * [don marti] | ||
| * Different proposals have been made on github, and we may need to take a look at these. More detailed and high quality suggestions than we can cover in one meeting. | ||
| * [garrett johnson] | ||
| * Can you share more details on what was discussed internally? | ||
| * [Leeron] | ||
| * Page titles, identifying user generated content and other signals were discussed. Security and privacy concerns on sharing content and/or sensitive information were flagged. | ||
| * [karlin] | ||
| * Pretty much to do with security concerns | ||
| * If a site can’t access a content in a frame, and topics generated includes details this may lead to learning more than what is allowed by default. | ||
| * [kleber] | ||
| * Multiple different type of barriers exist | ||
| * Josh mentioned security | ||
| * In terms of information flow, topics api should not make available more information than what is available w/ 3p cookies | ||
| * Overall, quality of the available topics is the larger issue - more flexibility here than with security. Knowing what the topics of the page are is critical. The author of the page knows most about the topics in that page. They are better suited to contribute to what is the ideal topic. | ||
| * Quality also should address malicious intent of any one deliberately changing, sabotaging or providing a topic. Topics does it well by using the domain name / host name. Page title, and other metadata can be used in that sense. Title is probably a better solution since that is available on the window.. | ||
| * [karlin] | ||
| * Title is dynamic, and people can still game the title (one a top n-characters are displayed, but it could be longer). | ||
| * [kleber] | ||
| * Using title may be appealing here (as opposed to only the hostname) | ||
| * Using page title, if it comes up as a Feature Request, from the folks who would actually opt into using it with the titles of their own pages, would be a big help in our prioritizing the effort. | ||
| * We can’t do it by default, it can be an opt-in, and to prioritize we need publishers submitting a feature request | ||
| * User Permissions policy (Don Marti, github #224) | ||
|
|
||
|
|
||
| ### Attendees: please sign yourself in! | ||
|
|
||
|
|
||
|
|
||
| 1. Don Marti (Raptive) (the company that used to be CafeMedia) | ||
| 2. Leeron Israel (Chrome) | ||
| 3. Josh Karlin (Google Chrome) | ||
| 4. Sathish Manickam (Google Chrome) | ||
| 5. Christine Runnegar (PING co-chair, part call) | ||
| 6. Michael Kleber (Google Chrome) | ||
| 7. Nitin Nimbalkar (PubMatic) | ||
| 8. Lisa Markou (Ford) | ||
| 9. Matt Digan (NYTimes) | ||
| 10. Jean-Baptiste Debordes (Criteo) | ||
| 11. Kelsey LeBeau (Google) | ||
| 12. Steve Luo (PubMatic) | ||
| 13. Garrett Johnson (Boston University) | ||
| 14. Eyal Abadi (P&G) | ||
| 15. Alex Cone (Google, Privacy Sandbox) |