According to the blog entry, this feature would be opt-in, and canvas application developers would need to provide an SSL url for the “Secure Canvas URL”.

If a user who has opted into the SSL-only version of Facebook attempts to access a Facebook Application that doesn’t have a Secure Canvas URL set, the user will evidently be shown a message (which will likely be confusing and scary, not because Facebook will purposefully make it so, but because most users don’t really understand SSL) that will give them the option to switch from HTTPS to HTTP. From the post:

If you do not provide a secure Canvas URL, we will display a confirmation page to let HTTPS users switch to HTTP and continue to your app.

This currently affects CANVAS apps only – not application tabs – although that may very well change once Facebook pushes the IFRAME version of tabs out some time in Q1.

HTTPS is slower and more server intense than HTTP, and it’s one more cost/timeline issue that has to be factored in. For some clients, I set up the hosting environment (which would include DNS, SSL, etc) – for others, their IT department provisions web space and handles DNS, and they often require a mountain of paperwork and a week to process.

For the latter scenario, the cost of the certificate is negligible, but for a highly-trafficked app, the increase in server load could have serious financial impact. It could mean the difference between needing one server and several.

For smaller companies, stepping up to SSL would mean buying a certificate and potentially paying extra for the dedicated IP address it will need, and if the app takes off, a much heftier hosting bill for running everything over SSL.

If the above would actually, truly improve the safety of the users in some significant way, I’d probably still be on-board.

Security is something I take very seriously, and in 2010, Firesheep showed the world how easy it was to hijack a user’s Facebook session and essentially pwn their account because the session data was being transmitted unencrypted and was sniffable over public wifi. To be fair, it wasn’t just Facebook that was affected, but if you’re logging into websites on an unencrypted public wifi, odds are your email accounts and everything else are at risk too.

That said, this seems like it will give naive users a false sense of security and not actually provide that much value for the effort involved by the app developers.

“Oh, this application must be safe – I’m using HTTPS, and the S stands for *secure*!”

Phishing, rogue apps and malware are already horrendous problems on social media websites, Facebook especially. I would much rather see Facebook (and others) improve their session handling before going in this direction. Reputable companies who are collecting any kind of PII are already running data submission over HTTPS, and non-reputable companies aren’t going to become more honest just by forcing them to encrypt the data they’re mining from your profile.

The net result is a lot of extra work for developers and companies for not a lot of benefit to not a lot of users, with the side effect of confusing people into thinking that SSL = trustworthy, or that a non-SSL app is malicious and trying to eat their souls.

IMHO, the much bigger threat to Facebook users is their own poor judgment on what to click on. Social engineering rules social networks, and no amount of encryption is going to fix that. As the fabulous shirt from Jinx says “there is no patch for human stupidity”.

Until people start being more critical of what they’re clicking on and what apps they’re allowing access to their profile, they’ve got a lot more to worry about than SSL. It’s the same false sense of security that users running antivirus programs often suffer from.

“I don’t need to worry about what I click on – I’m running antivirus! My virus definitions are up to date, so I am safe and protected and nothing can harm me.”

In 2008, Symantec had to write new virus signatures every 20 seconds to keep up with the onslaught of malware that was released. This was increased to every 8 seconds by 2009. [Source: Gray Hat Hacking The Ethical Hackers Handbook, 3rd Edition]

To prove my point, I’ve created FB Profile Spy. It’s still a work in progress, but it’s a better-security-through-humiliation project, similar to my better-behavior-through-humiliation project socialmediadouchebag.net. It’s completely safe – and not even hooked up to the Facebook API at all (but of course please feel free to use NoScript and check it out thoroughly before interacting with the links. I have nothing to hide.) Click through and “allow” the “app”. I need to tighten up the javascript slideshow lecture at the end and I need to sync up the layout with the new profile design, but it’s coming along.

What do you think? Am I just being a whine-ass lazy developer? Am I being a slacker security pundit? Let me know in the comments.

NOTE: This article first appeared on FBMHell.Com.

Also check out:

It’s literally just been launched, so I’m looking for your help. I’ll be going through some older posts and rounding up the questions that seem to come up often and writing up answers for the new site, but if there’s a burning question you’ve had for a while and haven’t been able to find an answer for, let me know in the comments.

One that comes up often is whether or not you can include an IFRAME in a tab, so don’t ask that one It’s already on deck.

I’m looking for all kinds of questions, ranging from the complicated to the more basic, so don’t be afraid to ask. More complicated tutorials (similar to what I’ve posted in the past regarding app development and complex mini-sites on tabs) will take a little longer, so be patient, and remember to subscribe to the RSS feed so you’ll get all the latest posts.

Categories will be added as content demands, of course.

I really want this site to be a great resource for everyone (including myself, as a repository of stuff I know works), so I’m looking forward to your feedback!

Also keep your eyes peeled for the launch of FBMLWizard, a drag+drop Facebook fan page tab builder.  I’ll update you here when it’s ready.

Also check out:

UPDATE May 20, 10:45AM: Facebook has actually apologized and done a complete 180 in the last 12 hours and they have reversed this decision. I’m leaving the original post up for reference, but as of right now, they have reverted back to the original way it worked, where any page admin can set default tabs, regardless of the size of their fan base.

From their developer forums:

As of last night, we’ve removed the recently-added authentication requirement for setting custom landing tabs on Pages. The requirement was instituted as part of a Pages quality initiative, and we apologize for the inconvenience this caused to our developer and business community. We are re-investigating the situation, and will not make any further changes without first giving our community standard notice and lead-time.

Thanks for all your feedback,
Matt Trainer

The Facebook platform is known for being exceptionally buggy, so most “me too”ers assumed it was a bug and patiently awaited a bug fix confirmation from Facebook. The question went unanswered for a day, until finally a Facebook employee dropped this bombshell.

Hello all,

We apologize for not messaging this earlier. Facebook recently made a change requiring that Pages be authenticated before enabling the ability to set a landing tab beyond Wall or Info. To be eligible for authentication, a Page must have greater than 10k fans or the Page admin must work with their ads account manager. If you are already working with an account representative, please contact that representative to begin the authentication process. If you do not work with an account representative, you can use this contact form to inquire about working with an account representative.

Also, for advertisers who don’t have a representative or 10k fans, and want to run ads and land users on a specific tab, you can still do so with standard Facebook ads by making their Destination URL as the URL incl. your tab. Unfortunately, this currently will not work with “Fan” ads.

Thanks,
Matt Trainer

What this means is that Facebook Fan Page admins can no longer specify a default landing tab for their fan page UNLESS they have 10k or more fans, OR they “have an account manager”. Having an account manager sounds great, right? The thing is, you have to spend at least $10k in Facebook advertising before they’ll even talk to you, let alone give you an account manager. That contact form leads to the “how much money are you willing to spend with us” form, and if your answer is less than $10k, don’t expect them to help you.

So once again, the little guy gets screwed. It started in November with their charges to their contest/promotional guidelines, which were also rolled out quietly with little or no notification to developers or users, which dictated something very similar. Certain types of promotions now have to be approved by an account manager. Only you don’t get an account manager unless you spend upwards of $10k in media buys.

Note that it appears as though this is only effective moving forward. If you’ve already set a default tab on your Facebook Fan page, they’re not going to take it away from you. At least not at this point. But as of yesterday, if you hadn’t already set a default tab, you won’t be able to do so without meeting one of the 10k requirements mentioned above.

I’m not even going to talk about the recent Facebook privacy issues. This isn’t the post for it, and honestly, I don’t have the energy to open that gigantic can of worms right now. But with those recent changes on top of this, I have to ask WTF they are thinking over there. Fuck you, Facebook.

Also check out:

If you develop Facebook applications, I strongly encourage you to check out their new Facebook Developer Roadmap, which breaks down upcoming changes in detail and let’s you know when to expect these changes to roll out.

I for one am thrilled to see Facebook finally trying to work with developers to give them a clear idea of what to expect and when. As someone who has spent the past two years writing Facebook applications and being frustrated by surprise platform changes, this is a giant step in the right direction from my point of view. Previously, it was not uncommon to get only a day or two’s notice – or no notice at all – regarding critical application functionality. If you’re the developer for one application, that’s inconvenient and annoying at best, if you’re obligated to maintain a dozen or so applications it can be utterly traumatizing.

From the look of things, Facebook is trying to streamline the way applications communicate with users, and is adding some features specifically designed to improve the flow of turn-based gaming and make it easier for users to find games amid the sea of applications in the app directory.

Overall, these changes bring new features to the application developer’s toolbelt, but changes to the newsfeed and Stream API also mean that several of the ways you were previously able to send messages to a user’s newsfeed/stream (the one you just updated in April to comply with their last round of newsfeed changes) will no longer be supported.

To put a finer point on it, if you don’t feel like extending your current applications to take advantage of the new features, you will still need to update them to get them to function as they currently do. If you do not update your application to use the Stream API, your application will NO LONGER send any messages to your users’ stream. More on this down below.

So here’s a quick run-down of what to expect in the next few months – I’m covering the issues that will affect current applications first, and then we’ll get into the good stuff that talks about new features and functionality, so you know what you have to update to keep your existing functionality before worrying about extending it.

Big changes to the Stream, old API not supported, templates disappear, new format

As I mentioned above, if you don’t care enough (or your clients are not paying you enough) to update your current applications with the new functionality these updates bring, you’re still going to have to spend some time in the code just to get them not to break.

As of December 20, 2009, when Facebook.showFeedDialog and feed templates are discontinued, if your application hasn’t been updated to use Stream.publish, Facebook.streamPublish, or FB.Connect.streamPublish, your application will no longer be able to send newsfeed messages.

These Stream API functions will be the only way to send messages to users’ streams and they are available right now, so I encourage you to start making the switch now so you have plenty of time to test and troubleshoot any issues that come up.

But wait – there’s more!

Stream stories will be rendered slightly differently, with only one image and few lines of text. Only the first image and first few lines of text will be rendered by default. A user can choose to expose the rest of the images and text by clicking a “See More” link.

Only one action link will be rendered, and it must be 25 characters long or less. “Formatting”-style characters (like “|”, “[", "]“, and others) will not be rendered.

Key Policy Change: In order to encourage intentional behavior, you will no longer be able to automatically pop up a Feed form for a user unless that user has explicitly indicated that he or she wishes to share this information. According to Facebook, “a user should never be surprised by a Feed form”. You can continue to render Feed forms through FB.Connect.streamPublish and Facebook.streamPublish.

In the Stream Roadmap page, they outline when it is appropriate to open a feed form:

• When the user has clicked a button that says “Share this”.
• When a user has indicated via your user interface that they want to share. For example, if a user wrote a review within your application, and they checked a box that said “Share with friends” next to your “Publish this review” button. If you pre-checked a “Share with friends” box and they unchecked it, a Feed form should not pop up.

Perhaps more importantly, they also outline when you should NOT prompt the user with a feed form (and therefore NOT allow your user to post the action to their stream):

• When a user takes an action that is a normal part of using your application, for example, achieving a new high score.
• When you present a user with a result or new information, for example, completing a quiz.

These last two will directly impact how a LOT of Facebook apps and games currently function. While it will no doubt have an adverse impact on monthly active users for the applications that currently trigger stream entries on these actions, it is most likely a response of Facebook users complaining about the tremendous influx of stupid quizzes that have been flooding their newsfeeds for the past several months.

Hopefully, the other changes detailed below will offset the impact of apps not appearing in the stream as often and will more than compensate for any loss in virality.

Check out the Stream Roadmap page on the Facebook Developers site for full details.

No more Profile boxes or Boxes tab

That’s right. Poof. Going forward (in the short term) application tabs will be the only way applications can integrate into Profiles. We will be removing profile boxes, application info sections, and the Boxes tab. Facebook says they are exploring additional ways to enable developers to integrate into Profiles.

Please note that it does NOT appear that Facebook will be moving application content currently in Profile boxes or the Boxes tab into Profile tabs for you. From the Profile Roadmap page on the Facebook Developer’s Wiki:

Where will users’ profile boxes go?
Profile boxes will not exist in the near future. Application tabs will be the only way developers can integrate into the profile. If integrations on the profile are an important part of your application, we encourage you to focus development and transition to application tabs.

(Timing: Late 2009/Early 2010)

So it looks like if you don’t make this change to your application yourself and you rely on Profile boxes or Boxes tab boxes for your application to work, your app will effectively just disappear from user profiles when this change goes live.

Application tabs will shrink from 760 pixels wide (today) to 510 pixels 520 pixels wide to accommodate a slightly revised design. Boxes, info sections, and the Boxes tab will be removed in the near future. This kind of sucks, in my opinion, but I assume they’re doing it to accommodate a new design with either larger ads or some sort of right-rail navigation. Still, that’s a 250 240 pixel loss of real estate. Bummer.

Update as of Dec 15, 2009: According to a recently updated roadmap page, they will be shrinking the tabs down to 520 instead of 510. This, along with other profile changes, is set to roll out early 2010 by their last estimate.

Slight Application Canvas page layout change. In order to make it clearer to users when they are using an application created by a third party developer, Facebook is going to slightly modify how the top-navigation is rendered on canvas pages:

Looks like they’re still tinkering with ideas on the new layout of Application Canvas pages, but overall this shouldn’t impact most applications too much. They encourage developers to periodically check the Canvas Roadmap page for updated designs.

Now then – we’ve covered all of the stuff that impacts your current applications as they are now. Let’s look ahead to some of the great new functionality ahead.

Email

Developers will be able to ask users to share their primary email addresses. This is a big deal because it was previously verboten to collect a user’s email address without specifically asking them to type it into a form and submit it. (Timing: Nov 2009)

New Application Counter (woot!)

The application counter is one of my favorite improvements laid out in this roadmap and is just one of many steps Facebook is taking to position itself as a gaming platform.

You will have the opportunity to increment your count to indicate to a user that they should take an action in your application, for example, take their turn in a game, or see a comment from another user on content they created within that application.

The count can be incremented by your application, and when a user clicks through to the application, the count will be reset to zero.

As we continue to see an influx applications leveraging Facebook as a platform for RPG and turn-based gaming, it seems Facebook is getting behind the idea and beginning to provide specific features to encourage growth in this area. (Timing: November/December 2009)

Games/Applications Dashboards

In fact, apps that are games will be separated by category from apps that are… well, applications. Plus, users have access to two different Dashboards, one for Games and one for Applications.

The Games dashboard will have a number of features that encourage users to find games their friends and playing, and to stay active in games they’ve started, including:

Recent games: Facebook will prominently display games that a user has recently played, showing the application icon and application name. Clicking on a game will take the user to the game’s canvas page.

Game News: There will be a text field next to each game on the dashboard where developers can set Game News. This area is free form and targetable by user, e.g. “You are ranked 17th among your friends. Austin’s score is the next highest at 28,400. Can you beat him?” or, “Your pumpkins are wilting – water them soon!”

Your friends are playing: Facebook will display some of the games that your friends are playing along with information about relevant activities in the game.

According to Facebook, an app cannot appear in both the Games directory and the Applications directory, and they’ll be reviewing Games listed in the Games directory to make sure they belong there.

All non-game applications will have similar functionality (your recent applications, application news messages, and applications your friends are using) in the Application Dashboard.

Application Notifications

Facebook is removing application-to-user notifications and user-to-user notifications. Instead, they encourage you to use other channels to communicate directly with your users, and to enable them to communicate with each other about your application.

Communication between you and your users:

They encourage you to use Email (once the user has opted to share their email address with you) for things like product announcements, newsletters, or billing and transactional communication.

If you want to notify users about an action they should take with your application (like taking their turn in a game), incrementing the Application Counter will be a good way to notify them.

The application news in the Application Dashboard will be a great way to share a brief message with a user while they’re exploring the Dashboards. You’ll be able to target these on a per-user basis.

Communication between your users and their friends:

The stream is the most powerful way to enable users to share their experiences with all of their friends.

The new Share flow will give your users the ability to send messages directly to their friends’ Inboxes, with attachments predetermined by you. This will be the best way to encourage one-to-one and one-to-few messages between users, and is intended to replace requests.

Users will still be able to invite their friends to check out your application.

The estimated timing on this is approximately 30 days after you are able to start requesting a user’s email address. (Latest estimate: November/December 2009)

Open Graph API: Incredible potential, or not at all?

The info on Facebook’s Developer page for this is a little vague at best. They state:

The Open Graph API will allow any page on the Web to have all the features of a Facebook Page. Once implemented, developers can include a number of Facebook Widgets, like the Fan Box, or leverage any API, which enable the transformation of any Web page so it functions similar to a Facebook Page.

For example, AwesomeTees might decide that strategically they would like to locate their brand identity at www.awesometees.com. AwesomeTees will install the Fan Box widget, which will allow any Facebook user to “Become a Fan” of AwesomeTees, thereby establishing an official connection to AwesomeTees. The user will then have AwesomeTees listed in their list of connections on their profile as Pages are represented today.

This isn’t that different than how it currently works, so that’s not really news. What is interesting is this one line n their description, further down:

Additionally, any content that AwesomeTees publishes on AwesomeTees.com will show up in the stream on Facebook like it normally would.

Wait, say what? It sounds like they’re saying that news updates that would normally appear on a website, and would have to be manually cross-posted to a brand’s Facebook fan page will somehow automagically appear. I would have to assume they will require some sort of XML or JSON standardized format that website news announcements will have to be published in, but there’s little detail out on this just yet. This feature is a ways off though, with initial versions not expected until the second quarter of 2010.

And finally – Verification goes away as a brand, becomes universal for all apps

According to the Principles, Policies and Verification roadmap, Facebook is doing away with paid Verification and is extending it out to all applications.

On December 1st, 2009 we’ll retire the Verification brand, as we scale what was a voluntary program into a universal requirement. There is no longer a submission process or fee, and there won’t be distribution boosts as the product will move towards more intentional user sharing. Starting today, we will suspend the processing of Verification submissions. All apps must meet Verification Checklist expectations and will be subject to review at any time.

So this means while you no longer have to shell out big bucks for your app to be verified, it also means that Facebook will probably be more aggressive about making sure all developer applications do meet their verification criteria, and will yank your app with ir without notice if it feels like your app isn’t up to snuff.

Full Timeline

To give you a little more perspective, here is the timeline of the upcoming Platform changes, based on Facebook’s Developer Roadmap and originally compiled by InsideFacebook.Com:

Late October 2009

• Simplified policies posted, verification program ended, and “extending verification standards to all applications”
• Platform Live Status tool launching, which will show “updates on platform stability and load”

November 2009

• New email permission API (developers can ask users to share their email address)
• Access point to invites will be moved “to either a filter in Inbox or surfaced in the Application and Games Dashboards”
• User-to-user Inbox APIs will be launched
• Stream story formatting changes (1 image shown by default, few lines of text, 1 action link)
• New “add bookmark” button

November/December 2009

• Notifications API (both app-to-user and user-to-user) will be removed (note: Facebook says this will happen “30 days after email permission is available”)
• Feed forms cannot be popped open without “explicit user intent” (note: this is a new Facebook policy)
• Application bookmarks moving from the bottom menu bar to the left side of the home page
• Counter API launching (counts can appear on home page application bookmarks)
• Applications and Games dashboards launching
• New application branding on canvas pages launching

December 2009

• All stream publishing APIs beside Stream.publish, Facebook.streamPublish, and FB.Connect.streamPublish will no longer be supported (December 20)
• Revamped developer site launching

Late 2009 / Early 2010

• Requests API will be removed (note: Facebook says this will happen “30 days after launching new Inbox sharing”
• Profile boxes will be removed (application tabs will be the only way to integrate into the profile page at that point)
• Improved analytics and APIs launching

Early 2010

• Open Graph API launching

Conclusion

So it feels like Facebook might finally, really be getting their shit together. This is arguably one of the biggest rounds of changes to the platform that we’ve seen in quite some time, and for the first time, they’re actually giving developers a head’s up and being very transparent about timing and impact.

All in all, the vast majority of these changes are great news for application developers. We’re getting tons of new features, new integration points and opportunities for viral engagement. The trade-off in what we’re losing seems to be well worth it, if all of these improvements come to fruition.

Also check out:

Something like this would do the trick:

[source='php']$template_bundle_id = 123456789;
$tokens = array();

try {
$facebook->api_client->feed_publishUserAction($template_bundle_id, json_encode($tokens), $array_of_friends_id, ”);
} catch(Exception $e) {
// error trapping goes here
}[/source]

The code above would insert a one-line story into the user’s profile wall (as seen below), and into their friends’ /home.php newsfeed.

While the profile item is nice, the truly viral aspects come from the friends’ newsfeed items. Most people don’t spend a lot of time on profile pages – they rely on their /home.php page for the overview of what their friends are doing by way of posted items, status updates and application messaging.

With the latest change in the Facebook API, suddenly feeds stopped appearing in the the newly redesigned friends’ newsfeed, now referred to as the “stream”. They were still being pushed to the user’s profile, but as we already mentioned, the usefulness of putting feed items there is somewhat limited.

With these new updates, publishUserAction no longer publishes anything to the users’ friends’ stream, and now only publishes one-line stories to the user’s own profile wall.

Enter Feed Forms and Facebook.showFeedDialog

Using showFeedDialog, the user is prompted whether or not they want to publish the action to their stream. While this does mean changing some application code, switching oer to the new feed system is actually very easy for the most part. (I cannot speak for how one would do it in a Flash-based application, as I haven’t had to tackle that yet.)

Assuming you’ve already created your feed template bundle in the feed template console, you’d do something like this:

[source='php']$feed_template = “{‘filmname’:'”.$film_name.”‘, ‘images’:[{'src':'".$film_cover."', 'href':'http://apps.facebook.com/snagfilms'}]}”;

echo ‘‘;[/source]

As long as you have a short-story version in your feed template, that’s pretty much all you have to do. If your previous feed templates only used one-line stories, you WILL have to create new feed template bundles that use short stories, as one-line stories are NEVER published to the stream. Otherwise, just stick that line of PHP/JavaScript into your form handler (or whatever script completes the action the user is initiating) in your application and you’re back in business.

To further complicate things, Facebook just announced the beta launch of their Open Stream API using Stream.publish, which looks like it might offer a simpler-but-different method by which you can publish feeds. Fortunately for this article – and for the time being, my sanity – the Open Stream API is in beta, and only application developers can publish to their stream from their apps. As more information is available about Stream.publish, I’ll try to keep you updated.

Also check out:

I don’t know if this is a bug, or just undocumented, but I am unable to get the FBID of a user (even one who has allowed and interacted with the app) if the application is on its own tab in a fan page. I can get it on the boxes tab (by way of a workaround below) or on its own canvas page, but nothing works for the application tab.

Part of one of the recent changes to the platform was that you could no longer use require_login() from a tab (boxes or application). You can still use it on the application’s canvas page, but when you try to use require_login() in a tab, you’ll get an error that tells you you cannot redirect, something like:

fb:redirect: redirect forbidden by flavor TabFBMLFlavor

A suggestion on the developer forums suggests using:
[source='php']$is_tab = isset($_POST['fb_sig_in_profile_tab']);
if( !$is_tab ) $user = $fb->require_login();[/source]

This basically checks to see if the application is being accessed via a tab (versus the canvas page or profile box). If it is being accessed via a tab, use the $_POST['fb_sig_in_profile_tab'], and if not, go ahead with require_login() as usual.

The problem is, while this works on profile tabs, it does NOT work on fan page tabs. When you use $_POST['fb_sig_in_profile_tab'] in an application on a fan page tab (or any of the other non-require_login() methods of getting a user’s ID) you end up with the ID of the fan page, NOT the viewing user.

This is a major problem for me, as many of the applications I have to build are not meant for addition to the directory, but are instead meant to be used only on a corporation’s fan page. The inability to access the user’s FBID severely limits what that application can do. In fact, it more often than not renders it completely useless.

To work around this, you can use the following to get the FBID of a user when your application is appearing in the Boxes tab:

[source='php']function get_user() {
global $facebook;
global $authorized;
$authorized=true;

// this will fail if user hasn’t authorized:
try { return $facebook->api_client->users_getLoggedInUser(); }

$authorized=false;
return $facebook->get_canvas_user()
}[/source]

and then setting the $user FBID variable with:

[source='php']$user = get_user();[/source]

However, even this does not work on applications appear in their own tab on a fan page.

I downloaded Facebook’s sample application, “Smiley”, to attempt to see how they did it. I’m certainly not new to Facebook application development, but I figured using their own code would help me see how they handle this particular issue.

I, of course, made the gross assumption that their own sample application would be updated with the most recent API calls and best practices. Not only is the Smiley’s app not up to date with the most recent ApI changes, it is flat-out *broken*. Thanks to several files that are completely *missing*, Smiley’s doesn’t even run. The very first line of the index.php makes an include call to a file called constants.php that DOES NOT EXIST. Well done, as usual, Facebook. The new API changes have been out for weeks now – there is just no excuse foer the ongoing broken samples and stubbed or missing documentation.

I have spoken to Facebook and they insist that this was a policy decision to prevent applications from spamming users – however there are a few problems with this explanation:

1. The FB user’s decide what applications can message them, email them, etc – and by blocking an app, they never hear from them again anyway. Application behavior is irrelevant.
2. If they were concerned with spamming, why does this behavior only emerge when the app is on its own tab? Its okay to spam from Boxes and canvas then?
3. If the user has allowed the application, they have voluntarily given the app their information.
4. Disallowing applications from accessing the FBID of users who have allowed the application renders many applications completely useless. They’re basically statis HTML pages, and it seems unlikely that Facebook would so detrimentally cripple such an important part of the platform.

I suspect that I’m receiving inaccurate information from Facebook regarding this behavior, and I suspect this may be a bug. If this behavior was actually implemented to prevent applications from getting the FBID of users who have allowed it, the decision would have applied to Boxes as well.

I’m still going back and forth with Facebook on this, but I wanted to post it here in case other Facebook application developers are having the same trouble. When I discover the fix, I’ll post a followup here.

Also check out:

These issues are not deal-breakers, and most restrictions can be easily worked around – but it took me some digging to find the answers, so I figured I’d post them here in case any of you are running into the same challenges.

These are not criticisms of Mosso - merely a head’s up on Mosso-specific configurations that may be confusing for folks in the process of switching. Workarounds for all of the challenges are posted here.

I’ll keep adding to this list – and I invite you to add your own in the comments. I’m still migrating sites, although I have the bulk of the heavy-duty ones moved already. (I was moving around 170 sites, so I took my time moving things so I could adequately troubleshoot and QA.)

No SSH

This isn’t news – I mentioned it my previous article, and they make no secret about not currently offering SSH (although it sounds like they’re working on possibly making it available.) They do offer SSHFs right now, and surprisingly, I have not run into any situations where not having ssh has been terribly prohibitive.

If you have large databases to import when migrating a site, the process is very easy. Export your current database, upload it to Mosso, and jump onto Live Chat from your admin panel. Just give the tech on duty the location of your sql dump, and your database credentials (the chat is SSL-encrypted), and they’ll import it for you. I’ve had to do this at least 10 times now, and each time, the tech has taken care of the import immediately with no wait time at all.

Quota on Mail Accounts

The default quota on email is 1GB per domain. While this is more than enough for many people, I have some IMAP accounts with tens of thousands of messages. Good news: all you have to do is hop onto support chat and they will increase your mailbox quota to whatever you wish.

Cron Jobs Require Output Email

If you don’t need any cron jobs, this one won’t affect you in the least – but if you do, this can be a bit of a pain. When you set up a cron job through the admin, they require an email as the destination for an output message, even if your cron doesn’t have any output upon success. No big deal if your cron runs daily or weekly, but I have a few that run every 5 minutes – you can imagine how quickly I’d fill up my mailbox at that rate.

The solution here is pretty simple – create a specific email account for cron job output, like <crondump AT yourdomain DOT com>. Then, in your webmail account, set up a filter that automagically deletes them, so you don’t eat up server space.

No Email Migration Scripts

In general, this isn’t a big deal. If you use IMAP, the easiest – although not particularly elegant – solution is to have your old server account and your Mosso account set up in the same email program, and copy the messages from old to new.

I’m not going to lie – for someone like me, with hundreds of thousands of messages to move, this is a bit of a pain in the ass – but you only have to do it when you first set things up, so it’s really not that bad. Set Thunderbird up to move the messages right before you go to bed, and all will be right with the world when you wake up in the morning.

If you’re using POP3, the email messages are stored on your computer, so there’s no need to really do anything special. I recommend having both POP3 accounts (old and new) set up for the 48 hours after you flip DNS, just in case some sender’s ISPs are a little slow to clear their DNS cache, but after the 48 hours propagation time is up, you should be able to safely delete the old POP3 account.

30-Second Script Timeout

This shouldn’t come up in most situations, but if you have a script that takes longer than 30 seconds to finish executing, the load-balancer will return a “No suitable notes available” error. If Mosso is having issues, you’ll also see this same error, but your own scripts can trigger it if they are taking too long to finish. The solution that Mosso suggests (even in annoyingly inappropriate applications) is to employ a “loading” bar that keeps the connection alive with the server, so the load-balancer doesn’t give up on the request. Obviously, this is not always going to be an adequate solution, but shorter script timeout limits are something to keep in mind when deciding if Mosso will be a good fit.

Generally speaking, your scripts probably shouldn’t be taking over 30 seconds to execute, unless they are specifically designed to do some seriously heavy-lifting – in which case they are probably home-grown scripts and could be modified with a loading bar or similar device to work around the limitation.

Unconfirmed: Issues with Facebook Applications That Use IFRAME

I don’t know whether or not this truly is an issue, since all of my Facebook applications are written in FBML, but one user on the Mosso forums has reported an issue retaining the Facebook API session on Mosso’s servers. I suggested appending the fb_session code to the IFRAME src, which he says he did, but I cannot confirm whether he did, or whether something else is wrong with his app. This is just something to keep in mind, and perhaps something to test during your trial month if this is important to you.

Tip: Dead-End Bandwidth-Eating Bots

While Mosso gives you a considerable amount of bandwidth, and their rates if you go over are reasonable, you may wish to consider setting up your .htaccess file to dead-end known bad bots and spiders. From an article on Javascript Kit:

The definition of a “bad bot” varies depending on who you ask, but most would agree they are the spiders that do a lot more harm than good on your site (ie: an email harvester). A site ripper on the other hand are offline browsing programs that a surfer may unleash on your site to crawl and download every one of its pages for offline viewing. In both cases, both your site’s bandwidth and resource usage are jacked up as a result, sometimes to the point of crashing your server. Bad bots typically ignore the wishes of your robots.txt file, so you’ll want to ban them using means such as .htaccess. The trick is to identify a bad bot.

Their handy article gives you a copy and paste solution to add to your .htaccess file that will return a 500 error to the known bots, spiders and site-rippers in the list.

Ready to Switch?

If you’re interested in giving Mosso a shot, they offer a 30 day risk-free trial (money back guarantee) – and if you use the promotional code REF-SNIPE, you’ll get a $25 rebate/refund on your first month’s bill. So basically, you get two months for free to give it a shot. If you’re still not sure or you have more questions, follow @mosso on twitter. They’re very responsive, and often quite funny.

Already Using Mosso?

Are you using Mosso already? What do you think about it so far? And what quirks have you encountered?

Also check out:

This is, of course, a BFD. As I mentioned in section one, while I was not going to assume that SocialCash was knowingly running any kind of malware, the mere appearance of impropriety can do irreparable damage to the reputation of both an application and the developers associated with it.

The back and forth on this is a little lengthy, but I thought it might be valuable for you to to see how this played out. The short version – after running some tests, they feel that the malware alerts are false alarms triggered by overly aggressive heuristic detection algorithms. They then went on to suggest that I might want to find a new ad network.

*blink*

So here’s the long version, starting from the very beginning…

Email from app user: Feb 1, 2009 11:05AM

I like the app or at least a lot of my friends do.

However, in the last two days my anti-virus has been flagging up a malicious link on your start page. It appears to be a script that, if allowed to run, will capture key strokes and other info. I re-checked using Norton anti-virus (I use Avira anti-virus normally) and it also flagged the same script.

Avira warns me that ” functionalities include – but are not limited to – downloading trojans, link to other infected pages, spy the user or spoof the content of a banking site. ”

Would you please check the page and remove this?

I immediately replied back to the user, asking if they could possibly provide any more information on what antivirus they’re running, whether it was the top ad or the bottom ad that triggered it (since I use SocialCash on top, SocialMedia on the bottom, and I needed to know whose ass to chew off), etc. They quickly replied:

Reply from app user: Feb 1, 2009 – 12:59PM

It happened in two different apps on FB who have the same ad server as you have at the top of your page – socialcash I think?

Okay, so it looked like SocialCash was potentially the issue. I sent an email to SocialCash at 2:03PM that same day, just moments after receiving the application user’s reply:

Email from me to SocialCash:  Feb 1, 2009 – 2:03PM

I received this notification from one of our users today. After discussing this with him further, he says it was happening on two other apps that were being served by SocialCash. When I removed the SocialCash ad code and stuck only with SocialMedia, the alert went away.

This is absolutely unacceptable. I don’t know whether this was a legitimate threat or not, but even if it was erroneously triggering this warning, this type of thing could do serious damage to the reputation of this application and any other applications associated with my name.

I would like an explanation of what happened here.

Maybe I came off a little too strong – I don’t think so. Malware alerts are, as I mentioned, a BFD, and to find out about this from a user sucks.

SocialCash replied, over 24 hours later – an admittedly longer response time than I would have hoped for in a situation where users think my application has a virus.

Email from SocialCash to me: Feb 2, 2009 – 4:53PM

We would never serve intentionally serve anything infectious or damaging, so this is definitely news to us.  What ad was it?  I see the users information below, so we will sync up with our tech side to see what we can find out.  I’m sorry that this has happened.  The more information you’re able to pass on, the quicker we can identify the issue.

I replied back that I was asking for more information from the users:

Email from me to SocialCash: Feb 2, 2009 – 4:57PM

I wish I knew which ad it was – I’d have sent a screenshot and explanation. Problem is, I naturally had to yank the SocialCash ads, lest my app get a reputation for distributing malware – so unless the reporting party happens to remember what the ads is, the only way for me to reproduce it is to turn those ads back on, which I don’t want to do until the situation is resolved.  I replied to him the day he emailed me [yesterday], asking if he could describe the ad, etc – but he hasn’t replied yet.

Days passed with no reply from SocialCash. I was hoping the issue was perhaps transient, so I decided to enable SocialCash ads again. Shortly afterwards, I received anotger malware complaint, this time from a totally different user. I sent another email to SocialCash, since I hadn’t heard from them.

Email from me to SocialCash: Feb 5, 2009 – 4:01PM

Any progress on this? I received another complaint today. We are going to lose users if this situation doesn’t get resolved quickly.

“everytime i click on to this add on my antivirus avira throws up a malware issue at least twice per page why is this are you infected???”

At this point, I reached out to some Windows users on Twitter. I created one page with only a SocialCash ad, and one page with only a SocialMedia ad, that way I could be 100% positive that SocialCash was the issue. I had 5 friends using Windows refresh each page upwards of 60 times, and their antivirus never triggered an alert. While I was relieved to know that most windows users were apparently not seeing this alert, it naturally made troubleshooting much harder.

Luckily, both of the reporting users had gotten back to me at this point, and both reported that the alert only popped up on the SocialCash page. SocialMedia was off the hook for sure. After doing a little more digging, I sent SocialCash an update with what I had found:

Email from me to SocialCash: Feb 5, 2009 – 5:33PM

It looks like both people who reported a problem were running Mozilla/5.0 (Windows; Windows NT 6.0;rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 – one with US-english as default language and one with en-GB as default language. Both reporting the problem with Avira, and one confirmed the same alert with Norton.

The next day, one of the Facebook application users was kind enough to email me back with more specifics and a screenshot of the alert they’re receiving. I forwarded this on to SocialCash:

Email from me to SocialCash: Feb 6, 2009 – 1:38PM

Here is more information – the best so far. Steven says its occurring on every page load of the SocialCash test page, and sometimes pops up several alerts on a single page load. See the attached screenshot of the virus alert.

Perhaps you should get in touch with Avira?

SocialCash replied later that day with their conclusion:

Email from SocialCash to me: Feb 6, 4:38PM

We’ve done some testing, and have confirmed that there is no malware inside of our advertisements.  Please know that no other users or publishers have reported positive hits with antivirus software.

The alert is caused by Javascript compression being flagged as potentially malicious by heuristic detection algorithms.  It’s a false positive that happens only when users enable heuristic detection in their anti-virus software.  There are many frequently used script libraries available on the web that cause a similar false alerts to be thrown.  We believe that the benefit of a much smaller download, and hence faster ad rendering and better performance, outweighs the smaller number of tech-savvy users who will surf the web with these controls enabled.  Since we’ve confirmed that our advertisements do not contain malware, and because that this is the first report we’ve received (amongst billions of impressions), we feel that this is the right approach to take to provide maximum value to the largest population of our users.

Given that you have sophisticated users who are raising these concerns to you, the last thing we want is for your use of SocialCash to impact your user base.  We don’t think there is a way to remove this behaviour from the subset of your users who see these errors.  This all being said, it may make sense for you to discontinue the use of our advertisements if you think this will have a negative impact on your overall user population.  We obviously take this type of feedback very seriously, and wanted to thank you for bringing this issue to our attention.

Please let us know if you would like any further information, and let us know your if you intend to continue to use our product.

This is the first report they have received, among billions of impressions? It seems statistically impossible that my application has received two reports of this problem, with only 100k monthly active users. Out of their billions of impresions, my puny 100k monthly active users make up only a tiny fraction of those impressions, so what are the the odds that not one but two of my users brought up a problem that no one else brought up.

The application is not one that appeals to particularly sophisticated people. It’s an absurdly simple application that lets people blow kises to each other – not exactly rocket surgery. The two users who reported it were clearly more savvy than an average user, which is probably why they actually contacted me about it, rather than freaking out and closing their browser window, convinced my application would steal their identity, email their grandmother all of their porn, make their ipod play only Jethro Tull and make their TV record “Gigli”. (Thanks, Weird Al!)

Conclusion

I’m glad SocialCash claims to take these reports very seriously, but deciding their advertisment loading time is more important than the reputation of my application is not acceptable to me. “We take this sort of thing very seriously, and we appreciate you reporting it to us so we could completely ignore it and keep doing what we’re doing.”

It would be different if something in their ad code was causing a weird display issue for users of certain browsers and operating systems. But this isn’t some flaky display quirk. This isn’t something harmless that no one will notice. People visiting my application think I am trying to do them harm. Even if the percentage of people experiencing this issue is very small, that message is not one I am willing to live with.

Maybe I’m being too hard on SocialCash – but I take my reputation seriously. It’s a shame they don’t. The impression I get from my email exchange is that I am a pain in the ass client to them, and not worth the hassle to them for the paltry 100k mau I bring to the table. At this point, they don’t seem to want my business, and I care more about my reputation than the $15 a day I make them from. So I’ll be exploring one of the alternate ad networks, replacing SocialCash with whichever seems to be the best. Stay tuned!

Also check out:

If you wandered in from Google and haven’t yet read the first article in the series, I strongly recommend it. There are some significant concerns discussed there that you may want to be aware of before implementing ads on your Facebook application.

A note on ad-blockers

For some reason, perhaps the url of the ad network sites themselves, the admin/reporting areas of SocialMedia (and Cubics, although I didn’t implement their ads) appear broken if you’re using AdBlock Pro for Firefox. The header images, and even some of your reporting tools, are being interpreted as advertisements, so they won’t display properly. The easiest way to deal with this is just to disable AdBlock Pro for the network domains giving you trouble.

Disable AdBlock Pro per site

A Note on AdBlockers & Your Reporting Console

Of SocialCash and SocialMedia, SocialCash definitely has a better reporting console – at least for my purposes here, since they let you see a daily performance breakdown  at a glance, where SocialMedia only gives you a graph view overview, and you have to select specific dates from a single dropdown menu.

Again, if you’re using AdBlock Pro, the flash performance graph may not appear for you until you allow ads on the SocialMedia domain.

Day-by-day reporting may not be important to you, and I suspect it will be less important to me as time goes on and I have more overall data.

The Revenue Model

Neither SocialCash nor SocialMedia do a stellar job of explaining exactly what your ad revenue is based (per impressions, per click, etc.), however I sent an email to SocialCash, asking about the rather dramatic fluctuation in revenue from day to say. They replied back:

Many of our advertisers take several days to report sales. This means that for the first few we days, we don’t know how much your app is earning. The flip side to this lag is that if you stop running ads with us, you will continue to earn money as sales are reported to us.

Reliable data is only reached looking across a minimum number of impressions rather than days. This is typically over 150,000 impressions, but also depends largely on the placement of the ad, how the ads fit in the flow of your application, and your audience’s general engagement patterns. The same ad can yield widely varying click through rates and conversions based on these factors. We’re currently putting together some knowledge documents for developers on this front, so let us know if you’d like any guidance on these areas.

This simply means that it will take a couple of days to see a reliable eCPM reading. You’ll find this to be the case with all other performance networks as well. (This is not true with “brand” networks that pay a fixed amount for every impression.)

This leads me to believe that the revenue model is not based on impressions or even click-throughs, but instead based on user buy-in. The user adds the advertised application, subscribes to the advertiser’s service, etc – and you earn money. It’s been my experience that although you end up with fewer revenue points (since you’re requiring the user to buy-in, not just click), however the payoff is higher than a simple click-through based model.

Basically, since they’ve actually made a sale, they’ll pay higher per buy-in than they would for a simple click-through, which gives them no guarantee of actual revenue for their money spent.

I cannot find the model on the SocialMedia website, however I will confirm how their ad revenue is determined over the next few days and update this section. I suspect it is a similar model to SocialCash, based on the fluctuations in earnings.

Payouts

Both SocialCash and SocialMedia offer PayPal and a mailed check as a way to pay you your earnings.

According to an email reply from SocialCash, payouts happen mid-month and end-of-month, give or take a day or two. Payments are allegedly made automatically, once you have earned over $50. I say allegedly only because I haven’t been with them long enough to say for sure – guess I’ll find out this week.)

For SocialMedia, developers have the option of being paid on a weekly basis though PayPal or by check. This process can be automated. All payment requests must be made by 10pm Wednesday night to be paid out that coming Friday. All requests made after Weds 10pm will be paid out Friday of the next week. The minimum PayPal payout amount is $25.

My Results So Far

I set up ads on my Facebook application on January 5, and as of end of day February 1 – just over three weeks – I have made $404.97 – 206.26 from SocialCash, and $198.71 from SocialMedia. While these numbers seem close, there are two details that should be noted: I started with SocialMedia a few days after I started with SocialCash – and the SocialCash ad has the top banner position, while the SocialMedia ad is a footer banner.

Three weeks isn’t long enough to make any decisions written in stone, however the fact that SocialMedia is basically keeping pace with SocialCash, given the fact it had a later start and has an arguably much less prominent position on the page. Given the fact that their ads seem (slightly) less deceptive – and I haven’t had anyone reporting them for virus alerts on the application as I have with SocialCash (see previous article), I am strongly favoring SocialMedia over SocialCash at the moment.

At the beginning of January, when I first added advertisements, I had approximately 54k monthly active users. As of February 1, I have 103k monthly active users. I was expecting a sharp drop in engagement once advertisements were implemented, figuring a lot of people would opt to use a similar application that didn’t have advertisements – however that is clearly not the case.

Here are my Facebook Insights report for the application from the beginning of the application launch:

Monthly Stats Graph for Facebook Application from Dec

Notice there is no significant drop in user engagement during the week of January 6, just after advertisements were added.

And here are the stats starting when the advertisements were added:

Facebook Stats starting from January 7

One would think that the ad revenue graphs would be at least somewhat similar to the engagement graph, however I have found that this isn’t the case at all.

Here are my stats from SocialCash, by week:

SocialCash stats by week

At the week level, you can’t see exactly how volatile the ups and downs are, so here are the past two weeks:

SocialCash by week

SocialCash by week

Because the reporting options for SocialMedia are not as robust, I can’t provide the same overviews as easily, but this is my performance over time for SocialMedia.

SocialMedia stats since inception

Conclusion

This experiment continues – three weeks is definitely not long enough to speak definitively about advertisements on Facebook, which ad network is the right fit, and which one will give you the most bang for your application buck. So far, I’m leaning towards SocialMedia, for the reasons detailed in the first article and this one – and the fact that they seem to be able to hold their own with regard to revenue is a big plus.

I’ll keep you posted on future progress and statistics – and SocialCash got back to me regarding the virus alert some users were reporting – check out part three in the series to learn more about it, and why I won’t be using SocialCash anymore.

Also check out:

This article series replaces my previous article, Advertising on Facebook – An Experiment, published in January. The information provided in the previous article will be provided in this series, but in a more organized, informative manner. That article is deprecated.

Social Media Advertising Networks

There are a handful of advertising networks that seem to be the top options available:

• SocialCash
• SocialMedia
• RockYou
• Cubics
• Offerpal (points-based offers)
• AdParlor

As of now, I have only experimented with SocialCash and SocialMedia, although I may expand the experiment to include others soon. SocialCash and SocialMedia seem to be the most popular choices of the above four, and SocialMedia has just raised an additional $6million in venture capital after coming out strong in 2008.

According to an article in Venture Beat, Social Media says it brought in between $15 and $20 million in revenue last year, mainly due to successful sales in the last six months.

A note about the ads

The types of ads offered by both SocialCash and SocialMedia tend to be what I consider a little deceptive. By that I mean many of them are engineered specifically to look like part of the application, and often use the application user’s name, photo and friend’s photos in the ad itself. SocialCash seems to be more guilty of this than SocialMedia, but both rely on similar tactics.

Ad by SocialCash

Some of the images in the above ad are profile photos from my friends Facebook profiles. This ad links to a mysterious Facebook app called Jamster Mobile Screensaver. I have no idea if this application is legit, and am not willing to sign-up and give it my mobile number to find out, but it feels fishy to me. Sort of reminds me of those “text L-O-S-E-R to shortcode 666666 for texts from hot girls” type of thing you see on TV at oh-my-god-o’clock in the morning.

Another sample ad by SocialCash

And in this ad, also by SocialCash, the ad pulls in my profile photo and my name. The advertiser site you get to when you click on seems to be some sort of Scrabble-type game, which requires the user to download an Active-X component to play. While I have no justified reason to believe this is suspect, an ad linking to a site that requires a download rubs me the wrong way, big time.

Another ad-type I have seen from SocialCash is a similar-style ad that leads you to a “quiz” website. At the end of the “quiz”, the website asks for your mobile phone number (without really explaining why), and in small text at the bottom, informs the user that they will be billed $19.95 per month for this service – when they are not even particularly clear on what the service actually is.

Still another ad style I have seen from them is one that leads you to a website that when you try to leave, a javascript alertbox pops up informing the user that they are going to miss out if they close the window, and sometimes even spawns a new popup window after the user has confirmed they want the window to close. I have a real problem with these kinds of ads. They feel a lot like the malware sites that try to convince (windows) users that their computer is infected, and they have to download this software to clean it. The software is, of course, malware and will subject the installer to a variety of ills from keylogging to unpromoted ads.

I am absolutely not implying that the advertisers with SocialCash are promoting malware - just making the comparison in how that type of ad feels to me, someone who’s been around the Internet block for 15 years. That said, I received a troubling message from one of my application users today, which I will address later in this article.

In the SocialMedia ad below, you can see they’re not pulling in as many user details, but a less savvy application user might not recognize this as an ad, and may actually think that this “Valentines Cards” thing is somehow related to the application itself. On the possible upside, the destination website, MyFunCards.Com, does not seem to be a paid service and seems harmless enough, although I certainly cannot speak to their SPAM policies or what they do with people’s email addresses when you send or receive a card from them.

Ad by SocialMedia

The Conundrum

My own personal feelings are that these types of ads are not entirely ethical. The problem is, they work – and their somewhat sneaky tactics are exactly why they work. Facebook users suffer from banner-blindness as much as any other web user, so your standard, run-of-the-mill banner ads just won’t get as high of a click-through rate. So before you begin, you need to ask yourself whether or not you can deal with your name being associated with advertisements that may not reflect your own ethics.

Ads that trick a user into clicking on them by making it seem like its part of the application functionality (“you have 1 new message!”) are deceptive. Offers that throw a javascript window alertbox when a user tries to close the advertisement page, asking if they are really sure they want to leave and miss out on xyz implements the same tactics that malware sites use. It just doesn’t feel right to me.

What SocialCash Had to Say

When I first signed up in January, I emailed SocialCash, expressing some concern over the types of ads being run. They replied with the following via email (in two separate emails, condensed for clarity):

Types of ads/offers.  One quick point on terminology:  “Ads” are the banners themselves; “offers” are what the user sees after clicking on an ad.  Your question seems to be on the offers.  We’ve been in the online marketing business since 2000 (on Facebook since early 2007) and advertisers range from large brands vying for app installs to tourism companies advertising discounted trips to Paris.   We display ads over 100+ countries.  In this range of advertisers is also mobile content, which provides users scheduled content on their mobile phone for a monthly fee.   This is a service many users enjoy worldwide[...]

[...]We’re in the process of upgrading our ads and you’ll see a change-over in the near term.  And like we said before, we have a wide mix of both ads and offers.  To fully understand the available options with advertising, we’d encourage you to do what most developers do and try multiple ad networks at once.  This is really the best way to learn the ins and outs of optimizing and monetization.  That experience also enables a great deal of choice for you on the whos, whats, wheres, etc. of advertisements within your applications.   There are tons of great resources out there!

An Additional Concern

As I mentioned earlier in the article, I received a troubling message from one of my application users today. I have emailed SocialCash about this, and expect to hear back from them tomorrow, but this situation was drastic enough for me to pull their ads from my application today. This is the message I received:

I like the app or at least a lot of my friends do.

However, in the last two days my anti-virus has been flagging up a malicious link on your start page. It appears to be a script that, if allowed to run, will capture key strokes and other info. I re-checked using Norton anti-virus (I use Avira anti-virus normally) and it also flagged the same script.

Avira warns me that ” functionalities include – but are not limited to – downloading trojans, link to other infected pages, spy the user or spoof the content of a banking site.

I replied back to this user immediately (for obvious reasons), and they replied again:

It happened in two different apps on FB who have the same ad server as you have at the top of your page – socialcash I think?

This, my friends, is a deal-breaker. If they do not have an adequate explanation for what happened, I will no longer be using SocialCash. Even if the advertiser/advertisement is not actually malware and was erroneously labeled as such, it is their responsibility to make sure something like this NEVER happens. With all the actual virus activity on Facebook, sometimes like this can ruin the reputation of an application – and once you lose the user’s trust, you WILL NOT GET IT BACK.

UPDATE: For more information on this issue, click here to read Part Three.

In the next article in the series, I show you my performance stats. Click here to go to Part Two!

Also check out: