Re: Fixing third party content

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