Re: iFrame access

Just as an alternative, and more thinking aloud at this stage...

Instead of the `sandbox` attribute, what if we took the `permission` suggestion from Raymes Khoury and Chris Palmer:

https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0034.html <https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0034.html>

https://noncombatant.github.io/permission-delegation-api/ <https://noncombatant.github.io/permission-delegation-api/>

From what I understand, this allows the iframed content to ask for certain permissions from the user (e.g. geolocation).

Maybe we could add a new permission:

    <iframe permissions="parent-text-content"></iframe>

And instead of a new synchronous cross origin primitive, the browser provides a new asynchronous API?

    parent.textContent();

----

Or maybe, and this one is a bit messy, the iframed content can do a `parent.postMessage('textContent')`, where the parent could return a response with its own function:

    window.addEventListener('message', function() {
            ...
        }, false);

But if this function does not return anything (or the 'message' event listener does not exist), then the browser creates a simple response with the textContent of the page.

This means that some websites can tailor their response, but the vast majority of websites can simply add the <iframe> without any JavaScript.

Craig






> On 21 Mar 2016, at 07:05, Craig Francis <craig.francis@gmail.com> wrote:
> 
> On 20 Mar 2016, at 21:22, Devdatta Akhawe <dev.akhawe@gmail.com <mailto:dev.akhawe@gmail.com>> wrote:
> I think there would be significant push back against introducing another synchronous cross origin primitive. But, I am not a browser engineer. Any reason postmesaage doesn't work?
> 
> 
> 
> That is a fair point, from the browsers point of view this is quite complex.
> 
> But at the same time, many websites rely on Adverts, and they are often "context sensitive".
> 
> So do you have an alternative?
> 
> Websites will need to copy/paste something, and a single iframe would be my preferred choice (it clearly shows the boundary).
> 
> I like the idea of using postMessage, but I want the browser to provide something by default for every website.
> 
> Anything that requires extra JavaScript (that websites needs to include/write) will complicate this too much.
> 
> For reference, websites currently copy/paste a line of code to include some poorly written JavaScript (often not async), that gets full control of the current page. And it typically pulls in extra JavaScript that has been written (and is unchecked) by a forth-party company, so they can create the advert, and make it interactive (which we can only hope has good intentions, but often does not).
> 
> Craig
> 
> 
> 
> 
> On 20 Mar 2016, at 21:22, Devdatta Akhawe <dev.akhawe@gmail.com <mailto:dev.akhawe@gmail.com>> wrote:
> 
>> I think there would be significant push back against introducing another synchronous cross origin primitive. But, I am not a browser engineer. Any reason postmesaage doesn't work? Maybe we can try a d fix those limitations? You can always fake a parentTextContent variable backed by postmesaage and updated async. This also gives the app finer control.
>> 
>> On Mar 20, 2016 5:08 PM, "Craig Francis" <craig.francis@gmail.com <mailto:craig.francis@gmail.com>> wrote:
>> Hi,
>> 
>> As part of my never ending quest to banish untrusted third party content into iframes...
>> 
>> Would it be possible to introduce a new token to the `sandbox` attribute, so that it allows the iframed document (cross domain) to read the Text Content of the parent document?
>> 
>> Something like:
>> 
>> 	<iframe sandbox="allow-parent-text-content-read ..."></iframe>
>> 
>> This would allow Ad networks to put their unsafe/untrusted/messy JavaScript into a sandboxed iframe, and for them to have the very limited permission of being able to read the `.textContent` of the parent DOM - which is something they insist on for "contextual adverts".
>> 
>> We can then block the third party from having full read/write access to the whole page.
>> 
>> This will stop them seeing anything that isn't the text on the page (e.g. CSRF tokens, or values in input fields):
>> 
>> 	<form action="/profile" id="profile">
>> 		<label for="name">Name</label>
>> 		<input type="text" id="name" value="Craig" />
>> 		<input type="hidden" name="csrf" value="kr3aN1oY" />
>> 	</form>
>> 
>> 	<script>
>> 		console.log(document.getElementById('profile').textContent); // Output "Name"
>> 	</script>
>> 
>> Craig
>> 
>> 
>> 
>> https://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-iframe-sandbox <https://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-iframe-sandbox>
>> 
>> https://github.com/craigfrancis/security/tree/master/third-party-content <https://github.com/craigfrancis/security/tree/master/third-party-content>
>>