|
Why?
I get an error from my gateway/proxy or firewall The most likely cause is that your ISP or company limits either the time a POST request can last or the amount of data which can be POSTed. Try smaller files, archivers such as WinRAR can split a large file into several smaller ones. For most people, an effective maximum size to upload anywhere is about 10MB. Is there any restriction on what I can or can't upload? Nothing larger than 50MB (52,428,800 bytes). Other than that, anything. No, restriction as in content? Y'know, like porn or whatever? Since only you and whoever else you send the URL to will be the only ones who know about it, why should anyone else care? Upload whatever the hell you like. Censorship sucks and there'll be none of that on Hattix. What happens if I upload something that pisses someone off? Most likely it'll be completely ignored and said someone told to grow a pair. I forgot the URL or filename. How do I get my file back? You can't. I can't. Nobody can. It's as good as gone. While this can be used as a small off-site backup service, you need to remember the URL or filename. If you just have the filename then use "upload.hattix.co.uk/files/FILENAME" to retrieve your file. I clicked "Upload" but it doesn't seem to be doing anything. Give it a few minutes. A file cannot be uploaded instantly, your computer needs to send it to the Hattix server. On cable and DSL, which have quite slow uploading speeds, this may take several minutes. If it times out, you'll need to make the file smaller or split it into several parts. The uploader only waits for 20 minutes, if an upload takes longer than this it is aborted. How does this work? It's quite a simple self-contained PHP script, derived from the web based file manager Hattix fully hosted users use. It uses a HTTP POST upload which is exactly how you attach files to web based email or upload pictures to whatever gallery, profile or networking site. In the name of simplicity and privacy, that's all it does. It doesn't list anything (indeed, takes measures to ensure no listing can be done). It does some funky database stuff too. Initially it was to teach me how to interact with MySQL through PHP, but now it's a privacy and anti-hacking device. How the hell can you afford to do this? I own the server, I own the bandwidth. If it's used or if it isn't used, I pay the same. I use it for my own purposes too, so I simply extend this service because I can. Are there any file name restrictions? If you can store the file name on your disk, chances are I can on mine. Spaces are a special case, for this the output of the script's link target has spaces replaced with "%20", which is more copy-and-paste friendly, as well as being how your browser should encode spaces anyway. The displayed URL will still be spaced, just the target will be fixed. For IE users, right click the URL and "Copy Shortcut" which will place the URL as text into the clipboard to be pasted anywhere. Certain characters are also stripped to protect against MySQL injection attacks. Tell me about the privacy aspect. It's simple in theory but quite complicated in practise. The simple description is that files are encrypted and obfuscated heavily, so much so that it's not even practical for me to recover them. The more complex description is below. First a file is broken into two, three or four chunks. When I say "the file" below, I'm really meaning "one of the chunks". The script creates fifteen directories on disk (i.e. folders) with two character hexadecimal names (to make sure some branching occurs) and it does this per-file but also randomly (kinda randomly) puts an uploaded file in the same directory as another one AFTER creating the randomly named directories. Each directory is abstracted away so they all look like /upload/files and each directory has a blank index.html created in it so it cannot be listed. The file is then encrypted against a private key stored elsewhere on the server (which is not world-readable). When you retrieve a file, the magic happens. When all those dirs were made, the script wrote to a database where the file really is on disk (the database data is also encrypted, this time against the filename). It looks up in this database where to find the file, then sends it you or whoever you gave the URL to. This is why you must use unique file names because only the last entry in the database is looked at, so if you use "me.jpg" then someone else uploads "me.jpg", your file is still on disk but cannot be found by this script. A sample (but fake) actual disk location is x:\uploader\0e\f4\5b\de\74\a3\fb\99\be\f8\a0\d1\40\f0\00\pr0n.jpg When a directory already exists, a new one is created under it and the process continues. Finding *anything* among that mess is exceedingly difficult, even for me with local disk access (backups can take hours if I don't disable 'backup empty directories'!). So much so that I put in an exception in the script. Upload a file with a name beginning with admin_ and it'll be put somewhere I can find it, this makes it handy for my personal use when people want to send files to me.So I can effectively delete a file by uploading another file with the same name? Yes. Uhm...so you made it do all that crap, but I don't actually see any of those folders? I did it to reinforce the privacy aspect. What good is a private service when I could just list the whole contents of the upload destination? Perhaps there's a coding error somewhere which allows an attacker to access directories? This system provides massive obfuscation which delays an attacker and there's no doubt I'd notice an attacker accessing the server before he found anything. What does the server log? Apache2 default logs. Same as pretty much any other website in the world really. The script removes the filename from the logs using a bit of magical jiggery-pokery. Magical what? Actually, it executes a small script running locally on the server which does a search and replace in access.log, to match "upload/*.*" and replace with "upload/-uploader-" I have a problem not covered here? This service comes with no support other than this FAQ. Try putting what you know about the problem into Google and seeing if that helps. What do you recommend I do if I don't want anyone else even guessing my filename? Rename the file to something like "10hf377651jewt". That sure won't be guessed. Consider the name to be the "password". How reliable is Hattix? 98% of the time (98.3% for the period November 2006 to January 2007) Hattix is responsive and available at full capacity. Another 1% of the time it was undergoing maintenance or development so at reduced capacity, this may be very slight and unnoticable or it may not be, but the server is still working. For the other 0.7% the server was unavailable. Update: As it now runs through Coral, small downtime problems should be unnoticable. How fast is the server? It's capped to around 200kb/sec upload and 50kb/sec download. It's plenty fast enough for general use. Update: The uploader now redirects through the Coral proxy system. This makes it more robust against man-in-the-middle attacks as routing becomes much more complicated as well as accelerating the server to far faster download speeds than it would be capable of alone. I've had reports of 1MB/sec download rates in this way. Uploading is unaffected. Does PHP work? No. Other projects on the server require some reduced PHP security (server side and non-exploitable by clients) so PHP processing is disabled on the uploader. So if I uploaded a few images and a html file, I could host a website here? You could, but anyone could overwrite it. If you know me (the server admin), I can provide you with a proper hosting account with PHP, MySQL, FTP, File Manager, etc. Why not use SSL (HTTPS)? SSL encrypts a connection but is largely used to ensure the identity of a server, to make sure that the connection hasn't been hijacked and sent somewhere else. This makes it good for light transactions (i.e. sending a credit card number or other personal information) but unsuitable for the kind of data that Hattix sends and recieves. Additionally, an SSL certificate for a web server costs quite a bit of money. If you want to donate one, feel free. Compatibility Report Internet Explorer 1.0 - Untested (Does not work on NT/2k/XP) Internet Explorer 1.5 - Untested (Does not work on NT/2k/XP) Internet Explorer 2.0 - Untested (Does not work on NT/2k/XP) Internet Explorer 3.0.1152 - Tested BAD (no HTTP upload support [1]) Internet Explorer 4.0 - Tested UNKNOWN [2] Internet Explorer 5.0.3314.2100 - Tested OK Internet Explorer 5.5 - Tested OK Internet Explorer 6.0 SP1 - Tested OK Internet Explorer 7.0.5730.11 - Tested OK Internet Explorer 7.0.6000.16512 - Tested OK Netscape Navigator 3.01 - Tested OK Netscape Navigator 3.04 - Tested OK Netscape Navigator 4.76 - Tested OK Mozilla Firefox 1.5 - Tested OK Mozilla Firefox 2.0 - Tested OK [3] Browsers such as Netscape and Mozilla are just re-branded versions of Firefox and are usually several versions out of date (hence are vulnerable to known security flaws). Browsers like Maxthon are re-branded versions of Internet Explorer but due to how IE handles re-branding, are always as up to date as the base IE browser. [1] IE3.0 can upload through HTTP, but requires special code to do so. Upload.Hattix has no support for this. [2] An unrelated error prevents IE4.0 from loading the HTML. It should have no issues, however. [3] A known issue with Firefox 2.0 occasionally means it sends the wrong MIME type. Hattix regenerates all MIME types on access, but FF2 users may find the MIME type on upload success to be nonsensical. This does not affect operation other than it means Hattix cannot generate links for images if the browser denies that what it has uploaded is an image.. |