├── README.md ├── LICENSE ├── .gitignore └── index.html /README.md: -------------------------------------------------------------------------------- 1 | # heatwg 2 | HEAT WG proposal 3 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2021 Robin Berjon 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | lerna-debug.log* 8 | 9 | # Diagnostic reports (https://nodejs.org/api/report.html) 10 | report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json 11 | 12 | # Runtime data 13 | pids 14 | *.pid 15 | *.seed 16 | *.pid.lock 17 | 18 | # Directory for instrumented libs generated by jscoverage/JSCover 19 | lib-cov 20 | 21 | # Coverage directory used by tools like istanbul 22 | coverage 23 | *.lcov 24 | 25 | # nyc test coverage 26 | .nyc_output 27 | 28 | # Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files) 29 | .grunt 30 | 31 | # Bower dependency directory (https://bower.io/) 32 | bower_components 33 | 34 | # node-waf configuration 35 | .lock-wscript 36 | 37 | # Compiled binary addons (https://nodejs.org/api/addons.html) 38 | build/Release 39 | 40 | # Dependency directories 41 | node_modules/ 42 | jspm_packages/ 43 | 44 | # TypeScript v1 declaration files 45 | typings/ 46 | 47 | # TypeScript cache 48 | *.tsbuildinfo 49 | 50 | # Optional npm cache directory 51 | .npm 52 | 53 | # Optional eslint cache 54 | .eslintcache 55 | 56 | # Microbundle cache 57 | .rpt2_cache/ 58 | .rts2_cache_cjs/ 59 | .rts2_cache_es/ 60 | .rts2_cache_umd/ 61 | 62 | # Optional REPL history 63 | .node_repl_history 64 | 65 | # Output of 'npm pack' 66 | *.tgz 67 | 68 | # Yarn Integrity file 69 | .yarn-integrity 70 | 71 | # dotenv environment variables file 72 | .env 73 | .env.test 74 | 75 | # parcel-bundler cache (https://parceljs.org/) 76 | .cache 77 | 78 | # Next.js build output 79 | .next 80 | 81 | # Nuxt.js build / generate output 82 | .nuxt 83 | dist 84 | 85 | # Gatsby files 86 | .cache/ 87 | # Comment in the public line in if your project uses Gatsby and *not* Next.js 88 | # https://nextjs.org/blog/next-9-1#public-directory-support 89 | # public 90 | 91 | # vuepress build output 92 | .vuepress/dist 93 | 94 | # Serverless directories 95 | .serverless/ 96 | 97 | # FuseBox cache 98 | .fusebox/ 99 | 100 | # DynamoDB Local files 101 | .dynamodb/ 102 | 103 | # TernJS port file 104 | .tern-port 105 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Healthy Ecosystem of Advertising Technology Working Group Charter 7 | 8 | 9 | 97 | 98 | 99 |
100 |

Healthy Ecosystem of Advertising Technology Working Group Charter

101 |
102 |
103 |

Mission

104 |

105 | Web technology has grown without paying much attention to digital advertising, and 106 | conversely ad technology has evolved without paying much heed to the fundamentals of Web 107 | architecture. This mutual ignorance has been the source of growing tension. The mission of 108 | the HEAT WG is to resolve these tensions, make advertising a first-class citizen of the 109 | Web, and to design advertising technology as Web technology. The end goal is for the Web to 110 | be the best advertising platform that it can be, and better than any other. 111 |

112 |
113 |
114 |

Background

115 |

116 | Digital advertising is a key business model that supports the production of content on the 117 | Web and subsidises access to it. As an advertising context, the Web has a solid foundation. 118 | It is an environment designed for trust, and a trustworthy environment is a good 119 | one to advertise in. 120 |

121 |

122 | Unfortunately, however, advertising has not been treated as a first-class citizen on the 123 | Web, and as a result the system of digital advertising that developed as a sidecar to the 124 | Web sits uncomfortably with the Web's overall architecture and with the expectations of its 125 | users. 126 |

127 |

128 | This has led to substantial tension. Digital advertising is largely done adversarially with 129 | respect to users, with lip service paid to dubious notions of control or consent and too 130 | often a cavalier approach to users' computing resources and privacy. The current system is 131 | also failing to provide a sustainable business model for publishers to create quality 132 | content and is proving inefficient for advertisers, much of whose money is lost to fraud as 133 | well as opaque layers of intermediation and arbitrage. Broad sharing of data has been 134 | associated not just with privacy issues, but has also been identified as a key factor 135 | leading to market concentration. 136 |

137 |

138 | The scale of the Web, of advertising, and of what rides on both makes this set of issues 139 | challenging. We can, however, fix this, and that is what the HEAT WG is tasked with 140 | accomplishing. 141 |

142 |

143 | The Web can, and does, support multiple business models, but none of the alternatives have 144 | proven able, on their own, to make up for the shortfall that the disappearance of 145 | advertising would constitute. Advertising is here to stay; the question is how to implement 146 | it in a way that matches the Web's foundational values. The Web was designed for broad 147 | access, and ensuring that advertising can be a key sustainable contributor to the Web is 148 | entirely in line with that goal. The Web is a massive piece of infrastructure and shared 149 | knowledge, and advertising a key contributor to sustain it. 150 |

151 |

152 | This view of advertising comes with consequences. The first is that advertising is for 153 | end-users. Supporting the Web infrastructure serves no purpose other than to improve 154 | the lives of people, and that is what advertising must be for. Today's advertising ecosystem 155 | treats the user as an adversary, a target whose data, attention, and computing resources 156 | we are entitled to. This breaks the promise of trust which is at the heart of the Web. 157 |

158 |

159 | The second is that advertising must be sustainable. It must support and help 160 | improve key components of the Web. An advertising ecosystem that fails to sustain 161 | publishers, which is what we are seeing in today's system, is one that is poorly designed. 162 |

163 |

164 | This leads directly to a third consideration which is that advertising must be 165 | effective. The more effective it is, the less of it is needed. The more attractive it 166 | is to advertisers, the better we can improve Web infrastructure with limited taxation of 167 | attention. 168 |

169 |

170 | Finally, such an essential system must, by its very nature, have very strong properties 171 | of governance and accountability. Users must know how their attention is used, 172 | advertisers must know where their money goes, publishers must control what runs on their 173 | sites. 174 |

175 |
176 | 177 |
178 |

Scope

179 |

180 | The group is tasked with standardising Web technology to support a wide variety of 181 | advertising use cases on the Web, while maintaining privacy for users and sustainability for 182 | the platform. 183 |

184 |

185 | The group will only consider proposals that are thoroughly respectful of people's privacy. 186 | Proposals that rely on users waiving away the protection of their data are explicitly out 187 | of scope. 188 |

189 |

190 | In assessing whether, amongst the many potential solutions that exist in the advertising 191 | space, a given proposal is in scope the group must consider whether it abides by this 192 | priority of constituencies: 193 |

194 |
    195 |
  1. 196 | Users come first. This rules out proposals that go against overwhelming user preference 197 | not to have their data shared and proposals that take excessive risk with user data such 198 | as those built atop cross-context identifiers. 199 |
  2. 200 |
  3. 201 | Then publishers, whose production the system seeks to support. This rules out proposals 202 | that expect trade secrets such as audience information to be shared with other parties not 203 | under the direct control of the publisher, and anything that limits publisher sovereignty 204 | over their own digital properties. 205 |
  4. 206 |
  5. 207 | Then advertisers, whose money finance the system. This requires supporting the ability to 208 | optimise spend, prevent fraud, and have farm-to-table accountability on campaign 209 | performance. 210 |
  6. 211 |
  7. 212 | Infrastructure providers such as browser vendors and adtech intermediaries. Proposals must 213 | be practical, durable, and implementable. 214 |
  8. 215 |
  9. 216 | Specifiers, theoretical purity — no one cares. 217 |
  10. 218 |
219 |
220 | 221 |
222 |

Deliverables

223 |

224 | The group is expected to work on the following specifications: 225 |

226 |
227 |
Requirements for a Healthy Ecosystem in Advertising (RHEA)
228 |
229 | This document will provide a detailed foundation explaining what a healthy ecosystem is 230 | for advertising. This will notably built atop the existing privacy work from the TAG and 231 | PING, and explain how it applies to advertising. 232 |
233 |
Conversion Attribution & Measurement in Private (CAMP)
234 |
235 | A set of solutions to enable privacy-preserving attribution on the Web. 236 |
237 |
Sharable Private And Robust Targeting of Aggregated Cohorts at Useful Scale (SPARTACUS)
238 |
239 | Interests targeting is an important part of advertising, but it can also easily be 240 | leveraged against people. It has often been implemented through violations of privacy and 241 | by taking publisher data to monetise it elsewhere. The goal of SPARTACUS is to enable 242 | publishers to provide interests targeting in anonymised ad requests, as well perhaps as 243 | allowing (smaller) publishers to share privacy-preserving means of creating interests 244 | cohorts. 245 |
246 |
Honest Options for the Targeting and Delivery of Anonymised Marketing (HOTDAM)
247 |
248 | This defines a set of interrelated pieces of technology to support cohort retargeting and 249 | anonymised ad requests. (The space occupied by FLEDGE and PARAKEET.) 250 |
251 |
Safe Locally-Inlined Content (SLIC)
252 |
253 | Ads are easier to make safe if they are bundled and limited in what they can do. This is 254 | the bundled file format for ads. 255 |
256 |
Governance of Ad Requests by a Union of Diverse Actors (GARUDA)
257 |
258 | To the extent that HOTDAM relies on a trusted server, it will need a governance model to 259 | ensure that it is indeed trustworthy. This specification will develop that model in full. 260 |
261 |
Advertising Capabilities for Direct Campaigns (ACDC)
262 |
263 |

264 | Buying directly from publishers is an effective way to cut out wasteful spending on 265 | intermediaries, but it requires the publisher to be large enough to have a direct sales 266 | operation and advertisers to want to go directly to publishers. For small businesses, it 267 | is often easier to buy inventory from a large self-serve platform than from a handful of 268 | local publishers, even though the latter might be more effective. 269 |

270 |

271 | An API with which to buy campaigns directly from a publisher, exposed at a predictable 272 | .well-known endpoint, would provide a step forward in this direction. 273 | Standardising an API means that products could be created by independent companies to buy 274 | directly from publishers, and to set up campaigns easily across multiple publishers (eg. 275 | all the papers in the county). 276 |

277 |
278 | 282 |
283 |
284 | 285 |
286 |

Chairs

287 |

288 | TBD 289 |

290 |
291 | 304 | 305 | 306 | --------------------------------------------------------------------------------