This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7032 - Sandboxing and Referer
Summary: Sandboxing and Referer
Status: VERIFIED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NoReply
Depends on:
Blocks:
 
Reported: 2009-06-17 21:02 UTC by Anne
Modified: 2010-10-04 14:55 UTC (History)
4 users (show)

See Also:


Attachments

Description Anne 2009-06-17 21:02:30 UTC
The Referer header should probably be affected in a sandboxed <iframe> that have the sandboxed origin browsing context flag set.

Depending on what HTTPbis does it might need to about:blank (I think).
Comment 1 Ian 'Hixie' Hickson 2009-06-17 22:36:59 UTC
why?
Comment 2 Adam Barth 2009-06-18 00:50:34 UTC
I think the thought process goes like this:

Premise 1) Referer can be used as a credential.
Premise 2) Sandboxed iframes should't get the credentials of their origin (e.g., they get some unique origin).
-------------
Conclusion: Sandboxed iframes shouldn't get a Referer.

Do you disagree with one of the premises?
Comment 3 Ian 'Hixie' Hickson 2009-06-18 07:46:32 UTC
I disagree with the first premise, and with the implication that the referrer is necessarily related to the origin.

I think I'm also confused with what refererrs we're talking about here. The original one for the page load during navigation? Subsequent ones for sub resources? Referrers for further navigations?
Comment 4 Adam Barth 2009-06-19 00:21:33 UTC
[reordered]

> I think I'm also confused with what refererrs we're talking about here. The
> original one for the page load during navigation?

Nope.

> Subsequent ones for sub resources? Referrers for further navigations?

Yes.  What one might call the "outgoing referrer" for the page.

> I disagree with the first premise, and with the implication that the referrer
> is necessarily related to the origin.

I think that's a reasonable position.  I'll let others who feel more strongly about this issue express their points of view.
Comment 5 Anne 2009-06-19 08:41:10 UTC
(FWIW, the others would be Tyler Close and Mark S. Miller both not cc'ed on this bug.)
Comment 6 Ian 'Hixie' Hickson 2009-06-26 09:15:48 UTC
I intend to WONTFIX this unless further information can be provided to explain why Referrer information for internal references to external resources within a sandboxed iframe should be dropped. It seems bad to have a context that is referrer-free; it would make it impossible, for instance, for a site to referrer-protect their images against third-party sites if those images are used in any sandboxed frame within the site itself.
Comment 7 Maciej Stachowiak 2010-03-14 14:48:17 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.