Tag Archives: software

Culture, News, Politics

Open wide, let me put this in you

1 Comment

Given that the UK Government is considering switching to open source formats and software, and that several municipalities (or entire government departments) within and without the EU have decided to ditch proprietary software in favour of FOSS (Free and Open Source Software) alternatives, it’s worth us having a look at the pros and cons of such a move, if only to better understand (or object to) the decisions being made at this level.

Firstly, a quick explanation of the terms are in order:

Open Source Software: See here for the official Open source Definition

Open source is a development model based upon the “four software freedoms” elucidated by Richard Stallman of the Free Software Foundation as: the freedom to run [the] software for any purpose; the freedom to study how the program works and change it to suit your needs; the freedom to redistribute the code; the freedom to distribute your modified software so others may benefit from your changes.
The free in Free Software refers to liberty, not price. In practice, this means that using software with an open source license gives developers, engineers and end-users the ability to share their ideas and make contributions (fix errors or bugs, add new features etc) that benefit anybody using said software. It also means that the code is available for constant review, giving rise to the argument that FOSS deals easily and promptly with, for example, security issues.

Proprietary Software:

Software licensed under the exclusive terms supplied by the copyright holder. Generally speaking, proprietary licenses give the right only to use the software under certain conditions, in practice meaning that one is restricted from modifying, sharing, studying, distributing or reverse engineering the code.
Only the provider of the software has access to the source code, and therefore only they can modify, release updates or add new functionality to the software.

Licensing:

It’s worth noting that both proprietary and open source (or free) licensing uses the same legal basis (usually copyrights) to construct agreements. Proprietary licensing (most often in the form of an End User License Agreement) will state precisely what you can and cannot do with your purchased license, whereas open source licenses can vary from completely free, i.e. no restrictions at all, to the requirement that published code must be released using the same or equivalent licensing.

So how would it benefit government departments?

1. Switching formats (for example from Microsoft’s proprietary .doc Word document format to the open standard .odt format) could mean that all government departments regardless of operating system or software in use will be able to read and write to the same target and expect the same results. Of course, I suspect this happens now with office documents, but is burdened by an EULA with an annual fee.
As the format has new features added, no additional cost is applied outside the manpower required to roll out the updates. This would also make it easier for the various departments to deploy a variety of operating systems depending on their needs without the burden of having to re-format documents for particular users.

2. Overall costs of deployment are reduced (not paying for licenses or new iterations of the software, for example). This is a disputed one, as a counter argument exists. The cost of retraining staff for using new software, and the cost of training or employment of new IT staff with a new system has been said to vacuum up any savings made by switching.
As it currently stands, much of the UK Government is still using versions of Windows and other related software created well over a decade ago, so I believe the retraining costs of switching would amount to much the same were they to update to more modern versions, with the added benefit of lower future spending.

3. Updates, bug fixes, plugins and tweaks etc can be created in-house without additional licensing or approval. Most IT departments, whether government or business, have employees who write and deploy software for front- or back-end offices. An easily understood example might be an intranet where employees have access to FAQs, forums, customer databases and the like. As has been my experience, certain parts of an intranet may make use of bespoke Internet Explorer (Microsoft’s default browser) features, such as ActiveX plugins. Only IE supports ActiveX, and only Microsoft decides whether a plugin is still useful or will be deprecated.
This is a problem because the choices are often either to use an outdated browser (not secure when used outside the intranet) or rewrite from scratch to whichever iteration they update to. This is a vicious circle, and would be ameliorated by using an open standard such as HTML5 to code the intranet and open source software to maintain legacy features (for example by using a browser’s plugin architecture or altering its code) while keeping up-to-date with regards to general internet security.

4. Writing your own software. Libraries and back-end services written for one open source program can often be used in other programs without express permission (depending on the license), lessening the burden of writing new ones from scratch.

What are the downsides to switching?

1. With regards to format-switching, Microsoft Office now supports open document formats, so only some brief training informing staff to save in .odt would be required. Switching entire platforms may require further training due to the variety of options available outside the proprietary software pool, however, given that various departments may be required to give training for new versions of proprietary OS deployments, I believe the costs are comparable.

2. Long term viability. An issue that comes up within the Open Source communities is what to do with a project when its creators or maintainers decide to no longer support the software. This could add to the overall costs if a department depends on some code that is no longer supported, as it may require a switch to an alternative or for the IT chaps to maintain it themselves.

3. Interoperability. An issue that plagues the modern world as a whole, really, but one that should concern a government considering deployment of FOSS. An example might be using Microsoft’s Exchange for email. Support for ActiveSync et al outside the Windows environment is choppy, if not appalling.

4. Regulations. There may be legal requirements upon software deployment, such as using particular encryption methods or in fact using software with specific licensing restrictions, exemptions, or requirements. I believe this would be the issue most necessary to adhere to, and the most difficult to overcome.

All cards on the table, I am an advocate of FOSS, so my opinions should be regarded accordingly.

That said, these are only a few of the pros and cons we should consider (the ones that came to mind when writing this post…). Can you think of any other issues governments could run into from a switch? Or perhaps you’ve noticed a benefit not noted above? How about a mistake I’ve made? Comments and suggestions very welcome through the comments link below.

Further reading:

List of Open Source Licenses
Legal Issues and Best Practices around procuring or deploying open source software

Censorship, YouTube

Leaguer fights back against Votebotting, TubeGuardian in development

7 Comments

Well, well, well. What do we have here?

In the war against censorship, one of our forum members and Youtuber joshTheGoods is taking matters into his own hands, and I have to say I feel much safer at night knowing that at least one sensible codemonkey is working on the software weapons we need.

Josh posted the video embedded below on his channel today, demonstrating an early build of TubeGuardian, an innovative background application that monitors your Youtube channel statistics (or anyone else’s, for that matter) and if given access to your account, will sense when videos are targeted by votebots, and automatically react to protect them. This does not involving counterbotting – which would only be stooping to the level of those free speech-hating cowards – but rather the act of defending your videos by disabling ratings. Check out the video for the full lowdown from Josh himself. It’s set to play in HD, so be sure to embiggen it with the fullscreen function for maximum effect.

Since I began writing this post, it appears the above video was itself votebotted! A nice demonstration of the effectiveness of TubeGuardian, which disabled ratings after just five 1-star votes. Note that it is not the number of ratings that triggers TubeGuardian‘s defence programme, but rather a suspiciously high number of ratings when compared to views.

As Josh mentioned in the video, he is open to suggestions as the software is in development, so if you have any, or can offer any help, please send him a PM on Youtube. If anyone can port the software to OS X, I’d certainly appreciate it (and let’s not forget our friends on Linux). Once it reaches a stable release, we will be sure to host the install files officially here at League of Reason.

In the meantime, check out joshTheGoods’ channel and subscribe to him for video updates about TubeGuardian.

Censorship, YouTube

Votebot Anatomy 101 – Part 2

16 Comments

Following on from Part 1 of my Votebot Anatomy 101 series of blog entries.

Some of the software that can be used in order to perform a Votebot attack is in my opinion quite expensive at around $100 a pop, I don’t have $100 to spare, and I certainly don’t want to line the pockets of the people who make the software, but from researching demo’s, videos, information on the web and my own knowledge of web technologies I will attempt to explain how a person might perform an attack and how the software facilitates this.

YouTube currently does very little to stop you from rating a video more than once in a given period of time. When rating a video a cookie is stored on your web browser with a list of videos you have rated (I believe this is also the same for when viewing a video), I’m not sure if this only stores the last video you rated or all videos you have rated in that session, the cookie is encrypted so the information contained is not easily viewable. If this cookie is deleted, or you rate a different video or your session times out and then come back you are then able to vote on that video again. (Whether the repeat ratings get counted I’m not sure of, but it would make sense that they are due to the massive number of ratings some people get during an attack. Even if the repeat ratings are not counted, it’s possible that with enough Sockpuppet accounts the same result can be accomplished.) It is possible however that YouTube may do some sort of throttling on ratings if there is a large number coming from one IP address in a short period of time, or at least, I hope they do.

From what I can gather, the majority if not all the software being used to perform a Votebot attack essentially acts the same way as a web browser but automatically performs the actions needed to add ratings to a video the way you would if you were doing it manually, only the software is able to skip certain steps, like viewing the video, which is why most of the time someone who has been attacked will see a disproportionate number of ratings to the number of views (for the more technically minded, the necessary POST parameters are sent directly to the URL used by YouTube’s AJAX scripts when the rating is clicked).

When a Votebot user decides to start an attack in its most basic form, they find a video they don’t like, copy the URL to that video and paste it into the software, set how many ratings they want to add to that video and the star rating they want for each rating added (depending on the software you can set a minimum and a maximum rating to randomly add a rating equal to/between those two values), then click a button and leave it running whilst it does its thing.

Continue reading Votebot Anatomy 101 – Part 2 →

Censorship, YouTube

Votebot Anatomy 101 – Part 1

10 Comments

Hi, this is my first blog post on the League of Reason. In case you are wondering who I am, I am the League of Reason webmaster, and as such, my main area of expertise is web based technologies (among other things). I keep the server running, the website up to date, and so on and so forth.

My scientific knowledge isn’t particularly good, my grasp of philosophy is almost non-existant, and my insight on religion is limited. So I think I’ll leave those things to those far more capable than I.

I’ve noticed that there isn’t a great deal of information on how Votebots actually work, and would like to give what information I know and any theories I have for what I don’t know about these how dubious bits of software do their dastedly work.

I’ll start by giving some information about the Votebot software and its origins:

For those who don’t know what a Votebot is, it is a piece of software or script that someone runs who wishes to drop a lot of votes onto a YouTube video to alter its ranking and thus its visibility in things like related searches. The name Votebot has actually been made up by the YouTube community who have been attacked by these bots, rather than have any positive effects from them (I say positive effects in the sense that a persons video has had its ratings increased rather than decreased. In my opinion, the use of this software to manipulate the rating of a video in any way is wrong and should not be looked at as a good thing regardless of its effects).

The original purpose of these software applications/scripts was to promote a persons own videos in order to gain exposure and make money through various means, and people do that, and can make a rather large amounts of money. Of course, this doesn’t mean it’s right, it gives the illusion of effort when there has been none or very little. The video in question may not even have anything worth watching, but can potentially out perform a video that is highly entertaining or informative.

Some of these software applications are not limited to simply casting votes on videos, they can also increase the number of views on a video or channel (YouTube have recently added a countermeasure that helps to prevent this, but also has some potentially harmful side effects to legitimate YouTubers which I will explain another time). On top of that they can automatically post comments,  add subscribers to a particular channel using Sockpuppet accounts, favourite a video on said Sockpuppet accounts, and also help create these YouTube Sockpuppet accounts with very little effort. Apart from the voting part the other features can only be used for ‘positive’ effects (except for the views countermeasure side effect I referred to earlier and will reveal in due course).

Well, that’ll do for now, I hope this information so far has been of use to you. If you already knew all this, then good for you 😛

In part 2, I will go into more depth about how Votebotters actually go about performing their insidious tasks and the inner workings of the software and its interaction with YouTube’s system.