Like anything in web development, developers have a choice to make: do they use technology in a responsible, law-abiding manner or not? Do they write code and systems that are helpful and beneficial to the visitor or not? As much as I would like to see everyone using their talents for good, I know that does not happen. Who do you think black-hat hackers are and what they do?
One of the many privacy invading tricks not-so-nice developers use are supercookies, evercookies, and similar techniques. These often make use of the “standard” HTTP cookies but are enhanced using Adobe Flash or HTML5 storage methods to make them harder to delete. These tricks raise legitimate and possibly serious security and privacy concerns, for they easily permit long-term tracking.
Note: I am not endorsing or recommending any of the following techniques. Persistent tracking of this nature is very questionable and concerning, and upon finding this I was rather disturbed it was going on. Please do not replicate any of the techniques I am going to detail. Always use responsible and law-abiding analytical methods with the visitor’s consent.
Byet Internet Services is, upon first glance, a rather sketchy-looking website host. However, they are known as one of the very few hosts offering completely free hosting.
Well, mostly free. There are a few catches, such as having to maintain a certain level of activity in order to keep your account and subdomain active. I once had a domain myself but accidentally let it expire from inactivity. Overall, the requirements for the hosting is nothing really obtrusive, that is, until 8 August when a buddy who uses the service often send me the following tweet:
Upon visiting his site, sure enough
?ckattempt=1 was tacked onto the URL. Upon opening the developer tools, I found a cookie from the site had been placed in my browser. I started by removing the query string and found it did not return. After confirming he had not changed anything lately and his account had not been compromised, I went to work reversing what was going on and figuring out why it was being done.
I quickly discovered server-side rerouting was at work. Upon removing the cookie and reloading the site, the page briefly flashed white and displayed a “Checking your browser” message before redirecting to the actual page with the query string added. Using timing and quick keyboard shortcuts, I was able to access the page source, which mumboking confirmed did not exist on the filesystem.
__test , which I concluded was a sneaky way to throw people off and conceal its purpose and to possibly make visitors believe the site administrator was trying something out.
Normally when “Checking your browser” messages are displayed, checks are being run to confirm your browser is compatible with the system. There are web apps that do these things (both legitimately and otherwise). By displaying such a message visitors are given assurance the page is loading and perhaps will work better because the web app has been customized to fit within their browser’s abilities and limitations. However, I had a feeling that was not what was going on here, as confirmed by the cookie’s hardcoded expiration date: 31-Dec-37 23:55:55.
Why would anyone use such an elaborate setup to generate a never-changing cookie with an expiration date 22 years from now? Easy: long-term visitor tracking. By using such a system across all their free domains, Byet would be able to gain substantial analytical data on all free domain visitors, even uniquely identify them (using server-side recorded values such as IP address, browser UA, and current time, among other possible values). Though I have no proof it is for tracking, the things I found next and later on helped solidify the theory.
By this point, I was feeling very disgusted by the low actions being performed. Yet my gut feeling was If they have gone this far, they probably have gone even further. Up to this point, I had been examining the code only on the site index. I deleted the cookie and visited another page. Sure enough, the cookie came back, meaning server-side rerouting for the cookie-setting code was happening on all pages. I left the dev tools open and switched tabs to report my findings to mumboking. As I finished up, I switched back to the site just in time to see the cookie receive an update. I quickly looked to find what changed. A minute later, the cookie updated again. The only difference: time set. Byet has just gone even lower, I thought. They set the cookie every minute, meaning even if I did programmatically delete it, it would be recreated again.
Checking the forums showed this was new behavior starting Thursday evening or early Friday morning affecting everyone with free domains. It was implemented without warning and broke many sites, especially ones that used database connections (because apparently their code was still being run on the “browser check” page?). Naturally this upset a lot of developers, and without a proper response anywhere in sight, a lot of people were very, very upset, myself and mumboking included.
I then returned to the forums to see if an announcement had finally been made. Sure enough one was, on the next Wednesday (a half week later), in my opinion too late to make an announcement explaining the sudden changes.
Hi All,Due to massive amounts of auto / bot /spam / application serving specific traffic causing performance degradation issues on free hosting services we have added new measures to reduce this.
You may have seen the new ‘Checking browser’ page, if so you would have also seen your page load faster than before after running this check.
The check is mandatory on free hosting, and may change over time, if you are using your free website for hosting a webpage, and this is causing issues contact us using the support channels in your vPanel.
If you are using your free hosting service for application hosting then we would recommend upgrading to premium hosting.
As always we are striving to offer the best ‘free web hosting’ experience, while dealing with the one in 100 that causes the problems for the majority.
I also found an unofficial response sent to an individual user on 9 August foreshadowing the official response:
The basic authentication was replaced with the current anti-bot secure option which relies on the fact that the visit needs to be from a real human.If you have seen any issues, please let us know and we will investigate. But this is currently mandatory on free service for security reasons.
In light of what I uncovered and the entire circumstance surrounding the ordeal, I maintain what I have detailed is a long-term visitor tracking system. All the practices and code used scream shady and suspicious with a rather lame (and late) excuse in an attempt to cover up the truth.
As a developer who aims to code responsibly and practice ethical behavior in all things, this super-persistent tracking cookie hurts me deeply. Such behavior is suspicious, questionable, privacy-invasive, and in my opinion plan wrong. The way Byet has engineered the system and handled the response is highly messed up. Such behavior is unacceptable and should not happen. Yet despite the wrongness of this whole thing, one question lingers: because the hosting is totally free of monetary payment, is there really much surprise we (visitors and admins) are trading privacy for payment? There is no such thing as a free lunch, so the lunch is paid for by various means, even if it is through nefarious means.
Subscribe to Caleb's Words
Get the latest posts delivered right to your inbox