Most of the rumors involve having the major streaming music players (pun intended) Spotify, MOG, Rdio more deeply integrated into the Facebook platform. GigaOm summarized Facebook's proposal to the music services (the mentioned Ticker has rolled out in a new design since).

22 September seems to be the date of the upcoming Facebook music announcement at f8 given the first talk beeing about "The Future of Digital Music".

Suprisingly this week MOG and Rdio both announcement support of limited free streaming, something Spotify has been offering in Europe, and more recently also in the US.

The Hints

I looked at the major music streaming services, and found an interesting reference in their HTML code. All track, album and artist pages got meta data in a yet undocumented format:

The providers whom all serve this custom Facebook format by tagging their pages music.song, music.album are:

• Spotify
• MOG
• Rhapsody
• Soundcloud
• Rdio
• Deezer (France)
• VEVO (added!)
• iheart (possible, no bridge)

These seem to be the launching partners. Confirmed notable services without the format:

• iTunes
• MySpace
• Pandora
• Turntable.fm
• Amazon.com (store and cloud player)
• Last.fm
• Napster
• Kazaa
• Groovershark
• emusic
• OVI Music

Facebook has been building a social graph for almost anything and anyone. These services providing detailed meta data regarding music, which users could like, share and comment would be a big win for Facebook and other developers to build from. The social graph would be expanded by a detailed music profile of users, and their friends.

The undocumented mentioned audio type audio/vnd.facebook.bridge seems to refer to a format that bridges audio between the streaming services and the Facebook platform.

It seems all the partners are ready: free streaming, link between the music service and Facebook, all we need is to wait few more days.

Update: the official partner list

For DirectLyrics I recently created a one-stop solution which solves all the issues these buttons cause. Key issues that needed solving: quick & fast loads (2kb gzipped), wide provider support (5), and non-blocking.

Result

• Easy install on any page by including an iframe which refers to a CDN hosted long term cached html file.
• Control variables on layout, supported providers, relevant url. Passed as #hash (keeps the file completely cached for users)
• Support both (native) tall counters as well the wide layout including the counters
• Providers: Facebook (Link and Send), Twitter, LinkedIn, StumbleUpon and Google +1
• Non-load blocking by using smart Javascript loaders

This is an early and quick release, but I’m planning on supporting this for a while. You can download the source, or hotlink to the Amazon CloudFront CDN version.

Setting

Example iframe:

<iframe
    src="/so/#href=http%3A%2F%2Fwww.yvoschaap.com%2F&promo=tweet%20text&position=tall&su=true"
    scrolling="no" frameborder="0"
    style="border:none; overflow:hidden; width:260px; height:65px;" allowTransparency="true">
</iframe>

Implementation settings go here

Sample

Google users must reside in the US, have a Google Profile, be logged in and enable +1 to see how it works.

Whether the +1 is useful or not is too early to call. But a noteworthy feature is missing: a button which can be attached on news posts to let visitors +1 their content. Just like when Google Buzz was launched an ugly hack was needed for months untill an official buzz button was made available. The buttons does exists because there is personalisation option available refering to non-Google sites.

Google claims the button is “coming soon” but I couldn’t wait, so I looked around the code, and looked some more, untill I found the button endpoint hiding from me, obfuscated, in a stray piece of javascript.

Check out these live Google +1 buttons:
[since this was posted the button is available to anyone]

as seen on Fanity integrated in the right-hand side bar.

You can make them horizontal or vertical just like Twitter retweet and Facebook like.
[since this was posted the button is available to anyone]

What I found out:
- They work! Clicking the button (try: Fanity)  indeed makes your +1 link appear on your Google profile.
- If the button is red with an exclamation mark you are not logged in or from outside the US. Check out the screen cap below.
- These buttons also reveal the total number of +1’s by changing the request URL. For example Google.com has 982 +1s, Techcrunch.com 241, Reddit.com 125. Whether this is a total count from my friend-circle only I’m not sure, but it should since that would make more sense.
- Google needs some more A/B-testing on alignment of the total +1 count.

An image for when Google takes it down, or you are not from the US/logged in:

As seen on:

And last but not least, I’ve been developing Fanity for the past few months together with Raoul. A lot of backend work has been done, tons of data is coming in and algoritmes are trained to handle it all. We’ve just launched a simple invitation interface to allow alpha users of the site to login and try the site out, while others (you!) can get an invitation for the upcoming launch. Expect something big!

As a application developer on Facebook, I usually run into certain walls that limit my application functionality. But I don't give up easily, and only recently I found a solution to one of my function limitations. Surprisingly, when looked into more carefully my solution allowed full access and control to the Facebook user account that accessed my application. Did I mention this would also be untraceable since exploit actions would happen from the users IP and own domain cookie?

Lets walk through it along some clarifying images. Flash applications run on a users' computer. A Flash application is able to load data into its environment. This is done by a request of the application, where the user loads a certain URL. Luckily - just with browser AJAX requests- a flash application hosted on domain X is unable to open a file on domain Y. If this would be possible, domain X is able to access content on domain Y, and when the user is logged in on domain Y retrieve and post back any personal data.

In certain cases this could limit a flash application capabilities. A relevant example: an application wants to display public Facebook user thumbnails. The application is on domain X, the thumbnails on domain facebook.com. To resolve such issues, Adobe (Flash's developers) introduced a "crossdomain.xml" file which could allow certain domains accessing another domain, leading to cross domain access by certain or all domains.

While indeed Facebook locked the front door from any non-facebook domain access via Flash, a simple subdomain change allowed any flash application (domain="*") to access it's domain data:.

This wouldn't be a big deal if the subdomain only hosts images, but unfortunately this domain hosts the whole Facebook property, including a facebook user session.

If you have auto-login enabled on facebook, you might recognize your fullname [update: its a screen cap now] in the snippet above (and the keys to do actions from the accounts credentials).

A huge problem that leads to full access and control of a user account whom has "auto login" enabled, and who hasn't?

But how does MySpace fit in this story? You would be surprised if I found a similar back door on not one, but two of the top 10 websites online, right? Well a quick look at the MySpace crossdomain.xml file shows again a locked door, except for one element: the domain farm.sproutbuilder.com was enabled to access myspace.com data.

A look at "sproutbuilder" showed a application builder (which indeed has a module able to load MySpace data: news updates) but more disturbing an upload function allows anybody uploading ".swf" files, the file extension of Flash applications. The location of the uploaded file? farm.sproutbuilder.com [exploit closed], exactly the domain that is allowed access to MySpace data.

You don't need much time to think of all the ways this could be exploited. All what has to happen is a active session, or a "auto login"-cookie and a URL which hosts a exploiting Flash file. For example when accessed, a automatic "post update" could be made, that would lure friends of the user to access the exploit URL, and the exploit would spread virally. An more invasive and hidden exploit could harvest all the users personal photo's, data and messages to a central server without any trace, and there is no reason why this wouldn't be happening already with both Facebook and MySpace data.

News item featured in various publications:

• TechCrunch
• Computerworld
• net-security
• Infoworld
• Slashdot

Things are changing: where only a few years ago websites – another form of an application a.k.a. app - were build by nerdy people in nightly hours, the current generation of nerds are at the core of building billion dollar businesses like Google and Microsoft. Nerds rose from unsocial creatures to Hollywood movie heroes (e.g. Harry Potter, Peter Parker). Today you’re cool if you know how to CSS hack your MySpace page. Nearly everybody has a online social network account. It has also become almost normal to talk about internet stuff on social occasions, something you shouldn’t have attempted only 5 years ago.

In my opinion these are signs of a trend that will continue due to a need to gain full control over computers – in specific by programming them – becomes mainstream. With computer devices from laptops to phones everywhere it make sense that an evolution will go from using available applications to creating your own applications adjusted to your specific demands. The basis of this is local and niche problems can bring local and niche solutions. For example I want to instantly share my French homework with my classmates by making picture of it with my camera phone, transform the image-to-text, spell check it online with an API, push it automatically over Bluetooth to my classmates and have them pay 10cents for the homework copy; a strange app that won’t be made by anyone any time soon, but why wouldn’t they create that app themselves?  The boundaries that have prevented this from happening are disappearing fast:

 
1. Knowledge: developing applications has been a very specific quality. But with computer devices all around us the ability to create a custom application for these devices makes programming a more common need. Schools started educating on computer usage and have already included basic programming courses (pun intended). And to be honest programming is no rocket science;  it’s actually very logical but just like being good in math or not some people might be better in other stuff.
 
2. Costs: with developing came high costs due to the highly trained personal. But quality guides on programming languages are freely available online and the numbers of books on any programming language are in the thousands.  Next to that; where previously websites were made in notepad, WYSISYG website editors and SDK’s like Eclipse (free!) provide some very strong frameworks to work with and help novice developers to create whatever they have in mind.
 
3. Publish & Spread: it is possible for anybody to develop a website and have it available online within seconds. There are no boundaries that prevend you from publishing an webapp online. The Apple app store (15.000 apps) and Google Android market (~1000 apps) provide a platform to publish and spread your app to the world. These apps are not made by big companies, but mostly by people who had an idea (bad or good), developed it, and released it for others to use.
 
4. Money:  previously it was hard to monetize your own developed app due to the lack of a (popular)  platform that handled (micro) payments. For the web Adsense solved this for website developers by providing advertising on any webpage. The last year or so mobile app stores opened the possibilities to monetize on mobile application development.  A thousand downloads of your 1$ application is a nice $1000 dollar, or if you want more you could’ve entered this competition that gave away over 10 million (25k to 225k each).

One major hurdle - in specific for mobile development - are the numerous development environments: JAVA, C++, Objective-C, .NET, J2ME. Don’t think you can make an iPhone app without having a Macintosh, and also don’t think a Nokia 6500 can have the same app code as a Nokia N95. The only solution right now is to create your app for every language there is since everybody still has different phones: if you pick ten random people you get ten different phones types with 6 different development environments.

There is so much more to say about development, but for this post I can summarize it to this: In the near future programming knowledge is widely educated, most current boundaries are resolved and only creativity with some excess time will limit people to make great custom apps for the world to use.

PHP: Clean up all the user input

One of the most common exploits are the result of unintended user input. User input by URL, forms and cookies has to get cleaned up from any exploitable input before doing anything with it. Most importantly you want html characters (like <,>) to be encoded to their harmless html representative and ', " escaped by a slash to exclude external code to be forced into your site. This script code below runs through the array $_GET, $_POST and $_COOKIE, and cleans up the values passed from the user. Please force integers on user input e.g. ID's by stripping out any other character. I'ts best to always also have Mod security installed.

These filters (filter_var) only work in PHP5, but with a good regular expression it can be also run in other versions. It's also good to truncate a string to a maximum number of characters or else you could exposed to this. In this script the string allowed is limited to 100 characters this could break alot of systems (like long user comments) so be carefull with that.

PHP: Working with forms

Never put any settings in hidden form fields, and expect them to not be exploited. Easily exploitable is the example below where a form value identifies the user by UserID.

These hidden form fields can be set to any value. Look at this example on a major bank website. Another tip is to add a token to a form field that is based on the clients encrypted IP, session and/or cookie so the form is harder to temper with by CRSF exploits. More on tokens and why it's needed in my upcoming post.

Also dropdowns can best be setup like the example below to restrict unexpected values from the user in $dropdown.

PHP: uploading files

Never let people upload stuff to your server, unless you know what you are doing. Best way is to store the uploaded file in a folder unavailable via a url (e.g. next to your public_html folder) and have a file act as a proxy that grabs the uploaded file and forces a innocent extension like .jpg (only when it's an jpeg of course).

Javascript: don't echo/print user input in javascript

A very common exploit like XSS is usably the fault of javascript code beeing run on the domain. Javascript can steal and forward user cookies, or make any (unintended) user actions like "delete account". For example this javascript php combination:

Could easily be exploited by creating a url /?username=name'+alert(1);+foo+=+'bar. The cleanArray() function above helps some against these problems since it adds slashes, truncates the string and encodes characters.

User management: don't store anything critical in a cookie

It seems tempting to store certain values in a cookie, saving time to retrieve settings from a database for example. For example to give a user administration rights:

Also saving $passwords, $usernames and $userID's (especially incremental $userID's. UserID = 1 having admin capabilities?) in a cookie is a bad idea, cookies are as easy to tamper with as changing a variable in a URL. Best way is to crypt or md5 settings to identify a user:

When a user has a cookie, and you want to check it's credentials. From the cookie $useridentifier you generate the md5 by combining your encrypt key and user IP and match that with the users cookie set.

Another best practice is to set the cookie to HTTPOnly, to exclude javascript (AJAX) to read the cookie contents.

PHP: Header forwards

An not widely known behavior on a well known practice: A header forward, without a exit() or die() could continue to load the page if the browser (or an exploiter) continues to load the page.

Mysql: limit your updates and deletes

When performing sql queries that contain dynamic variables always limit your query to 1 (of course unless you need to update or delete a bunch).

Apache: Mod Security

Install mod security. It has a nice black list of rules that block certain (common) exploit attempts from the external environment e.g. blocking exploits in the user agent string, bogus image uploads, injecting XSS, SQL injecting, commands, and url request string. In your .htaccess you set the mod_security to on on most apache installs:

And last be very careful when installing external scripts like Wordpress, Gallery or even Cpanel (webbased server control panel) on your server. These scripts could have a security hole that can be exploited throughout your domain and even on the whole server. Always update to the latest version, and don't install in the standard directory so crawl bots won't find it easily.

• Competition in the search engine listing is huge and always on your tail. With a very good reason: real money is being earned from the traffic. Thousands of dollars a day could be the difference between being #1 or #2. If you find a great way to out rank your competitor, you can count on them imitating your strategy. And not much stands in their way, because it’s hard to hide your SEO strategy with tools like Yahoo! SiteExplorer or Technorati that reveal your (in-)linking strategy. Or notepad that shows your complete page markup (HTML) . While page markup and content are important, my experience shows inlinks are the main ingredient to success (note: that’s not a secret). All these success factors can be revealed and adopted by the competition.
• Search engines are always tweaking their ranking algorithms. Your strategy that got you to the top, could as easily bring you back to the bottom again. If you are #1 yesterday, and #1 today, doesn’t mean you will be #1 tomorrow. I’ve learned that the hard way by now…

You end up with a constant craze of tweaking your markup, adding content, revising changes based on a possible relation between your edit and rankings, expand your site with functions, restyle to minimalism, focusing on high traffic keywords, focusing on niche keywords, link exchanges, no-following, etc. Whatever your personal fad is.
But in the end, the search engines are a blackbox, and you can only hope that you’re lucky enough to come out on top.
My thoughts went out to search for another way to make money with online traffic without search engines as middlemen who determine my online and offline faith. I don’t want to invest in (ad-) campaigns, or do low margin arbitrage on buying and selling traffic, nor do I want to game the system since that wouldn’t be a long term strategy either. I need a strategy that is low maintenance, fully automated, little competition, providing quality ad views/leads and viable as a respectable long term business. It maybe sounds lazy, but that’s not my intention, these qualities will make a scalable business with low operating costs.
And there the answer is: 404. File not found. Dead links. Expired domains. Misspellings. Typos. Dead ends. All traffic that goes to waste and ends on a blank page. I might be able to come up with a variation of what businesses are already doing with dead-end traffic:

• Millions of people mistype domains. Even a small percentage of 0.01%, could lead to billions of pageviews on the wrong place. Instead of focusing on the first part of a domain name (e.g. googgle.com) by buying all these misspellings (typo squatting is a well known ‘business’ practice) for a few dollars each, this company made a deal with the country of Cameroon – owner of the .cm extension – to handle all typos in the last three characters of the domain name: (“domain.cm”). This deal leads any domain + .cm to their ad page.
• Instead of getting the standard not found page, or could not connect from your browser, internet provider Verisign hijacks the user and redirects them to a related ad page instead. A nice traffic flow leading to a good revenue bonus for an internet provider. But they are not unique: browser toolbars are also in the game with a ‘service’ of fetching a dead link, and redirecting a search results/ad page to the browser. Google, Adobe, Yahoo, Microsoft are all forwarding dead end traffic to their businesses. Google’s new browser chrome has it started turned on.

So my brain brainstormed on my next possible project that didn’t need Google, or any other search engine: Own 404! Spider the internet in a smart way, get loads of data from browsers and webpages. See how internet traffic moves from click to click, and focusing on dead ends: a page that isn’t there anymore. When logged, get control of the page (yes, legally), push to a relevant ad page. When no owner of the dead end (domain) exists get the domain. Instead of the dead end 404 page, people get my ads!
With the internet getting older and bigger by the day, more dead ends pop up, and I’ll be happy to take them over. No more high traffic website with content, but a high traffic end-point with ads:
5 visitors per page/day, control 200,000 previously dead-end pages, gives 1 million page views/day, CPM 3 dollar, $3000/day * 365 = 1,095,000 a year.
While the project might be viable… my current and upcoming projects are still bound by the search engines and their judgments and I’ll have to accept it... for now.