Back in January, we released the first version of Microsoft OneNote app for iPhone. Today, the OneNote team has announced that there’s a new version available (1.2) which introduces search, shared notebooks, and more customization options. OneNote app for iPhone will now also be available in 5 additional markets: Canada, the UK, Ireland, Australia, and New Zealand.

If you want to be able to access your OneNote notebooks from wherever you are, OneNote on SkyDrive is a great solution for you.

In this release, you’ll be able to sync shared notebooks and work with others directly from your iPhone, keep specific notebooks from syncing to your iPhone, and search for text across all of your notebooks. If you’re an iPhone user, you should never again be without your vacation plans, your recipes, or your to-do list.

Stop by the OneNote blog to see the full feature list.

The OneNote team does read all comments and reviews in the App Store and also actively monitors the OneNote forum on the Microsoft Answers website. Please do spend the time to provide feedback and rate the app after you’ve used it – the team is listening!

Mike Torres
Group Program Manager, SkyDrive Devices and Roaming

We all take a lot of photos. In fact, according to data provided by InfoTrends, more than 73 billion still images were shot in the US alone in 2010. If you’re lucky enough to own a DSLR (digital single lens reflex) camera, you’re likely to take two and a half times as many photos in a given month as your friends with point-and-shoot cameras. That’s a lot of photos. What’s more, nearly a quarter of those photos are taken in a raw image format.

For those of you who are unfamiliar with raw format, it is the uncompressed output from each of the original pixels on the camera’s image sensors. Raw files have several advantages over JPEG files including higher image quality, finer control, and more image information. Think of them as big, digital negatives waiting to be processed.

We know from customer feedback that dealing with raw images on Windows hasn’t always been easy. While there is software that works well to convert raw files to JPEG, we have some good news for consumers looking for a built-in Windows solution. Today we’re happy to announce that Windows Live Photo Gallery 2011 now supports raw format images. Just download the Microsoft Camera Codec Pack for Windows 7 and Windows Vista to be able to view raw photo files from more than 120 DSLR cameras in Photo Gallery, as well as in Windows Explorer.

Viewing is only part of the story. Photo Gallery will also support editing copies of your raw images. Because raw files are like digital negatives, they’re protected originals, not to be altered or harmed. We know your originals are precious, so if you want to alter a raw image, Photo Gallery makes a copy of the raw original and converts it to either JPEG or the far superior JPEG-XR (or HD Photo) format. With JPEG-XR, all of the quality of the raw original is there so you can fine-tune different editing effects. You can fix red-eye, remove blemishes, or make detailed image adjustments with confidence knowing your original raw file is safe. When you use your raw files to construct an amazing panoramic stitch or Photo Fuse, a new file is generated and you get an even higher quality result than before.

With the new codec pack, Windows will now support viewing and editing a wide range of photo file formats including raw, JPEG, PNG, TIFF and more. This new update unlocks the power of every photo on your computer so that your PC is capable of organizing, viewing and editing your digital memories, whether they were shot with a camera phone, point-and-shoot camera, or a higher end DSLR. So keep shooting all those great photos! And if you’re lucky enough to own a camera that supports raw, give it a try. If you’re already shooting in raw, we hope we’ve just made your life a little easier.

Brad Weed

Group Program Manager, Windows Live

With the recent release of our developer platform we’ve made it easy for developers on modern mobile platforms such as Windows Phone, Android, and iOS to easily integrate the ability for users to access their information such as contacts and photos from Hotmail, Messenger, and SkyDrive in their favorite mobile apps and devices.

We’ve streamlined the process for doing this in the following ways:

• Lightweight application setup process which requires no server-side code.
• Mobile optimized sign-in and user consent experiences
• Providing code samples which illustrate the key steps in building a mobile application that access a user’s cloud data

Lightweight application setup process

One key thing we learned from our previous releases is that developers of mobile applications often do not have web services backing their applications. This means that any process we had that requires an application to communicate with our various authorization and web service end points would need to be enabled for client-side applications.

Today, our registration process at http://manage.dev.live.com is extremely lightweight. The only information required to create an application is the name and language of the application, as shown below:

Once you click I accept, you are provided with a client ID and client secret.

Those familiar with OAuth 2.0 may notice that a step appears to be missing: providing the URL the user is redirected to after they have successfully logged in and granted access to your application to access their data. This step is now optional. Web-based applications can still provide this data on our application management site.

Mobile and desktop applications that do not have a website that the user can be redirected to should instead use https://oauth.live.com/desktop as their redirect URL when making OAuth 2.0 authorization requests. This URL should not be provided as the redirect URL for the mobile application in the application management site since it will be rejected.

Mobile optimized sign-in and user consent experiences

As mentioned in my previous blog post, we’ve built mobile optimized user experiences for users signing in and granting permission to applications to access their data.

We’ve created a code sample which shows how to access a user’s SkyDrive photo albums from Windows Phone and is available to download from the MSDN code sample gallery. The code sample shows the key steps an application has to go through to sign in the user, get permission to access their data, and then actually access the user’s information as well as the related user experiences.

The process of signing in the user requires the application to construct a URL to our OAuth 2.0 authorization end point and request the appropriate scopes required to access the data the application is interested in. The code looks like this:

/// <summary>
/// The URI for the OAuth service's Authorize endpoint.
/// </summary>
private static readonly string OAuthAuthorizeUri = "https://oauth.live.com/authorize";

/// <summary>
/// The list of scopes.
/// </summary>
private string[] scopes = new string[] { "wl.basic", "wl.photos" };

/// <summary>
/// Build the OAuth URI.
/// </summary>
/// <param name="scopes">The requested scopes.</param>
/// <returns>The OAuth URI.</returns>
private Uri BuildOAuthUri(string[] scopes)
{
    List<string> paramList = new List<string>();
    paramList.Add("client_id=" + HttpUtility.UrlEncode(MainPage.ClientId));
    paramList.Add("scope=" + HttpUtility.UrlEncode(String.Join(" ", scopes)));
    paramList.Add("response_type=" + HttpUtility.UrlEncode("token"));
    paramList.Add("display=" + HttpUtility.UrlEncode("touch"));
    paramList.Add("redirect_uri=" + HttpUtility.UrlEncode(MainPage.RedirectUri));

    UriBuilder authorizeUri = new UriBuilder(MainPage.OAuthAuthorizeUri);
    authorizeUri.Query = String.Join("&", paramList.ToArray());
    return authorizeUri.Uri;
 }

When the constructed URL is navigated to in a browser, the end user goes through the following user experience. First they are asked to sign in.

After signing in, the user is shown a permission dialog where they are asked for consent to grant the application access to their basic information and SkyDrive photos, which the application requested.

Once the user completes these flows, the application gets back an access token which can then be used in combination with our REST APIs to access the user’s data. It should be noted that the permission granting step only has to occur once, after which the application has access to the user’s data until the user decides to revoke access to their data by visiting our consent management page.

In this particular code sample, the application simply lists the user’s profile information and SkyDrive photo albums.

More Code Samples to Come

We’ve gotten a lot of feedback that developers would like to see more code samples that show how to access data from Hotmail, Messenger, and SkyDrive from their favorite programming languages and platforms. Rest assured that your feedback has been heard, and we’re working on providing a larger breadth of code samples as we speak. For now, mobile developers can download the SkyDrive API example from this article to get started.

Thanks again for all the feedback, and please keep it coming.

Dare Obasanjo – Lead Program Manager, Messenger Connect Platform

We hope you’ve had a chance to try the new version of SkyDrive that we shipped a few weeks ago. You probably noticed that the performance of the web experience has been dramatically improved and redesigned for simplicity. In this post, I’m going to cover a few of the things we did to make the new SkyDrive web experience faster.

Our overall goal in the new SkyDrive architecture is to use HTML5 and modern browser capabilities to reduce or eliminate page loads and make each click feel nearly instant.

The old version of SkyDrive was based on a server-rendered architecture, which meant that every time you clicked on something in a SkyDrive web page, SkyDrive would essentially do a complete server-generated page load. A page load is a very slow process which generally takes many seconds to complete due to the lack of client-side caching and numerous client-server round-trips. This meant that every user action would take at least a few seconds, which was clearly not ideal. This was a “least common denominator” approach that catered to people with old browsers.

As our tens of millions of users upgrade to modern browsers, we can take advantage of new capabilities and move to an intelligent AJAX architecture. The key to making AJAX performance great has to do with intelligent client network utilization since the client network is usually the biggest bottleneck to performance. We focused on four distinct things related to intelligent client network utilization:

1. Reduce the number of client-server requests (client-side caching).
2. Reduce the payload size of each request (get only what you need and compact protocol).
3. Reduce the number of “miles” a request has to travel (put servers/Content Delivery Networks close to users).
4. Make the most out of each request (utilize batching and pre-fetching).

So, let’s go into the details of what we did.

Eliminating page loads

This new SkyDrive architecture harkens back to the days of AJAX in many ways, in fact it basically is AJAX. When we first attempted to move to AJAX, earlier in the previous decade, we ended up with pretty slow web experiences. A combination of issues contributed to this, such as browsers that were slow and brittle with JavaScript, slower end-user network connections, usage of XML which was big and slow to parse, and a lack of client-side caching.

Today, modern browsers are much faster and robust at JavaScript execution than they were 8 years ago and we’ve switched to JSON as our protocol format which is lightweight. We’ve also gotten much better at client-side caching and we’re continuing to perform data requests asynchronously so that the web experience isn’t suspended while we wait for the server to respond. It’s tricky to make this all work well across all of the major browsers, but that’s our goal.

There is still a page load when you navigate your browser to SkyDrive. The very first time you visit SkyDrive (we call it PLT1 – first page-load) is slower than future visits (we call that PLT2) because we have to download a set of static resources from Content Delivery Networks which get cached on the client.

AJAX generally requires more client-side resources because more is happing on the client. We do some tricks to improve PLT1 such as pre-downloading SkyDrive resources when you’re at the login.live.com page so that they are already on the client by the time you get to SkyDrive. The other trick we do is to delay the download of a specific set of resources that are not needed immediately within the SkyDrive experience. (WebIM is a great example of this.)

Another page load optimization that we made was around how we generate the HTML page from our ASP.NET web servers. We used to wait to return the HTML page to the browser until we had constructed the entire page. To generate the SkyDrive main web page, we have to call multiple back-end systems and returning the HTML page to the browser was contingent upon these back-end calls completing.

The improvement we made was to flush and return HTML fragments to the browser as soon as they’re ready on the server. The key advantage here is that we can give the browser the HTML fragments that reference script and CSS almost immediately so that the browser can start downloading those resources (if not already cached) in parallel to other work that our server is doing (e.g. back-end calls). The idea is to get more working (especially networking calls) happening in parallel across the entire distributed system (client and server).

You may still notice that some parts of the new SkyDrive experience still require a full page load, such as editing the permissions of a folder, deleting a file, or arranging photos in an album. Right now, we only moved the SkyDrive file browsing experience and the photo viewing experience to the new AJAX architecture, but we will move the rest of the site in future updates.

HTTP/JSON data access protocol

As I mentioned, the biggest change we made was around moving the SkyDrive file browsing experience to AJAX, which means we render the SkyDrive user experience on the client. This allowed us to eliminate full page loads and make browsing feel instant. To move to this client-driven, client-rendering model, we needed the ability to fetch SkyDrive user data (not HTML) from our servers, so we built a data access protocol which is based on HTTP and JSON.

The data access protocol allows us to efficiently fetch the user’s data that is required for whatever the view the user has chosen in the web experience (e.g. show the first 20 out of 100 documents sorted by name, in the “School Project” folder).

The data access protocol supports sorting, filtering, and paging; and the API essentially maps one-to-one with the types of views that the user can generate from within the experience. The key is that we can perform one server request to fulfill a view.

It’s important that our servers are able to execute and return data via this API quickly. We achieved this by performing all of the data sorting, filtering, and paging in our SQL Server database tier. We used to pull a large swath of data out of our SQL Server and then manipulate it on our ASP.NET servers, which was inefficient. The optimal thing to do is rely on the power of SQL Server to optimize and execute queries in a way that lets us get back and return only the data that we need.

As I mentioned, we also use the JSON data format for this data access protocol which is network efficient, and browsers can parse it really fast. Since we’re almost always fetching just one page of user data, most of our data requests are only a few KB in size and are returned in milliseconds (of course depending on the end-user client network bandwidth).

The data returned via this data access protocol is cacheable by the browser. Client caching is really the biggest win when it comes to improving the performance of the experience. When a data request can come out of the client cache, it’s the most optimal outcome. In addition to the experience being faster, it also means that the request isn’t hitting our servers, which means our servers don’t have to do as much work, and it saves us money (we can have fewer servers). I’ll explain more on how we are caching user data below.

One other trick that we’re doing is that when you first go to SkyDrive and we do a full page load, we return the top-level user data, inline on the HTML page that is returned from the server. This eliminates a second round-trip to the server where we would have had to fetch the top-level user data. This is a good example of batching what would have been two requests into one request.

List view virtualization

In the old SkyDrive web experience, if you went to view a particular folder, we would download a web page that contained all of the files in that folder. An example of a typically folder is the Windows Phone camera role folder that is stored in SkyDrive. Around 25% of Windows Phone users have around 1000 photos in this folder. Viewing a camera role folder with 1000 photos resulted in a very slow experience.

The new SkyDrive is much better at handling views of large folders because we added support for virtualized list views. Most people are familiar with this concept because most client applications, like Microsoft Outlook, use virtualized list views to improve performance.

The key idea here is that when a user views a folder with a lot of files, we only fetch and display what’s needed to fill the current screen in the browser. It’s incredibly efficient and fast because we are only fetching a small page of data from the server (few KB) or cache, and we’re only rendering a small amount of HTML. The other really cool thing that we did was utilize the browser scrollbar for allowing the user to scroll through the list. As the user scrolls, we are dynamically fetching data and rendering the list view. The end result is a very fast and smooth experience, regardless of how many files are in the folder.

As I mentioned, the ability to support virtualized list views is supported by our data access protocol because it allows us to fetch a specific page of files. You can test this out by going to a large folder of files in SkyDrive, and then hitting CTRL+END. You’ll see that you can quickly scroll and see the last page in the folder really fast because our storage system is able to quickly execute this query at the database level.

Client-side caching

Client-side caching is critical to achieving great web performance because it allows us to completely avoid a certain set of network requests and render our user experience almost instantly, since the data is coming from the local computer. The more we can cache on the client, the better!

We’re doing two levels of caching in the new SkyDrive architecture. As I mentioned above, all of our data requests made to our HTTP/JSON access protocol are cached in the browser’s cache. If the same data request is made as a prior request, it will be served from the browser’s cache instead of actually hitting the network and calling our servers. This allows us to cache user data across SkyDrive browser sessions.

The next layer of caching is an in-memory data cache. This cache only exists for the current SkyDrive session. We have this cache so that moving back and forth between views is incredibly fast. Once we request data via our data access protocol, which may have been served from the browser’s cache, we hold that data in memory for the SkyDrive session. We do some tricks around pruning this cache so that it doesn’t get too large.

Another concept that we’ve introduced into the new SkyDrive architecture is the idea of pre-caching. If you go into the new SkyDrive photo viewer for a photo album, SkyDrive starts downloading photos so that when you get to that photo, it’s already on the local computer. However, if we pre-cache photos that you never view, we will have wasted some networking calls and server cycles, so there is a delicate balance to be maintained with pre-caching. We’re also doing another type of pre-caching in the file list view, where we fetch a few items beyond the current view so that scrolling is smoother.

Leveraging more features of HTML 5 down the road

We’ve embraced a lot of new web standards in the latest release of SkyDrive. As I mentioned, we use JSON to represent user data when we talk to our servers. We’re using HTML5 for CSS animations, reflow animations and other features. We’re using local storage for various parts of our caching support. We’ve also worked on making our HTML more standards compliant, so that everything you see works in as many modern browsers as possible.

We will continue to leverage more and more features of HTML5 down the road. We still use Silverlight for our rich upload control because it allows us to resize a photo to a smaller size before it’s uploaded. Also, all our JavaScript is built on top of JQuery, starting with this release. We found that JQuery increased our developers’ productivity. We also reuse all of the code between the PC and mobile views of SkyDrive, so the mobile experience is faster now as well.

We’re still evolving the rest of the SkyDrive experience to the new and faster architecture. Soon we’ll move more things to be “inlined” or driven dynamically from the client, instead of requiring full page loads. And we’ll also be moving actions, such as delete and move, to be asynchronous operations instead of page loads.

We’ll continue to focus on improving SkyDrive performance because we know that speed is an important part of making the SkyDrive experience useful.

Let us know what you think of the new, speedier SkyDrive.

Steven Bailey
Development Manager, Windows Live

At Hotmail, we know that account hijacking is a big problem, and we continue to work hard to prevent it. We’ve noticed a couple of things about hijacked accounts. First, many accounts have weak passwords that make them easy targets for hijackers. Second, when someone’s account gets hijacked, their friends often find out before they do, because the hijacker uses their account to send spam or phishing email to all their contacts.

These two observations led us to develop a couple of new features that help protect your accounts. The first lets you report a friend’s account as compromised – a feature unique to Hotmail – and the second prevents you from using common passwords that make your account easy to hack.

Getting spammed by a friend

Maybe you’ve had this happen to you: You sign in to Hotmail, and you see you’ve got new mail from one of your friends. You open the message only to discover that it’s spam! Maybe it’s obvious spam – like an ad for a product. Or maybe it’s a more involved story – like a plea for money, with an explanation that your friend is stuck in a foreign country and needs cash, when you know for sure that your friend is safe and sound at home.

Whatever the case, one thing is for sure: this email isn’t really from your friend at all. Instead, it’s from a spammer who has hijacked your friend’s account. When this happens, you probably call or text your friend or contact them on an alternate email address to let them know that their email account has been compromised. But you wish you could do more.

Now you can. Hotmail lets you report your friend’s account as compromised. It’s easy: When you get that spam message supposedly from your friend, you just click “My friend’s been hacked!” on the “Mark as” menu:

You can also report an account as compromised when you mark a message as junk or otherwise move a message to the Junk folder:

What happens under the hood

Our compromise detection system is always working in the background to detect unusual behavior. When we detect bad behavior from an account (like an account that suddenly starts sending spam), we mark that account as compromised. It’s a bit like your credit card company putting a hold on your account when they detect suspicious activity.

When you report that your friend’s account has been compromised, Hotmail takes that report and combines it with the other information from the compromise detection engine to determine if the account in question has in fact been hijacked. It turns out that the report that comes from you can be one of the strongest “signals” to the detection engine, since you may be the first to notice the compromise. So, when you help out this way, it makes a big difference!

Once we mark the account as compromised, two things happen:

• First and foremost, the account can no longer be used by the spammer.
• When your friend attempts to access their account, they’re put through an account recovery flow that helps them take back control of the account.

Making it work with all accounts

We released this feature a few weeks ago. Initially, it only let you report Hotmail accounts that were compromised. But it worked really well – we got thousands of reports of compromised accounts.

Of course, we didn’t want to stop there; we wanted to go a step farther and make it work for any email account. After all, even if you’re a Hotmail user, you probably get email from friends using other email providers, and those accounts can get compromised, too.

We did the work to enable other email providers like Yahoo! and Gmail to receive these compromise reports from Hotmail including those submitted by you, and those providers will now be able to use the reports in their own systems to recover hacked accounts.

So now, in Hotmail, you can report any email account as compromised, and Hotmail will provide the compromise information to both Yahoo! and Gmail.

How well is it working?

We’ve had this feature turned on for only a few weeks, and we’ve already identified thousands of customers who have had their accounts hacked and helped those customers reclaim their accounts. And we’ve found it to be very effective and fast. Accounts that you report as compromised are typically returned to the rightful owner within a day.

An ounce of prevention is worth a pound of cure

Of course, we don’t want to just detect when accounts are compromised; we want to prevent them from being compromised in the first place. That’s why we continue to innovate and build more features to help protect your account.

We‘re making another addition to the long list of account security and protection features that we’ve released over the last year. We will now prevent our customers from using one of several common passwords. Having a common password makes your account vulnerable to brute force “dictionary” attacks, in which a malicious person tries to hijack your account just by guessing passwords (using a short list of very common passwords). Of course, Hotmail has built-in defenses against standard dictionary attacks, but when someone can guess your password in just a few tries, it hardly constitutes “brute force!”

Common passwords are not just “password” or “123456” (although those are frighteningly common), but also include words or phrases that just happen to be shared by millions of people, like "ilovecats" or "gogiants."

This new feature will be rolling out soon, and will prevent you from choosing a very common password when you sign up for an account or when you change your password. If you're already using a common password, you may, at some point in the future, be asked to change it to a stronger password.

Of course, having a strong password is just one step to protecting your account. You should also provide “proofs,” including an alternate email address, a question and secret answer, and, even a mobile number where we can reach you via text message. You can learn more about how to set up account proofs, or go ahead and set up your account proofs now.

Join the fight

When it comes to account security, the Hotmail team is dedicated to doing all we can to help protect your Hotmail account from thieves and spammers. We’ll continue to work to protect your account with new and innovative features, and now you can join us in the fight and help protect your own account and your friends’ accounts, too.

Dick Craddock
Group Program Manager, Hotmail