W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2016

Re: Fixing third party content

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 22 Mar 2016 19:16:13 +0000
Message-ID: <CAEeYn8ifsOui=usMtyVkFABv1LkFzcLkb95LTHOiDircfmupPQ@mail.gmail.com>
To: Craig Francis <craig.francis@gmail.com>
Cc: Yoav Weiss <yoav@yoav.ws>, WebAppSec WG <public-webappsec@w3.org>
My idea is not well developed, but I was thinking it might be possible to
build on the mechanisms of how content scripts work for Chrome extensions.
I was specifically thinking of the case of "third party measurement" in a
broad sense, whether for page analytics, or advertising measurement and

On Tue, Mar 22, 2016 at 12:03 PM Craig Francis <craig.francis@gmail.com>

> On 22 Mar 2016, at 18:47, Brad Hill <hillbrad@gmail.com> wrote:
> My thought was to add an attribute to a script tag that puts the script in
> a virtualized environment with filtered access to the DOM
> Hi Brad,
> I like the idea of limiting the current <script> tag, but do you have any
> idea of how you would do this?
> I'm keeping in mind that most third party content needs to add content to
> the page, and they typically give the HTML code to the website to simply
> copy/paste (which is the kind of website the browser needs to protect).
> And just to confirm, I'm not suggesting a new type of iframe, the iframes
> we have at the moment are pretty much perfect for isolating most third
> party content, we just need to make a couple of tweaks (the ability to read
> the parent textContent is probably the most difficult).
> Craig
> On 22 Mar 2016, at 18:47, Brad Hill <hillbrad@gmail.com> wrote:
> I chatted with some folks about similar ideas during the W3C digital
> marketing workshop.  My thought was to add an attribute to a script tag
> that puts the script in a virtualized environment with filtered access to
> the DOM, read-only - inspired a bit by the Chrome isolated world security
> model for extensions.  I called the idea "frosted glass", as in, today
> these 3rd party scripts are standing in the shower with you, but they could
> be behind frosted glass - where they can look but not touch, and only to a
> limited level of detail.
> I think what the filter does would need to have some flexibility.  Ads
> might want to be able to see a view of the DOM that includes text content
> (and only text content).  Other, more cooperative use cases that are
> possibly even more ubiquitous than ads are analytics scripts, which need a
> different filter - they want to be able to see certain events firing and
> the structure of the page, maybe the class and id attributes of tags, but
> should probably not be able to see text content directly.  Or you might
> want to specify a one-way transformation as a filter, so the DOM looks
> totally realistic but is just hashes/HMACs that only you can make sense of
> at scale.
> My hope in adding an attribute to a script tag instead of creating a new
> type of iframe was that you could continue to use existing things without
> having to modify those scripts at all - they would be not be aware they
> were getting an information-limited view unless they were changed
> specifically to test for that.
> On Tue, Mar 22, 2016 at 5:40 AM Yoav Weiss <yoav@yoav.ws> wrote:
>> FWIW, I totally agree that the way third party content is embedded today
>> is troubling from both security and performance perspectives.
>> Do you have any documents regarding which type of read access these ad
>> providers require? Are you sure read access would satisfy their needs? Are
>> ad providers unified regarding these requirements?
Received on Tuesday, 22 March 2016 19:16:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:55 UTC