New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
This site will be read-only for 3-4 hours starting at Sunday, 08:00AM PDT
Starred by 39 users

Issue metadata

Status: WontFix
User never visited
Closed: Jun 2013
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

issue 508730

Sign in to add a comment

data: URL in document does not inherit origin.

Reported by, Oct 13 2010 Back to list

Issue description

Chrome Version       : 8.0.552.0 (Official Build 62249) dev
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
  Firefox 3.x:OK
         IE 7:EPIC FAIL
         IE 8:EPIC FAIL

What steps will reproduce the problem?
1.View the attached file

What is the expected result?
Main Document and I-Frame Document should have same origin

What happens instead?
You get error "Unsafe JavaScript attempt to access frame with URL data:text/html;charset=utf-8,<!DOCTYPE%20html><html><head><title></title></head><body><h1>IFrame%20Document</h1></body></html> from frame with URL file:///c:/Users/####/####/test.html. Domains, protocols and ports must match."

Please provide any additional information below. Attach a screenshot if

"If a Document or image was generated from a data: URL found in another Document or in a script
The origin is the origin of the Document or script that initiated the navigation to that URL."
firefox screenshot.png
24.9 KB View Download
chrome screenshot.png
50.8 KB View Download
710 bytes View Download
Issue 54204 has been merged into this issue.
I can confirm this behavior even in newest Chrome dev (17). It seems like data URLs are handled as separate origins which is against HTML5 spec:

"The origin is the origin of the URL that redirected to the data: URL."
Project Member

Comment 3 by, Aug 10 2012

Labels: -Pri-2 Pri-3 Action-NeedsReview
Status: IceBox
Due to the age of the issue, changing the priority to P3, however because it has at least 10 stars, marking it for review.

Comment 4 by, Aug 10 2012

Status: Unconfirmed
Is this bug going to be fixed? This is holding up PNG download of SVG images (a very useful feature) in a couple of webs apps. and some diagraming apps that use SVG.
Labels: -Area-Undefined Area-WebKit
Related upstream:
Project Member

Comment 7 by, Mar 10 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 8 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Comment 9 by, Jun 17 2013

I have lot of respect for Chromium, and this is the reason why I think not having this BUG fixed since more than 4 years is getting ridiculous. 

In a year where HTML5 and web app explode, Chromium has no way to process client images:

- webkit is *NOT* SVG.  It does it its own way and therefore is improperly mimicking SVG filters (see Webkit is OK when innovating, but today it's a HAS-BEEN => follow W3C this is why we love you.
- no way to mask / gradient / crop etc...
- not even speaking of transitions

data url and canvas might have been a solution to bypass Webkit baby-talk, but sigh, the Chromium security officer gives you a fine...  

Please, increase the priority!
Adam, could you comment on what we should do here?
Status: WontFix
This topic is a long-standing disagreement between Chrome and Firefox.  Unfortunately, there are now silos of content built up that rely on each browser's behavior, which makes it difficult to change.  I would not expect us to change our behavior anytime soon.

If you're running into this issue, please consider using the "srcdoc" attribute on iframe instead:

<iframe srcdoc="<h1>Hi there!</h1>"></iframe>

That will run in the origin of the parent document.

Comment 12 by, Jun 17 2013

Sorry Adam to intervene here.  I know you are working hard, you do all do awesome, but I cannot and never will, accept an argument being "it's a disagreement between FX and Cr".  

I just know one rule: W3C. Either you follow it, or you do your own walled garden.

That is what *we*, all the worldwide developers having open source, share and W3C standards in mind, that is why *we* fight for years against Redmond's ukase (for instance).  That is why *we* choose to go Chromium and that why *we* are comfortable using it.  If you want to change the rules... it's up to you!
The truth is that we collaborate on the specs in the W3C.  We can either make the spec vague, which doesn't benefit anyone, or we can argue to change the spec to reflect our behavior and put Firefox out of compliance.  I don't think either will change what implementations do, at least not in the short term.

I'm sorry that we're not able to match the spec in this regard.  If we did change our behavior to match the spec, we'd get angry bugmail from other folks whose web sites we just made insecure.  On balance, I'd rather get bugmail about spec compliance than about introducing vulnerabilities into web sites.

Comment 14 by, Jun 17 2013

If matching the spec will make folk's websites insecure then surely their websites are already insecure if their visitors happen to be using anything other than Chromium?  What is this behaviour defending website owners from?
In some cases, that's true.  In other cases, the authors of these web sites only expect to receive visitors that have this behavior.  That's what I meant above when I referred to "silos of content."

An example of the above is mobile web sites.  Many authors of mobile web sites assume that users are using a WebKit-based browser.  I'm sure you have an opinion about whether that's a good thing or a bad thing for those authors to assume, but even if we disapprove of their motivations, we're still painted into a compatibility corner.

Comment 16 by, Jun 17 2013

Leaving aside the issues of web development best practice as well as the question of whether a web browser should be developed with the interests of content authors or content users, that doesn't really address my question. I'll try to explain a different way: if I was of nefarious intent, the fact that I needed to use a different browser to exploit a security hole in a website doesn't seem like it would be any sort of barrier.
> if I was of nefarious intent, the fact that I needed to use a different browser
> to exploit a security hole in a website doesn't seem like it would be any sort
> of barrier.

Indeed.  Perhaps you should raise that as a security issue in Firefox.

Comment 18 by, Jun 17 2013

Well, I'm sure that non-answer won't frustrate anyone.

So, to summarize your position:

1) The security implications of following the standard are so dire that there's no way Chrome can even consider doing it
2) Not doing it in Chrome has no impact on the security of the web
3) The dire consequences that prevent Chrome doing it are not so dire that it's worth arguing to get the spec changed to protect everyone
You're taking what I'm saying to extremes.  Like many issues, this issue has a set of trade-offs.  At the moment, and for the foreseeable future, keeping our current behavior appears to be a better trade-off for us that adopting Firefox's behavior.  Likewise, my understanding is that Firefox's current behavior is a better trade-off for them than adopting adopting our behavior.

We could spend the effort to change the spec to match our behavior, but my prediction is that if we did that, Firefox would look at a similar set of trade-offs and decide to keep their current behavior.  The net result of that exercise would be that this angry bugmail thread would move to Firefox's bug tracker instead of this one.  I don't think moving the angry thread around is worth the effort required to change the spec.  Instead, I'd rather spend standards resources on this topic when there's actually a chance that the parties will end up with an inoperable implementation.

In any case, this bug is marked WontFix, and I don't think further discussion of this topic at this time is going to change that.

Comment 20 by, Jun 18 2013

What about giving the user some choice like when trying to get access to the microphone etc. Something like a popup to choose between w3c spec compliance or google quirks or something? This way the devs could at least have the option of informing and prompting the user to get to the desired results.
 Issue 486848  has been merged into this issue.
Proposed solution not suitable for XHTML because if I fill srcdoc IFRAME still operate in HTML mode.

XHTML mode I can enable only with header "application/xhtml+xml".

Please make an exclusion for all the URL starts with data: this should not impair the safety of sites.

I attach example.
You can play with:
1. Prepare XHTML.
2. print IFRAME
2.2 KB Download

Comment 23 by, May 12 2015

Ult iip
Blocking: chromium:508730

Sign in to add a comment