Re: Fixing third party content

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
anti-fraud.

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

> 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?
>>
>>
>