Opened 5 years ago

Last modified 5 years ago

#7740 needs_review defect

flashproxy badge works just like a web bug

Reported by: arma Owned by: dcf
Priority: Medium Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: bastik.public@…, griffinboyce@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When I add the flashproxy badge to my page (in this case, I added it to https://www.torproject.org/docs/pluggable-transports.html.en), I basically instruct all my users to let you know when and from where they have visited my page.

For normal images, the usual fix here is to get a copy of that image and host it from my website, so you don't get to see how often it's fetched.

I expect it would be a hassle if everybody that puts up a badge serves their own copy of the javascript for the flash proxy side -- they'd never stay up to date, etc.

Worse, it seems to me that the flashproxy javascript itself basically serves the same purpose as the web bug, so even giving you the code locally won't help much.

So the remaining question is: is there anything practical that can be done to improve the centralized web bug situation here, or is it an entirely lost cause? For example, is there a way to separate "I want to be a flashproxy" from "here's the page that gave me the badge"?

Child Tickets

Change History (6)

comment:1 Changed 5 years ago by bastik

Cc: bastik.public@… added

Oh, JavaScript in iframes can operate in the origin of the placing source?
Oh, iframes send a referrer? (The website in an iframe knows that it's iframed in website xyz?)

That would be kind of bad. (Please answer to these questions later on)

comment:2 Changed 5 years ago by dcf

There are two different entities contacted when you load the iframe, and they know different things:

The web server hosting flashproxy.js (currently crypto.stanford.edu) gets to see the referrer, but only gets contacted once a day while the proxy is operating. (It would be only once when the proxy starts up, but I have a meta-refresh set for once a day so that proxies can update themselves.)

The facilitator knows while the proxy is operating, but it does not see the referrer (as far as I can tell). That is, it doesn't get to see the URL of the page containing the iframe; the referrer it sees is crypto.stanford.edu/flashproxy/embed.html. Same with the WebSocket connections that are made to the relay and the client: they don't have a Referrer but they do have an Origin of crypto.stanford.edu.

Oh, iframes send a referrer? (The website in an iframe knows that it's iframed in website xyz?)

To the best of my knowledge, this is not the case.

So from the point of view of the facilitator, the badge is more innocuous than a web bug, because it doesn't see the referrer. From the point of view of the hosting web server, it does work as a web bug.

Self-hosting the badge gets rid of the third-party server. (As you mention it also has disadvantages like not being able to easily update the proxy source code.)

There is something called rel=noreferrer that purports to prevent the browser from sending a referrer. It appears to work for links; I don't know if it works for other things like img and iframe.

There may be other ideas, I'm brainstorming.

comment:3 Changed 5 years ago by cypherpunks

I did some research using the Network Tab in Google Chrome. iframes send referrers and sadly rel=noreferrer doesn't change that.

comment:4 Changed 5 years ago by cypherpunks

The same is true for Firefox.

comment:5 Changed 5 years ago by saint

Status: newneeds_review

Because of spammers abusing empty referrers, this is a bit of an arms race in and of itself. And what works for FireFox might not work for Chrome, etc.

Right now there is at least one way to keep the referring site from being sent to the server no matter which browser the user is using:

Option 1: PHP header redirect

Blog => iframe.php (redirects to) => embed.html

<?''php ''header('Location: http://crypto.stanford.edu/flashproxy/embed.html'); ?>

Option 2: Create the iframe using javascript (probably a nesting iframe situation)

{{{
''//doesn't block the load event'''''function''' createIframe() {    '''var''' i '''=''' document.createElement("iframe");    i.src '''=''' "//crypto.stanford.edu/flashproxy/embed.html";    i.scrolling '''=''' "none";    i.frameborder '''=''' "0";    i.width '''=''' "80px";    i.height '''=''' "15px";    document.getElementById("bridge").appendChild(i);};''// Check for browser support of event handling capability'''''if''' (window.addEventListener) window.addEventListener("load", createIframe, '''false''');'''else''' '''if''' (window.attachEvent) window.attachEvent("onload", createIframe);'''else''' window.onload '''=''' createIframe;
}}}

<div id="bridge"></div>

Option 3: Set parent.location for the iframe (doesn't work in FireFox) 

<iframe src="javascript:parent.location='//crypto.stanford.edu/flashproxy/embed.html'"></iframe>

comment:6 Changed 5 years ago by saint

Cc: griffinboyce@… added

Repeating due to borked code above

Option 2: Create the iframe using javascript (probably a nesting iframe situation)

<script type="text/javascript">
//doesn't block the load event
function createIframe() {

  var i = document.createElement("iframe");i.src = "//crypto.stanford.edu/flashproxy/embed.html";i.scrolling = "none";i.frameborder = "0";i.width = "80px";i.height = "15px";document.getElementById("bridge").appendChild(i);

};

// Check for browser support of event handling capability
if (window.addEventListener) window.addEventListener("load", createIframe, false);
else if (window.attachEvent) window.attachEvent("onload", createIframe);
else window.onload = createIframe;
</script>
<div id="bridge"></div>
Note: See TracTickets for help on using tickets.