Due to a whole slew of – perfectly legitimate reasons – it’s fairly uncommon for a website to post clearly identify the parties reasonable for design, development, hosting, support, etc. It can be a little difficult to figure out sometimes.

Typically when trying to figure out who made a website I take the following steps (in order):

1. Google the domain name (in quotes). If the site is listed in the body of the portfolio, it’ll often show up in the first page of results. You could probably throw other keywords – like “portfolio” or “design” or something – into the search. I usually don’t bother.
2. Take a look at the HTML, Javascript and CSS source. Sometimes the comments contain copyright notices, author names or other clues. companyname.js is always a good one.
3. Do a whois lookup of the domain. Sometimes the designer will be listed as one of the contacts or the design company will actually run their own nameserver. But with domain privacy services this is becoming less fruitful.
4. When that fails I load up robtex.com. Among a variety of other tools, the site has a utility (under the “shared” tab at the top) that lists domains sharing the same IP, sharing the same name server, sharing the same mail server. If you’re lucky, one of those domains will be designer.

Number 4 was my old pro-tip that made me feel smarter than everyone else online.

But…

Recently I’ve discovered Google Analytics ID databases.

A Google Analytics ID is the part of Google Analytics tracking code that identifies a website, it sits in the tracking javascript running on every website using Google Analytics. The look like “UA-#####-#”. Each site has a unique ID, except when you set up a website’s profile under a parent account, the first part of the ID is shared by all the child accounts. So, UA-12345-1 and UA-12345-2 are in the same account, probably controlled by the same person or company.

Evidently, there are a number of services that crawl the intertube recording which Google Analytics IDs are found on which sites. ReverseInternet.com seems to be a good one, but if that fails, you can always Google the ID (in quotes).

TL;DR: This is how I found out isitchristmas.com was run by @klondike, before he tweeted about it.

I almost had a major meltdown, until Google informed me that OS X Lion is horribly insecure! Horribly, horribly insecure.

You can gain access to (almost) anyone’s Lion account in 3 simple steps.

1. Restart the machine in recovery mode by holding down cmd+r on reboot.
2. Open terminal in the utilities menu.
3. Type `resetpassword`.

Neat idea.
You can do it yourself in .htaccess. Just add:
Redirect 301 /+ {insert your profile url here}

Check it: ohryan.ca/+

Thanks to Isaac Lewis

The solution, use bcrypt. Essentially, it’s an extremely slow hashing algorithm.

To me this seems a little bit like security through obscurity, every once in awhile – as CPU speed increases - you’ll have to update your algorithm to generate hashes even slower.

See also.

• Marco’s Blog Post.
• His PHP implementation of bcrypt.

*A modern server can calculate over 300MB of hash data per second!

In this post I’m going to talk about creating an upload progress bar without the need for a clunky flash object. I’m going to do it with PHP, jQueryUI and a gracefully-degrading framework-independent library.

AJAX Upload

I stumbled across the aptly named AJAX Upload code library (developed by Andrew Valums) at work the other day.

The feature list is quite impressive:

• multiple file select, progress-bar in FF, Chrome, Safari
• drag-and-drop file select in FF, Chrome
• uploads are cancellable
• no external dependencies
• doesn’t use Flash
• fully working with https
• keyboard support in FF, Chrome, Safari
• tested in IE7,8; Firefox 3,3.6,4; Safari4,5; Chrome; Opera10.60;

The package includes a javascript library to handle DOM creation and magical ajax-ey transactions, as well as server-side code written in PHP, CGI, Java and Cold Fusion. The server-side code is required to manage the file upload, where some other solutions use APC or PECL’s uploadprogress, Andrews code makes clever use of PHP streams to track the upload progress.

Relevant snippet from php.php:

    function save($path) {
        $input = fopen("php://input", "r");
        $temp = tmpfile();
        $realSize = stream_copy_to_stream($input, $temp);
        fclose($input);

        if ($realSize != $this->getSize()){
            return false;
        }

        $target = fopen($path, "w");
        fseek($temp, 0, SEEK_SET);
        stream_copy_to_stream($temp, $target);
        fclose($target);

        return true;
    }

Why didn’t I think of that?!

The Javascript & HTML

Here’s an example of a really basic uploader utilizing jQueryUI’s progressbar.

<!DOCTYPE html>
<html>
<head>
    <title>AJAX Upload Test</title>
    <link rel="stylesheet" href="/path/to/js/uploader/fileuploader.css" type="text/css" >
    <link rel="stylesheet" href="/path/to/js/css/blitzer/jquery-ui-1.8.13.custom.css" type="text/css" media="screen" title="no title" charset="utf-8">
    <script src="/path/to/js/jquery-1.6.1.min.js"></script>
    <script src="/path/to/js/jquery-ui-1.8.13.custom.min.js"></script>
    <script src="/path/to/js/jquery.altAlert.js"></script>
    <script src="/path/to/js/uploader/fileuploader.js"></script>
</head>
<body>
    <div id="progressbar"></div>
    <a href="javascript:void(0)" id="uplbtn">Upload A File!</a>
    <div id="file-uploader">
        <noscript>
            <p>Please enable JavaScript to use file uploader.</p>
            <!-- or put a simple form for upload here -->
        </noscript>
    </div>
    <script>
    $(function() {
            // Initialize the jQueryUI Progressbar
			$( "#progressbar" ).progressbar({
				value: 0
			});

			// Initialize the uploader
			uploader = new qq.FileUploaderBasic({
				debug: true,
				element: document.getElementById('file-uploader'),
				button: $('#uplbtn')[0],
		        action: '/js/uploader/uploader.php',
				multiple: false,

                // Update the progress bar
				onProgress: function(id, fileName, loaded, total){
					var percentLoaded = (loaded / total) * 100;
					$( "#progressbar" ).progressbar({
						value: percentLoaded
					});
				},                        

				// display a fancy message
				onComplete: function () {
                    alert('Tada!');
				}
		    });
	});
    </script>
</body>
</html>

The real key here is updating the progressbar value in the uploader’s onChange event.

So there you have it!

Turns out that as of iOS 4.0, iPhones have been tracking your physical movements and logging it along with the phone’s backups.

A small team of researchers have discovered these logs in iTune’s backup files, they’ve released a handy little app that collects all the data from your user folder and plots it on a map. iPhoneTracker.app and further information available here.

Here is the visualization of everywhere I’ve been since Sept 28, 2010:

You can see lots of activity in and around Winnipeg (including trips up to the Gimli and Victoria Beach), a flight to Toronto and subsequent travel around southern Ontario and a road trip to Minneapolis. It’s fascinating.

I’m not sure if this is a terrifying privacy hole or a neat little hidden feature. I’m leaning towards neat feature, since the data is stored locally on your computer and can be encrypted automatically by iTunes.

At this point in time a method for disabling the “feature” does not exist. I expect Apple will be responding in short order.

Starting today we’ll provide you with the ability to experience Facebook entirely over HTTPS. You should consider enabling this option if you frequently use Facebook from public Internet access points found at coffee shops, airports, libraries or schools. The option will exist as part of our advanced security features, which you can find in the “Account Security” section of the Account Settings page.

Enabling this option will effectively prevent you against Firesheep and similar account hijacking methods. I think it’s fairly safe to assume this feature is a direct response to Firesheep, even if it seems to have taken them 4 months to roll out. Though, it could also be a response to Zuckerburg’s account hack yesterday.

I’m going to go one step further than Facebook and say, you should absolutely enable this option as soon as it’s available to you.

To implement these rules:

1. Replace “mobiledirectoryhere” with the path to your mobile site. If your mobile site is located in a subdirectory, use the full URL (including “http://”) and you can omit the first RewriteCond.
2. Then copy & paste the ruleset into the site’s .htaccess file or the main apache configuration.

Rationale

Since the last time I wrote about mobile browser detection and redirection in 2009 the mobile device landscape has changed once again. Smartphones dominate the mobile browsing landscape and feature phones are almost not existant in server logs.

The old redirection rules I posted attempt to redirect every mobile phone under the sun. At this point in 2011, it’s probably safe to completely ignore ancient phones and simplify your Apache rules in the process.

Have you received an annoying notice from your ISP accusing you of illegally downloading a Hollywood blockbuster?

Would you like to live in a better internet?

Well, I have the answer for you: encryption. You see, every BitTorrent packet your computer sends or receives contains header data stating that it’s BitTorrent traffic as well as the filename and other identifying information. By default, this data is send in plain-text, your ISP is able to intercept any traffic you send an inspect the contents (see: deep packet inspection). Your ISP may use this data to actively throttle your BitTorrent traffic (or even your connection in general if they so choose); they may also match the filename against a list of known filenames for movies or other blacklisted content and then send you (fake) legal demands.

By enabling encryption in your BitTorrent client, you make it much more difficult (individual results may vary) for your ISP to determine that a packet is a BitTorrent packet; it may also prevent you from receiving those nag letters in the mail.

Any BitTorrent client worth it’s salt will have an option buried somewhere in the preferences to enable encryption.

I’ve attached a screenshot for the client I use, Transmission:

TorrentFreak has an older with instructions for Azuerus (now Vuze), BitComet and µTorrent. The instructions may be somewhat out of date, but I’d imagine the settings would be in similar locations. When all else fails, Google it.

Update: Doug McArthur notes in the comments, enabling encryption may end up filtering out peers on less popular torrents.

The Firefox modify headers extension can be downloaded here: https://addons.mozilla.org/en-US/firefox/addon/967/

Check out the reddit discussion for more details.