Building a platform for Windows Live Workshop

1
Building a platform for Windows Live (Workshop)

• Simon Davies
• Microsoft Ltd
• sdavies_at_microsoft.com

2
What is this session about?

• Looking at a platform that Windows Live has faced
  
• Working out potential solutions
• Capturing and discussing the solutions
• Contrasting with the Windows Live solution
• Why are we doing this?
• Is this a generic issue that will need to\has
  been addressed in other domains?
• What potential solutions are there?
• Is the platform sufficient? Does it matter?
• Others?

3
What is this session about?

• Platform What does it mean?
• For the purpose of this session platform A
  modern web browser (e.g. Internet Explorer,
  Firefox, Safari etc.)
• The requirements\problem\guiding principles of
  Windows Live define this for us.
• Windows Live What is it?
• Not really relevant other than to provide
  context, requirements, principles etc for this
  problem
• For the purpose of this session Provides a set
  of services that enable any browser based
  application to access and end users data

4
Principles\Requirements

• Users are in control of their personal data
• No authentication requirements for application
• Developer and End User Consistency
• Data can be accessed from any browser
• Low friction developer impact
• Client based integration only
• User experience matters

5
Some examples for context

• A web application accesses my contact details in
  order to enable me to easily send an interesting
  piece of content to one or more of my contacts
• A web application access my address book to
  enable me to send flowers to one of my contacts
• A web application enables me to see the online
  presence status of my contacts and send a message

6
The Core of the requirement

• Using existing browser features\constraints
  provide a mechanism that enables personal
  information to be displayed in a 3rd party
  website.
• No data must be provided to the 3rd party website
  without the users explicit consent

7
What features do we need from our platform

• Encapsulation data must only be accessible via
  our defined interfaces
• Message Passing we need a way of passing
  messages between the 3rd party site and our
  encapsulated data representation
• No data on the wire we dont want to send data
  cross domain on the wire
• No caching we dont want the browser cache to
  store any of this
• Essentially we need similar features to that
  provided by UI frameworks such as Windows Forms

8
Workshop

• In Small Groups can you
• Describe a high level solution to this problem?
• Or
• Articulate other (non Windows Live) scenarios
  that require this type of facility
• Or
• Is there some other interesting facet of this
  problem?
• Or
• All of the above

9
Your Solutions
10
The Windows Live Beta Solution
11
Contacts Control Usage Model

• Web app specifies size location of HTML element
• User clicks link to sign into live.com domain
• Users contacts displayed in control
• User selects one or more contacts, clicks Submit
• User reviews selected info, clicks Send
• Web app receives selected contacts in OnData event

12
Messaging How does it work?

• Browser security model blocks access to data
  inside an iframe viewing a document in a
  different domain
• However, there are supported patterns of behavior
  in which actions of one iframe can be observed by
  another iframe, even across domains
• Current base implementation pass data in the
  hash of the URL (http//www.foo.com/channel.htmd
  ata)

13
URL Hash Techniquehttp//www.foo.com/channel.htm
data

• Script in any context can assign to an iframes
  src property
• iframe.src is write-only
• Browser ignores data after in URL
• Never hits network stack
• Never cached locally
• Technique Send data to other domain iframe by
  tacking data onto end of URL in other domain
• Receiving URL wakes up in page load event,
  processes data in URL

14
Basic Channel Flow
http//a.com/main.html
var channel document.getElementById(ch
annel) channel.srchttp//b.com/channel.htmdat
adata
Iframe.id channel
http//b.com/channel.htm
onLoad var msg document.location.hash.substr
(1) alert(Got the message! msg)
15
Security Threats

• Receiver has no idea who the sender is
• Malicious code could send random garbage
• Source code could be copied modified

16
Security Features

• URL data visible only to receiver
• Data inside iframe is inaccessible to outside
  code
• Source code of the iframe only works when
  executed in the context of the live.com domain
• Validity of Sender Shared secret handshake
• Block replay random attacks
• Endpoints can be hardcoded
• Reply only to predetermined URL

17
Conclusions

• What have we learnt?
• What should we do next?
• THANK YOU!!

18
Resources

• http//dev.live.com/contactscontrol/v0.2/default.a
  spx