I am sorry, but I absolutely HAD to blog about this. It is now confirmed that Sam Raimi will be directing the upcoming Warcraft movie based on Blizzard's Warcraft game franchise. For those not in the know, Warcraft has been around since 1994 in the form of a real-time strategy game with two sequels and a number of expansions. It then transformed into the now massive World of Warcraft, the worlds largest Massively Multiplayer Online game, with over 11 million subscribers.
How do I know its going to be amazing?
1. The franchise lore
The storyline that accompanies Warcraft and the events that play out in its plot all the way from the 1994 RTS game to the current WoW are a move makers delight. Full of action, intrigue, drama, wars, treachery and love stories.
2. Sam Raimi
When Blizzard first publicly expressed an interest back in 2007 about making a Warcraft movie, Uwe Boll approached Blizzard saying he could direct for them. With this directors serious lack of success at game to movie conversions (anyone remember Street Fighter?), Blizzard pretty much laughed him out and told him where he could stick his offer. They then went and selected, in my opinion, one of the industries finest action/fantasy directors. Pretty much anything Sam has directed has ended up golden.
3. Blizzards neurotic caution with its IP
Blizzard has a very big reputation for ensuring that the quality of anything related to its IP is stellar. For evidence, look at Starcraft Ghost, a game that was supposed to be an FPS based version of the Starcraft universe that was never launched because Blizzard thought it wasn't good enough. The expansions for World of Warcraft were also supposed to only take a year each and notoriously took a lot longer because Blizzard wanted to ensure a quality product. Starcraft 2 as well was supposed to be released last year but was delayed because again, Blizzard wanted it perfect.
I have no doubt they will employ the same tactic with the movie and not allow it to be released if it ends up being a load of crap.
There have also been numerous comments around by people who are not as in love with the Warcraft universe as I am, or the 11 million other players of WoW, and believe that only die-hard fans will watch it. Personally I don't think this is the case. The same was said about Harry Potter and yet more people have watched the movies than have read the books or even knew about the books. The lore and storyline that exists within the Warcraft universe is so broad and appealing that it should be a great movie to watch regardless of if you have ever seen or taken part in the games.
So come release day I will be at the front of the ticket buying queue and happily settle down in front of the big screen with popcorn and drink to be absorbed in a universe I have come to love.
Lok'tar Ogar!!!
Wednesday, July 22, 2009
Tuesday, July 21, 2009
RIAA needs to follow the example of other industries
By now, the RIAA's actions in its attempts to combat piracy is infamous. From suing individuals that they think have illegally downloaded content (even if it is blatantly obvious they never did) to trying to push ISP's into policing the Internet on their behalf. However, there are other IP industries that have moved on and followed the times, innovating to keep themselves current and up-to-date with the latest information age trends that demand content online. I am referring specifically to the movie and book publishing industries.
One of my fondest memories here in South Africa, was writing an article to a local IT publication, discussing how the latest movie titles can be bought at almost any street corner for about half what they cost in the stores, and that the best way that the movie industry could combat these pirates was to drop pricing and so make it unprofitable and too risky for these operators to continue. A few months later, genuine DVD titles in shops dropped from R300 each to a paltry R150 or thereabouts. Now, even if you went looking, the street-side vendors selling their pirated versions have all but vanished.
Combine this kind of pro-active approach to keeping your physical stock moving with online content-delivery platforms, and the amount of news I read about the movie industry losing out to pirates is so minimal its more like background noise.
Moving onto book publishers, ebooks could have been a real threat and could have resulted in publishers employing tactics similar to the RIAA. Instead, you can now buy ebooks online for a fraction of the price of physical books themselves. And developments like the iPhone and iPod Touch (amongst others) make consuming an ebook that much more pleasant. While devices like the Kindle by Amazon and now Barnes & Nobles own ebook reader also point to the book publishing worlds flowering digital transformation, I still think these large, expensive devices are ridiculous, but that is just a personal opinion.
The RIAA on the other hand seems convinced that the only way to continue in a world where people want their content digitally, is to deny them that and enforce draconian and, to be honest, ridiculous measures to preserve a business model that is so behind the times its laughable. People are already buying music online on a per track basis. The RIAA, and the companies it apparently attempts to protect, need to realise that the days of the "album" are nearly at an end. People want songs not epics. People do not want to be forced to buy a physical storage medium like a CD that contains 12 songs when they are only interested in 1.
Lastly, if the RIAA is not careful, they may find themselves defunct, along with the record companies they represent. With the explosion in online presence by artists and the ease with which anyone can publish content online, even music, recording studios that sign up artists as has traditionally been done, may no longer be necessary. Artists generate the majority of their own income by touring and royalties, not record sales. Record sales only help market the artist to a prospective audience and line the recording studios coffers. But when an artist has access to an all pervasive medium like the Internet as well as the multitude of portals to market their own content (YouTube, etc), they may realise they don't actually need a recording studio anymore. Artists may dictate to marketing agencies how they want their content promoted instead of the other way round.
One of my fondest memories here in South Africa, was writing an article to a local IT publication, discussing how the latest movie titles can be bought at almost any street corner for about half what they cost in the stores, and that the best way that the movie industry could combat these pirates was to drop pricing and so make it unprofitable and too risky for these operators to continue. A few months later, genuine DVD titles in shops dropped from R300 each to a paltry R150 or thereabouts. Now, even if you went looking, the street-side vendors selling their pirated versions have all but vanished.
Combine this kind of pro-active approach to keeping your physical stock moving with online content-delivery platforms, and the amount of news I read about the movie industry losing out to pirates is so minimal its more like background noise.
Moving onto book publishers, ebooks could have been a real threat and could have resulted in publishers employing tactics similar to the RIAA. Instead, you can now buy ebooks online for a fraction of the price of physical books themselves. And developments like the iPhone and iPod Touch (amongst others) make consuming an ebook that much more pleasant. While devices like the Kindle by Amazon and now Barnes & Nobles own ebook reader also point to the book publishing worlds flowering digital transformation, I still think these large, expensive devices are ridiculous, but that is just a personal opinion.
The RIAA on the other hand seems convinced that the only way to continue in a world where people want their content digitally, is to deny them that and enforce draconian and, to be honest, ridiculous measures to preserve a business model that is so behind the times its laughable. People are already buying music online on a per track basis. The RIAA, and the companies it apparently attempts to protect, need to realise that the days of the "album" are nearly at an end. People want songs not epics. People do not want to be forced to buy a physical storage medium like a CD that contains 12 songs when they are only interested in 1.
Lastly, if the RIAA is not careful, they may find themselves defunct, along with the record companies they represent. With the explosion in online presence by artists and the ease with which anyone can publish content online, even music, recording studios that sign up artists as has traditionally been done, may no longer be necessary. Artists generate the majority of their own income by touring and royalties, not record sales. Record sales only help market the artist to a prospective audience and line the recording studios coffers. But when an artist has access to an all pervasive medium like the Internet as well as the multitude of portals to market their own content (YouTube, etc), they may realise they don't actually need a recording studio anymore. Artists may dictate to marketing agencies how they want their content promoted instead of the other way round.
Monday, July 20, 2009
PHP Security Tips
Having worked with PHP for a number of years I am still at times shocked at how little some developers know about the security implications of their code or how they may be inadvertently compromising their applications by coding a certain way. This articles focusses on some aspects of PHP coding and what to look out for while you are developing to help make your application as secure as possible.
The following tips I have arranged in order of what I feel can be the most dangerous. If anyone has any comments please feel free to post them up and share with everyone else.
1. Command line commands
PHP has a great amount of power, and that power extends to the servers command line itself, allowing you to execute shell commands to the server directly from within the script you are coding. I have seen some coders liberally pepper their code with the shell_exec() function or equivalent PHP functions without a seeming care for what they may be opening up.
My first tip here ... don't use these functions! That's right, if you have no critical need to actually run a command on the servers shell then just don't do it. Rather take the time to figure out another way, rather than potentially open up your server to an attack through this vector.
Now granted that there are numerous ways that the server itself can be setup, as far as PHP's rights as a user to access certain server functions, and these should be enabled anyway. These are topics for a system admin and so are out of scope of this article, but why run the risk anyways.
Secondly, if all other options are exhausted and you absolutely have to use the shell, then please remember to clean up all data being run. As an easy way to clean, you can use PHP's own escapeshellarg() function which can clean some obviously shell-like stuff from any input, but this is also not good on its own.
Another tactic is to avoid using user submitted data as part of the shell argument. For example you can let a user choose from a few options and then run a corresponding argument in shell that was pre-written, rather than add a users submitted data in the argument.
2. Variable variables
Like shell commands above, just don't use them! They are a very big potential risk security-wise and there is almost always an alternate method to using a variable variable. For those who are not sure what I mean, PHP has the ability to create variables based on the value of another variable, for example:
What would be echoed is:
Now imagine a hacker figures this out and is able to submit user data to overwrite one of your own variables with his value and so compromise your system. The consequences, depending on where its been used, can be very dangerous.
Other ways to make using this more secure? There aren't any. Just don't use them!
3. Clean, clean, clean those submitted values
We all know the $_SERVER, $_COOKIE, $_GET and $_POST server variables. Those oh so convenient variables that store all that lovely URL and form data that a user submits. But it is shocking how many developers go straight from using that user input as is! Values submitted in URL's and forms by hackers is the number ONE vector of attacks on web applications and therefore should get the biggest attention when you are developing applications. Great PHP frameworks like symfony will escape arguments from forms and URL's as a matter of course and are therefore great, but this doesn't mean you are still safe.
SQL injection is the biggest attack through form submission and is really quite preventable. Functions such as mysqli_real_escape_string() are great for ensuring that posted data is escaped properly before it hits the database query level.
Another to check for, and this applies to framework users as well, is to properly validate your data. Frameworks can do some basic checking on data but are not complete as they tend to be very generic, validating for the sake of "is it a string", "is it x characters long", "is it an email address" etc. Fields like First Name in a form for example can be validated further. Does the name have any spaces? If so, it is incorrect. Does it have any numbers? If so it is invalid. Again, these just help prevent any possible vectors of attack.
These are just a few of the very large security risks to keep a look-out for while developing. While this isn't a complete guide by any stretch of the imagination on PHP application security, hopefully people may find the information here useful.
If you have any comments or extra tips to share, feel free to add your comment.
The following tips I have arranged in order of what I feel can be the most dangerous. If anyone has any comments please feel free to post them up and share with everyone else.
1. Command line commands
PHP has a great amount of power, and that power extends to the servers command line itself, allowing you to execute shell commands to the server directly from within the script you are coding. I have seen some coders liberally pepper their code with the shell_exec() function or equivalent PHP functions without a seeming care for what they may be opening up.
My first tip here ... don't use these functions! That's right, if you have no critical need to actually run a command on the servers shell then just don't do it. Rather take the time to figure out another way, rather than potentially open up your server to an attack through this vector.
Now granted that there are numerous ways that the server itself can be setup, as far as PHP's rights as a user to access certain server functions, and these should be enabled anyway. These are topics for a system admin and so are out of scope of this article, but why run the risk anyways.
Secondly, if all other options are exhausted and you absolutely have to use the shell, then please remember to clean up all data being run. As an easy way to clean, you can use PHP's own escapeshellarg() function which can clean some obviously shell-like stuff from any input, but this is also not good on its own.
Another tactic is to avoid using user submitted data as part of the shell argument. For example you can let a user choose from a few options and then run a corresponding argument in shell that was pre-written, rather than add a users submitted data in the argument.
2. Variable variables
Like shell commands above, just don't use them! They are a very big potential risk security-wise and there is almost always an alternate method to using a variable variable. For those who are not sure what I mean, PHP has the ability to create variables based on the value of another variable, for example:
$foo = bar;
$$foo = "Hello";
echo $foo.'\n';
echo $bar.'\n';
echo $$foo.'\n';
What would be echoed is:
bar
Hello
Hello
Now imagine a hacker figures this out and is able to submit user data to overwrite one of your own variables with his value and so compromise your system. The consequences, depending on where its been used, can be very dangerous.
Other ways to make using this more secure? There aren't any. Just don't use them!
3. Clean, clean, clean those submitted values
We all know the $_SERVER, $_COOKIE, $_GET and $_POST server variables. Those oh so convenient variables that store all that lovely URL and form data that a user submits. But it is shocking how many developers go straight from using that user input as is! Values submitted in URL's and forms by hackers is the number ONE vector of attacks on web applications and therefore should get the biggest attention when you are developing applications. Great PHP frameworks like symfony will escape arguments from forms and URL's as a matter of course and are therefore great, but this doesn't mean you are still safe.
SQL injection is the biggest attack through form submission and is really quite preventable. Functions such as mysqli_real_escape_string() are great for ensuring that posted data is escaped properly before it hits the database query level.
Another to check for, and this applies to framework users as well, is to properly validate your data. Frameworks can do some basic checking on data but are not complete as they tend to be very generic, validating for the sake of "is it a string", "is it x characters long", "is it an email address" etc. Fields like First Name in a form for example can be validated further. Does the name have any spaces? If so, it is incorrect. Does it have any numbers? If so it is invalid. Again, these just help prevent any possible vectors of attack.
These are just a few of the very large security risks to keep a look-out for while developing. While this isn't a complete guide by any stretch of the imagination on PHP application security, hopefully people may find the information here useful.
If you have any comments or extra tips to share, feel free to add your comment.
Tuesday, July 14, 2009
Mouse gestures with KDE 4.3
For a few months now I have been using KDE 4.3 which, as of this post, is in RC 2 stage and will be the default on Kubuntu Karmic Koala (9.10). One of the greatest features I have found with this new version of KDE is the ability to use mouse gestures!
Sure, mouse gestures themselves are nothing new and have been used in the likes of the Opera browser for years now, but to have an operating system supporting this feature is a great step as it just increases the usefulness of the feature ten fold. This post is just a quick demo to show how to setup and use mouse gestures. Remarkably very easy.
First of all, you need to get to the System Settings panel. Press Alt+F2 and type "System Settings" or go to the Application Launcher >> Computer >> System Settings until you see this window:
Now open the Input Actions applet and you should see:
Along the left side there is a tree menu. Just right-click on the blank space there and navigate to New >> Mouse Gesture Action and click on Command/URL. You will then see:
Enter the name Firefox. On the right side, click the tab near the top labelled Trigger so that we can set what mouse action will open Firefox. Click the Edit button at the bottom and a new window pops open. Hold the left mouse button down and draw whatever mouse movement you want to use to open Firefox. In my case I did an upside-down L or rather an F without the little line. Generally you want to keep the gestures as uncomplicated as possible. You should now see:
Click the Action tab at the top and in the Command field type in "firefox" (minus the quotes of course). Hit the Apply button and its setup.
By default, mouse gestures work while holding the right mouse button down. So hold your right mouse button and draw the gesture you decided on anywhere on the screen. In my case I will draw my upside-down L. Firefox should now open. You can of course change which mouse button needs to be used; especially useful if you have a multi-button mouse.
Under the tree-menu click the Settings button. You will see it says that mouse button 3 is selected. 1 is the left button, 2 is the wheel and three is the right mouse button. Change the number, hit apply, test your gesture with the mouse button you want use and if it doesn't work change it again. Eventually you will get the correct number that corresponds to the mouse button you want to use.
There are other options as well for mouse gestures. For example, by exploring the DBus option, I was able to figure out how to use a mouse gesture to allow me to switch desktops easily. This is a very advanced feature however and I'll put together a little demo on how to use DBus and mouse gestures in another post if I have time. For now, enjoy the ease-of-use that this advanced new feature of KDE 4.3 gives you and have fun. :)
Sure, mouse gestures themselves are nothing new and have been used in the likes of the Opera browser for years now, but to have an operating system supporting this feature is a great step as it just increases the usefulness of the feature ten fold. This post is just a quick demo to show how to setup and use mouse gestures. Remarkably very easy.
First of all, you need to get to the System Settings panel. Press Alt+F2 and type "System Settings" or go to the Application Launcher >> Computer >> System Settings until you see this window:
Now open the Input Actions applet and you should see:
Along the left side there is a tree menu. Just right-click on the blank space there and navigate to New >> Mouse Gesture Action and click on Command/URL. You will then see:
Enter the name Firefox. On the right side, click the tab near the top labelled Trigger so that we can set what mouse action will open Firefox. Click the Edit button at the bottom and a new window pops open. Hold the left mouse button down and draw whatever mouse movement you want to use to open Firefox. In my case I did an upside-down L or rather an F without the little line. Generally you want to keep the gestures as uncomplicated as possible. You should now see:
Click the Action tab at the top and in the Command field type in "firefox" (minus the quotes of course). Hit the Apply button and its setup.
By default, mouse gestures work while holding the right mouse button down. So hold your right mouse button and draw the gesture you decided on anywhere on the screen. In my case I will draw my upside-down L. Firefox should now open. You can of course change which mouse button needs to be used; especially useful if you have a multi-button mouse.
Under the tree-menu click the Settings button. You will see it says that mouse button 3 is selected. 1 is the left button, 2 is the wheel and three is the right mouse button. Change the number, hit apply, test your gesture with the mouse button you want use and if it doesn't work change it again. Eventually you will get the correct number that corresponds to the mouse button you want to use.
There are other options as well for mouse gestures. For example, by exploring the DBus option, I was able to figure out how to use a mouse gesture to allow me to switch desktops easily. This is a very advanced feature however and I'll put together a little demo on how to use DBus and mouse gestures in another post if I have time. For now, enjoy the ease-of-use that this advanced new feature of KDE 4.3 gives you and have fun. :)
Subscribe to:
Posts (Atom)