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 macOS, 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.

Only browsers and operating systems that are new enough to support TLS 1.1 encryption are supported. Any browser new enough for that is, conveniently, also new enough to render modern HTML and CSS correctly.

Browsers and operating systems older than that only support encryption that has been broken in the years since they were released. Most websites are now dropping support for old systems that don't support at least TLS 1.1 encryption. For a complete list of what browser+OS combos support TLS 1.1, see https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers

In summary, the following should generally work:

  • Windows 7 and newer
  • macOS 10.9 (Mavericks) and later
  • Apple iOS 9 and later
  • Android 5 (Lollipop) and higher
  • Chrome 22 and newer
  • Firefox 27 and newer (though at least Firefox 57 is recommented to avoid other security issues)
  • Internet Explorer 11 and Microsoft Edge
  • Safari 7 and higher
  • 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, so we don't recommend it. 12.18 is the oldest that still supports TLS 1.1

These will NOT work well:

  • Windows XP and Vista are NOT supported. You MIGHT be able to make it work if you use Firefox 52 but even that isn't supported by Mozilla after Summer 2018.
  • Android 4 (Jelly Bean, KitKat) is NOT supported. You MIGHT be able to make it work if you use Chrome 22 or later but this is NOT guaranteed.
  • Internet Explorer 9 and 10 MAY work IF you are on at least Windows 7 AND you manually enable TLS 1.1 in its preferences; it's disabled by default. But you really should use something else if possible.

We expect to cut off support for TLS 1.0 in mid 2018.

Fark Mobile looks really weird on my device - what do I do?

First, check to make sure you're on a fairly recent device/browser. In particular, Blackberry 4.5 or below does not render even simple HTML very well. (It's unknown if any current Blackberry devices support TLS 1.1 anyway.)

If you're on a supported device, and things still look strange, check your settings. For example, Blackberry has a setting to view a page in either Page View or Column View. Fark Mobile must be viewed with Page View to be seen correctly. Windows Mobile has settings for 'One column', 'Full Page', and 'Fit to Screen'. For Fark Mobile to be viewed correctly, choose 'Fit to Screen'.

If things still look strange, please take a screenshot (or just take a photo with a digital camera), post it somewhere, and send us a Farkback with a link to the image.

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 using Perl's Plack toolkit and back-ended by MariaDB, all running on fourteen FreeBSD boxes and two Ubuntu 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. Or we can't afford to rewrite it all. Pick one.  :)

The hardware is co-located at QX.net here in Lexington, Kentucky. (We have a webcam on it...)

In case of problems, we have an outage page that's hosted on DigitalOcean's cloud service.

This product includes GeoLite2 data created by MaxMind, available from http://www.maxmind.com.

Is Fark reachable via IPv6?

Yes, since World IPv6 Day on June 6, 2011.

Recent browsers are warning about pages not using HTTPS (SSL). When is Fark going to turn SSL on?

March 1, 2018.

We didn't earlier due to many ad networks not supporting SSL until recently. BareFark disables ads, so it also enabled SSL. But now SSL is always enabled for everyone.

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. Fark was not an SSL-only website until March 2018, and we don't 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/

In fall 2016, this also started happening to AdBlock Plus users.

This ought to stop happening as of March 1, 2018, due to us switching to SSL for all pages.

See the answer to the next question also.

Comment quoting and voting doesn't work reliably for me.

If comment posting, quoting, or voting randomly works sometimes and randomly doesn't work other times, disable any AdBlock Plus and/or NoScript plugins in your browser, and try again. Both over-aggressively disable non-ad-related Javascript that break legitimate functionality in our comments code.

Subscribing to BareFark disables ads and thus reduces the chances that AdBlock Plus will disable non-ad-related Javascript.

If you're using the Pale Moon browser, an update to it in November 2016 may have caused similar issues. In that case, the solution is to switch it from Gecko compatibility mode to Firefox compatibility mode (under Tools/Options/Advanced).

See the answer to the previous question also.

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.


On Twitter





Top Commented
Javascript is required to view headlines in widget.
  1. Links are submitted by members of the Fark community.

  2. When community members submit a link, they also write a custom headline for the story.

  3. Other Farkers comment on the links. This is the number of comments. Click here to read them.

  4. Click here to submit a link.

Report