Tag Archives: Javascript

Ajax anonymity blogs cookies debugging EFF firefox Google Chrome Google Moderator Greasemonkey how-to HTTP headers internet Panopticlick privacy redirects sessions ShareThis web-development

Spring Cleaning – 4 Steps to Rehab Your Old WordPress Blog

I’m thinking about doing a bit more writing, and to be honest I have left this blog pretty unloved since my last redesign in… hmmm… 2008? Much has chanced since then – for example, a huge percentage of visitors these days are on tablets and mobile devices. Your old WordPress theme might not look very nice on an iPhone or Nexus 5 (I know mine didn’t).

I spent a couple of hours shaking the cobwebs off my old WordPress site, taking it from this:

The old WordPress default theme with minor tweaks

To what you’re looking at now. I also made a few small changes to speed up my blog.

Step 1: Update your theme

This used to be a huge pain, requiring you to download files, customize the HTML and CSS, and upload it to your server. The WordPress theme system is a lot friendlier now. I just went to to Appearance -> Themes and clicked the “Add New” button. This gives you search box, but I found the “Featured” link was the best place to start. I chose TwentyThirteen, it allows me to set a nice big header image and it looks good on different screen sizes. The current header is a photo of the Sierras from Lone Pine, CA.

Step 2: Clear out old widgets and code

I used to have a bunch of extra widgets in my blog, but many of them were never really useful for my readers or now pointed to defunct services (I still miss you, Google Reader!). I cleared out a Feedburner widget, an old version of the Google Translate widget, and a few other things. You might be surprised how much you can improve your site’s loading time just by deleting some inefficient Javascript.

Step 3: Speed it up

Speaking of loading time, my site was abysmally slow. Not slow enough that I noticed on my fast connection at home, but faster sites make users and search engines happier. One of the best tools to find bottlenecks is Google PageSpeed. You can have Google analyze your site and get a detailed report of the problems or install a Chrome or Firefox extension to check from your browser.

A few things worth checking:

  1. Are you compressing your files? You can set up Gzip compression on your server or use a plugin like WP Super Cache.
  2. Are you telling browsers when they can use their own cache? Instead of sending a page or image to a user, you can let them know they can use their cached version with a 304 Not Modified HTTP status code. WP Super Cache also has a setting for this.
  3. Are you hosting your own copies of common libraries like jQuery? I’m using a plugin called Use Google Libraries that points to widely-cached copies of these files on Google’s servers.
  4. Are you regenerating pages from PHP and MySQL every time someone visits? If your pages don’t change very often, use WP Super Cache.

Step 4: Actually start writing again

This is the hard one. I feel like between work, family, and posting small things to social networks, I’ve lost the time and energy to write longer-form articles. I have a fun project coming up that will definitely prompt some posting, and this article itself is a start, right?

If you have any other tips for cleaning up a WordPress blog or getting back into writing, let me know in the comments.

Three Ways Sites Can Track Visitors Without Cookies, Part 2

In part 1, I wrote about the EFF’s Panopticlick project and the implications for anonymity. I’ve got two more methods up my sleeve.

2. Use the cache.

Cookies aren’t the only thing your browser downloads and keeps around, and for good reason. Logos and other images with stable filenames don’t tend to change very often, so instead of re-downloading them each time you revisit a site your browser caches them on disk. Other external files like Javascript can also be cached. This makes surfing the web a lot faster for everyone.

Any time someone is able to send you a file that sticks around, though, they’ve got a way to figure out if you’ve been there before. And as Josh Duck outlined in his blog post, Abusing the Cache: Tracking Users without Cookies, it’s not too tough to embed a tracking code to track your user sessions whether or not you clear your cookies.

This isn’t too terrible – users can always clean their cache, and this is generally most useful for tracking individual users visits to a single site. If you could convince enough site owners to add your widget to their site, though, you might be able to get more interesting data.

3. Check which links the user has visited.

This isn’t a new technique, at least by web standards, you can see examples as early as 2006 by Jeremiah Grossman. CSS gives you the ability to set up custom styles for links – the default style, the style when the user hovers or clicks, and most importantly for this hack the style after the user has visited the link. Browsers styled visited links differently even back in the ancient days of the web, turning blue link text to purple to help you navigate.

Any site can create a list of links to other sites and, with a bit of Javascript, tell if you’ve visited those sites in the recent past. The list of links can be hidden from the users view, so they might not even notice what’s going on. Spyjax is one example implementation with source code.

This is limited since you have to explicitly check for each potentially-visited site. So you might be able to check to see if they’ve been to Facebook, but not get the list of every social networking site they’ve ever been to. On the other hand with browsers like Chrome and Firefox getting faster all the time, checking lots of links by brute force is more possible. Users can always limit or clear their browsing history to make this technique less effective.

Should I panic yet?

Not quite, but it’s always a good idea to be on the lookout for things that undermine the assumptions of privacy and anonymity that people tend to have while surfing the web.

We’ve looked at clever ways to track a user from visit to visit, from site to site, and to get information about other sites they’ve visited. But each can be defeated, so if you want more anonymity you can still have it. To be honest I worry more about malware stealing passwords, phishing sites tricking people into giving away bank account info, and companies that have lots of sensitive info being hacked or ordered to divulge info by government. None of those problems rely on new Javascript hacks or can be fixed by clearing the browser cache.

Found a new clever hack for tracking users? Got even more important privacy concerns that I missed? Please post in the comments below.

Three Ways Sites Can Track Visitors Without Cookies

There’s an old joke about the Internet that’s important for two reasons. First the joke:

On the internet, nobody knows you're a dog

It’s important because it illustrates a key cultural and technological underpinning of the Internet: anonymity. The second reason it’s important is that it’s so old, printed in the New Yorker in 1993, which is basically old testament times in Internet years. So for decades, the web has allowed people to browse without telling or proving who they are. Though many sites would love if you created an account and logged in, the vast majority are perfectly happy to serve up pages to you without even knowing if you’re a person or a dog.

But there are many reasons to want to track a user from page to page or from site to site, and there are various ways to do it. The most common way involves cookies. Web developers need a way to create user sessions or else things users like (shopping carts, preferences, the ability to update your profile picture) are impossible to implement.

Cookies are pretty well understood, and users can turn them off or clear them out if they really want. Google Chrome, for example, has “Incognito Mode” which allows you to surf without saving cookies, history, etc. from session to session. Even with cookies off, though, maintaining a user session within a particular site by passing around a session id isn’t too hard. It’s trivial to do in PHP for example.

Most users are pretty comfortable with this state of affairs – Facebook knows who I am because I logged in, but I trust them. Amazon knows who I am but that’s cool because I’m shopping. Some other site doesn’t know who I am, but it knows that I’m the same person who clicked on the widget to change the language a couple minutes ago.

People start getting uncomfortable when you start tracking them across sites. People become even more uncomfortable when they no longer have control over their anonymity. Three recent techniques violate both of those comfort zones in limited ways.

1. The EFF’s Panopticlick project.

Follow the link above and click the “test me” button. Is your browser silently betraying you? This is a very clever hack based on the fact that browsers almost always send some information to web servers in http headers (the user agent, what type of content the browser is willing to accept, etc.). People have been misusing user agent headers to try to get Javascript working in multiple browsers for years. Panopticlick also checks for available plugins and fonts. Adding all this data up there’s enough variability from one browser to the next that you can apparently reliably identify individuals. The EFF has a great post on the information theory behind the project.

This doesn’t mean sites will know who you are, but they could use this information to know that you visited web page A, B and C whether or not you want them too. An ad network could use this info to track you across many sites. An unscrupulous site could sell this info, giving your browsing history away for cash, and if you log into a site that has personally-identifying info about you (email, shipping addresses, etc.) the history could potentially be tied back to a person.

Next post, I’ll talk about another way to track users without cookies and a way for a site to tell if you’ve visited other sites in the past. I’ll also tell you why you shouldn’t panic, though I admit a better writer would have told you that first.