If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

Tech Questions

Fark looks weird on my computer.

First, try temporarily disabling ALL your extensions/plug-ins to see if the problem goes away. Many of the issues reported to us via Farkback end up being related to glitches from (sometimes outdated) extensions.

If you are having problems with images or style sheets not loading, try clearing your browser cache first.

If you're only having trouble with some/all of our images loading, and you're on Firefox (especially on Linux), and clearing cache and disabling extensions didn't help, try this:

  • Go to your Firefox Preferences: on most platforms this is under Tools -> Options, or on Mac OS X, it's under Firefox -> Preferences.
  • Find the Content button, look for the "Load Images Automatically" option, and click the "Exceptions..." button to the right of it.
  • Remove any entries in the list containing fark.com or fark.net. On a normal Firefox install, the entire list is blank/empty.

Before reporting any cosmetic issues via Farkback, look here to see a screenshot of what Fark is supposed to look like. Anyone using a current browser on a screen at least 1024 pixels wide (even 9" netbooks have screens that wide) should be seeing something reasonably close to that screenshot.

The following browsers are known to work well:

  • Internet Explorer 9, 10, or 11 (see warnings below about IE 6 and 7 problems)
  • Safari 4 and higher on Mac, Windows, and iPhone
  • Firefox (always use the latest version available)
  • Google Chrome
  • Opera version 15 or higher (the point at which it becomes Webkit-based). Opera 12 is supported only for reading Fark, not for commenting on links.

The following browsers are known to have problems:

  • We do not support IE6 or IE7. If you are still running Internet Explorer 6 or 7, PLEASE do yourself a favor and upgrade to at least IE 9, and preferably IE 11. IE 6/7 has many CSS bugs that will never be fixed, as well as numerous security problems. IE 8 will mostly work, but with some glitches...
  • To get IE 8 you must be running at least Windows XP SP2, which is no longer supported by Microsoft. You must be running at least Vista to run IE9/10. Any version of Windows older than Vista (including XP) has serious security holes anyway. We highly recommend Windows 7 as a minimum these days, and preferably the 64-bit version.
  • Sony Playstation (PSP/PS3) devices might want to use the mobile version, though the current Playstation 3 browser seems to (mostly) work well enough.
  • We have not tested versions of Opera older than 9.2. The Nintendo Wii browser is Opera based, and works fine.
  • Netscape 4 will not be supported, given its enormous list of CSS-related bugs -- it's over 10 years old. If you are on an antique Macintosh that can only run classic MacOS 9 or 8 (which would have to be over 15 years old), try the iCab browser, which will work far better than the copies of Netscape or Internet Explorer that Apple bundled with those ancient systems. For everyone else running any version of Netscape at all, even Netscape 9, upgrade to Firefox.

I don't want people posting pictures from my website in Fark threads. How do I stop it?

If your webserver is running Apache put a file on your image host called .htaccess (note the leading dot) and put the following lines of text in it:

   SetEnvIfNoCase Referer "^https?://[a-z]+\.fark\.com" denyimage
   order deny,allow
   deny from env=allowimage

Or possibly this version:

   RewriteEngine on
   RewriteCond %{HTTP_REFERER} ^https?://[a-z]+\.fark\.com/.*$ [NC]
   RewriteRule .*\.(gif|GIF|jpe?g|JPE?G|png|PNG)$ - [F]

Other examples exist if you search Google for something like "blocking image linking rewriterule". There are some other tutorials here and an .htaccess generator here.

You can find examples for other webservers, like Microsoft's IIS, using Google. If you have a method for IIS that works that doesn't involve installing new ISAPI filters, let us know.

I have pictures on my own website that I want to post on Fark threads, but don't want other sites posting them. How do I stop it?

(This is the opposite of the previous question.)

If you want your pictures to show up ONLY on Fark and not be swiped by someone else, and your images are hosted on a web server running Apache, put a file on your image host called .htaccess (note the leading dot) and put the following lines of text in it:

   SetEnvIf Referer "^$" allowimage
   SetEnvIfNoCase Referer "^https?://[a-z]+\.fark\.com" allowimage
   order allow,deny
   allow from env=allowimage

Or possibly this version:

   RewriteEngine on
   RewriteCond %{HTTP_REFERER} !^$
   RewriteCond %{HTTP_REFERER} !^https?://[a-z]+\.fark\.com/.*$ [NC]
   RewriteRule .*\.(gif|GIF|jpe?g|JPE?G|png|PNG)$ - [F]

Other examples exist if you search Google for something like "blocking image linking rewriterule". There are some other tutorials here and an .htaccess generator here.

You can find examples for other webservers, like Microsoft's IIS, using Google. If you have a method for IIS that works that doesn't involve installing new ISAPI filters, let us know.

How come the Google search thingie on the main page doesn't work?

You probably have Javascript disabled. Try turning it back on and see if that helps.

The popular "Adblock" plugin for Firefox, with Filterset.G, is known to break our Google search tool. The workaround is to try to do a search, then go to Tools -> AdBlock -> Whitelist This Page. You may also have to whitelist the main Fark page. Also, you might try "AdBlock Plus" which may help (or, according to some reports, may not). This may have been fixed in later versions of AdBlock; please let us know so we can update this FAQ entry. :)

My firewall is registering hits from Fark. What's happening?

Usually this question is about people's firewalls registering "attacks" from img.fark.com when there aren't any. The actual issue is that your firewall's timeout for idle TCP connections is too short. Specifically, it's shorter than the HTTP Keepalive timeout.

Medium-length explanation:

When a web browser connects to a web server and pulls a page, image, or other file down, it can keep the connection open for a few seconds/minutes. This speeds things up if the browser has to get another file from the same webserver -- which is almost guaranteed when you have a webpage with a bunch of images on it -- because it doesn't have to disconnect and reconnect for every single image. But it can't leave it open forever, either, so after a certain number of minutes (or seconds) the server or the browser will close the connection.

Firewalls work by (I'm oversimplifying here) blocking all incoming traffic except what's specifically allowed. Any outgoing connections have to be monitored so that a temporary hole for the return traffic can pass back through. If a connection being monitored goes completely inactive -- like say your computer got powered off while you were downloading a large file -- it doesn't want to leave that hole open forever. So after a certain number of minutes, it removes the connection from its list of what it was monitoring.

If the web server/browser gives up before the firewall gives up, everything's cool, but if the firewall gives up first, then it'll forget about the connection the web server/browser had, and when they get around to closing down, the firewall logs it as an attack (usually a FIN scan) when it really isn't.

This sort of thing happens with DNS lookups all the time. Suppose you've got a computer behind a firewall that wants to look up a name, like www.google.com. Your firewall sees the request go out to your ISP's nameserver, and decides it'll give up after, say, 30 seconds. Now if Google's nameservers are running so slow that it takes 35 seconds to return the answer, then the firewall will log an attack from your ISP's nameserver, on UDP port 53, 35 seconds later. So don't complain to your ISP that their nameserver is attacking you -- they will laugh at you. :-)

Otherwise check the settings on your firewall. On Cisco PIX and ASA 7.x and 6.x for example, look at the "timeout conn" command. On Cisco's IOS firewall, look at "ip inspect tcp idle-time". (And "ip inspect dns-timeout".) It might also help to get the latest version of your firewall software -- Sonicwalls in particular used to be excessively paranoid about this sort of thing and getting the latest firmware from Sonicwall helps cut down on the false alarms.

Anyway, to work around paranoid firewalls like this, we've set our web server's keepalive timeout unusually short, and the complaints about this issue have largely disappeared.

What platform do you run all this on?

The software is all homebrew stuff, written in-house in mod_perl and back-ended by MySQL, all running on about a dozen FreeBSD boxes. It was cobbled together as a quick hack, which then evolved over the years into an even bigger hack. There are other systems out there with more/better stuff, but, hey, we like being unique. :)

The hardware is co-located at QX.net here in Lexington, Kentucky. (We have a webcam on it, but the lights are usually off...) Offsite backup is co-located at Bluegrass.net in Louisville, Kentucky. They're both very cool ISP's.

Is Fark reachable via IPv6?

Yep. We participated in World IPv6 Day in June 2011, and have remained IPv6 reachable since then. (This is native connectivity, without the use of a tunnel broker.)

Why do links to external sites use Javascript-based redirects now?

In mid March 2014 we switched from doing 301-based redirects to Javascript-based redirects, with a "Location:" header as a backup for those with Javascript disabled. This seems strange, but there is a good technical reason for it:

We send a lot of traffic to other sites, obviously. It's generally a good courtesy to let those sites know where the traffic comes from, so they know who to thank (or blame). Usually, that's accomplished by your web browser sending a "Referrer:" header to the target site, letting them know where the click originated from.

We recently discovered that some browsers won't send that if you click from a secure site (SSL) to a standard, non-secure (unencrypted) site, and that hoses the stats pretty badly. This is by design in the HTTP specification (section 15.1.3 in RFC 2616). Sometimes it's also omitted when going from a non-secure to a secure site, as well. While Fark is not yet an SSL-only website, that is a long term goal of ours, and we want to lose other sites' ability to tell who's sending them traffic.

Also, if we share a link on a social media site (Facebook, Twitter, etc), the referrer tends to indicate that social media site instead of us.

Strangely, using Javascript to do the redirect, instead of the traditional approach (a 301 HTTP response code), solves both problems. It turns out Google and Facebook use the same approach, probably for the same reasons. It's a fairly harmless bit of Javascript (literally one line of code, containing just a 'window.location.replace()' call). If you run some kind of browser plugin that blocks Javascript, there's no danger in whitelisting Javascript from the "fark.com" domain. (Doing so also enables voting on comments, and several other bits of functionality that would otherwise be lost.)

There is supposed to be a fallback method in there for those that disable Javascript, which should allow the redirect to happen anyway, after a delay of a second or three. If that's not happening, and the redirect never happens, we'd be interested in finding out why; send the details of your browser config and any plugins you run, to Farkback.

I get "You need to enter a comment!" when attempting to post comments.

This started happening to some people running NoScript on Firefox, around May/June 2014. The problem seems more likely to happen when the comment you're posting contains images.

Either disable NoScript, whitelist Fark in NoScript, or add an exception for Fark in NoScript's XSS (Cross-Site Scripting) detector. To do the last option, option NoScript Options, go to Advanced, then XSS, and then enter the following exclusion pattern:

  • ^https?://[a-z]+\.fark\.com/

I changed my password but Fark keeps telling me "Login Failed", even though I KNOW I'm using the right password

If you're using Chrome autofill for your passwords, and you change your password, it doesn't like to listen. Even if you clear out the field and retype your password, Chrome will often replace your typed password with your old saved password and it'll fail every time.

To fix this, you have to delete the Fark entry from Chrome's managed passwords. See this Chrome help page and look under "Delete saved passwords" for more detailed instructions.

Please Contact Farkback if you're not using Chrome autofill, or if you're still having problems.

Submit a Link »






Report