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

Re: iFrame access

From: Craig Francis <craig.francis@gmail.com>
Date: Tue, 29 Mar 2016 10:39:25 +0100
Cc: WebAppSec WG <public-webappsec@w3.org>
Message-Id: <74914F30-CFB1-4DC3-A79B-009E6284DF90@gmail.com>
To: Chris Palmer <palmer@google.com>
Hi Chris,

I completely agree that granting access to the textContent is not good, and I would "prefer the embedder explicitly pass the relevant text to the embedee".

I'm just trying to work out how best to help the Ad networks (and the millions of websites that host those Ad's) to migrate to a system which is much safer, and extremely easy to deploy.

Perhaps the best example is Google Ads, where websites "just" need to copy/paste some JavaScript:

https://support.google.com/adsense/answer/3221666?hl=en-GB <https://support.google.com/adsense/answer/3221666?hl=en-GB>

This is why I'm thinking of an API that allowed advanced websites to provide a tailored response (so they can explicitly exclude sensitive information), but at the same time allow the typical website to not need to write any custom JavaScript - they simply include an iframe which grants a bit more access than usual (not ideal, but it's much better than full read/write access to the DOM).

If this isn't considered, then Ad networks will continue providing a <script> tag to copy/paste, because that's easier (and we are back to square one).

For now I'm just looking for ideas, not suggesting this needs to be implemented.

Craig




> On 28 Mar 2016, at 20:39, Chris Palmer <palmer@google.com> wrote:
> 
> I'm not a huge fan of letting cross-origin iframes get access to the textContent of any element in the embedder's DOM. It's potentially a privacy and security nightmare. For example, what if public content is blended in with private content in the embedder's DOM? The embedee could drive around looking for it. Not cool.
> 
> And, yes, another synchronous API is a bummer.
> 
> I'd much rather have the embedder explicitly pass the relevant text to the embedee by some means, either postMessage, an iframe element attribute, or URL query parameters.
> 
> Yes, it requires ad tech developers to do a little work. But, if they want to get paid, they have to do a little work. And the heat is on them now to stop egregiously violating people's privacy and security on the web. The good news is, they are starting to see that: http://www.iab.com/adopting-encryption-the-need-for-https/ <http://www.iab.com/adopting-encryption-the-need-for-https/>.
Received on Tuesday, 29 March 2016 09:39:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:18 UTC