Blog

Why Internet Filtering Can’t Work

Posted on December 19th, 2009

I’ve seen some renewed interest in the Australian Government’s terrible idea to try and filter the internet, and there’s even a protest planned for people to black out their websites and profile images soon like what was done in New Zealand to protest against the ‘guilt upon accusation’ plan to block people’s internet if somebody just accused them of copyright infringement three times. The No Clean Feed group have some pretty good reasons as to why an attempt to filter the internet would have absolutely no beneficial effects and be a general disaster. Here’s my take:

There are too many protocols which can’t be filtered

The government plans to filter exactly one (1) protocol on the internet, which is HTTP. Think about that for a second – it’s essentially like banning particular subjects from bookstores, and expecting that now the public can’t access them, which is utter rubbish. In this situation, people could still mail the information to each other. They could share the books around. They could put the information up on noticeboards and other public places. The internet is exactly the same. The vast majority of the content that the program aims to filter out is not using the protocol they are going to filter. There’s FTP, bittorrent, email services, and many other peer to peer protocols that not only won’t be filtered, but really can’t. This first point essentially renders the whole scheme useless, but wait, there’s more!

There’s too much content to filter

Just on the HTTP protocol, which the government is going to attempt to filter, there are literally billions of pages of information. How can anybody really expect that they could even attempt to find all the illegal or adult content on it? There is just too much information to filter, and even if it was possible to find every illegal site on it, hundreds of new sites will inevitably pop up within weeks to replace those blocked ones. This is just the way the internet is – it’s not provided from just a few sources like most other forms of media. Anyone can create content on it, good or bad, and new content appears so quickly that any effort to filter it is quickly rendered futile. It’s not like trying to find a needle in a haystack – it’s like trying to find one in a field of millions of haystacks that’s rapidly expanding!

It’s too easy to bypass

There’s one other massive problem that renders the internet filtering plan completely ineffective, and that is encryption. It’s fairly simple to open up an encrypted connection to a network in another country, which gives anybody the ability to completely bypass the whole filtering system – because they can’t see the information that is passing through it. Now, in an environment like a school, the ports that are required to do this can be simply blocked, but in the real world any action like that would cripple many Australian businesses by removing the channels they use to do business with other countries, and cost billions to the economy.

But at least these virtual private networks are too complex for a child to set up, right? Surely we are still protecting them with the scheme? Turns out that the answer is a resounding no, given that there are thousands of (completely legal) websites that make bypassing the filtering even easier. They use secure socket layer (SSL) encryption, which is used to secure bank websites and credit card payments, to anonymously and securely view websites without having them filtered at all. It’s as simple as going to a website and typing a web address in the box. Seriously, this is like locking the front door but leaving all the windows open – there’s simply no way the internet filtering can be effective. Again, they could try to block these sites, but given that they’re legal and have a vast range of legitimate uses, this wouldn’t be possible at all.

There will be many sites incorrectly blocked

A report summing up the results of a trial undertaken by some ISPs showed that the internet filtering technology would incorrectly block 10,000 completely legal web sites out of every million sites blocked. Really, that error rate is unacceptable. Many of these incorrectly blocked sites may be reputable companies, for whom the internet is their only point of business. Is it fair that we eliminate all their Australian customers in the sake of a filtering scheme that is ineffective? And how will these people apply to get their sites unblocked? Given that the people creating the blocklist are going to be trying to search through billions of sites

It will slow down the internet

Let’s face it – here in Australia, our internet is already slow enough. Given that all the internet companies in the country have to use a telecommunications network (mis)managed by a single monopoly, we don’t have the luxury of fast, cheap internet that many other countries like Japan, Sweden and even South Korea have. So why is the government not only chasing after a plan that can’t possibly work, but one that also reduces the speed of our internet by up to 80 percent? This is exactly the kind of speed reduction that the report linked in the above predicts this filtering will cause.

Where’s the accountability?

Having a small, government controlled group deciding what information people should and shouldn’t be able to see is worrying, to say the least. Sure, the line right now is that they’re only going to block illegal material, but how can we know this is the case as time goes on? Perhaps now this is all about “protecting children and families”, but how do we know if eventually they start to increase the range of subjects being blocked? The “Great Firewall of China” has been widely criticised for essentially removing free speech on the internet by blocking thing like Google searches for ‘freedom’, information about subjects such as capitalism and blogs and websites that criticise their government. Given that our government refuses to release the blocklist proposed for this new filter in Australia, how can we be sure that they aren’t going to start doing the same thing and just pull the plug on websites they don’t agree with for us? At least with the review board that classifies films and so on, we know when something’s banned. With the new Internet filtering, the government can restrict access to any site they want, without the public having a clue. I’m sure that they’ll insist that it’s all in our best interest, and ask us to trust them, but with absolutely no accountability, I know I don’t.

It’s a waste of money

So the government wants to bring in a scheme that can’t possibly work. How much is this debacle going to cost? Turns out that they’ve budgeted more than $44 million dollars to this scheme. That kind of money could easily have gone into our hospital system, or creating jobs, or any other number of worthy causes. But instead they choose to burn it in this useless mess.

The only people who support it have no idea about the how the internet works

I think these points are pretty compelling as to why it’s a stupid idea to attempt the impossible task of filtering the internet. Really, the only people who want this filtering installed are the ones who have no idea how the internet works. Unfortunately it seems that these are exactly the same people who are making the legislation that we have to adhere to – which is about as effective as having somebody who’s never held a scalpel try to perform open heart surgery on you. It’s very important that everyone who understands the futility of the internet filtering plan to take action. The No Clean Feed group have some petitions you can sign and other suggestions for ways to speak out against this terrible plan.

In the end…

The government says that the scheme is all about protecting children from inappropriate content on the internet, but it is so horribly broken that it will be completely and utterly ineffective. All it really does is bring Australia down to China’s level (who censor search terms like ‘freedom’) in the eyes of the rest of the world. It won’t make a difference at all to internet safety, except perhaps by slowing the internet down so much that nobody can stand to use it.

‘The Cloud’ is a stupid, redundant buzzword

Posted on December 6th, 2009

I’m sure everyone has noticed that ‘the Cloud’ has suddenly become the flavour of the month, just like ‘Web 2.0’ did last year. But just like Web 2.0, the Cloud is a stupid, redundant buzzword that really means nothing. I mean, let’s just take a look at what Wikipedia says about Cloud computing

The term cloud is used as a metaphor for the Internet

What’s that? You mean that ‘cloud storage’ is really just internet storage? Yes it is – it’s exactly the same as what I’ve been doing for several year with some web-space and an FTP client. The Cloud is the kind of buzzword that marketing departments come up with to make things that we’ve had for years sound new and interesting again, and it really annoys me that it has crept into the vernacular of many computer users as well. I’m all for having backups on the internet, and using web applications (of course, most of the applications I use won’t be able to be run over the internet for a very long time, but that’s a different story). But calling these ‘cloud services’ or ‘cloud computing’ is just stupid.

SI prefixes for hard drive sizes

Posted on October 15th, 2009

An interesting change in Mac OS X 10.6 is that Apple switched the representation of file and hard drive sizes to base-10 SI units instead of using binary prefixes. This means that a 60 GB hard drive which usually shows up as 55.8 GB will now appear within a few megabytes to the advertised 60 GB. I wasn’t really that happy with the idea at first, but when you think about it, it actually makes a lot of sense.

Bits and bytes
Now, it seems logical that since a computer works in binary, file sizes need to be represented with binary prefixes too. But in reality, the number of bytes in a kilobyte is completely arbitrary – since the operating system and the applications that run on it only represent file sizes in bytes. We could decide that there were 2504.25 bytes in a kilobyte and the computer wouldn’t care at all. If we’re just shortening the sizes for our convenience, why make it so hard for ourselves? Doesn’t it make more sense that a 1500KB file is 1.5MB, and not 1.464MB?

But what about file transfers?
I’ve heard people say that changing file sizes to SI units will make working file transfer speeds confusing, but the opposite is actually true – bitrates are actually already represented in SI units, so changing how files are represented on disk would make it easier to work out how long files would take to transfer.

Ram and SSDs
Now, since hard drives are designed around SI units, it makes sense to use SI units to represent its capacity and file size in SI units. But what about solid state drives and RAM? Well, RAM should stay as binary sizing, but as for solid state drives, it doesn’t really matter. The only difference is that a SSD sold as 256 GB (which is actually 256 GiB using the correct prefix) would show up as being 274.9 GB instead. Does this really matter? We’ve put up with our hard drives showing up as being smaller for so many years (a 1TB drive appears to be 92.677GB smaller), so I don’t think it’d be too bad.

Really, all we need is standardisation. A good first step to this would be to show RAM, solid state drives and hard drive sizes using the correct prefixes (GB and MB for SI units and GiB and MiB for binary). Unfortunately ‘mebibyte’ and ‘gibbibyte’ sound pretty stupid compared to megabyte and gigabyte though… But that’s all the more reason to switch to SI units.

C++0x is insanely awesome

Posted on October 13th, 2009

I came across an FAQ that outlines some of the features coming in the new C++ standard, C++0x, which should be finalised sometime this or next year. It really has some awesome features that, in my opinion, brings some of my favourite features of managed languages like C# to the much faster and more efficient C++. I’m already using some of the features in my applications, as a few are available as part of the Technical Report 1, in the std::tr1 namespace. A lot of the best features (like the concurrency features) are still to come in most compilers though.

Here are some of the new features that stand out to me:

Smart Pointers

One of the biggest complaints about C and C++ is that you have to manage your own memory, which means that allocating memory and then forgetting to free it can cause problems like memory leaks. The current version of C++ does have a smart pointer, called std::auto_ptr, that can help with this, but it’s not really very good, because you can only have one reference to the pointer it manages. C++0x now features the std::shared_ptr, which is far better.

Concurrency

C++ by itself has been a completely single threaded language in the past, but in C++0x, we will be able to use threading, locks, and other concurrency features without having to rely on third party libraries, which are usually quite platform specific.

Hash tables

C++ already has the std::map, which can map an object to a key, such as a string, but this has a log(n) lookup time – that is, retrieving a result will get slower as you put more items in it. C++0x now features the std::unordered_map, and three other hash tables which have a faster, constant lookup time. The tradeoff is that adding items to a hash table can be slower, because it has to dynamically resize the table.

The unordered_map should really be called something like hash_map, but there are some compilers and third party libraries that already use that name.

Range For

This is one of those things that is going to be a big timesaver in writing C++ code – whereas previously for iterating through a container like a map, you’d have to do something like this:
for(std::tr1::unordered_map::iterator it = m_Elements.begin();
it != m_Elements.end(); ++it)
{
// Draw the widget
it->second->Draw();
}

now you can use the range for statement, which lets you do this:
for(Element::Ptr x : m_Elements)
{
x->Draw();
}

This is a lot like the foreach statement in C#, which is really nice.

Tuples

Tuples are like arrays that can hold different types, and they are really handy if you want to return more than one value from a function. Instead of constructing a class or struct to hold the data, which would take a lot of extra code, you can just construct a tuple for it. Tuples are extensively used in Python, and are extremely handy.

There are a lot of other great changes coming to the language, and the FAQ has a lot of good examples. The only problem now is waiting for the compilers to support the new standard…

Mac OS X Snow Leopard

Posted on September 3rd, 2009

Snow Leopard
Ars Technica has an excellent review of the new Mac OS X version recently released – Snow Leopard. As they say, Snow Leopard is all about the internal changes to the operating system, and there’s some really exciting stuff going on under the hood that will be very useful in the future. Here’s my thoughts on some of the things brought up in the article:

Quicktime X

Quicktime X in an interesting new feature. Quicktime is a rapidly aging framework that is way past its prime, and Quicktime X is here to completely replace it. Quicktime X is, I’m sure, going to be a very good, modern, 64 bit multimedia framework in the future, but for now it’s fairly underpowered. Why are Apple throwing it in already then? Well for a while now, Apple have provided an Objective-C interface to Quicktime for applications to start moving over to the new architecture. Quicktime X now works with this interface, but transparently uses Quicktime 7 to do a lot of its internal processing. This means that applications can work with full functionality through the transition to QT X, and there won’t suddenly be hundreds of applications that just stop working when Quicktime 7 is completely pulled (which will likely be Mac OS X 10.7). Therefore, it is a good move on Apple’s part to put Quicktime X in in my opinion.

Clang

To me, Clang is probably the most exciting thing about Snow Leopard. Although GCC is still the default compiler for C languages on the system, now Mac OS X ships with the Clang compiler (which is a front end to the LLVM virtual machine project) and is recommending that developers switch to it. This is very cool, because not only is Clang heaps faster than GCC, it is also a much more modern architecture, has far better error reporting, and makes faster executables. The biggest downside though is that Clang’s C++ support is in its fairly early stages, but Apple (who have hired most of the developers of the LLVM and Clang projects) has said that they are aiming for full C++ compatibility for the compiler.

OpenCL and Grand Central

OpenCL and Grand Central are pretty exciting as well, and have the potential to really speed up the whole Mac OS X system. OpenCL allows developers to easily code applications that take advantage of the computer’s graphical processing unit, or GPU. This is one area where Apple’s investment in LLVM will really pay off – the OpenCL code will be compiled to bytecode, and LLVM will be used to generate code to run on the GPU if it is available, or on the regular CPU if not. Grand Central will make it far easier to program for multi threaded environments too, with a lot less overhead than regular POSIX threading.

All in all, Snow Leopard brings some massive changes under the hood that will allow developers to make much higher performance applications, and provides some better APIs to do so than we have seen in the past, with a few nice user-visible features thrown in to make the (extremely cheap) upgrade seem more worthwhile to those who don’t realise how much of a massive architectural advancement it is. I’m looking forward to giving it a spin.

Elegance in Gnome

Posted on August 31st, 2009

It’s a bit old now, but Hylke Bons posted a great wrap up on elegance in software user interface design, and some big problems that application designers in the Gnome community need to work on fixing. Things like multiple borders when only one is needed, redundant labelling, lack of whitespace and so on. Gnome does look pretty good (especially when you change the fonts) but there are still a lot of things that could be improved.

Gnome Global Menu

Posted on July 31st, 2009

I recently blogged about integrating menus in an X11 window manager’s window borders, and I assumed that this would require quite a lot of changes to both GTK+ and the window manager, with an API to communicate between them, but it seems that it may be far simpler than that. I came across a project called gnome-globalmenu which takes window borders out of applications and places them in the panel, without any changes to the applications. Using a similar method, the window border could grab the menus, and then a transparent theme could used to blend in toolbars, tabs, scrollbars and so on like in my other post on the topic, if the theme so wanted.

The only problems is that it seems to work with GTK applications, so KDE and other toolkit applications, as well as applications like Firefox and Wine which draw their own menus wouldn’t be able to integrate. In this case, and for windows with no menus, a normal sized window border could just be used.

New Site

Posted on July 24th, 2009

Over the last month or two I’ve been re-designing and recoding my website, and today I changed over to the new codebase and design. It’s a lot brighter than the old site, and has a far better photo gallery. There are still some parts missing from the site, like the production section and most of the development part, but I think that generally it’s far better than the old one.

You can read about the changes in the news section.

Extending the application/window manager integration

Posted on July 20th, 2009

After my post suggesting that we should have an API that window managers can provide to integrate menus with the window borders, I thought I’d take it a little further and make a mock-up of what Firefox could look like with a the menus, toolbar and tab bar integrated into a black glass like window border theme:

Firefox Mockup
Here’s what I think Firefox could look like (Click for full size)

Fairly nice, I think. Given the greater flexibility, it could also allow people to create themes that look like Mac OS X, Vista (if you’re into that kind of thing) or anything else. Take the Mac OS unified window look for instance – it would be very difficult to create it with current theming systems:

Grapple Firefox Theme on Mac OS X

With the ability for a window manager to manage the menus and toolbars, this would be possible.

On window managers and menus

Posted on July 19th, 2009

There’s been a lot of talk on the future of the Gnome project’s default window manager, Metacity, such as using CSS to design window border themes and giving applications the ability to extend the window menu. But I think that we could go one step further than just the little window menu – as suggested by the Tango project, maybe we could move all the menus into the window border. Obviously this would require changes to the window manager, to GTK, and probably even the applications that use it. Still, it would have a lot of advantages:

  • The changes to GTK could make integrating GTK apps with systems like Mac OS X much easier – if the menus were not embedded in the layout of the application, they would not require a library like ige_mac_integration – just changes to the Mac OS backend.
  • Furthermore, if somebody was interested in making a window manager that had a menu system like Mac OS X, it would be far easier to implement with a system like this.
  • The window’s icon could be made bigger, which looks better – you can hardly fit any detail in 16×16 pixel icons.
Window mockup

A mock-up I made of an integrated menu.

I don’t really know much about the internals of X11 window managers, but I expect the process would have to be something like the following: On loading a GTK application, the toolkit would have to query the window manager to see if it supported menus. If it did (and was running a compatible window border theme), GTK would pass it the menus (through the UIManager XML format or something) and it would render them. If the window manager or theme was not supported, they would just be drawn by GTK as they are now.

One difficulty might be sending events back to the application from the window manager. Another could be the difficulties of handling multiple windows with menus on a universal menu bar system such as Mac OS X.

Anyway, it was just an idea that, if possible, could really improve the look and feel of user interfaces, among other benefits.