RAAK is proud to announce our latest project. We helped conceive and then built a creative platform (Guided Collective) that we think might just be a major sign post on the road of change creative agencies are hurtling along.

Ever since Unilever’s crowdsourced Peperami campaign, debates have raged (Brand Republic) about the future of crowdsourcing and its potential to encroach on the domain of agencies. On the other side of the pond, people like Bud Cadell have even wondered if the future needs an agency at all (Whatconsumesme).

Guided Collective is a hybrid between a traditional agency and a crowdsourcing platform. It is driven by a collective of top freelance creatives from all kinds of disciplines that use an online collaboration platform to pitch and collaborate on creative briefs.

The platform is invite-only, so we can't show what really is under the hood of Guided. But included in this post are some screengrabs that we made with dummy briefs & content

(more…)

In my previous post on Facebook Extended Permissions I focused on the positive aspect of this much-debated (and much-hated) aspect of working with Facebook’s API’s. After all, they are there to make things clear and secure, for both the developer and the user. The road to security in Facebookland is not paved with yellow bricks all the way, though, especially not for the user.

The offline_access extended permission

This permission allows an application offline access to all of the data the user has given the application permission to read. Why is this a problem? When the user clicked on Allow in the connection dialog, they have already allowed the application access to the information, right?

Right.

However, without the offline_access permission, the application is not allowed to store the user’s information, and the user’s information can only be used while the user is using the application (ie while the user is online). Which makes the offline_access permission more of a meta permission.

The offline_access permission gives an application the ability to request information on the user’s behalf, while the user is offline. Allowing this permission sounds serious, Orwellian even.

For developers this might be bad news. It is very likely that fewer users will click Allow when seeing the offline_access permission in the list of permissions than otherwise.

But what is the real world implication of this permission?

Imagine a developer with malicious intent gets the offline_access permission from a user. Most users do not check their installed applications very often, if ever (especially since it’s so well hidden within the Facebook settings).

The user then (for instance) gets spammed to bits by the malicious developer (or clients of the malicious developer). Upset user decides to change their email address. It’s a big hassle, but worth it, if the user stops getting spam. The user also updates their email address on Facebook, to receive Facebook notifications in their new inbox sans spam, and voila, the malicious developer gets their new email address, because the user has granted them offline access. In fact, the malicious developer can, in stead of 1995 style email address lists, sell self-updating email address lists to their clients for ten times the price. Pretty nifty, huh?

The power of Facebook’s Newsfeed to spread information is legendary. The good news for users (a bad news for unscrupulous marketeers) is that while a facebook app with the offline_access permission can query as much information about you as it wants to, whenever it wants to, it can not post to your Profile on your behalf, while you’re offline. Your friends won’t receive any updates in their feeds, unless you were part of the process.

Next week: Facebook Like Button – The real bad one