Effective basically immediately, our team is moving over to become the in-house crew responsible for building all of Zerofootprint's products, including the Kids and Youth Calculator, the One Minute Calculators, the Facebook Calculator, and the Personal Carbon Manager. We have a few great projects to wrap up before everyone trades in their old Radiant Core punch cards for their shiny new Zerofootprint ones, so keep an eye out for a few more announcements on this very blog.

Longer term, we're happy to announce that we've been working really hard to find a home for all of our great clients and we're delighted that The Jonah Group will be taking over from us on some of our accounts. We're still working out some of the specifics, but they're an excellent shop and we're really delighted that we can end our professional services practice on such a high note. We've spoken to all of our clients and they've been very congratulatory and supportive, which just goes to show that we really did have the best customers a firm could ask for.

For all of you Foundation users out there, we're also thrilled to announce that we'll be releasing the full product under and Open Source license, with the Jonah Group picking up the bulk of the ongoing maintenance and development. We're still weighing a few Open Source license options (though we're leaning toward the Mozilla Public License), so if you have a favourite please leave a comment below.

This is one of those rare deals which is truly a win-win for both sides, and I know I speak for Ron and the whole team at Zerofootprint, as well as for Michael and the Radiant Core crew, when I say that we are all very much looking forward to saving the world together. We've spent the last four and a half years building websites and web applications, and although we've had a wonderful time and worked on some great projects, very few of them served an altruistic purpose beyond promoting a product or selling more widgets. We're now in the very enviable position of knowing that each feature we spec, each line of code we craft, and each bug we squash brings us that much closer to reducing the world's CO2 footprint. I don't know about you, but that's pretty inspiring for me. Keep an eye on the Zerofootprint site for some big changes over the coming months, and we'll see you at the next DemoCamp, Rails Pub Night, CaseCamp, TransitCamp, etc.

I had the privilege of attending this morning's press event and live Twittered, so if you'd like to know more about what was said, see my Twitterstream. Press coverage is starting to appear (the Toronto Star is up with Website measures local carbon footprints), and watch the news tonight for footage from CBC and Citytv, both of whom sent camera crews. Mayor Miller apparently loves it and was there to say lots of nice things, which is always a good endorsement. Check it out for yourself!

6:00pm
Demo: AskItOnline.com (Kaitlyn McLachlan, Clear Sky Media, http://www.askitonline.com)

6:15pm
Demo: GigPark (Pema Hegan, Noah Godfrey, http://www.gigpark.com)

6:30pm
Demo: Mono Project .NET Development on a Mac (Geoff Norton, http://www.mono-project.com/)

6:45pm
Demo: PlanetEye (Butch Langlois, http://www.planeteye.com)

7:00pm
Demo: SceneCaster (Alain Chesnais, http://www.scenecaster.com)

7:15pm
20 minute break

7:35pm
Ignite: The Future Is Simple (Geo Perdis, http://mediaworks.ca/)

7:50pm
Social Services Mashup (Clara Severino, UofT, Partnership) 

8:05pm
How to Rock SXSW (Rannie Turingan, http://PhotoJunkie.ca)

8:20pm
The State of Wireless in Canada Sucks (Tom Purves, http://wirelessnorth.ca/)

8:35pm
Leveraging Wide Open (Mike Beltzner, http://www.mozilla.com)

8:40pm
20 minute wrap up and social

9:00pm - 11:00pm
Duke of Westminster (http://westminster.thedukepubs.ca/) will have finger foods for us and is staying open an extra hour so you can get your drink on :)

We didn't have a chance to work on this release, but we're really looking forward to a whole bunch of the new features. There's a great rundown on Mozilla Links' A Deeper Look at Firefox 3 (even if they did call our work "washed out" :), which is well worth the read if your browser blood runs red. Some of our favourites:

• The Proto native theme for Mac OS will finally give Firefox a truly platform native feel on our favourite operating system
• A number of changes to the toolbar and tabstrip which make a lot of sense from the perspective of optimizing the browser experience (the Go button is gone! Let the rejoicing begin!)
• Places, which will bring some sanity to our extensive bookmarks collections
• Blocking JavaScript from resizing windows without permission (and various other nefarious message control tactics — take that marketeers!)
• Our good friend Madhava's awesome work on the Add Ons manager which brings browsing and installation of Add Ons right into the browser chrome. It's about time!
• Our other good friend Johnathan's equally awesome work around security, site verification, and anti-phishing measures, summed up in Larry the Security Guy.

Date: Monday, February 25th, 2008
Time: 6:00pm to 9:00pm
Location: Toronto Board of Trade, 1 First Canadian Place, Toronto, ON
Cost: Free (cash bar if you're thirsty)

Dinner will be served, the Demos will be excellent, the Ignites will ignite, and then we'll adjourn to The Duke of Westminster for more food and drinks.

As always, details are available at on the BarCamp's  DemoCampToronto17 page, 'tickets' are at Eventbrite, and those wishing to sign up for a demo or ignite session can do so via the Wufoo DemoCamp form.

We've seen a lot of turnover at recent DemoCamps and we're always happy to welcome new faces into the crowd. Since this is the first DemoCamp of 2008, we're going to change the old "bring a new person" rule around a bit and ask everyone to "bring a new person AND an old friend who hasn't been out in a while". Things have changed a lot since our humble beginnings around the BubbleShare board room table, so let's bring them back and show them what's new!

Lastly, we're always looking for individuals or companies who would like to put up $200 and help make the event possible. If you're interested, please contact me directly and I can give you a rundown of what's involved.

Hope to see everyone there!

SciBarCamp is a gathering of scientists, artists, and technologists for a weekend of talks and discussions. It will take place at Hart House at the University of Toronto on the weekend of March 15-16.

Bringing the academic and entrepreneurial communities together is one of Greg's big passions and this event is a clear move in that direction. Should be a lot of fun! Plus, it's sponsored by our friends at MindTouch who make the awesome DekiWiki, and if past evenings out with AaronF and the crew are any indication, this should be good! Hopefully they'll make it up for the weekend.

There are magazines about business, and then there's the Harvard Business Review. If you're at all involved in doing business in the western world, odds are you've read an article from HBR or even have a subscription. It would not be an exaggeration to say that a whole generation of thought and business leaders have been shaped by the content HBR has published. And so, along with my co-authors Eli Singer and Mark Kuznicki, it is my incredible honour to annouce the publication of our article, titled Sick Transit Gloria, in the Breakthrough Ideas for 2008 section of the February issue of the Harvard Business Review.

Our short piece shares the story of Toronto TransitCamp with a general business audience. We're in great company and I highly recommend you take a few mintues from your busy day to read through some of the articles on the Breakthrough Ideas for 2008 site. We'd also love if you would take an additional moment (we're so needy!) to vote for TransitCamp in the Best Unconference in BlogTO's Best of Independent Toronto Poll.

For those of you who aren't familiar with TransitCamp, our article tells the tale of a community and a public agency coming together in an innovative new way to solve problems together, using technology and social media and the BarCamp unconference toolkit to change their relationship. We're very proud to have helped the Toronto Transit Commission to usher in a new era of collaboration with its customers and community stakeholders! For more information, read the article in Harvard Business Review or check out the HBR page on the TransitCamp wiki for links that provide a comprehensive overview of the background, the design, the experience, the media coverage, the conceptual foundations and the influence of TransitCamp.

As authors, we want to be clear that while our names may appear in the byline of this article, these ideas and the event itself were created and inspired by a group of local community participants and peers and global thought leaders who both helped and inspired us. We would like to acknowledge those contributions and inspirations here:

Our friends who helped make TransitCamp happen: Robert Ouellette, ReadingToronto; Tim Shore, BlogTO; David Topping, Torontoist; Matt Blackett, Spacing; Adam Giambrone; David Crow; Bryce Johnson; Joey Devilla; Madhava Enros; Michael Glenn; Misha Glouberman; Julia Breckenreid; Ryan Feeley; Kieran Huggins; Andrew Moore; Kevin Bracken & Lori Kuffner, Newmindspace; Rannie Turingan, photojunkie; Patrick Dinnen

Friends and inspirations: Alec Saunders, Iotum; Amber MacArthur; Alex Lowy; Andrew Baron, Dembot; Anthony Williams; Arieh Singer; Audrey Carr, Between Us; Austin Hill, Billions with Zero Knowledge; Ben McConnel and Jackie Huba, Church of the Customer Blog; Bianca Goldman, A Wee Bit Skint; Bonnie, Ernie & Rachel, GreatCycling; Brian Oberkirch, Like it Matters; Cambrian House; Chris & Jessie, Istoica; Chris Anderson, The Long Tail; Chris Messina, FactoryCity; Colin Henderson, The Bankwatch; Colin Smillie; Cory Doctrow, Craphound; David Eaves; David Gray, Communication Nation; David Pritchard; David Weinberger, Everything Is Miscellaneous; Doc Searls; Don Tapscott; Elspeth Roundtree; Eric Goldman, Napoleon's Gambit; Ev Williams, Evhead; Greg Wilson, The Third Bit; Guy Kawasaki, How to Change the World; Howard Rheingold; Hugh MacLeod, gapingvoid; Iris Glaser, Tailor Communications Design; Jason Kottke; James Bow, Transit Toronto; James Cherkoff, Modern Marketing; Jeannette Hanna & Jeff Howe, crowdsourcing; Jeff Jarvis, BuzzMachine; Jeremiah Owyang; Jesse Hirsh; Jevon MacDonald, socialwrite.com; Mike Beltzner; Joe Clark; John Battelle, Searchblog; John Moore, Brand Autopsy; Johnnie Moore; Joseph Thornley, Pro PR; Karen Quinn Fung; Kate Trgovac, My Name is Kate; Kathy Sierra, Creating Passionate Users; Kelly Seagram; Kenyatta Cheese, Braintag; Lawrence Lessig; Lee Goldman; Lee Odden; Leila Boujane, Idee, Inc.; Lloyd Alter, treehugger; Maggie Fox, Social Media Group; Mark Dowds, Mark Evans, A Canadian Take on the Web; Mark Raheja; Mark Surman, commonspace; Martin Cleaver; Matt Mason; Matt Mullenweg, Photo Matt; Matthew Dewall, Maybe Sorta Kinda; Matthew Ingram; Michael Anton Dila, Torch is Wicked; Michael Lenczner; Michael O'Connor Clarke; Michael Geist; Michael Seaton, The Client Side Blog; Michelle Perras, Shot From the Hip; Mitch Joel, Six Pixels of Separation; Nicholas Carr, Rough Type; Nikki Goldman; Om Malik, GigaOm; Peter Francey; Phil Hood;Richard Florida; Riccardo Cambiassi; Rob Hyndman; Robert Scoble, Scobleizer; Ryan Coleman Found in Translation; Saul Colt, The Smartest Man in the World; Scott Beale, Laughing Squid; Sean Howard, Craphammer; Sean P. Aune; Sean Wise; Seth Godin; Shel Israel, Global Neighbourhoods; Steve Munro; Steve Rubel, Micropersuasions; Stowe Boyd, /message; Stuart MacDonald; Sulemaan Ahmed; Tara Hunt, HorsePigCow; Michael Arrington and Erick Schonfeld, Techcrunch; Thomas Purves; Tim O'Reilly; Todd Defren, PR Squared; Tom Davenport, Make IT Matter; Tom Williams, the $5 philanthropist; Tom Peters; Will Pate; Yochai Benkler

The existence of Office on the Mac platform has always been a bit of quandary for Microsoft. On the one hand, they sell a lot of copies and make a good chunk of revenue on it. On the other hand, they sell it to people who don't buy Windows (unless they're going to run it in Parallels or Fusion) and are therefore helping to support the existence of a platform which directly competes with two of their primary money makers (Windows and Office for Windows). There was actually a point in history, back in the dark days of 1997, when Microsoft invested $150m in Apple and pledged to continue to develop versions of Office (and InternetExplorer!) for Mac OS — a move which may well have saved Apple's bacon. Fast forward 10 years and we have a new release of Office, so what's changed?

On the surface, this is a great update. Lots of thought has gone into the UI, which resembles a Mac OS native version of the Ribbon seen in Office 2007 for Windows. It's Intel native, which makes it much faster on modern Macs than Office 2004 was (mostly because it's no longer running in the Rosetta emulation layer). What's not to like? Well, there's one thing. It's a small thing when you read it in a long list of changes, but when you actually stop to think about it, it's not such a little footnote.

Microsoft Office 2008 for Mac OS no longer supports Visual Basic for Applications Macros. VBA has been the standard Macro language for Office releases on both Mac OS and Windows for a long, long time and there are probably millions of Office documents out there that have embedded macros. I regularly use two such documents, an Excel spreadsheet which we built internally and which helps us calculate accurate estimates for clients, and a Word document which was provided to me for a project I'm working on and which I have to use to complete my work. Opening our Costing Workbook in Excel gives the following error dialog:

The first time it came up, I didn't read it properly and thought it was the old security warning that Excel used to give when opening a document with macros in it. It was only on the second pass that I realized what I was seeing: we will never be able to use our Costing Workbook again. This is a little more insidious in the project document I have to use, as it opens without a warning but none of the built-in functions and buttons do anything. Clicking on the "Learn more about macros and Office for Mac" shows a Help window with the following contents:

Cause: Office 2008 for Mac cannot run Visual Basic macros or load add-ins that contain Visual Basic macros.
    Solution: Keep the macro in the file.
    Solution: Remove the macro from the file.
    Solution: Save the macro in another macro-enabled file format.
    Solution: Create a new macro by using AppleScript.

The first three are just solutions which allow you to keep the macros from getting destroyed when the file is saved in Office 2008 format. The last one is the real kicker: the only actual solution is to recreate your macros in AppleScript format. Kudos to Microsoft for beefing up AppleScript support for the suite (and it does look pretty thorough), but what they're basically saying is that you can no longer interop with your Windows colleagues and you have to recreate any macros you had in a completely new language. You may find yourself scratching your head at this point, much as I was when I made this discovery. Why would they do such a seemingly stupid thing? Erik Schwiebert ("Schwieb"), a member of the Mac team, explains in an excellent blog post Saying Goodbye to Visual Basic (have I mentioned how much I love Microsoft's approach to corporate blogging? No? It's awesome. Everyone should learn from them). I completely sympathize with Erik's description of their plight and I agree that a two year delay would have been unacceptable, but I also think this decisions has some very serious consequences for Apple's potential in the corporate market.

We basically run Office only because our clients do. If we had our choice, we'd probably run Pages for word processing, we would definitely run Keynote for presentations (and I use it for any of mine already), and would be stumped to replace Excel (Numbers is a nice start but it's a long way from ready). If we felt that there were other applications out there which would flawlessly handle our clients' documents, we'd probably switch today (we've tried NeoOffice and OpenOffice with mixed results — suggest alternatives in the comments). We're a small shop though, and we get to set our own IT direction. Many of our colleagues work in large organizations who have IT departments which have been actively hostile toward Macs until recently and have only just started to come around (if they have at all). A big reason for that change has been Office, since Mac users can work seamlessly with their Windows colleagues (particularly in an Exchange environment using Entourage). If you work in an organization large enough to have an IT department, there's a pretty good chance that your company has also got some complex documents with macros in them (likely in Excel, which sees a lot more scripting than Word). The very rock and hard place described by Erik is about to crush your chances of getting a Mac on your desk, since any new Mac will be Intel-based and any new license of Office will be 2008 and now you'll be back into no-interop land. I'm not the only one who finds this so disheartening: in an opinion piece published in Macworld way back in December 2006 (when Microsoft first announced that they were removing VBA support), Rob Griffiths said:

Microsoft Office isn'€™t among the apps that will run natively on Intel-based Macs, ”and it won't be until the latter half of 2007, according to media reports. But when it does ship, Office will apparently be missing a feature so vital to cross-platform compatibility that I believe it will be the beginning of the end for the Mac version of the productivity suite.

He also points to a thread on Ars Technica, which includes 3 pages of angry feedback from people who will be seriously affected by this decision. I feel for the Microsoft Mac Business Unit (MacBU) team members who had to make this decision, even though I'm sure that ditching VB's ten year old implementation was a weight off their shoulders. Unfortunately for me, and for many of you, it was really just a transfer of weight onto our shoulders.

So, if you're feeling that weight, MacTech Magazine published their Moving from Microsoft Office VBA to AppleScript: MacTech's Guide to Making the Transition guide in their April 2007 issue (which is now entirely available online), which I recommend as a fantastic starting point. I agree with their introduction in that there is an advantage for Mac users who take the time to learn AppleScript: it's the scripting language for the whole platform so you can easily build scripts which integrate Office into other apps, and you'll know how to script non-Office things as well. I actually do a fair bit of AppleScripting from time to time and have made some great little scripts (particularly Copy Path, which copies the path to the current Finder window onto the Clipboard), and I encourage Mac users with a programming bent to learn it. I'm just not sure you should be forced to do so in order to keep using your own documents.

I think the talk went well despite yesterday's incredible wind actually knocking out power to the venue (they were worried the projector might strain their backup generator and it sure did and the power died as I wrapped up :). The crowd's tech knowledge spanned everything from very casual web use to bloggers and SEO-fanatics, so I started off with a quick review of the basics (e.g.: Web 1.0's one way street vs. Web 2.0's participatory conversation), and then jumped into blogging, social media, search, ecom, and collaboration. We covered a lot in an hour and some people were starting to get a bit of the Information Overload glaze in their eyes, so I wrapped up with an encouragement to take advantage of the wealth of free software and opportunity and get out there and experiment. I'm on the train on the way back to Toronto now, but will post the slides to SlideShare from a more reliable net connection for anyone interested.

We resolved to stop making resolutions we couldn't keep — did you make any fun resolutions? Leave 'em in the comments and we'll drop by your blog later this year to remind you about them :)

While you're here, why not help make the world a little better in the new year? Our good friends at Zerofootprint, with whom we've been doing quite a lot of work lately (stay tuned for some exciting announcements!), have been nominated for a very prestigious TechCrunch Crunchy Award in the "Most likely to make the world a better place" category, and they could really use your vote! Visit the Crunchies site and vote for them right away. The world appreciates it!

Click for the full size card

1. Tractability: How difficult will it be to launch a worthwhile version 1.0?
2. Obviousness: Is it clear why people should use it?
3. Deepness: How much value can you ultimately deliver?
4. Wideness: How many people may ultimately use it?
5. Discoverability: How will people learn about your product?
6. Monetizability: How hard will it be to extract the money?
7. Personally Compelling: Do you really want it to exist in the world?

If you're developing a new product — or even just thinking of doing so — do yourself a favour and read the post to get a sense of where you stand. It's obviously not gospel (and sometimes the best ideas come out of left field and can't even be charted on existing metrics), but it's a really good step further down the road and will help you prepare for some of the questions investors are likely to ask if you go in that direction.

The Email Standards Project works with email client developers and the design community to improve web standards support and accessibility in email.

The fruits of their labour is already visible in things like the compliance reports for various email clients (Apple Mail [Excellent], Gmail [Poor], Outlook 2007 [Poor], and Windows Live Hotmail [Average] to name a few), and in their development of an email Acid Test to compliment The Web Standards Project web version. Standards make the world better for everyone, so if you work with email, read it, or send it (which should cover just about everyone who reads this blog), you should stop by their site and lend a hand.

So, it was with much sadness that I read the news this morning. As reported on blognation by Marc's close friend Oliver, he suffered a massive coronary sometime between 7:30 and 8:10 am yesterday and was rushed to the Presbyterian Hospital in Albuquerque, New Mexico, where he remains in critical condition and is not expected to regain consciousness for the next 24 - 48 hours. Our thoughts go out to Marc, his wife Sue, and his son Jason, as well as to the entire tech community who have been touched by his generosity. If it were possible for this world-spanning network of people to produce full and rapid recoveries as well as we produce the technology Marc so lovingly reports on, we would do nothing but.

For those of you wishing to send cards, gifts, or other happy thoughts in physical form:

Presbyterian Hospital
Cardiac Care Unit Bed #3
1100 Central Ave SE
Albuquerque, NM 87106

The hospital also offers a service through which you can send patients a virtual card.

Update: Oliver Starr is blogging status updates on Marc's condition on his blog. Please visit there for the latest news and link to that page rather than the original Blognation story.

On November 6th, 2007, Facebook launched a series of new tools to help advertisers target the 54 million people now regularly using their site. They're still throwing around a 3% weekly growth rate and have a target of 60 million active users by the end of the year, so it's not hard to picture the day in the not-so-distant future when hospitals Facebook babies before handing them over and the little bundle of joy comes with a neural implant that pokes their parental units when the diaper is full.

The new tools round out the Facebook Business offerings to an even six:

             
• Social Ads
             
• Pages
             
• Beacon
             
• Insights
             
• Platform
             
• Polls

Platform and Polls are old news to anyone following the company, so the really interesting news is in the other four. All of them are very much interlinked, so that you create a Page for your brand or product, advertise it through Social Ads to a very targeted market, learn about your success through Insights, and connect to your off-Facebook (off-Book?) service via Beacon, build custom apps for your Page on Platform, and learn about your users through Polls. It's a marketer's dream, but what does it mean for you as a user? The web is somewhat up in arms about Beacon particularly because it just stinks of privacy violations, at least if you care about things like companies tracking your every move online. This post is going to dig deep in Beacon and see what makes it tick from a purely technical perspective, but we'd be happy to do a follow-up post about the ethical question if there's enough interest. Leave a comment and let us know!

Pinging Beacon

This post is an in-depth look at Beacon, and is broken down into a few sections to make it easier for you to navigate:

• Beacon in a Nutshell: an overview of Beacon and a visual tour of the user interface elements
• Beacon from 10,000 Feet: a look at the technology behind Beacon from way up high. Read this if you don't want the finer details but do want an idea of how it works.
• Blocking Beacon: if you're concerned about privacy and want to stop Beacon, check this part out.
• Walking through the Code: this is the section for you if you're the type of person who loves reading code listings and wants to know exactly what makes it tick.

Beacon in a Nutshell

Here's what Facebook has to say:

Allow your customers to share with their friends the actions they take on your website. For user actions you define, Facebook Beacon will publish a story in the user's profile and to friends' News Feeds with a link back to your site.

What that means in real terms, is that you can add a recipe to your recipe box on Epicurious, and you'll get a very familiar looking Facebook pop-up in the bottom right corner of your window letting you know that your new recipe is being sent to your news feed:

If you do nothing, you have effectively opted-in and you have consented for the item to be published (i.e.: Facebook will assume your consent to publish the content). The window will disappear eventually, and the next time you log into Facebook, you'll see a notice like this one at the top of your homepage:

If you go to your Profile page, the items will appear mixed in with everything else in you mini-feed:

You'll notice that those two screen captures show different recipes being added, which is because Beacon isn't entirely without issues. Although I've been playing with it for a few hours now, items about Epicurious recipes stopped being added to my feed just after 7:30pm. There may be some internal limitations applied by the algorithm to stop feeds from being overloaded with actions from any one site, or it might just be broken :). The help page on Epicurious explains that they are sending four types of actions to Facebook:

             
1. Rate a recipe
            
2. Review a recipe
            
3. Add a recipe to your Recipe Box
            
4. Register on Epicurious

Encounters with Beacon are slowly starting to be reported on other sites as well. A post from yesterday on Groundswell documents a Close encounter with Facebook Beacon in which Charlene Li (Vice President, Principal Analyst for Forrester Research) had her first run-in on Overstock.com. In her post, she explains how she bought a coffee table from that site and was surprised to discover, when she logged into Facebook later that week, that there was a notice at the top of her page about the purchase:

Charlene should have been shown the pop-up window as well but she might have missed it or something might have failed to show it while she was on Overstock (there's a slight delay before it pops up, so it's possible that she navigated away from the page or closed the window before she saw it). It's unfortunate that it didn't work as advertised because, as she says:

The biggest problem is the lack of transparency. Facebook is right in that I would really like to have some things that I do on third party sites to conveniently appear in newsfeed, e.g. events I'm attending from Evite or eBay/craigslist listings so that my friends know about them. That's the promise of Beacon. But I need to be in control and not get blindsided as I did in the example above. I was seriously wigged out, but wouldn't have been if Overstock had simply told me that they were inserting a Facebook Beacon and given me the opportunity at that time to opt-in to Beacon.

As I mentioned above, this isn't a post about the privacy or security concerns of Beacon (though it will address some of them below). There's some pretty neat web technology at play which we thought would interest our more technical readers, and so, just like we used to do with Dad's calculator we're going to take Beacon apart and put it back together again (hopefully in one piece – sorry Dad!).

Beacon from 10,000 Feet

That basically wraps up our tour of how Beacon does what it does. It's a fairly long explanation, so here's a quick summary:

            
1. The partner site page includes the beacon.js file, sets a

   <meta>

   tag with a name, and then calls Facebook.publish_action.
            
2. Facebook.publish_action builds a query_params object and then passes it to Facebook._send_request.
            
3. Facebook._send_request dynamically generates an

   <iframe>

   which loads the URL http://www.facebook.com/beacon/auth_iframe.php and passes the query_params. At this point, Facebook now knows about the news feed item whether you choose to publish it or not.
            
4. The

   <iframe>

   loads a facebook_helper.html file, which lives on the partner site, and which contains a call to Facebook.process_message_from_helper.
            
5. Facebook.process_message_from_helper parses a call to Facebook._perform_action from its own query_string and calls it.
            
6. Facebook._perform_action dynamically creates the toast pop-up and displays it in the bottom right corner of the window.
            
7. The user is given the choice of cancelling the publication (i.e.: opting-out), which will cause the item not to appear in their news feed.

And there you go! A very clever series of steps to allow for a very simple integration by partners and a neat side-step of the Cross-site Scripting security features in modern browsers.

Blocking Beacon

Those of you wearing tin foil hats (or hats at all, really), are probably wondering how you can block this nefarious beast from spreading all of your secrets. You've got a few options:

• If you're not worried about Facebook knowing what you do but are worried about your friends finding out, you can go into the External Websites area of your Privacy settings and set specific sites to never publish. They'll only show up after you've triggered them the first time, so the list will only contain sites you've already visited which are Beacon-enabled.
            
• If you're worried about Facebook and you're friends knowing what you do on other sites, make sure you don't browse other sites while you're logged into Facebook. When you add a recipe to your recipe box and aren't logged in, a request is still made for the beacon.js file and gets as far as creating the

  <iframe>

  and loading auth_iframe in it, but that page now returns "no user" and the process stops.
            
• If you're paranoid about the entire process (or don't trust yourself to always log out of Facebook before browsing other sites), and you just want to make sure that nothing gets through, and you're using Firefox, follow Nate Weiner's excellent instructions in his Block Facebook Beacon post (basically, install the BlockSite add-on and add www.facebook.com/beacon/* and facebook.com/beacon/* to the list). If you're running InternetExplorer, you can try following these instructions to add the same two URLs to your restricted zone, but your life would really be much improved by downloading Firefox so I'd recommend you do that instead. UPDATE: we've confirmed that the exceptionally useful AdBlockPlus for Firefox will also block Beacon if you add a pattern for http://*facebook.com/beacon* to the list of filters. The script tag embed for the beacon.js file gets blocked which prevents the rest of the app from working. Note that you can set ABP to be disabled for certain sites (a virtual necessity if you use them often and they have heavy Flash requirements), which will in turn allow Beacon to work.
  

Walking Through the Code

IMPORTANT NOTE: All of the code shown here is copyright and all rights reserved and please-don't-sue-us owned by the respective parties who wrote and publish it. It was not disassembled for profit and we used only publicly available free tools (Firefox with the FireBug and TamperData Add-Ons installed) and source which was available through standard web protocols.

It has traditionally been very difficult to connect two websites together and exchange information between them without building complex backend integrations. Sure, they could have built Beacon by implementing a web service in which the third party servers (like Epicurious) would contact the Facebook services through an entirely backend channel whenever I did a certain something (like add a recipe to my recipe box), but that would have meant asking partners to invest some fairly serious engineering effort in order to support it, and the opportunity to display a fun pop-up window to allow me to opt-out would have been gone. Instead, Facebook followed the route of having partners embed a JavaScript file on their site, and make a simple JavaScript call to populate the item. Let's take a look at an example:

I'm a big fan of risotto – so big, in fact, that one of the reasons I married my wife was to get better access to her Risotto Milanese. I can't think of anything I'd really rather have for breakfast, so we're going to use a recipe for Breakfast Risotto as our example (you should load that page in another tab so that you can flip back and forth).

If you take a look at the source and search for Facebook, you'll find two entries. The first is on line 133 and sets up the name of this item for the news feed entry:

<meta name="facebook_label" content="Breakfast Risotto Recipe">

The second is on line 167 and actually pulls in the Facebook JavaScript file:

<script type="text/javascript" src="http://facebook.com/beacon/beacon.js.php?source=5194643289"></script>

The source ID (5194643289) identifies Epicurious and corresponds to a list maintained internally by Facebook, which allows them to validate sources. You can actually load that file directly and you'll find a suprisingly well formatted JavaScript class called window.Facebook. We'll dig into it a little bit later on, but the first method deserves mention all by itself, entirely based on its name:

write_awesome : function(url) {
             return '';
},

The two lines we're particularly interested in on the Epicurious page have to do with adding this recipe to our recipe box, and you'll find them on lines 1195 and 1197:

<a href="javascript:void(0);" id="addRecipeButton">Save To Recipe Box</a>
<script type="text/javascript">new LoginRequiredLink('240748',
                'addRecipeButton',
                '/user/recipebox/save?id=240748&returnto=/recipes/food/views/240748',
                'recipeBox',
                'recipeBox');</script>

For all intents and purposes, this has nothing to do with Beacon and basically just rewrites the addRecipeButton link to point to the right URL for saving it if you're logged in (note: a more modern approach would be to use Ajax to send a message to the server to save this recipe and prevent having to actually go to a different page, which would improve the experience here since the back button from the save page takes you back to effectively the same page in the pre-saved state). If you want to follow the rest of the way through this you're going to need to register an account on Epicurious, so go ahead and do that and I'll wait right here. Done? Great. Reload that page and you should now have an enabled Save to Recipe Box" button. Now, before you go and click on it to watch Beacon in action, you'll need to make sure that you've logged into Facebook in another tab or window. This is critical and is in fact overlooked by a lot of the people who are upset about the potential privacy violations: don't leave yourself logged into Facebook and you won't have a problem with other people using your machine and logging Beacon events. Go ahead and login and then hit that button.

You should now be on a page which shows the recipe as added. There's a lot of Epicurious-centered JavaScript at play on this page which we're not overly concerned about, so I'm not going to mention it except where it affects the Beacon integration. As on the previous page, we have a

<meta>

<script language="javascript">
    runOnLoad(function() {
        if (Facebook) {
                Facebook.publish_action('queue',
                    'http://www.epicurious.com/recipes/food/views/240748?mbid=fbfeed');
        }
    });</script>

Basically, if the Facebook object was instantiated when the beacon.js file was included, go ahead and publish an action of type 'queue' with the URL of this page as the link (with a tracker on the end so Epicurious knows you came to the recipe from a Facebook feed). The runOnLoad function gets called down on line 1330 from inside a

<script>

publish_action : function(action, urls) {
    urls = urls || window.location.href;

Set the urls variable to the value passed in or the location of the current page.

    setTimeout(function() {

Set a timeout of 50 milleseconds and then call the following function.

        if (Facebook._BROADCAST_ACTIONS[action]) {
            var query_params = [['action_name', action]];

Check to see if we were passed a valid type of action and set the action_name to the value passed in. The list of available actions is quite extensive: buy, wish_list, queue, sign_up, bid, review, add, book, comment, create, design, download, find, fly, get, join, play, post, rate, rent, shop, stay, subscribe, support, update, view, vote, watch, enjoy, order.

            if (typeof urls == 'object') {
                for (var i = 0; i < urls.length; ++i) {
                query_params = query_params.concat([['urls[' + i + ']', urls[i]]]);
            } 
       } else {
            query_params = query_params.concat([['urls[0]', urls]]);
        }
        Facebook._send_request('http://www.facebook.com/beacon/auth_iframe.php', query_params);
        }
    }, 50);},

Manipulate the URL if required to build the request and then send it to facebook using the _send_request function.

The next piece of code is key to how this whole thing works. Those of you familiar with JavaScript will know that browsers spend a lot of effort preventing something called Cross-Site Scripting (often shortened to XSS). We covered this back in July 2006 with a post on 5 Tips for Protecting Your Site Against XSS, and Wikipedia has an excellent a very in-depth look at the issue in their Cross-site Scripting entry. The gist of it is that you can't have a script from one site run on another site and you can't drop a cookie from one site and read it from another, so how does your news event from Epicurious get posted into Facebook without using a backend server connection? All thanks to the humble _send_request function (line 75 in beacon.js):

_send_request : function(url, query_params) {
    query_params = query_params.concat([['source_id', Facebook._source_id],
        ['random', Math.random()],
        ['ref_url', window.location.href]]);
    var src = url + '?' + Facebook._form_query_string(query_params);

This is pretty simple – parse the info handed to this function and get ready for below.

        setTimeout(function() {
        var ifr = document.createElement('iframe');
        ifr.style.display     = 'block';
        ifr.style.width       = '0px';
        ifr.style.height      = '0px';
        ifr.style.border      = '0px';
        ifr.style.margin      = '0px';
        ifr.style.padding     = '0px';
        ifr.style.overflow    = 'hidden';
        ifr.style.visibility  = 'hidden';
        ifr.src = src;
        document.body.appendChild(ifr);
    }, 0);
},

This is where it all goes down. This code creates an

<iframe>

So, an

<iframe>

<iframe>

<iframe>

<html><body><script type="text/javascript">window.onload = function() {
    window.top.Facebook.process_message_from_helper(
        window.location.search.substring(1),
        window.location.hash.substring(1));}</script>
</body></html>

Nice and short: when the page loads into the

<iframe>

<iframe>

process_message_from_helper : function(query_string, hash_string) {
            var params = Facebook._parse_query_string(query_string);

Facebook._parse_query_string is to an internal function (beacon.js, line 276) which pulls about the key/value pairs from the query string (e.g."action_name=queue") and returns an array containing the key and value (e.g.: ["action_name", "queue"]).

            var argument_list = [];
            var function_name = '';
            for (var i = 0; i < params.length; ++i) {
                var key = params[i][0];
                var val = params[i][1];
                if (key.substring(0, 3) == 'arg') {
                    argument_list[parseInt(key.substring(3))] = val;
                }

Some of the keys stored in the query_string start with 'argx' to denote that they arguments (where x is an integer indicating which argument this is – arg0, arg1, arg2, etc.). If that's the case, store the value in the argument_list array at that location (e.g.: arg0 goes into the argument_list[0]).

                          if (key == 'function_name') {
                                       function_name = val;
                          }
             }
             Facebook[function_name].apply(null, argument_list);
}

If the key is 'function_name', then we want to call that function in the Facebook object. That

if

else

if

It's interesting to note that none of the arguments which got stored when we built the query_string above started with arg or had a key of function_name. Since we had to fake our way into seeing the auth_iframe.php page, we didn't get a look at the full set of arguments passed into it from Epicurious. The trail would have gone cold here, were it not for the wonderful Firefox add-on called TamperData. With the add-on installed and the sidebar open, you can watch all of the GET and POST requests that a page makes as it loads. The recipe save page from Epicurious makes 116 requests to build the page, pulling from three servers (www.epicurious.com, www.google-analytics.com, and www.facebook.com). We only really care about the ones made to Facebook, of which there are 6. The GET call to auth_iframe.php is the one we're after, and it looks like this:

http://www.facebook.com/beacon/auth_iframe.php?action_name=queue
&urls[0]=http%3A%2F%2Fwww.epicurious.com%2Frecipes%2Ffood%2Fviews%2F240748%3Fmbid%3Dfbfeed
&source_id=5194643289
&random=0.2268030104517741
&ref_url=http%3A%2F%2Fwww.epicurious.com%2Frecipes%2Ffood%2Fviews%2F240748%3Frecipename%3DBREAKFAST%2520RISOTTO%26saved_to_box%3Dy

Which is not dissimilar to the version we constructed. Thanks to TamperData, we can get the response to that request, which contains the following location:

Location=http://www.epicurious.com/facebook_helper.html?function_name=_perform_action
&arg0=queue
&arg1=%5B%22http%3A%5C%2F%5C%2Fwww.epicurious.com%5C%2Frecipes%5C%2Ffood%5C%2F
views%5C%2F240748%3Fmbid%3Dfbfeed%22%5D
&arg2=<auth_token_redacted>
&random=1305590124

When the call gets made from Epicurious rather than by us, the response fits right into the pattern that process_message_from_helper is looking for. In fact, if you go to that URL and view the source, you'll seem the same thing we saw when we loaded auth_iframe directly, except now being served from Epicurious instead of Facebook. Applying what we know from process_message_from_helper, we've now essentially called:

_perform_action(queue, ["http://www.epicurious.com/recipes/food/views/240748?mbid=fbfeed"], <auth_token_redacted>, 1305590124);

Note that we've made a trip through the Facebook server to get here, which means Facebook has already recorded this news feed item whether we choose to publish it or not. This is a much longer function so I've edited out some parts which are not key to the core functionality. If you'd like to see the whole thing, we're now on line 159 of beacon.js. One thing to note before we dive in: the term 'toast' will only make sense if you've actually seen the pop-up appear. Since it rises up from the bottom edge of the window frame, it looks a lot like toast popping up in a toaster :)

_perform_action : function(action_name, urls, auth_token) {
             Facebook._kill_toast();

Although it may sound like it, no one at Facebook has a vendetta against breakfast foods (that we know of). This just kills the window if it's already visible from a previous instantiation.

             var toast = Facebook._toast = document.createElement('div');
             var query_param = [['action_name', action_name],
                          ['urls', urls],
                          ['source_id', Facebook._source_id],
                          ['ref_url', window.location.href],
                          ['random', Math.random()]];
             if (auth_token) {
                          query_param.push(['auth_token', auth_token]);
             }
             var src = Facebook._action_toast_url + '?' + Facebook._form_query_string(query_param);

Create the HTML element that will hold our toast, then setup the query_params. The toast window contains another

<iframe>

<iframe>

              [...redacted...]
             var iframe_style = 'width: 345px; height: auto; left: 0px;'
                         + 'border: 0px; margin: 0px; padding: 0px; display: block; position: absolute; background: transparent;';
             toast_inner.innerHTML = '<iframe src="%27%20+%20src%20+%20%27" style="" 
                     allowtransparency="true" frameborder="0" scrolling="no"></iframe>';

Format the

<iframe>

              var iframe = Facebook._toast_iframe =
              toast_inner.getElementsByTagName('iframe')[0];
             iframe.style.bottom = '-150px';
             toast.appendChild(toast_inner);
              document.body.appendChild(toast);
             [...redacted...]
         }}

Lastly, append the inner_toast div to the toast div which we created at the top. The next block calculates the position of the div and sets some style values.

We're almost done, honest. Referring back to our TamperData output, the URL for the

<iframe>

http://www.facebook.com/beacon/action_toast.php?action_name=queue&urls=["http%3A%2F%2Fwww.epicurious.com%2Frecipes%2Ffood%2F
views%2F240748%3Fmbid%3Dfbfeed"]&source_id=5194643289&ref_url=http%3A%2F%2Fwww.epicurious.com%2Frecipes%2Ffood>%2Fviews%2F240748%3F
recipename%3DBREAKFAST RISOTTO%26saved_to_box%3Dy&random=0.820036078758848&auth_token=<auth_token_redacted>

If you were logged into Facebook, and I hadn't removed the auth_token, and you load that URL in a window, you would probably see the contents of the toast window rendered in all of its glory. Since you can't do that, I'll just repeat the screenshot of the toast window from above:

You have five options at this point:

            
1. Close: closes the toast window and sends the news item to your news feed.
            
2. Learn More: takes you to a page on the Epicurious site with more information about the Facebook integration (Facebook Action Sharing and Story Publishing).
            
3. This isn't me: pops up a new window with a Facebook login in it so that you can login and add the item to your own news feed. This closes the toast window, but closing the login window without logging in didn't seem to log me out of Facebook. The recipe hasn't shown up in my feed, so I'm assuming that still blocked it from being published.
            
4. No Thanks: closes the toast window and stops the story from being published.

One important privacy consideration, despite this not being a privacy post, is that Facebook still knows that you added a recipe to your recipe box (or bought a book on Amazon, or a coffee table on Overstock.com, even if block the item from being posted to your news feed. I haven't seen any evidence here that shows that Beacon is sending along anything other than basically an action type, a name (in the

<meta>

Wrapping Up

That well and truly brings us to the end of our look at Facebook Beacon. It seems impossible that you might have read all this way down and not have been lulled into sleep, but if you're still awak (hi!) and have questions, leave them in the comments below and I'll do my best to answer them. If you're interested in reading more about this topic, and particularly about the privacy concerns or integration between Beacon and the other Business tools, let me know! Thanks for reading :)

The apple is red.
It is John’s apple.
I give John the apple.
We give him the apple.
He gives it to John.
She gives it to him.

1. Profile Information (user data)
2. Friends Information (social graph)
3. Activities (things that happen, News Feed type stuff)

Looks like OpenSocial won't have its own markup language (Facebook, for example, requires the use of FBML), which means developers will have one fewer thing to learn. The platform is launching with a bunch of partners in place, including Orkut (owned by Google), Salesforce, LinkedIn, Ning, Hi5, Plaxo, Friendster (apparently they still exist), Viadeo and Oracle (not well known for social networking, but they've got an impressive sounding internal app). They've also worked with some of the bigger Facebook developers to get them on the new platform, including Flixster, iLike, RockYou and Slide.

This is interesting, if for no other reason than that Google has managed to perform a buzzword bingo coup and cram two of the hottest words of 2007 into a single name. Sometimes it feels like the sky is raining social from giant buckets, and you'll be seeing a lot more about open in the coming months as the open source world continues its mainstream push. We're big believers in (and supporters of) openness and I'm glad to see some of the walls around the garden come down. The is brilliant in a lot of ways (particularly in their ability to scale and to solve the security issues which typically ruin similar efforts), but your data is very much locked into their site. We'll have a better idea of how OpenSocial will change that when the API is actually released later (and particularly about whether a layer could be developed which allows developers to build Facebook apps on it), and will report back.

We stayed at the City Inn, which turned out to be a refreshingly modern and simple hotel with free ethernet in the room (courtesy of a lovely pink CAT5 cable). We rallied the troops for a fun night on the town, taking advantage of The Commercial House's pretty fantastic pint, burger, and chips for £4.95. Tuesday morning saw us up bright and early for a walk to the University of Bristol campus, to pay a vist to 3CResearch, a member company doing "convergent technology research for digital media processing and communciations" (in case you're wondering — and I certainly was — the three C's are Communications, Content, and Creativity). We were given a demo of their Visualise project, which delivers streaming video to mobile devices (currently over WiFi but soon over faster and more pervasive delivery channels like HSDPA and WiMax). It was designed to offer a better experience to fans of events like rally racing, which generally involves standing in a cold, wet field for hours on end in the hopes that a car will hurtle past you for an exhilirating 15 seconds. Visualise means you can still stand in the same damp glen, but now you can watch the race from multiple viewpoints on your mobile, as well as peruse stats and driver info (assuming the touchscreen still responds to your frozen fingers). In all seriousness, the technology can be applied to any kind of event and would be great for things like music festivals like Coachella, at which you would need to clone yourself several times over just to catch half the bands you wanted to see. The demo was followed by a presentation by Dr. Geraint Jones about a number of the other 3CResearch projects, including Intelligent Content Based Retrieval (ICBR) (analyze video archives and index based on content, motion, etc.) and Motion Ripper (extract motion data from video and apply captured motion signals to computer animation — i.e.: analyze a video of birds flying and animate an electronic bird). Their research is very interesting, if not entirely cutting edge, but I thought the more interesting part was the conversation which erupted over licensing of technology and how pure research facilities can successfully commercialize their ventures. Sutha suggested they take a look at the MIT Media Lab model, which is basically pay-for-play (i.e.: companies can pay an upfront and quite large fee and then have access to all of the research), and I would think there's a lot to be learned from the MaRS Discovery District and from the University of Toronto's Innovations Group.

We spent the late afternoon and evening at Watershed Media Centre, a facility that reminded me of The Bookshelf in Guelph, a favourite haunt during my University years. Watershed includes a few cinemas, a caf&eaccute; and some meeting facilities, and was our home for a great mini-trade show event which consisted of 40 South West companies meeting and greeting our Canadian crew. Steve Collett (International Trade Advisor from UKTI) started us off, Ian Kelso (from Interactive Ontario) gave a quick state the union of New Media in the New World, and I followed him with a quick Introducing the Canadians rundown of the companies in the mission (and including a photo of a polar bear cub, two bears making out in the woods, and the poster from South Park: draw your own conclusions). I was followed by Mark Leaver (Director of Development from South West Screen), who mirrored Ian's talk but focused on the South West region of the UK, and then we were treated to a fantastic presentation by Adam Montandon, Director of HMC Interactive, who have built some truly amazing interactive experiences for Cadbury's Purple Planet and The Royal Obeservatory. He also has the excuisitely good taste to have fallen in love with a Canadian girl and is working on a (longish) term plan to move to our fair lands to be with her. I cornered him after and insisted that we line up a DemoCamp demo on his next visit, which he heartily agreed to (or maybe defensively, so I'd let him out of the corner — hard to tell). The trade show was a great success and I met a number of interesting people doing interesting things in which we might well take an interest, including John Bradford from jbsh, LLC (who are working on an educational product for the Canadian market), Paul Bason from University College Falmouth (who was delighted by Michael Wesch's latest and who was really interested to hear what we looked for in students and in whether we'd be into a distance-learning based partnership), David Karney from Potential Difference (a swank Bristol web shop who are basically Radiant Core's British counterparts, but on .NET), and James Ovenden from Ball Fusion (who are marketing an amazing video on street soccer skills — check out some of the tricks on their homepage). Apologies to the gentleman from Sanoodi, whose slightly odd application name I've managed to easily remember but whose much less odd personal name I've completely forgotten (owing to his lack of business cards, of course). We had a great chat about his app and where it's headed, and I showed him Toronto's own Planet Eye and the Specialized Riders Club (run by our friend Chris Matthews) for some inspiration. We ended the evening with a delicious dinner for fourteen at the Severn Shed (don't worry Mike: I didn't pick up the tab!), during which I had the pleasure of chatting about documentaries, music, books, and television with Julia Bennett (from White Pine Productions), Jason Krogh (from Zinc Roe), and Paige Chambers (from the Canadian Business College).

Stay tuned for Day 3, which will mostly be a train ride to Glasgow!

Back in early July, I was having a coffee with Ian Forrester from the BBC Backstage at our local Balzac's, when in strode Ian Kelso from Interactive Ontario. Ian to Ian (i2i?) introductions were made, and Mr. Kelso (my former boss from many moons ago!) laughingly suggested that we should join them on the Trade Mission they had just announced so that Mr. Forrester could buy me a coffee in his hometown. And here we are, three months later, sitting in the Tower 1 Meeting Room at The Tower Hotel in London, listening to John Davies, Technology & Strategy Adviser from United Kingdom Trade & Investment, talking about his country's strategic direction.

So, we're here until this afternoon, then off to lovely Bristol for a tour of 3C Research and a mini-trade show, then to beautiful Glasgow on Wednesday for some networking and a tour of the Hillington Innovation Centre on Thursday. I've got a criminally early train on Friday (5:50 am!) back to London, where I will sadly not have coffee with Mr. Forrester (who will be en route to Berlin) but rather lunch with his colleagues, a pint or two with Ian Hayward from Glaxstar (the company, not the alien galaxy), and a lovely dinner with the team from eBay UK (with whom we did the eBay Firefox Companion and are now working on a top secret new project).

I've got my trusty Rebel XTI and have been trying to capture some shots while keeping it out of the rain (no mean feat), which I'll make sure to post and link to. Many thanks to Sutha Kamal for playing tour guide yesterday and showing me around the banks of Thames, the Tate Modern, a few Starbucks (a charming little chain of coffee shops!), an historic pub (Lamb and Flag, which has been around since Charles II), and a great Vietnamese dinner at Cay Tre. More as it happens!