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.2 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.2 encryption. For a complete list of what browser+OS combos support TLS 1.2, see https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers

In summary, the following should generally work:

  • Windows 7 and newer
  • macOS 10.12.1 (Sierra) and later
  • Apple iOS 10 and later
  • Android 7.1.1 (Nougat) and higher
  • Chrome 29 and newer
  • Firefox 50 and newer (though at least Firefox 57 is recommented to avoid other security issues)
  • Microsoft Edge
  • Microsoft Internet Explorer 11 probably still works, but we don't recommend it
  • Safari 10 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 29 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.2 in its preferences; it's disabled by default. But you really should use something else if possible.

We cut off support for TLS 1.0 in mid 2018, and TLS 1.1 in late 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.

I'm getting "Certificate expired" errors when visiting Fark, starting on September 30, 2021

This affects any website using a certificate from LetsEncrypt, which is several tens of millions of websites -- LetsEncrypt is the largest certificate provider now. It's far from a Fark specific issue.

The root certificates that LetsEncrypt used to use expired at the end of September 2021. The new one they're using now is recognized by all current operating systems and browsers. If you're getting errors, then your operating system or browser is too old and needs an update.

[LetsEncrypt has a list of the minimum operating system versions that has a new-enough root certificate store], which is summarized as:

  • Windows 7 or newer (I know they say XP SP3 works, but... just don't)
  • macOS 10.12.1 Sierra or newer
  • iPhone iOS 10 and iPad OS 10 or newer
  • Android 7.1.1 Nougat or newer
  • Firefox 50 or newer -- Firefox has its own root certificate store and ignores the one in the operating system, so using Firefox can be a workaround if you can't upgrade your operating system
  • Ubuntu 16.04 or newer
  • Debian 8 Jessie or newer

We always strongly recommend running the newest software available. Old software often has unpatched security vulnerabilities. For example, while macOS Sierra is new enough to avoid this specific problem, it has long been unsupported by Apple, as have the Macs that cannot run anything newer. The iPhone 5 is long obsolete but can still run iOS 10.

LetsEncrypt has a number of other resources on this:

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 about a dozen FreeBSD cloud instances. 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 using the trendy platform of the week. Pick one.  :)

The main website is hosted at Vultr's cloud service. In case of problems, we have an outage page that's hosted on Amazon'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.

Some resources, such as some images, may be IPv4 as of mid 2019, due to limitations with DigitalOcean's CDN. That was fixed in July 2022 by moving the images to Linode.

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 prior to that date. But now SSL is always enabled for everyone.

We turned port 80 off entirely on December 12, 2022.

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 allowing 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, allow 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.