Windows Live for Developers

Windows Live and Activity Streams

Rob Dolin — Thu, 26 Aug 2010 01:15:33 GMT

Did you know that Microsoft’s Windows Live has been actively embracing the emerging Activity Streams open standard?

About a month ago, I traveled to Portland, Oregon, USA to participate in a “Federated Social Web Summit” organized the day before OSCON by Evan Prodromou and the team from Status.net. We spent the morning with each participant demo’ing their project or protocol for about five minutes. Below is my attempt to re-format my presentation as a blog entry.

---

My name is Rob Dolin and I’m a Program Manager on the Windows Live Social team. I’m also a co-author of the Activity Streams in Atom spec. You can find me on identi.ca as @RobDolin (and a few other places.) In the next few minutes, I’ll try to briefly explain:

What is “Windows Live” (from the perspective of federated social activities)
Where activity streams show-up
How can your project or service read activities from Windows Live
How can your project or service write activities to Windows Live
How can Windows Live direct users to your project or service

Windows Live as an activities generator, store, and display

Windows Live includes a set of web services, PC apps, and mobile apps:

Web services: Hotmail, SkyDrive, Profile, Groups, Spaces, …
PC apps: Messenger, Writer, Photo Gallery, Movie Maker, Mail, …; together “Windows Live Essentials” (WLE) – Download the WLE Beta
Mobile apps: Messenger for iPhone, Messenger for Windows Phone, http://m.live.com/, SMS Messenger

If you only do one thing to get a sense of how Windows Live integrates activities, I recommend downloading the WLE Beta and running Messenger.

Activity streams integrated throughout Windows Live and other Microsoft services

The activity stream from Windows Live (sometimes referred to as “Messenger social updates”) is integrated throughout Windows Live services and apps.

Windows Live Messenger

Windows Live Messenger has a new (default) full window view that dedicates more than 2/3 of the screen to the Windows Live activity stream:

Windows Live Hotmail

The new Hotmail homepage also includes a large area dedicated to the Windows Live activity stream:

The Windows Live activity steam is not just displayed in Windows Live branded properties, but it’s integrated into Outlook, MSN, and the forthcoming Windows Phone 7:

Outlook Social Connector

If you install the Outlook Social Connector for Windows Live Messenger, you’ll be able to see recent social activities of your contacts when you email with them:

As you can see above, the Windows Live activities stream doesn’t just include activities from Windows Live, in Douglas’s case above, it includes photos he shared on Flickr. Users can bring activities they have done from across the web into the Windows Live activities stream. I’ll explain more below about how you can enable your users to share activities from your service or app into Windows Live.

MSN

There’s also a new social module on the MSN homepage. On the USA homepage of MSN, this is in the right column:

Windows Phone

The upcoming Windows Phone 7 has a new “People” view that is powered by Windows Live Activity Streams:

How to Read Activities

On every one of the hundreds of millions of Windows Live users’s profile pages, there is a link to an Activity Streams (Atom) feed of that user’s publicly shared activities. You can easily get to this from your web browser by clicking the orange RSS/Atom icon:

This will take you to a feed of the user’s publicly shared activities on Windows Live. Try it on your own Windows Live profile: http://profile.live.com/.

You can view this in a web browser or your favorite RSS reader. And if you view the source of this feed, you’ll notice that it includes the <activity:verb> and <activity:object> elements of Activity Streams in Atom:

In addition to this link on profile pages to public Windows Live activities, developers can also read non-public activities (if a user gives permission) through the new “Messenger Connect” API’s. I’ll talk more about these below and you can learn more about these at http://dev.live.com/.

Activities in Windows Live from 75+ partners and growing

Since December 2008, users have been able to bring their social activities from dozens of services across the web into Windows Live. This has included services you likely know well like Facebook, YouTube, MySpace, Pandora, Hulu, and WordPress:

And this includes services from all around the world like AlloCine, Arto, Azbuz, Biip.no, Bilddagboken, Blingee, and more:

All of these integrations are powered by open standards including RSS 2.0, Atom 1.0, MediaRSS, Activity Streams in Atom, and at base, XML. In the next few paragraphs, I’ll briefly explain how you can add your project or service to write activities to the Windows Live activity stream so that they show-up in Messenger, Hotmail, MSN, Outlook, and Windows Phone.

How to Write Activities

There are three ways to enable your users to bring their activities from your project or service into Windows Live:

Badge
Feed
API

Writing Activities to Windows Live via Badge

The easiest way to write an activity to Windows Live is to have a user click a “badge” link. For example, try clicking this link: http://profile.live.com/badge/?url=http://status.net/2010/06/28/federated-social-web-summit-2010-announced. This takes you to a page (below) where you can add your own user message and confirm that you want to share that particular URL. As a developer, you can replace the “url” QueryString parameter with whatever URL your user has indicated he or she wants to share.

The http://profile.live.com/badge/ page will pre-populate a page title, description, and screenshot image for you from the page, OR you can pass these in as QueryString params to specifically populate them. You can also pass a return URL as a QueryString param so the user gets redirected back to your site after they share the link.

More details on the “badge” are at: http://msdn.microsoft.com/en-us/windowslive/ff796213.aspx including sample code you can quickly cut and paste into your own website:

Writing Activities to Windows Live via Feed

If your service has RSS, Atom, MediaRSS, or Activity Streams (in Atom) feeds, you can enable your users to tell Windows Live to poll their activity stream feed from your service. To set-up your service, you get an Application ID and fill-out a relatively simple form at: http://manage.dev.live.com/

As shown below, this will ask you for some basic info like your Home page URL, Sign-up URL, Support URL, and of course, Feed type:

You’ll also tell Windows Live how to compose a URL to retrieve your feed. For example below, Windows Live asks users to enter a “User name” and then uses the “replacement patterns” you specify:

Windows Live gives you a variety of choices for “User input label” and has these values translated into over 40 languages so you don’t need to know how to ask a Hungarian user for their email address.

After you’ve set-up Windows Live to know how to poll your service’s feed, you can direct users to the page where they can add your service: http://profile.live.com/services/add.aspx?AppID={YourAppID}&ru=http://www.YourService.com/return. You can even pass a “ru” QueryString parameter to specify the “return URL” for Windows Live to direct users to after they have connected Windows Live to your service. To get started, go to http://manage.dev.live.com/.

For each user who connects your service, Windows Live will start polling relatively frequently (every 30-60 minutes) and then start polling less frequently for less active users on your service.

If your service already has RSS, Atom, or Activity Streams feeds, this is likely the easiest way to help your users bring their content into Windows Live. To get the nicest looking results (i.e. photos treated as photos, etc.) you might just need to add a few <activity:…> elements as described in the “Choosing your Activity Type(s)” section below.

Writing Activities to Windows Live via API

Finally, your service can also write activities to Windows Live via our “Messenger Connect” set of API’s. You’ll set-up your connection to Windows Live and similarly point your user to an add.aspx page passing-in your AppID. The user will consent to have you write activities on their behalf (and possibly do other things like read and write SkyDrive photos or Messenger contacts ) and the user will be returned to your site (or client application) along with a token you can use to make calls on the user’s behalf.

To push write activities to Windows Live, you’ll make HTTP POST’s where the body of your request is in the Activity Streams in Atom format. The below screenshot from the online documentation describes how this gets rendered:

While there are potentially hundreds of <activity:verb> + <activity:object> combinations from Activity Streams, Windows Live supports a large portion of the most common combinations:

More details on publishing activities to Windows Live via API can be found at: http://msdn.microsoft.com/library/ff748785.aspx.

Choosing your Activity Type(s)

(This section was added at the suggestion of my colleague, @AngusLogan)

Whether you’re writing via feed or writing via API, if you choose a specific pairing of <activity:verb> and <activity:object-type>, users will potentially see your activity looking differently. For example:

A “Post” of a “Status Update” is displayed in Messenger as:

A “Post” of a “Photo” or a “Post” of multiple “Photo” objects in a target “Album” looks like:

A “Post” of a “Bookmark” looks like:

And a “Post” of a “Blog-entry”:

There are about a dozen more variations and you can see examples of what all of these look like on the web and what the XML for these looks like at: http://msdn.microsoft.com/en-us/library/ff748785.aspx.

Thank you, more?

I hope that you found this blog entry both useful and informative. To learn more:

Download Windows Live Essentials for PC and/or Messenger for iPhone
Connect some of the services you use: http://profile.live.com/services/
Check-out Messenger Connect and all of the great information at http://dev.live.com/

Leveraging Activity Streams, you can read activities from Windows Live into your app or service; and write activities from your app or service to Windows Live so your users and their friends will see them in Messenger, Hotmail, MSN, Outlook, Windows Phone, and more.

Thanks very much for reading and for your interest in Messenger Connect—

--Rob Dolin
Program Manager, Windows Live team

P.S. If you enjoyed this blog entry and would like to see more blog entries along similar topics, please leave a comment explaining what you’d like to learn more about.

Realtime Shared Experiences with Messenger Connect

Angus Logan — Mon, 28 Jun 2010 17:36:00 GMT

Communication and sharing has emerged over the past few years as a critical element making experiences more personalized and compelling across the web. Lots of sharing is done asynchronously (via activity feed or email), but for some things you want real time sharing (it is tough to view photos or watch a TV show together asynchronously ). The challenge is: how do you know when your friends are available to engage in a real-time sharing experience, knowing the “presence” of your friends is important because it can shape how you engage with them. Having an always-on real time client is essential, because the likelihood of both users being on the same website at the same time is low except for very special circumstances. Connecting to a persistent chat client via a third party website is necessary to deliver on these scenarios.

People want to be able to share experiences like inviting a friend to a site in realtime, chatting with their friends without context switching, and see who else is on the web site. By integrating Messenger, the #1 most used free instant messaging service in the world (see some staggering stats) into your site you will be able to:

Let users connect with their friends in a differentiated, more personal mode of communication
Reach their friends no matter where they are, on your web site, on their phone, in one of the many Messenger clients (Windows, Mac, iPhone, etc.)

By adding real time experiences to your site, you are in essence making the site do something it didn’t do before, and conversations are “sticky”, therefore user engagement will go up.

Some shared experiences you can add to your site are:

Targeted (to one person or a few people), real time sharing of content. An example of where this is useful is sharing a picture that you want to discuss, or collaborating on travel plans – things that require realtime action by the other party.
Creating immersive experiences and reducing context switching - if someone is watching your glorious full screen video or playing an immersive game, they may be worried they’ll miss conversations or not be able to chat with their friends, embedding chat in your media consumption or game play experience will reduce context switching.
Rendezvous (are my friends on this site?) – for high traffic properties such as live streaming events or video play back, being able to tell if your friends are on the site (after opt-in of course) can drive more time on the site and shared experiences.

Implementation Options

There are a range of implementation options ranging from simplest (least amount of time to code) to most flexible:

Sharing Badge – the sharing badge can be added to a site with just a few lines of HTML and can allow users to publish/broadcast to Messenger Social or IM content to one of their friends

Chat control for real time events – to allow users on the same page to leave real time messages for each other. Users will be able to see the messages from their friends and others on the site.

UI Controls – a set of JavaScript building blocks which can be combined to speed up development. These controls can be easily skinned using CSS and extended using JavaScript. Try the Controls Playground.

JavaScript Library – the most advanced and most powerful way to integrate real time experiences into your site.

To get started adding real-time shared experiences so your site, check out this documentation.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Identity (authentication, profile & relationships)

Angus Logan — Mon, 28 Jun 2010 17:36:00 GMT

There are over 500 million Windows Live IDs that are used every month. That is a lot of users who can sign into web sites. In addition to base level authentication you can also pre-fill registration forms with things such as the user’s email address, so that information doesn’t need to be manually typed again and again (remember this video?). Users are able to quickly sign in and sign-up without needing to enter a username and password. Many users will already be signed into Windows Live (e.g. Hotmail) so they won’t need to enter their password again and can effectively sign into your web site in 2 clicks (1 on the in the page, 1 within the popup window).

There are several additional things we’ve been working on from a user experience perspective. We’ll cover these in more detail in subsequent posts but they include:

Conditionally showing the sign in button if the user has recently signed into Windows Live ID (more technical info)
Registration forms can be customized based on the email address the user entered. E.g. if a user typed @hotmail.com (or any other email address in a Windows Live namespace) the registration form could be tweaked to encourage use of Messenger Connect (more technical info)
Inbound traffic such as email marketing/invitations to @hotmail.com addresses or Messenger social updates could include some parameters to tell the web site “the user came from Windows Live” to encourage them to sign in/sign up quickly using Messenger Connect (remember when Plaxo got 92% conversion?)

For more information about the underlying technology of authentication, see this post or this page.

My contacts/relationships are part of my identity too

Another thing we’ve heard from customers, and observed on the web, is that customers want to be able to automatically find their friends on a web site or be able to invite them to a site via email. Historically the Windows Live Contact API enabled users to take their entire address book with them to another web site for the purposes of friend finding (indexed by email) and friend inviting (by sending an email), or in very specific circumstances migrating their address book.

We believe in these scenarios, they are important, and we think they add value to users and partners. However, we also believe in sharing the minimum amount of data required to let a user complete a desired action (more info). To that end, in the near future, we will deprecate the existing Windows Live Contacts API and remove email addresses from the Messenger Web Toolkit JavaScript Object Model. We will post more information regarding the specific timelines and what this means if you are using these interfaces. Moving forward, access to the entire address book (including email addresses of a Windows Live user’s contacts will be restricted (more info). We are working hard on building public APIs (subject to the Terms of Use) to enable the find my friends by email address & invite via Email APIs – look for another post on this topic in the near future.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Developing with Messenger Connect: Recognizable & intuitive

Angus Logan — Mon, 28 Jun 2010 17:35:00 GMT

The primary goal of Messenger Connect is to help web sites & apps grow their traffic and engagement, at a reasonable cost. To that end, the technical implementation and business terms have been designed to be predictable for web developers and marketers who are familiar with the social connections domain.

First question I get asked: Is Messenger Connect standards based?

We’ve tried to make Messenger Connect as easy as possible for developers to implement. Where possible, the latest emerging specifications and standards have been implemented and Microsoft engineers are actively involved in the community to help evolve the technologies which enable the relatively new use case of social connections. Some of the technologies we have implemented or contributed to are: OAuth WRAP, Portable Contacts, ActivityStrea.ms, and OData. What about the next big thing? As new technologies are created, and developers ask us to implement those technologies, we will work with the community and evaluate adding them to the mix.

Implementation options

Messenger Connect can be used on web sites (and other apps) to provide Windows Live users access to their information and communicate/share with their friends. This access to information and friends is made possible by several types of programmatic interfaces:

Badges – simple HTML tags that can be added to a page
JavaScript APIs (including user interface controls) which execute within most popular browsers and talk directly to the Windows Live services
.NET APIs which can be used in server-side ASP.NET code or in rich client applications
RESTful services end points which can be called in a server-to-server manner

Badges

Some developers don’t want to write JavaScript or server side code. That is OK. Our sharing badge can be simply added to a page in a few lines of code.

<a href="http://profile.live.com/badge?url={your URL}" title="Share with Messenger" target=”blank”>
  <img style="border-style:none; vertical-align:middle; margin-right:4px" 
     src="http://img.wlxrs.com/$Live.SN.MessengerBadge/icon16wh.png" 
     alt="Share with Messenger" />Messenger</a>

Try it: Share

Consent, access, privacy, data rights, revocation

We recently posted about the privacy aspects of Messenger Connect (read it here). We strongly believe that users own their data and they should be able to share or access it from the websites and applications they want to. Web sites cannot access any of a user’s non-public information from Windows Live without prior consent (see the experience below) from the Windows Live user. App developers are encouraged to only request the bare minimum of permissions required to complete the desired scenario in a just in time manner (E.g. if a user is signing up, ask for their profile, if a user is adding something to their calendar, ask for calendar write permissions). If a user chooses not to grant permission for the site to access what they requested, the web site must handle the exception flow and reduce the permission requests, or explain why those permissions are required.

If the user leaves the “Remember this connection” checkbox checked (it is checked by default), the web site will be granted permission for 1 year (or until the user revokes the permissions). If the user unchecks the “Remember this connection” button, the web site will get access for 3 hours. At any point in time the user can browse to http://consent.live.com and revoke the permissions they previously granted the web site. After the token expires, or the user revokes permission, the web site would get 401 Unauthorized errors when trying to access the data, and would need to re-request that the user grants permission.

The web site renders a “sign in” button either manually by creating HTML, or using the wl:signin tag. If the web site uses the wl:signin tag (more info), an additional attribute can be added to only show the sign in button if a Windows Live cookie exists.
The user browsing the website (e.g. www.example.com) and sees a Messenger Connect button and clicks Sign In. To ensure the most Windows Live users know they can “Connect”, the iconography used for button will be aligned behind a single brand used across all “non-Windows Live” web sites (i.e. the current Hotmail / Messenger / Windows Live / SkyDrive brand fragmentation will be reduced in “off-network” scenarios).
A popup window is opened which includes the partner’s logo, a link to their Terms of Service and Privacy Statement. The partner must clearly outline in their ToS & Privacy Statement what they will be doing with the permission granted by the end user.
The user can click “What will I share?” to see each individual permission the partner is requesting.

If the user grants permission, a token is returns to the site, and the window will be closed.

One a website has been granted the appropriate permissions and has received the token, access to the user’s Windows Live data & services is possible through two interfaces: JavaScript & RESTful interfaces.

The permission granted is for 1 year (unless the user unchecks Remember this Connection). If the web site wants to access the Windows Live resources without the user being present, or without the user seeing the Messenger Connect consent screen again, the token should be stored alongside the user’s profile in the partner’s website.

If the user changes their mind and no longer wants the web site to have the ability to interact with their Windows Live account, the user can go to http://consent.live.com to revoke permissions at any time. If the partner tries to interact with the user’s Windows Live account after consent has been revoked, they would get “unauthorized access” errors and would need to re-request access from the user.

JavaScript libraries & user interface controls

Adding a script reference to the Messenger Connect dynamic loader enables access to a wide range of Windows Live data and Messenger features, including IM conversations. Developers can choose to use the data objects only or can add UI elements such as <wl:signin>, <wl:userinfo> or <wl:bar> to their page. You can experiment with the data model and controls hands-on using our new interactive SDK at http://isdk.dev.live.com/.

RESTful service endpoints

A set of cloud endpoints are available to web sites and applications for the purposes of accessing and managing user data. Generally the RESTful service endpoints will be used for web sites that want more of a “roll your own” approach to data access. Additionally, the RESTful endpoints are useful for sites that want to access the user’s data while the user is not present (for example: out of band processing of data - each week the website could make a call to Windows Live to download a user’s address book to see if some of their Windows Live friends have joined the web site).

These endpoints are multi-headed (the data is generally available in several formats), and can be queried and sorted. If developers prefer the data to be returned in several formats this is easily configurable using the $format query string key (for plain XML $format=XML, for JavaScript Object Notation (JSON) use $format=JSON, the dynamic formatting is also applied to emerging specifications/standards such as $type=portable). Additional formats for representing user data will be added based on partner feedback.

The RESTful service endpoints are also intelligent and most data-types exposed will support filter, select, orderby, and count the protocol used is the Open Data Protocol (OData).

Developer tooling

To make it easy for developers to kick the tires, we’ve created a few tools: the Controls Playground, the API Playground, and the REST Explorer – these tools will evolve over time as we see where developers need help. In a future post we’ll share details about the statistics which will be available from the application management portal.

The Controls Playground lets you quickly preview the Windows Live UI controls in action, customize controls and see results in real-time and also generates markup for these controls for you to copy, paste in your application.

The API Playground lets you try out the API service to see what type of interactions are possible:

Select common tasks such as adding a new contact to Windows Live, and preview the code
See common API usage patterns
Run API code, using sample data, and see the output in real-time
See the underlying REST HTTP traffic including request and response

The REST Explorer lets you interact with the RESTful endpoints directly against your own Windows Live ID.

If you have any questions about the different ways of developing with Messenger Connect, please visit our forums.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Social Distribution

Angus Logan — Mon, 28 Jun 2010 17:35:00 GMT

Messenger social is the “newsfeed” which is associated with a Windows Live user and shown to their Messenger contacts across Windows Live, including Messenger and Hotmail. The new Messenger full view is optimized for showing users their friend’s activity across a range of sites. For a limited set of partners (Facebook and MySpace today, LinkedIn coming soon) it allows users to comment inline back to these sites. For others, it allows users to share activities with their friends in Windows Live and enables users to click through to partner sites.

The simplest and most unique is the Messenger Connect sharing badge. This badge operates like other sharing badges, resulting in a social update. If the user chooses to; they can send an instant message to one of their Messenger contacts and have a conversation in real time about the content.

An individual entry in the newsfeed (aka activity) is known as a social update in Messenger. There are many different types (~ 20) of activities (e.g. pictures, comments, ratings), and when clicked they drive traffic back to the partner’s website.

The supported templates will be evolved on a quarterly basis as new activities become popular. Messenger Connect uses the ActivityStrea.ms format which is an emerging specification for making user activities portable.

A screenshot of the new Windows Live Messenger in full mode, activities appear on the left hand side

Screenshot of Messenger social in the Windows Live Messenger for iPhone

For a website to publish to Messenger social, push (via JavaScript and REST) and pull interfaces exist. The pull interface can be done with existing RSS or Atom feeds with minimal modifications. Below is an example of a comment and the corresponding Atom feed:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"      
 xmlns:activity="http://activitystrea.ms/spec/1.0/"  
 xmlns:thr="http://purl.org/syndication/thread/1.0" 
 xmlns:media="http://purl.org/syndication/atommedia">
  <title>Title of the feed</title>
  <id>http://www.contoso.com/profileid</id>
  <link rel="alternate" type="text/html" href="http://www.contoso.com/profile"/>
  <updated>Mon, 10 May 2010 14:12:21 GMT</updated>
  <entry>
    <id>http://www.contoso.com/profileid</id>
    <title>Cool Stuff</title>
    <published>Mon, 10 May 2010 14:12:21 GMT</published>
    <updated>Mon, 10 May 2010 14:12:21 GMT</updated>
    <link rel="alternate" type="text/html" 
     href="http://www.contoso.com/link_to_content"/>
    <content type="html">I think this is cool</content>
    <activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
    <activity:object>
    <activity:object-type>http://activitystrea.ms/schema/1.0/comment
    </activity:object-type>
      <title>Cool Stuff</title>
      <link rel="alternate" type="text/html" 
       href="http://www.contoso.com/link_to_content" />
      <link rel="preview" type="image/jpeg" 
       href="http://www.contoso/thumbnail.jpg"/>
      <summary>I think this is cool</summary>
    </activity:object>
  </entry>
</feed>

To let your users share activities from your site with their friends in Messenger social, visit this page. Additionally, if you know what the next big social activity type will be, leave us a note in the forum.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Messenger Connect – Making your data more portable while retaining control over its use

Angus Logan — Fri, 25 Jun 2010 23:30:47 GMT

Last week Omar Shahine blogged about our new privacy features in Windows Live, where we’ve made some improvements that we hope you will appreciate and find both powerful and easy to use. We also recently announced Windows Live Messenger Connect, an exciting new feature set that enables you to easily connect to Windows Live from third party applications and lets you take your Windows Live experience and data, with your consent and at your discretion. Additionally, we also announced the new Messenger (try it now), which provides the most complete picture of what your friends are doing across your social networks and other sharing sites, including comprehensive integration with Facebook, LinkedIn, and MySpace.

We believe that you should be able to choose to take your Windows Live data with you when you travel the web. Messenger Connect allows you to do that by providing a way to sign in to third party web and client applications using your Windows Live ID. Messenger Connect allows you to bring your Windows Live profile and contacts with you; easily share with your friends and enable Windows Live Messenger-based chat within third party applications; and access your photos, calendar, and more. In order to enable third party applications to ‘connect’ and interact with Windows Live accounts, we needed to design to help to ensure that customers’ data is protected and accessed in a manner consistent with customers’ expectations and desires, as well as enable great partner experiences. These principles guided our design work:

Principle 1: Data portability (you own your data)

As a top-level principle, we believe that customers own their data. Your identity and profile, your address book, your newsfeed, your photos, your documents: as a Windows Live customer, you own all that data. So you should be able to take that data with you. Our role is to help you protect your data, help you make informed decisions about how your data is accessed and updated, and help you port your data to other places like the PC. That means that if you would like to access your Windows Live data from a different third party service, or even take your data completely to another service, you should be able to do that. To enable this, we give you ways to export your data from Windows Live into common formats, so that you can import it to wherever you like, as well as in many cases make this more seamless with direct integrations with partners. In a world where people are connecting services back and forth from each other, this can be complex. Just to be clear, when you connect one of your social networks (like Facebook, MySpace, and LinkedIn) to Messenger, any of your data or your friends data made available to Messenger via those connections is governed by our partners’ policies and our agreements with them.

Principle 2: You have control over your data

As Omar discussed in his post, customers should be able to easily control who has access to their data in Windows Live. You entrust Windows Live with your data, and it is only available and accessible within Windows Live. But we also know that you may want to be able to access your Windows Live data in the third party applications or websites you use. For example, you may want to share your photos or other non-public data with your friends. We make it possible for you to do so, but you have to give us your consent first. And, if at any point, you decide you would like to revoke a partner’s access to your data – you should be able to easily do so.

Principle 3: Right data for the right scenario

We believe that third party applications that access Windows Live should only access the minimum amount of user information required to complete the desired scenarios. For example: if a web site only needs permission to publish social updates, they shouldn’t also request permissions for reading photos.

Messenger Connect: Making my data and my friends data available in a responsible manner

There are cases where challenges and tradeoffs between privacy and data portability exist. An example of this tension is where a customer would like to share their complete address book with a third party, and that address book contains information such as email addresses and phone numbers. The contents of my address book are a combination of “my information” as it is “my address book” but may also include my friends’ email addresses and phone numbers. These shared data ownership scenarios are complex and have informed our design choices.

Independent of the information type or service access being made available, we have been working to replace unauthorized “screen-scraping” models, which require customers to share their usernames & passwords (“credentials”) in an unsecure manner with many sites, with the use of safer, legitimate APIs. The use of legitimate APIs and clear user consent flows have been important across the industry as they provide a safer alternative to requiring customers to share their credentials with third parties. Moving third parties away from screen scraping and the practice of asking users for their credentials without the use of APIs that use delegated authentication (more info) is important because when you share your credentials in the clear these websites can now act on your behalf. Even if a web site is not malicious, your credentials could be exposed if the third party service is compromised. Use of APIs helps to promote customer credential security, enables selective disclosure of information and the ability to revoke access.

To help us safeguard customers’ privacy and enable partner scenarios, we’ve created two distinct tiers of partner access policies. Both tiers require explicit customer consent, and follow the same security model, but are available for different group of third parties.

Public APIs: Our “Public APIs” are available to all developers and third parties to access in a self-service manner. Appropriate use is governed by our Terms of Use and Terms of Service, and is monitored for abuse reported by customers. Third parties can sign-up for access through our application management tool at http://manage.dev.live.com.
Restricted APIs: Our “Restricted APIs” allows third parties to access more sensitive information on behalf of customers. Therefore, these APIs are reserved for a select group of third parties explicitly approved by Microsoft, and meet clear and consistent criteria.

It is worth noting that within each policy tier, we have provided many ‘granular access scopes’, which allow third parties to request access to specific sets of data to complete a specific scenario. You can learn more about these scopes here.

The experience

So, let’s take a quick look at what the experience looks like when connecting with third party applications through Messenger Connect.

Sign-in and consent. When you click a Windows Live ‘Connect’ button on a third party website (explicit customer content is required), it initiates the sign-in and consent experience.

The initial screen provides you with the ability to sign in with your Windows Live ID, and learn about the level of access the third party application is requesting.

Making informed decisions. When you click the “What will I share?” link, you get detailed information about the specific pieces of data and capabilities the application is looking to access.

Managing access to your data. At any point, you can edit your permissions for any third party application within Windows Live and revoke its access to your data.

Reporting abuse. In addition, we provide “Report abuse” links from the Windows Live services so that you can inform us of any application that may be violating our Terms of Service, or generally behaving in a way you find inappropriate. In extreme circumstances, we also have the ability to suspend or revoke a third party application’s ability to use Messenger Connect, thus automatically revoking any permissions a customer granted the third party.

I hope this post has given you some insight into how we approach your privacy in Messenger Connect. As Omar previously noted, this is a challenging problem with many complex dimensions, and one that many in the industry continue to struggle with and refine. We are committed to continuously listening to our customers and partners, and together improving the experiences, technologies, and policies.

Angus Logan (@anguslogan)
Senior Technical Product Manager
Windows Live

Welcome to the Windows Live for Developers Blog

Angus Logan — Wed, 16 Jun 2010 20:50:45 GMT

Hi everyone, I’m Angus Logan (@anguslogan), the Senior Technical Product Manager for Messenger Connect. As we lead up to the launch of Messenger Connect, I want to start a conversation with app developers and marketers. We are consolidating a few of our Windows Live developer related blogs into one place… here!

We hope this blog will complement the Inside Windows Live blog, which Chris Jones describes as “dedicated to software engineers, web industry insiders, and to our most passionate Windows Live customers, those who want to dig a little deeper into how we build our services and how they’re used worldwide”.

The posts will include but are not be limited to:

Code tips and tricks - code-a-plenty from JavaScript to RESTful endpoints with a little AuthZ/N mixed in.
User experience guidance - Most motivation for using something like Messenger Connect is to make life easier for users. People who don’t know what connecting is should be guided by an intuitive user experience to connected bliss. There are lots of tricks we are constantly learning in the social web space; we’ll cover some of those here.
Trends & emerging specifications - I love the community around the social web. The technology moves fast and the concepts do as well. As emerging specifications or trends that relate to Windows Live come up, we’ll post our thoughts and ask you for yours.
Measurability - Writing code is fun, but even science experiments need measurement. At the Open ID User Experience workshop in Chicago, I mentioned the most important thing for the year will be web sites/developers showing value for all the social technologies they integrate. I’m a bit of a metrics nerd. I will definitely cover how you can measure the impact of integrating social into your site/app. If we didn’t measure, how else would you know which Feature to kill (WARNING: Dave McClure’s presentations aren’t for the faint hearted)
Service updates - We’ll use this blog to keep you informed of upcoming service, policy/guidance, and technical changes

If you are interested in connecting with the Windows Live audience, subscribe now – if there are other things you’d love us to cover, leave a comment below.