Re: Fixing third party content

I think that will be useful, so please do keep thinking about it... e.g. it would be nice if Google Analytics or New Relic could have some restrictions placed on them (iframes won't work for them).

I'm more focusing on third party content that shows something on the page - for that iframes are perfect, as you effectively draw a box for them, and you can apply lots of desperately needed restrictions.

Craig



> On 22 Mar 2016, at 19:16, Brad Hill <hillbrad@gmail.com> wrote:
> 
> 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?