AllowSeamless - Revision history

Abarth: /* Alternatives */

2012-05-27T00:15:44Z

Alternatives

← Older revision		Revision as of 00:15, 27 May 2012
Line 60:		Line 60:
	Some folks might want to predicate allowing seamless on the origin of the containing document. Rather than include a list of origins when allowing seamless, this use case is better addressed using <code>Frame-Options</code> or <code>ancestor-origins</code> because that documents that wish to be seamless with some (but not all) cross-origin parents rarely want to be displayed non-seamlessly with the forbidden origins. Rather that bloat this mechanism with an origin whitelist, we should instead make use of the existing mechanism for whitelisting which origins can contain a frame.		Some folks might want to predicate allowing seamless on the origin of the containing document. Rather than include a list of origins when allowing seamless, this use case is better addressed using <code>Frame-Options</code> or <code>ancestor-origins</code> because that documents that wish to be seamless with some (but not all) cross-origin parents rarely want to be displayed non-seamlessly with the forbidden origins. Rather that bloat this mechanism with an origin whitelist, we should instead make use of the existing mechanism for whitelisting which origins can contain a frame.

			===Meta Element===

			Rather than using an attribute on the <code>html</code> element, we could use a <code>meta</code> element. That would work too. The choice is mostly aesthetic. Because seamless already interacts with the document element (e.g., to propagate styles), placing the indicator on the <code>html</code> element seems more aesthetic, but this is a topic upon which reasonable people might disagree.

	[[Category:Proposals]]		[[Category:Proposals]]

Abarth: /* Proposal */

2012-05-27T00:12:20Z

Proposal

← Older revision		Revision as of 00:12, 27 May 2012
Line 22:		Line 22:
	==Proposal==		==Proposal==

	One approach is to use an attribute of the <code>html</code> element to indicate that this document is willing to be displayed seamlessly with cross-origin parents. ~~For example, if~~ the <code>html</code> element has ~~a void~~ attribute <code>allowseamless</code> and if the document is displayed in an iframe that contains the <code>seamless</code> attribute, then the iframe will resize automatically and attempts to navigate the frame will be redirected to the containing frame:		One approach is to use an attribute of the <code>html</code> element to indicate that this document is willing to be displayed seamlessly with cross-origin parents. If the <code>html</code> element has an attribute <code>allowseamless</code> and if the document is displayed in an iframe that contains the <code>seamless</code> attribute, then the iframe will resize automatically and attempts to navigate the frame will be redirected to the containing frame:

	<html allowseamless>		<html allowseamless>

Abarth: /* Security Analysis */

2012-05-27T00:07:55Z

Security Analysis

← Older revision		Revision as of 00:07, 27 May 2012
Line 59:		Line 59:

	Some folks might want to predicate allowing seamless on the origin of the containing document. Rather than include a list of origins when allowing seamless, this use case is better addressed using <code>Frame-Options</code> or <code>ancestor-origins</code> because that documents that wish to be seamless with some (but not all) cross-origin parents rarely want to be displayed non-seamlessly with the forbidden origins. Rather that bloat this mechanism with an origin whitelist, we should instead make use of the existing mechanism for whitelisting which origins can contain a frame.		Some folks might want to predicate allowing seamless on the origin of the containing document. Rather than include a list of origins when allowing seamless, this use case is better addressed using <code>Frame-Options</code> or <code>ancestor-origins</code> because that documents that wish to be seamless with some (but not all) cross-origin parents rarely want to be displayed non-seamlessly with the forbidden origins. Rather that bloat this mechanism with an origin whitelist, we should instead make use of the existing mechanism for whitelisting which origins can contain a frame.

	~~==Security Analysis==~~


	[[Category:Proposals]]		[[Category:Proposals]]

Abarth: /* Proposal */

2012-05-27T00:07:36Z

Proposal

← Older revision		Revision as of 00:07, 27 May 2012
Line 31:		Line 31:
	</body>		</body>

	This situation differs slightly from how seamless works normally in that styles are not inherited from the parent document to the child. We don't inherit styles by default because inheriting cross-origin styles is significantly more risky than autosizing (see ~~xyzzy~~ above). If the author wishes the document to inherit styles from its parent, the author can include the token <code>inherit-style</code> in the value of the attribute:		This situation differs slightly from how seamless works normally in that styles are not inherited from the parent document to the child. We don't inherit styles by default because inheriting cross-origin styles is significantly more risky than autosizing (see Security Concerns above). If the author wishes the document to inherit styles from its parent, the author can include the token <code>inherit-style</code> in the value of the attribute:

	<html allowseamless="inherit-style">		<html allowseamless="inherit-style">

Abarth: /* Proposal */

2012-05-27T00:07:22Z

Proposal

← Older revision		Revision as of 00:07, 27 May 2012
Line 22:		Line 22:
	==Proposal==		==Proposal==

	One approach is to use an attribute of the <code>html</code> element to indicate that this document is willing to be displayed seamlessly with cross-origin parents.		One approach is to use an attribute of the <code>html</code> element to indicate that this document is willing to be displayed seamlessly with cross-origin parents. For example, if the <code>html</code> element has a void attribute <code>allowseamless</code> and if the document is displayed in an iframe that contains the <code>seamless</code> attribute, then the iframe will resize automatically and attempts to navigate the frame will be redirected to the containing frame:

	~~===Examples===~~

	<html allowseamless>		<html allowseamless>
Line 32:		Line 30:
	and width.		and width.
	</body>		</body>

			This situation differs slightly from how seamless works normally in that styles are not inherited from the parent document to the child. We don't inherit styles by default because inheriting cross-origin styles is significantly more risky than autosizing (see xyzzy above). If the author wishes the document to inherit styles from its parent, the author can include the token <code>inherit-style</code> in the value of the attribute:

	<html allowseamless="inherit-style">		<html allowseamless="inherit-style">
Line 39:		Line 39:
	as the value of form input elements) to my parent.		as the value of form input elements) to my parent.
	</body>		</body>

			It's likely we should treat the value of the <code>allowseamless</code> attribute as a space-separated list of tokens to allow for future extensions.

	==Alternatives==		==Alternatives==

Abarth: /* Proposal */

2012-05-27T00:01:06Z

Proposal

← Older revision		Revision as of 00:01, 27 May 2012
Line 21:		Line 21:

	==Proposal==		==Proposal==

			One approach is to use an attribute of the <code>html</code> element to indicate that this document is willing to be displayed seamlessly with cross-origin parents.

			===Examples===

			<html allowseamless>
			<body>
			If my parent iframe has the seamless attribute, then <a href="http://example.com">this
			example link</a> will navigate my parent and the iframe will autosize to the right height
			and width.
			</body>

			<html allowseamless="inherit-style">
			<body>
			Now in addition to the above, I will inherit styles from my parent. Inheriting styles requires
			an additional opt-in because letting my parent style me could leak more information (such
			as the value of form input elements) to my parent.
			</body>

	==Alternatives==		==Alternatives==

Abarth: /* Examples */

2012-05-26T23:59:51Z

Examples

← Older revision		Revision as of 23:59, 26 May 2012
Line 41:		Line 41:

	==Security Analysis==		==Security Analysis==

	~~==Examples==~~

	~~<html allowseamless>~~
	~~<body>~~
	~~If my parent iframe has the seamless attribute, then <a href="http://example.com">this~~
	~~example link</a> will navigate my parent and the iframe will autosize to the right height~~
	~~and width.~~
	~~</body>~~

	~~<html allowseamless="inherit-style">~~
	~~<body>~~
	~~Now in addition to the above, I will inherit styles from my parent. Inheriting styles requires~~
	~~an additional opt-in because letting my parent style me could leak more information (such~~
	~~as the value of form input elements) to my parent.~~
	~~</body>~~


	[[Category:Proposals]]		[[Category:Proposals]]

Abarth: /* Per-Origin Control */

2012-05-26T23:59:37Z

Per-Origin Control

← Older revision		Revision as of 23:59, 26 May 2012
Line 37:		Line 37:

	===Per-Origin Control===		===Per-Origin Control===

			Some folks might want to predicate allowing seamless on the origin of the containing document. Rather than include a list of origins when allowing seamless, this use case is better addressed using <code>Frame-Options</code> or <code>ancestor-origins</code> because that documents that wish to be seamless with some (but not all) cross-origin parents rarely want to be displayed non-seamlessly with the forbidden origins. Rather that bloat this mechanism with an origin whitelist, we should instead make use of the existing mechanism for whitelisting which origins can contain a frame.

	==Security Analysis==		==Security Analysis==

Abarth: /* Alternatives */

2012-05-26T23:56:11Z

Alternatives

← Older revision		Revision as of 23:56, 26 May 2012
Line 35:		Line 35:

	In this approach, the server includes a <code>Content-Security-Policy</code> (CSP) HTTP header that includes an <code>allow-seamless</code> directive. Unfortunately, this approach conflicts with the basic premise that CSP directives ''tighten'' the security of the document. In this case, the <code>allow-seamless</code> would ''loosen'' the security of the document and potentially expose it to attacks.		In this approach, the server includes a <code>Content-Security-Policy</code> (CSP) HTTP header that includes an <code>allow-seamless</code> directive. Unfortunately, this approach conflicts with the basic premise that CSP directives ''tighten'' the security of the document. In this case, the <code>allow-seamless</code> would ''loosen'' the security of the document and potentially expose it to attacks.

			===Per-Origin Control===

	==Security Analysis==		==Security Analysis==

Abarth: /* CORS */

2012-05-24T02:07:50Z

CORS

← Older revision		Revision as of 02:07, 24 May 2012
Line 28:		Line 28:
	In this approach, the server opts into allowing seamless by supplying CORS headers that allow the parent access to the document. This approach has a number of disadvantages:		In this approach, the server opts into allowing seamless by supplying CORS headers that allow the parent access to the document. This approach has a number of disadvantages:

	# In order to opt into autoresizing, the child document must allow the parent full read access to its contents because the parent can use cross-origin <code>XMLHttpRequest</code> rather than an iframe to retrieve the document. Although autoresizing leaks some amount of information about the child, some servers might want to opt into autoresizing without leaking '''all''' the information in the document.		# In order to opt into autoresizing, the child document must allow the parent full read access to its contents because the parent can use cross-origin <code>XMLHttpRequest</code> rather than an iframe to retrieve the document. Although autoresizing leaks some amount of information about the child, some servers might want to opt into autoresizing without leaking ''all'' the information in the document.
	# If the document contains subresources, the some information from those subresources might leak to a seamless parent. For example, if the child document contains a seamless iframe to third document from the same origin as itself, information about the height of that third document might leak to the parent. This violates the semantics of CORS, which operates per origin.		# If the document contains subresources, the some information from those subresources might leak to a seamless parent. For example, if the child document contains a seamless iframe to third document from the same origin as itself, information about the height of that third document might leak to the parent. This violates the semantics of CORS, which operates per origin.
	# CORS is awkward to use with resources that require cookies because <code>Access-Control-Allow-Origin: *</code> works only with credential-less requests. If the child uses cookies, the server will need to supply a <code>Vary: Origin</code> header, which makes caching difficult (and triggers bugs in some proxies and older versions of IE). For this reason, CORS works better with static resources, such as images and scripts, than with dynamic resources, such as server-generated HTML documents.		# CORS is awkward to use with resources that require cookies because <code>Access-Control-Allow-Origin: *</code> works only with credential-less requests. If the child uses cookies, the server will need to supply a <code>Vary: Origin</code> header, which makes caching difficult (and triggers bugs in some proxies and older versions of IE). For this reason, CORS works better with static resources, such as images and scripts, than with dynamic resources, such as server-generated HTML documents.