- From: Brian Smith <brian@briansmith.org>
- Date: Mon, 10 Nov 2014 15:36:51 -0800
- To: Brad Hill <hillbrad@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Sun, Nov 9, 2014 at 4:04 PM, Brad Hill <hillbrad@gmail.com> wrote: > Rechartering Thread 5: Sub-Origins > > Based on our survey results and discussion at TPAC, there is strong > consensus for supporting work on a sub-origin proposal based on the > following input document: > > http://www.chromium.org/developers/design-documents/per-page-suborigins > > Joel Weinberger would be editor. Hi, I'd like to make sure I understand this correctly. Let's say there were a popular search engine at https://centillion.example.com that uses <script src=https://tripletap.example.com/insert-ad.js"> to insert an ad into the page. Let's say that ad-blocking tools know to block all requests to tripletap.example.com so the ads won't show up. centillion.example.com could avoid the ad blocking (or at least make it much more difficult) by loading the ads from its own domain https://centillion.example.com instead, but it doesn't do so currently because that would eliminate the protection that same-origin policy provides, causing undue risk. But, with this proposal, https://centillion.example.com could safely serve the ads that it would normally serve https://tripletap.example.com and keep the protections of same-origin policy, while still making ad-blocking difficult. In particular, tools like Mozilla's just-announced-today tracking protection depend on being able to completely avoid making a request to a tracking service, but with the suborigin proposal, it wouldn't even know the suborigin until it received the response to the request that it is trying to avoid making. Is this correct? Cheers, Brian
Received on Monday, 10 November 2014 23:37:18 UTC