Infosys | Microsoft

Every new technology brings its own mechanism to mitigate security threats. This post discusses on how silverlight deals with cross site scripting.

 What is Cross Site Scripting?

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Examples of such code include HTML code and client-side scripts. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Vulnerabilities of this kind have been exploited to craft powerful phishing attacks and browser exploits.

To allow flash based clients to access its resources, servers need to place a policy file at the root of the domain called crossdomain.xml and all access permission in that file.

Silverlight uses the same logic to allow the APIs to access cross domain resources. It supports flash based policy file. It also supports a file specific to Silverlight clients named as clientaccesspolicy.xml. This is also a xml based file with published format but different from flash format.

Silverlight runtime first tries to download the clientaccesspolicy.xml file and if found, all access permissions are granted using this file. If this file is not available, it tries to download flash based policy file. If none is found, access is denied. These files are not downloaded in case of same domain access.

Posted by Venkatesh Rajagopalan Narayanan at 04:06 PM | Permalink | Comments (0) | TrackBacks (0)

As the world awaits better times to invest in newer technologies in the pursuit of mankind’s never ending and ever evolving ambitions on engineering newer things to make life exciting, Microsoft is showing pointers on the road ahead.

Microsoft has taken HCI and car infotainment to the next level through its Commute UX initiative.

It’s a curve that is literally tending towards the famous “Knight Rider” which I used to watch with awe in my childhood days.

Imagine “talking” to services that reside on the cloud as you drive down! Commute UX is all about bringing computing and collaboration to its best possible use particularly in car infotainment systems.

 The Commute UX initiative is based on the following drivers

Speech enabled - speech is the interaction channel left in eyes busy/hands busy activity such as driving.

Multimodal - speech is strong in browsing large lists (music, address book), touch screen/buttons - for selection from short lists (disambiguation). Smooth transition from speech only to GUI/touch only interfaces based on the conditions and user.

Situation aware - to mimic the behavior of the passenger and not to speak during passing, lane change, etc. Gradually to change the behavior based on speed, weather, and driving conditions - turn GUI off under heavy driving conditions to minimize the driver's distraction, for example.

Context and person awareness - increases the usability of the system by filling defaults, coming from the context and habits of the driver. They are easy to obtain, monitor and store as the car has limited number of users (drivers).

Seamless integration of in-car and in-cloud services - Connected to the cloud dialog system just gets smarter and provides more information and services in a smooth and nice way.

Browse through through the following to catch a glimpse of Commute UX

http://www.microsoft.com/presspass/events/msrtechfest/videoGallery.aspx?initialVideo=techfest_commuteUX

Posted by Venkatesh Rajagopalan Narayanan at 06:37 AM | Permalink | Comments (0) | TrackBacks (0)

As web 2.0 matures and becomes pervasive across various business domains, some interesting and thought provoking ideas are emerging about what progression to Web 2.0 means for user experience design and usability engineering.

1.       Web 2.0 will lead to the proliferation of Web applications and, consequently, intense competition. Well-designed tools for working with unstructured data will drive the average user's progress along the experience continuum. Consequently, user observation will be more critical than ever in the research process.

2.       To create usable user experiences, design teams must be able to understand the context of use from any user, at any time, and through any channel. At the same time, the burden for participants and design teams must be eliminated, making it simple for users to share their true experiences. Design teams must be able to observe these experiences on-demand, either live or asynchronously. It is only in this way that the context of use will enable teams to create usable designs that drive users to realize the promise of Web 2.0.

Posted by Chandan Gokhale at 11:05 AM | Permalink | Comments (0) | TrackBacks (0)

Microsoft introduced Windows Presentation Foundation (WPF) with .NET framework 3.0. What started as extensions to Visual Studio (VS) 2005 is a now a in-house native to VS 2008 and the VS 2010 designer is itself getting implemented in WPF (more details in Jason's blog here).

Needless to say that WPF is very powerful new presentation platform that really makes "imagination is the limit" a reality. Designers and developers can now work real closely like never before and create some really super cool user experiences.

Anyway, I am not planning to use this blog for explaining what WPF is all about. You can find many online articles on the same. WPF is native to .NET framework now and allows one to create thick client applications. However Microsoft didn't stop there and they had the support for XAML Browser Application (XBAP). XBAP is pretty much same as WPF and requires full .net framework on the system to run, but it runs in the browser security sand box.

Since WPF was targeted towards thick client, it was probably expected that MS will come up something that is for thin client applications. XBAP isn't really thin client since it needs full .net framework on client side. So we soon had Silverlight (SL), which is a sub-set of WPF (and fits snugly into a just around 4 MB download). Interestingly with SL 3, MS is adding the out of browser support for SL.

Given that SL really runs on the client side and uses WCF primarily to get server side data (unlike ASP.NET which runs on server side), SL application can continue to run even if there isn't a network connection, till the time one really makes a server call to pull/push data. Anyway, MS really took this forward but adding features that allows one to detect network connectivity and also take SL applications out of browser to give the real offline application scenario.

Now does this compete with WPF? Not really, since SL is a subset and you can't do all that you do in WPF, but for your typical business/departmental application, you would most likely anyway not use all features of WPF (some of them may still be restricted to game vendors). Hence the question really is where to use WPF? Where to use XBAP? Where to use SL? Where to use SL out of browser support?

If you are reading this for getting an answer to this, I regret to disappoint you, but I am also really looking at seeing how you are making use of these technologies. To me personally, there hasn't really been a real solid reason to do XBAP over WPF. Similarly people ask for offline support, but I am not convinced. If you can't connect, all your data isn't available and if you really want to cache some and do offline, then why not use WPF itself. People say that offline still allows you to target many different operating systems as against a full version of .net and WPF that will run only on windows, which seems reasonable.

However I will really like to hear from all you people out there as to what are your decisions points to select between WPF and XBAP and SL and offline SL? And do you think offline SL will impact usage of WPF?

Posted by Atul Gupta at 08:56 AM | Permalink | Comments (1) | TrackBacks (0)

It’s always great to go through debates on new technologies. It is sure to give you some interesting insights into the technology at the same time forcing you to think n number of times whether you would want to invest your time on it. I came across such a debate on Microsoft “Oslo” today. There is a post - Where is Oslo going? at ebPML.org. If you are a developer who is getting started on Oslo, you might get disheartened when you read this one and you might start asking yourself whether you would want to really invest your time on this piece of technology. This post criticizes the thinking behind Oslo and its usefulness in moving towards Model Driven Development. The author of the article concludes by saying, “This project is focused on solving problems that people have already solved and completely missing the mark on MOP.” For those of you who don’t know what MOP is; it stands for Metamodel Oriented Programming.

But Doug Purdy (Product Unit Manager, Microsoft) decided to answer many of the questions that the author had raised in his post about “Oslo” and its relevance. He has put up a post on his blog to answer these questions. When you read this one, I am sure you will get some kind of confidence back on the technology. Going through the post will also give you an understanding about the problem “Oslo” tries to address which something like the DSL toolkit today doesn’t.

Interesting read!

Posted by E. Krishna Kumar at 05:22 AM | Permalink | Comments (6) | TrackBacks (0)

An application has a lifecycle of its own and is prone to changes and enhancements. Hence when we talk about model driven applications, it becomes really important to think about how you can version your Schema and Data that you have in your "Oslo" repository. This whitepaper on MSDN provides an overview of the "Oslo" repository's design for supporting schema and data versioning.

Posted by E. Krishna Kumar at 03:08 AM | Permalink | Comments (0) | TrackBacks (0)

And the more it hacks itself, the more secure it becomes. Compilers are hard task masters. They cut out a distinct path for the application execution and force it to run that way, come hell or high water. Letting an application change its behavior by teaching it to understand itself has been a fairly less explored subject.

One main reason being, mainstream software developers typically confine themselves to the assortment of data structures provided by their favorite language. Say, a nice C# developer sticks to Hash Tables, Dictionaries and Generic entities or a hybrid collection of all these to represent all sorts of rules, constraints or any knowledge pertaining to the domain. But such objects aren’t mature enough to represent the kind of rules which can dynamically define the behavior of the application.

Let’s talk in non-technology terms. Here’s the most famous syllogism from the college-days.

Rule 1: All men are mortal

Rule 2: Socrates is a man

Question: Tell me about Socrates.

Answer: Socrates is mortal

How do you represent this when coded in your favorite language? If a software can be intelligent enough to automatically infer the Answer based on Rules 1 and 2, that would be its first step to modify its own behavior based on the business rules.

Let’s take the Outlook example we discussed in a previous post. We need to represent a rule where the software monitors a user’s actions of moving his emails from “Barack Obama” to the outlook archive “Obamaniac”. The software finds that the user always does this move, decides that this is his pattern of behavior, and it automatically creates an Outlook rule which moves all mails from “Barack Obama” to the “Obmaniac” folder.

One very useful method of representing such rules is the First-Order Logic. Mathematically, the rule for our Outlook example could be represented as below using First Order Logic. ( = There Exists,=And,= For All)

Implementing first-order logic in code is never simple. Prolog is one excellent language to represent first-order logic, but is too general purpose for our interest. What could be helpful, is something which, in principle, is similar to Prolog, but is more driven by the domain.

In the next post, we’ll explore the idea of domain driven representation of logic.

Posted by Kishore Gopalan at 05:06 AM | Permalink | Comments (1) | TrackBacks (0)