I just got this in my inbox from Google.

Before I quote the email I'd just like to add my own heart felt sentiments: Please die Internet Explorer 6. Please die now. You're very old, insecure, and stupid. Please die fast but painfully for putting the world through extended support and allowing yourself to exist for what? almost 10 years now?!

Dear Google Apps admin,​

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology. This includes faster JavaScript processing and new standards like HTML5. As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 ​as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010. After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser. We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience. We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

I kept reading on Giz about how HTML 5 takeover is imminent and each time lost a little respect for my favourite gadget blog. It's good to know that when it comes down to it some of them do actually know what they're talking about.

Gizmodo, who were some of the idiots I referred to in my post yesterday redeemed themselves by publishing a very comprehensive breakdown of why HTML 5 isn't saving anyone anytime soon 40 minutes ago, and (although they only briefly touched on it, being that the post is primarily about HTML 5) why Flash is better at doing the kind of things HTML 5 is supposed to usurp in imagination land.

HTML isn't platform ubiquitous and never will be because whoever has the monopoly is also directly motivated to keep web standards to shit. Companies are companies and the monopoly will always be a company.

Flash on the other hand is already platform ubiquitous. Write once, deploy everywhere. The only problem with flash is resource use, which 10.1 - already in 2nd beta will address.

Flash also now has the ability to run native c/c++ code, so decoding video with flash will be as fast as doing it natively in the browser. Well as doing it natively in the browser will eventually maybe possibly in 5-10 years if the web can come together in happy fairy land on HTML 5 implementation.

Goodbye Flash?? I say goodbye web browsers and hello Adobe AIR branded front ends to web services and content.

Here's a small excerpt from John Herrman of Gizmodo's comprehensive HTML 5 breakdown, although I strongly recommend you read the whole thing as it makes things clear for the tech - and not so tech, savvy:

...

The Basics

Before we get into what HTML5 means, we have to talk about what it is, and to talk about what it is, we need to talk about what it's built upon.

Hypertext markup language, or HTML, is the language underneath every web page you've ever been to. The language, along with its various complementary technologies (see: CSS, Javascript), has become immensely complex over the years, but the concept is simple. HTML is what turns this:

<u><em><strong><a href="http://gizmodo.com">Hello!</a></strong></em></u>

Into this:

Hello!

It's basically a set of instructions that a website hands to a browser, which the browser then reads and converts into a formatted page, full of text, images, links and whatever else.

Here, try this: Right-click anywhere on this webpage, and click "View Page Source," or "View Source," or something to that effect. Your eyes will be assaulted with a wall of inscrutable text. You'll see evidence of syntax, but your brain won't be able to parse it. Your eyes will glaze over, and you will close the window. This, my friends, is HTML. But you probably already knew that, because it's 2010, basic web languages are basically in our drinking water. So what's this "5" business?

Somewhere in the central command center basement of the internet, there's a group of guys who maintain the standard, or the rules, of HTML. In the case of HTML5, the buck stops with the Web Hypertext Application Technology Working Group (WHATWG), and to a lesser extent, the World Wide Web Consortium (W3C). It is through these independent standards organizations that new features are codified and presented to the public, and later—in theory—supported by various browsers, no matter what company is behind them.

In the early nineties, the W3C and a few influential torchbearers would collect various new web features thought up by different browser makers, publishing these standards with the hope that we didn't end up with different internets for different browsers. By the mid to late nineties, the standards had grown in both size and stature, then serving as the de facto guide for browser makers and developers alike. (If this sounds a bit rosy, the reality was far grimmer—just ask any seasoned web developer about Internet Explorer, version 6 or earlier.)

Despite an occasionally rocky road, HTML standards went beyond being just a record of changes in web technology; eventually they became the blueprint to push them forward. Still, standards are guides, not laws, and no browser maker has to adopt each and every revision.

The last major revision of the HTML standard, version 4.01, was published in 1999. HTML5 hasn't yet been formally codified, but it was born in 2004 and has been undergoing steady work and maintenance since. In the '90s, HTML discussion centered around topics like font coloration, or tables, or buttons, or something more esoteric. Today, a new HTML version means deep-down support for the modern web, namely web apps and video.

John Herrman - Read the rest on Gizmodo

The internet is a buzz with talk of the downfall of Flash. Flash, the only web platform with 99%+ penetration rate cross platform, and 90%+ penetration rate for their latest version only 3 months after release. The platform that powers the web's content, games, and more than 75% of all interactive online media. That's now able to power desktop and mobile applications, and with the imminent release of Flash 10.1 will bring far more efficient and lower memory/ram usage. So much lighter on cpu in fact that it's able to play HD Youtube videos on mobile phones and netbooks without a problem. Yes, Flash, the downfall of Flash.

There are two main arguments to this. The first is the emergence of HTML 5. HTML 5 finally allows video and audio playback without any plugins, and canvas - a tag which allows for complex drawing, embedding fonts, etc. etc. Things Flash has been able to do for years, has a huge head start on, and does really well. Flash has supplied us with everything from video streaming to blackjack, and even website design as a whole, and yet HTML 5 is supposed to just oust the holder of the crown and sceptre when it's finalized? I don't think so. The problem nobody seems to get is that Internet Explorer still has a majority market share, by a lot depending on who you ask - and Microsoft will likely NEVER support standards because it directly counters their business model. Aside from that, and the fact that every browser that will support HTML 5(ie: everyone else), will implement it differently from each other, with different aesthetics, features, code, BUGS, etc. But even more crucial the HTML 5 spec itself is not even complete yet. It's not even finished, and it's unfinished in a deadlock between the web giants who not only can't decide or agree on which video and audio formats are the best performance wise, but also who owns the rights to implement those formats in their browser and who'll have to pay massive royalties should the true patent holders (still somewhat unknown for sure) decide to cash in. No one wants to properly look this up for a variety of reasons and so HTML 5 - supposed to bring the web together and herald a new dawn of the internet can only work if EVERYONE does in fact come together and implement it in exactly the same way; disregarding that ubiquitous HTML 5 means EVERYONE loses something, some everything.

The other main argument is the Apple iPad - just announced. Which like the iPhone doesn't support Flash. Apple uses the old "Flash is too resource intensive" argument to convince you that limiting you from the full web is a good thing. This simply isn't true. It's false. Both iPhone 3Gs and iPad could happily run the current version of Flash or Adobe AIR just like your laptop/desktop. And it's also entirely up to the developer and how they program and how resource intensive they make their flash app/widget/game/etc. The only reason, listen up, the ONLY reason Apple does not support Flash, is because the Flash platform already powers so many games and useful tools and full blown applications on the internet it threatens Apple's very business model of the Itunes/App Store. Apple wants companies to develop all their apps again specifically for the iPlatform and invest in it. If you could make a Flash app that ran on the iPhone it would also run on Android and every other smart phone. But if you invest in the iPlatform your app will only run on the iPlatform. If Apple was a monopoly the FTC would be pushing them down for their anti-competitive vindictive behaviour.

Apple doesn't block Flash support in their mobile products because they want to push innovation in HTML 5. If HTML 5 was advanced enough, or popular enough to be worth creating the caliber of applications possible on Flash, Apple would immediately configure mobile Safari to block, impede, and hinder the advancement of standards just like Microsoft with IE. In a heart beat. Apple promotes HTML 5 because they know it'll be years before it's anywhere close to where Flash is today, if ever. In fact Apple is one of the "powers that be" preventing the HTML 5 spec from being finalized in the codec wars. Apple wants you locked into their platform. Apple doesn't care about advancing the web, or a better user experience, they care about the big media companies bringing their content online through Apple's platform. Apple wants the iPad to replace your tv, radio, and other media consumption devices. They do not care about the open web.

Adobe on the other hand continues to open up the Flash platform and benefits from creating a ubiquitous platform across desktop and mobile. There are fully open source versions of their Streaming and Application servers, and free and open source ways to develop for their platform. Anyone can build a Flash application, for the browser, desktop, Windows, Mac, Linux, Safari, Internet Explorer, Chrome, Firefox, Opera, etc. etc. Build one application and deploy everywhere using an incredibly powerful, scalable, and mature toolset. Apple on the other hand - should you decide to invest in it, puts you in a position where you may or may not after months of development time and costs even get your application onto a device, regardless you'll have payed Apple to be a developer and to submit it in the first place or even get access to their development tools, and should you get through the random and gauntlet of barriers they can still remove your software from their platform and devices at a moments whim. They can and do literally remove your application from people's phones after being downloaded and used without warning to backup the data put into or created by your app. Anytime for any reason. AND if you're lucky enough to get your application through all these extra months of hurdles and costs and lost revenue you're only gaining access to one small subset of mobile devices.

It is absolutely ridiculous to think the HTML 5 is going anywhere anytime soon, let alone even coming close to eclipsing Flash in any way. Not from Apple, they don't want anything to compete with their platform for getting applications on their devices - Flash or otherwise(HTML, Java, Silverlight), and not from anywhere else because it's just not mature, complete, or will over the next 12-24 months be implemented uniformly or consistently across browsers or operating systems. Even in the event that somehow all these competitors come together to reduce their own profit margins and upset shareholders in the name of benefiting the user and happy popcorn rainbows, it will still only have the capabilities of Flash 8-ish. By then Flash Player 11 will be out and all the best web apps will have an Adobe AIR application front end and you'll use an Adobe AIR application to browse through a market place of Adobe AIR apps. Yes we're moving towards the cloud, and yes the cloud and desktop are becoming indistinguishable, but moving into the browser is only a temporary measure for some companies before they build a desktop front end for their service.

The iPad, iPhone, and iPod are toasters. Every person with an iMobile device also has a desktop or laptop for work and actually managing their digital life. Every single person I've seen raving for HTML 5 and the downfall of Flash depends heavily on Flash and its phenomenal capabilities. They're all idiots.

I've been using a php script as a gateway to fetching certain content from a server, mainly mp3 files. There are a bunch of reasons for doing this, the main ones would be to be able to easily log which files are being accessed, when, and by who - and if you plan on creating widgets for your users to stream the content they upload to your site and they happen to put it on a heavily visited part of the web you can temporarily disable or limit that user's widget's access to content giving your other user's priority and preventing your server from crashing or being overworked.

So in the Flex/AIR app I've got a URLRequest that's used to load a Sound object. Instead of specifying the index.php it had been accessing http://domain.com?var1=blah&var2=blah. Usually this will redirect to the index.php sending it the post variables and letting it do it's thing and fetch the mp3. It works on Adobe AIR for Mac, it works in a browser on Mac/Windows. But in a URLRequest from Windows it doesn't work, confirmed for XP and 7. It doesn't just redirect to the /index.php file and drop the POST/GET variables, it actually just doesn't redirect anywhere, and you get an IOError. You'd think the redirect would be handled entirely by the server and transparent to the client, but it appears that for whatever reason, Adobe AIR on Windows just returns an IO Error.

Either way it's easy to fix, you just have to specify the index file in your URLRequest like so: http://domain.com/index.php?var1=blah&var2=blah.

You probably found this because you're trying to make a socket connection from Flex/Flash and getting the following error:

SecurityError: Error #2123: Security sandbox violation:

Adobe went through a number of phases making the rules for serving and checking Policy files stricter. There are different security sandboxes. If you publish your flex/flash application on domain.com, and the application attempts to load content from domain2.com, it will look for a Cross Domain Policy File at domain2.com/crossdomain.xml to get permission. It does this automatically, however you could specify the location of the Cross Domain Policy File in your flex application using the following method:

Security.loadPolicyFile("http://domain.com/remote_content/crossdomain.xml")

A Cross Domain Policy File only has authority to grant access to content below it in the folder hierarchy. So a policy file in /remote_content/ can't grant access to content in the root folder, and in addition a Policy File at the domain root can override any other policy file. It has maximal authority. Subdomains are considered separate domains - which as a side note most search engines see subdomains that way too.

Now that's Cross Domain Policy Files, In general Adobe Air applications operate in one of the local system sandboxes and has thus have access to content on any domain. This post is about Socket Policy Files. When you access regular web content you're generally connecting to your server on port 80 and being served content by Apache or whatever web server you happen to be running. When you do this you're using http protocols under the hood and never have to deal directly with that crazy stuff. If you want to make a raw socket connection to your server you will need to serve up a Socket Policy File on a specific port.

First I just want to stress the difference between a Cross Domain Policy File and a Socket Policy File. For some reason my dyslexia and the ton of misleading, vague, and now out of date and incorrect information I kept thinking they were the same thing. Second there is no way as far as I'm aware to serve a Socket Policy File with Apache.

The default port for flex/flash to search for a socket policy file on port 843. There are several places on the web that talk about being able to connect to higher port numbers without a Socket Policy File, well that doesn't seem to be the case anymore. Just assume that any raw socket connection from a flex/flash client requires a Socket Policy File.

You can serve the Socket Policy File from the port you're connecting to, but this is tricky considering the manner in which Flex/Flash goes about loading the Socket Policy File and rewriting the service to serve this up, especially if you're using server software built by someone else, means it's just better to keep the Socket Policy File Server as a separate always running entity on the system.

Now in the simplest implementations you need a process either written in python, perl, c++, php cli, or whatever. It needs to be listening on port 843. It has to wait for - very specifically - the following string<policy-file-request/> followed by a NULL byte. Upon receiving that it needs to serve up the policy file which needs to at least have allow-access-from domain set to *, and to-ports set to *. You should use the links at the end of this post to familiarize yourself with the differences between and all options you can specify in Policy Files. It's easiest to keep the Policy File as an actual file, instead of adding the text of the file to your custom server code. And that's it!, now you can go on with a better idea of what information out there is out of date or not.

Here are some important links to help you on your journey:

Adobe on setting up a Socket Policy File Server

Adobe on Policy File changes for flash 9 and 10

Adobe on the structure of Policy Files

An intro to Sockets

Working PHP Cli Socket Policy File Server

This is straight from the Ear-Drum.org Blog, we have 15 beta slots available. Edit, Collaborate, and Remix music, improve your technique or just learn how to play with the ultimate community in a desktop app.

Go download the app right now at Ear-Drum.org

We're currently looking for 15 more beta testers. Spread the word,request an invite.

Then Download Ear-Drum.org Desktop

Digg us:
http://digg.com/music/Ear_Drum_org_is_Looking_for_15_more_Beta_Testers

Follow us:
http://twitter.com/eardrumorg

Link to us:
http://ear-drum.org

Ear-Drum.org Desktop 0.2.0 has been released. Check out the changelog or read the Ear-Drum.org blog post see what's new.

Download EDO Desktop and request a beta invite to get in on the private beta.

Ear-Drum.org is the brand new face of a project I've been working on for years. It's an RIA(Rich Internet Application), which is just a trendy and faster way of saying a powerful web enabled desktop application.

Ear-Drum.org is a music community in a desktop app. I've been searching for the ultimate online music community for a very long time and while a very few have come close to that before being seriously sold; hacked; or turning evil, none - and absolutely none that are currently available, come close to having any soul. It's as if the people behind them are robots in suits, anti-groove people worrying about a bottom line and completely detached from the depth of experience of connecting with another person through music. Ear-Drum.org differentiates itself with a heavy focus on collaboration, learning, and immersion, while also letting you promote your music and meet other musicians. It's for pros as much as it is for beginners and everything else in between. We can always learn from each other and expand on our abilities. Ear-Drum.org strives to be the rich and engaging environment that's required for that kind of deep interaction.

I've gone through lots of prototypes over the years trying to find the best platform, model, and everything else that goes into creating something like this, and the EDO(Ear-Drum.org) Desktop app is the output of that iterative design/development process.

The decision to launch in private beta was made pretty early on. It allows us to build out features and refine the experience with a controlled subset of users. There is still room in the beta so head over to Ear-Drum.org to request a beta invite. Be a part of the early days and help us shape the ultimate online music experience.

The Desktop app is cross-platform so Windows/Mac/Linux it'll just work thanks to Adobe AIR. To get Adobe AIR click here.

Spread the word! The more people that get involved the more people there are to collaborate with. You can help by letting people know about us with your Twitter account. Get the word out on Facebook, Myspace, and other social platforms. Link to us on social networking sites like Digg and Delicious or write about us on your blog. Pass on the Ear-Drum.org link and let's start jamming. It's gonna be a fun ride.

Sometimes you need to automate some terminal commands within your web application. I personally prefer PHP over other server side languages, and in this case its ability to run such commands are fantastinominal. There are a bunch of built in functions for securing/escaping arguments and commands, and a bunch of methods for executing shell commands. The main differences between them are the way output is returned to php. For most cases you should be fine using escapeshellarg() and shell_exec() methods - assuming you're using variables posted to your server code as arguments. You should read up on the various program execution methods over at php.net, and research all the implications and security risks involved in using them.

This post doesn't focus on their use, but instead on how to give Apache(or whatever web server you're using) root access on your server. In fact what you need to do in order to simplify your scripts is allow the Apache process to run root commands without a password. That's RIGHT, without a password. This can be exceptionally dangerous so you may want to limit this root access specifically the no-password-necessary root access only to specific programs you need to run from your scripts. Otherwise a small programming error would let malicious people take full control of your web server with ease.

The main purpose of enabling no password root access here is so you can easily run programs with a single command and not worry about being challenged for a password or having to deal with that in your server code. It's potentially more dangerous to store your root password in a public facing script than giving it no-password-root-access to a single program. A fair amount of web software and tools will have versions of their commands that can be run on a single line for this purpose.

This is for Ubuntu, but should work on most other distros with little tweaking.

First add the following line to your php script:

echo shell_exec("whoami");

This will output the user that Apache, or whatever server is running your php file, is running as on the system. Typically Apache runs as www-data, but your system may be set up differently.

Now open a terminal and ssh into your web server. Run the following command:

sudo visudo

What this does is edit the /etc/sudoers file, however using the visudo command is necessary for changes to properly take effect. Go to the bottom and add the following line to enable the Apache user to sudo without a password:

www-data ALL=NOPASSWD: ALL

The first ALL refers to hosts, the second ALL refers to programs/commands. If you only want to grant Apache sudo access to a specific program replace the second ALL with the full path to the command file. So even though you will be able to call last from your script without worrying about the path, you need to know the actual path here:

www-data ALL=NOPASSWD: /usr/bin/last

Now you should have a list of shortcuts at the bottom of the terminal, you want to "WriteOut"(ctrl+o) the file which is the same as saving it, you'll be prompted to choose the path to save to, make sure that you're saving it as /etc/sudoers, otherwise it may try save your changes as a copy.

You can now try run last from your php script by adding the following to your php script:

echo shell_exec("sudo last");

Now that it works you may want to remove the echo lines from your script, or test it with a different command since showing the world who's actually running Apache or the output of last is not something you want.

I needed a function to strip out html tags from a text input, but still let me specify allowable tags.

Instead of spending time figuring out the regular expressions needed to pull it off and becoming a better programmer, I figured why repeat work someone else has probably already done.. I mean I could be a busy man. Anyway I found this great function on Flexer.info [link]. But after trying it out I noticed that the one tag I really really wanted to be parsed out iframe wasn't. It seems because I had specified i as an allowable tag it was also accepting iframe.

So with all due respect to Andrei, below is the revised function with the security hole patched.

All I changed was near the bottom where it determines if it's an allowable tag or not the reg exp was

<\/?" + tagsToKeep[j] + "[^<>]*?>

which allowed any character to follow the allowed tag as long as it wasn't a nested tag, which included frame following i. This will also support self closing tags.

 
// strips htmltags
// @param html - string to parse
// @param tags - tags to ignore
public static function stripHtmlTags(html:String, tags:String = ""):String
{
    var tagsToBeKept:Array = new Array();
    if (tags.length > 0)
        tagsToBeKept = tags.split(new RegExp("\\s*,\\s*"));
 
    var tagsToKeep:Array = new Array();
    for (var i:int = 0; i < tagsToBeKept.length; i++)
    {
        if (tagsToBeKept[i] != null && tagsToBeKept[i] != "")
            tagsToKeep.push(tagsToBeKept[i]);
    }
 
    var toBeRemoved:Array = new Array();
    var tagRegExp:RegExp = new RegExp("<([^>\\s]+)(\\s[^>]+)*>", "g");
 
    var foundedStrings:Array = html.match(tagRegExp);
    for (i = 0; i < foundedStrings.length; i++)
    {
        var tagFlag:Boolean = false;
        if (tagsToKeep != null)
        {
            for (var j:int = 0; j < tagsToKeep.length; j++)
            {
                var tmpRegExp:RegExp = new RegExp("<\/?" + tagsToKeep[j] + " ?/?>", "i");
                var tmpStr:String = foundedStrings[i] as String;
                if (tmpStr.search(tmpRegExp) != -1)
                    tagFlag = true;
            }
        }
        if (!tagFlag)
            toBeRemoved.push(foundedStrings[i]);
    }
    for (i = 0; i < toBeRemoved.length; i++)
    {
        var tmpRE:RegExp = new RegExp("([\+\*\$\/])","g");
        var tmpRemRE:RegExp = new RegExp((toBeRemoved[i] as String).replace(tmpRE, "\\$1"),"g");
        html = html.replace(tmpRemRE, "");
    }
    return html;
}