I've seen a bunch of posts on here about google analytics tracking and iframes and how there could be some issues. Also have seen this: https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingSite#trackingIFrames
I have tracking code in the parent website that I don't care about, and I have tracking code in the page that's embedded in the iframe that I do care about. The iframe content is a completely different domain.
I was wondering if the iframe page will be able to get all the information about demographics and properly be able to send data up to Google for event tracking and whatnot. Again, I don't care about the parent at all in this case. Just that the google analytics code in the iframe works completely on its own.
I feel like the article I posted above from Google is relevant for users that want to somehow link the analytics in the iframe with the analytics in the parent, but I could be mistaken?
The documentation describes exactly what you have to do. It really boils down to:
Load the iframe using _getLinkerUrl to link the visit inside the iframe with the visit on the top frame
Use P3P headers on the iframed page to work around stupid internet explorer.
I would add some notes:
Even if you don't care about the top level page you should add a tag into it, if you don't you can't use _getLinkerUrl and you lose the traffic source, etc. If you don't use _getLinkerUrl GA inside the iframe will think it's a brand new visit referral from the top level page.
Setting cookies inside an iframe, in a third-party domain is the definition of a third-party cookie. Because of that any browser that is set to block third-party cookies will block the GA cookies and GA won't work. This include Safari (both Desktop and Mobile) that are set to block third-party cookies by default. So if visits using Safari or iDevices are important for you (likely these days) this tracking won't probably give you good results. The only solution is to eliminate the iframed page, either put it in your domain or open it in a new window/tab.
Related
I have created a game in google sites and would like to use cookies to track the player's highscore. I am not sure if google sites allows cookies in embedded html. I checked the code of the google sites page and figured out that my embedded html is actually stored as an iframe, which as far as I know, does not allow cookies.
It will be difficult to implement it since like you said its in an iframe and the domain of the iframe is dynamically generated. A similar issue is raised here. An alternative option would be to create a web app on firebase and link it with your google sites, but this could be slightly different from your initial idea of keeping track of user's score on the browser.
When you search anything in a browser it will be saved in your search history and that can be used for, e.g. displaying relevant ads to you.
I was wondering, if say you have an iframe linking to another website, will that contribute to your search history?
i.e. If I make a webpage where the user can enter a URL into a text input and the iframe loads the URL entered, will that count in your search history?
By default the iframes does not show up in the browser history as your browser history has a history of the pages visited.
If you want to save it in the browser history (depending on the browser) you can do it via javascript pushState, however you might encounter the origin errors. This will only work for the same origin websites.
https://developer.mozilla.org/en-US/docs/Web/API/History/pushState
Please note many websites block iframing them in your website via header: X-Frame-Options:SAME-ORIGIN due to security (for example google.com, youtube.com)
I have a static website, it only contains html and css. No javascript, no php, no databases. On this site, I'm using images, which I get from image-hosting websites (like imgur).
I've noticed when I visit my website (on Google Chrome at least), if I click the information button next to the URL, it says there are cookies on this site. If I click on the cookies button, it says The following cookies were set when you viewed this page and has a list from cookies, including from those sites that I use for image-hosting.
If I delete them, they come back after a while, but not immediately. I'm trying to avoid cookies as the site is very simple. Are they considered part of my site? If so, is there anything I can do, except hosting the images myself?
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
Are they considered part of my site?
That depends on your perspective.
The browser doesn't consider them to be part of your site. Cookies are stored on a per-domain basis, so a cookie received in response to a request for an image from http://example.com will belong to http://example.com and not to your site.
However, for the purpose of privacy laws (such as GDPR) then they are considered part of your site and, if they are used by the third party to track personally identifiable information, you are required to jump through the usual GDPR hoops.
If so, is there anything I can do, except hosting the images myself?
Not really.
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
Cookies are generally set with HTTP response headers, not with JavaScript.
Whenever a browser requests a file from a server it automatically forwards any cookie data along with the request. Image Hosting services may use that for different purposes.
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
So the question is, how to they set these cookies?
Let's say, you use a simple img tag to load an image from a hoster.
<img src="imageHoster.tld/123xyz.png">
The site imageHoster.tld can handle that request by redirecting all requests to e.g. requestHandler.php and that file can set the cookie before sending the image with a simple
<?
setcookie("cookieName", "whateverValue", time()+3600);
header('content-type: image/png');
...
?>
What happens there is actually the same as if you would set the image source like that:
<img src="imageHoster.tld/requestHandler.php?img=123xyz">
Are they considered part of my site?
Since these so called third party cookies are set when visiting your site one could consider them as part of your site. To be on the safe side I would at least mention the use of third party services in the data privacy statement.
If so, is there anything I can do, except hosting the images myself?
Third party cookies can be disabled in the clients browser. But you can't disable them for the visitors of your site. So no, to avoid third parties setting cookies on client browsers visiting your site you can only avoid using their services.
Is there a way to create a Chrome extension to trick a site loaded in an iFrame into thinking it's not in a frame?
We load clients' sites into an iframe for demos, but some resources get blocked due to them disallowing being loaded in an iFrame. We'd like to load these sites into a frame as though you were browsing directly to the site in a standalone tab.
You should use the Chrome's webRequest in order to intercept the server response. See the API. Here you go for onHeadersReceived event where you are in control of any response headers => you need to remove X-Frame-Options header from the response.
That's pretty much it, if this is the only problem in loading those sites.
However, for the sake of completeness, in order to fully trick the browser (which you most likely do not need) you need also to inject a script into every page that would clear up some things like window.parent by simple removing them from window object and some other things like origin etc. However removing the header would work for 99.9999% of your use cases.
Looking at a few advertising companies (DoubleClick, Atlas), I've come across the concept of iframe buster files, that are hosted on the same host as the ad publisher (one example: http://www.adopstools.com/ibusters/atlas/atlas_rm.htm, and there's a lot of JS code that works with that page).
I read that they're used to dynamically resize the iframe. Is that all there is to iframe busters? Does hosting them on publisher's host help with JS cross-domain restrictions?
Added: I'm referring to the use case described here: http://blog.operative.com/?tag=iframe, and not just changing the iframe source document to the top level.
This is done for "take over ads". We use iframes (ADI - iframe vs ADJ - javascript) for a few reasons:
1 - they slow down the loading of your page content.
2 - they can break javascript on your page causing your page to stop functioning properly.
3 - worse case: they inject malicious code.
Using the iframe (ADI) approach the ads are isolated into their own document and can't interfere with the main web page.
However, there are cases when your marketing team wants to run take over ads. They are ads that expand outside their iframe window. For these ads the "iframe busting" approach was setup by most of the top advertising vendors. This approach requires you to host a file on your side that the ads can interact with and by pass the cross-domain restrictions of browsers.
Here is a comprehensive list of these files: http://www.adopstools.com/?section=miscellaneous&page=iframes
iframe busters are intended to break a webpage out of an iframe inside another page so that they become the top level page
e.g. if I had an iframe in this answer with your site inside it, the role of an iframe buster on your site would be to bust your site out of my iframe and prevent me from using iframes to show your website
This is similar to frame busters, where a website may be encased in a frameset with a second frame up top showing a digg bar or advertisement. In this case, a frame buster would force the browser to display the website and only the website as intended by the author, rather than in a frame with potential advertisement or malware bundled in another frame.
In the provided example, the JavaScript is used to insert a script tag to a second JavaScript file which performs the actual frame busting. The JavaScript used in the html file linked simply obfuscates this process while loading different urls for different advertisements, each with different iframe html to insert.
The lengths gone to are likely to be a factor of a cat and mouse chase, as is common with frame busting techniques, where sites have written scripts to bust out of frames, and the companies responsible for framing the sites have written anti-frame busting scripts, so anti-anti-frame busting scripts have been written.
Iframe Busters are used to help certain type of rich media creatives perform their full function. FOr example an Expandable rich media will not expand if served into an Iframe without being able to bust out of the Iframe.
This is where the Iframe Buster comes into play.
The purpose of the Iframe buster is to allow the creative to break out of the Publishers Iframes so the creative can be fully functional.
Typically it s a file which needs to be placed in a folder on the sites domain.
So www.yoursitename.com/folder/iframebuster.html
This location will need to be referenced whenever you serve an Expandable ad into the Iframe.
What the iFrame Buster does is it allows an expandable banner to come outside of it's Ad Unit dimension. For rg. if you have a 300x250 ad slots and you have an 300x250 ad banner that expands to 300x500 on mouse over or on click then iFrame buster allows it break that 300x250 boundaries and give room to the banner to expand by 300x500.
Doubleclick iFrame buster us generally required if you have a Rich Media Creative like a Pushdown, PubBar or Expandable being hosted and served/setup in DART Studio.
Atlas has their own iframe buster code, MediaMind has addineyev2.html and similarly FlashTalking and other have theirs which are required to be hosted on the server where the ads are going to run.