- From: Craig Francis <craig.francis@gmail.com>
- Date: Mon, 1 Feb 2016 10:08:10 +0000
- To: Craig Francis <craig.francis@gmail.com>
- Cc: Simon Pieters <simonp@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On 29 Jan 2016, at 16:50, Craig Francis <craig.francis@gmail.com> wrote:
> Maybe a new header, or maybe CSP, or something else?
Mike West and Anne van Kesteren from WebAppSec both think that a custom header would be best when working cross origin.
Something like:
Expose-Height-Cross-Origin: 1;
https://github.com/whatwg/html/issues/555#issuecomment-177797476
So assuming there aren't any better solutions (or header names), and using the following CSS for compatibility reasons:
iframe { height: max-content; }
What's the next step?
Craig
> On 29 Jan 2016, at 16:50, Craig Francis <craig.francis@gmail.com> wrote:
>
> On 28 Jan 2016, at 12:23, Simon Pieters <simonp@opera.com> wrote:
>
>> For instance, adding CORS means that the content is also readable with XHR.
>
>
>
>
> Good point.
>
> It would be useful for the remote site to see the Origin header, but just simply opening access with "Access-Control-Allow-Origin" isn't a good idea.
>
> It's a shame there isn't a way of saying "Access-Control-Allow-Feature" to go along with Origin/Methods/Headers/Credentials... but I don't think that can be added now, as too many websites and browsers have implemented the current functionality.
>
> Maybe a new header, or maybe CSP, or something else?
>
> Or do we just simply allow the browser to set the height and not worry about it... personally I don't want to allow another vector for information leakage, but you are right, there are other ways of doing this already.
>
> Craig
>
>
>
>
>
>> On 28 Jan 2016, at 12:23, Simon Pieters <simonp@opera.com> wrote:
>>
>> On Thu, 28 Jan 2016 12:57:09 +0100, Craig Francis <craig.francis@gmail.com> wrote:
>>
>>> On 27 Jan 2016, at 13:02, Simon Pieters <simonp@opera.com> wrote:
>>>
>>>> CORS doesn't require an extra request for normal GETs. But I think we should investigate the use cases for cross-origin autoresize more first; maybe using CORS is not suitable because it would expose "too much", and autoresize was the only thing people wanted to enable?
>>>
>>>
>>>
>>> Good point, has been a while since I last did any CORS work.
>>>
>>> When you say it will expose "too much", what do you mean by this?
>>
>> For instance, adding CORS means that the content is also readable with XHR.
>>
>>> I'm just thinking of the height of the iframed page allowing a malicious website (the one that created the iframe) to infer something about the victim website within the iframe (e.g. is this user logged in).
>>
>> Yep. Though this is typically possible through other means already, e.g. trying to load some resource and see if you get a 'load' or 'error' event.
>>
>>
>>> I think in most cases iframes work exceptionally well at allowing you to include content from elsewhere.
>>>
>>> This is often because another website is providing the content, or because you have some content that you want to sandbox (because it's potentially untrusted).
>>>
>>> But the problem I often face is getting the iframe to have the right height (just so it does not create scroll bars):
>>>
>>> http://stackoverflow.com/search?q=resize+iframe
>>>
>>> The dumb approach is to set its height to something ridiculously tall.
>>>
>>> Or the more complicated one involves JavaScript + postMessage(), and this is always implemented slightly differently between websites.
>>>
>>>
>>>
>>> And you won't hear any complaints from me about it being done via "height: max-content" :-)
>>>
>>> Craig
>>>
>>>
>>
>>
>> --
>> Simon Pieters
>> Opera Software
>
Received on Monday, 1 February 2016 10:08:40 UTC