I missed my update last week, so this post actually covers the past two weeks.

Rewrite with dijit._Widget

One of the first things Peter mentioned after my initial commits was that my code was not very Dojo-like, and (though he didn't say it) not very good. I had all the setup code in a single initialization function, which the client had to explicitly call. Instead of having a separate class for each component (Source, Canvas, Editor), each piece was declared as a dojo.dnd.Source and then specific actions were attached here, there, and anywhere. The code was not at all modular, with the implementation exposed in many places. Peter gently suggested making each component a subclass of dijit._Widget, which would give me a lot of built-in functionality (dijit.byId, constructors, etc.) for free.

Refactoring the code to subclass dijit._Widget has been very helpful. The components are completely decoupled, my code is much more modular, and the client code is quite simple. Creating a class for each component also makes customizing their behavior a cinch, since it's easy to monkeypatch any of the class methods.

PropEditor

I've finally created the PropEditor, which allows you to edit the properties of a field element. Right now it only supports changing the name, but eventually it will be able to edit the choices for a select, change the default value for a field, and more.

pub/sub

I'm trying to keep the components completely decoupled after the refactoring, so each piece is usable in isolation from the others. This means that, for example, the Canvas can't call a method of the PropEditor when a field is selected, since there may not even be a PropEditor instance on the page. Instead of direct method calls, I'm using dojo.publish + dojo.subscribe to pass messages and data around to anyone who wants to listen. This is my first time doing event-driven programming like this, and I think it's a neat way to maintain modularity between classes. The PropEditor could actually be used on any page that publishes the correct messages, not just in concordance with my Canvas class.

Loading existing elements

Since I'm building a form editor, and not just a form creator, the Canvas needs a way to load existing form elements from a page. Taking a page from dojo.dnd.Source, the Canvas will now add any existing soc.ed.Elements to its internal structure when the Canvas is created, similar to how dojoDndItems are gathered.

All the major pieces of the editor have been created, so now I'll be focused on making each one richer and better.

Hi dojoers,

I am thinking to put my analysis document for GFX 2.0 (this document has been updating from the first time discussion with my mentor Mr.Eugene Lazutkin). You can read the document to know more about abstract design of GFX 2.0... At the moment, I am writing document to explain thoroughly about GFX 2.0 implementation, it will be described about:
- Assumption implementation (for example, no color texturing, no light feature, etc)
- Implementation detail (including design diagram, improvement made to increase performance)
- Problem (algorithm, feature that hard to implement)

Link for the analysis document can be read in this link

Dojo’s improved RPC and new REST services can be used with a wide array of web services. One particular use is Amazon’s Simple Storage Service (S3). Dojo can connect to Amazon S3’s with a trivial proxy and be used as a normal RPC service. Not only that, Amazon S3 is a REST service and therefore it can be used as a data store with Dojo’s new REST implementation of dojo.data, JsonRestStore. You can read and write to your S3 database using the convenient Dojo Data API, and use the data store in Dojo widgets.

Getting Started

To get started with Dojo + S3:

• First, you must be signed up to use Amazon S3.
• Dojo uses a simple proxy to communicate with S3 (doing so directly from the browser would be insecure). The proxy PHP script, proxy.example-php, located in /dojox/rpc/s3/, must be renamed to proxy.php to be used.
• The proxy requires PHP 5 (other languages hopefully will be added) and the following modules:
  • Crypt_HMAC
  • HTTP_Request
• Next you must enter your Amazon access key and secret access key into the proxy.php file on line 3 and 4:

  $accessKey = "access key";
  $secretAccessKey = "secret access key";

Now we can start using Dojo services to connect to S3. You use the Dojo RPC service with the “PROXIED-PATH” envelope:

dojo.require("dojox.rpc.Service");
dojo.require("dojox.rpc.ProxiedPath");
var s3Buckets = new dojox.rpc.Service({
	target:"http://s3.amazonaws.com/",
	proxyUrl:"../s3/proxy.php", // the path to the proxy
	transport:"REST",
	envelope:"PROXIED-PATH",
	contentType:"application/json",
	services:{
		myBucket:{ // name of the service (usually the bucket)
			target:"myBucket", // enter you bucket here
			parameters:[{type:"string"}]
		}
	}
});

To use the S3 as a Dojo data store you can use the S3Store module. First setup an RPC service as shown above and then pass the RPC service to the S3JsonRestStore:

dojo.require("dojox.data.S3Store");
// and create a store for it
s3Store = new dojox.data.S3Store({service:s3Buckets.myBucket});

You can then use the s3Store as a normal Read/Write Dojo Data store. And since the S3Store is an extension of the JsonRestStore, you can use all the additional features of that store including fast, compact syntax, referencing, and offline capabilities are coming soon. With the S3Store you can build sophisticated apps with very thin server architecture; UI logic can be handled on the browser, and database storage can be delegated to Amazon’s S3. This is just one of the many new features available with Dojo 1.2.

This week I've made a lot of progress on rails' JavaScriptGenerator. JavaScriptGenerator basically offloads a lot of the work to the underlying prototype js library, and it's meant to be an expressive means of speaking javascript with ruby code. To maintain this flexibility, I've been implementing a lot of prototype functionality in our drails javascript package.

There are 2 new classes, drails.Element and drails.ElementCollection, and one new interface, drails.Enumerable.

drails.Element is a stripped down version of prototype's Element, but rather than extending a DOMNode with additional functionality, it wraps it in a class and provides the basic API that rails explicitly exposes in JavaScriptGenerator. I say explicitly, because a neat feature of JavaScriptGenerator is that if you call a method that isn't explicitly defined in it, it tries to pass it down the chain to the underlying javascript.

The implementation of drails.Element is the opposite of the prototype Element. prototype declares a bunch of methods that look like this:
Element.insert(element, insertions);

and then "methodizes" them each time a DOM Node is extended, with code that looks something like this:
// element == Dom Node
    for (property in Element.Methods) {
      value = Element.Methods[property];
      if (Object.isFunction(value) && !(property in element))
        element[property] = value.methodize();
    }

Function.prototype.methodize = function() {
    if (this._methodized) return this._methodized;
    var __method = this;
    return this._methodized = function() {
      return __method.apply(null, [this].concat($A(arguments)));
    };

Instead of this, I define the methods as instance methods of the drails.Element class, but then provide the same "static" style interface as prototype by instantiating a new instance of drails.Element for the "static" style interface:

drails.Element.Functions = (function(){
  function functionize(method){
    return function(){
      var args = drails.toArray(arguments);
      return method.apply(new drails.Element(args[0]),args.slice(1));
    };
  }
  functions = {};
  for(prop in drails.Element.Methods){
    var value = drails.Element.Methods[prop];
    if(dojo.isFunction(value) && prop[0] != "_"){
      functions[prop] = functionize(value);
    }
  }
  return functions;
})();

It took me awhile to get this flow correct and working, as there are some tricky scope issues when passing around anonymous functions. At least now I finally understand what this means.

drails.ElementCollection is similar in scope, in that it wraps a NodeList (i.e. one returned from dojo.query) in a class, and mixes in the Enumerable interface, so you end up with an Enumerable collection of drails.Elements.

Not much more to say here until I finish getting unit tests in place, but you can have a look at all the new javascript code here: http://pastie.org/226646

Please let me know if you see anything amiss with it.

I created a nice animation effect that splits the element into an arbitrary number of rows and columns, then sends them flying away from the element's center. The user can specify whether or not the pieces fade out as they move, and whether or not the distance and duration of each piece's animation should be randomized.

The effect is accomplished by cloning the node once for each piece and combining each piece's animation together. The original node's opacity is set to zero onPlay.

Unfortunately, there are a few small kinks I still need to work out in the way the effect is structured. For example, many of the basic _Animation arguments are ignored, and the effect does not play nicely with dojo.fx.chain.

Now that I have a successful technique for splitting a node into pieces and animating them, I can create a whole slew of unique effects never before seen in a JavaScript toolkit. I'll be demonstrating these effects here as I perfect them.

Hi! I’m Eric Lawrence, Security Program Manager for Internet Explorer. Last Tuesday, Dean wrote about our principles for delivering a trustworthy browser; today, I’m excited to share with you details on the significant investments we’ve made in Security for Internet Explorer 8. As you might guess from the length of this post, we’ve done a lot of security work for this release. As an end-user, simply upgrade to IE8 to benefit from these security improvements. As a domain administrator, you can use Group Policy and the IEAK to set secure defaults for your network. As web-developer, you can build upon some of these new features to help protect your users and web applications.

As we were planning Internet Explorer 8, our security teams looked closely at the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. While we were building new Security features, we also worked hard to ensure that powerful new features (like Activities and Web Slices) minimize attack surface and don’t provide attackers with new targets. Out of our planning work, we classified threats into three major categories: Web Application Vulnerabilities, Browser & Add-on Vulnerabilities, and Social Engineering Threats. For each class of threat, we developed a set of layered mitigations to provide defense-in-depth protection against exploits.

Web Application Defense Cross-Site-Scripting Defenses

Over the past few years, cross-site scripting (XSS) attacks have surpassed buffer overflows to become the most common class of software vulnerability. XSS attacks exploit vulnerabilities in web applications in order to steal cookies or other data, deface pages, steal credentials, or launch more exotic attacks.

IE8 helps to mitigate the threat of XSS attacks by blocking the most common form of XSS attack (called “reflection” attacks). The IE8 XSS Filter is a heuristic-based mitigation that sanitizes injected scripts, preventing execution. Learn more about this defense in David’s blog post: IE8 Security Part IV - The XSS Filter.

XSS Filter provides good protection against exploits, but because this feature is only available in IE8, it’s important that web developers provide additional defense-in-depth and work to eliminate XSS vulnerabilities in their sites. Preventing XSS on the server-side is much easier that catching it at the browser; simply never trust user input! Most web platform technologies offer one or more sanitization technologies-- developers using ASP.NET should consider using the Microsoft Anti-Cross Site Scripting Library. To further mitigate the threat of XSS cookie theft, sensitive cookies (especially those used for authentication) should be protected with the HttpOnly attribute.

Safer Mashups

While the XSS Filter helps mitigate reflected scripting attacks when navigating between two servers, in the Web 2.0 world, web applications are increasingly built using clientside mashup techniques. Many mashups are built unsafely, relying SCRIPT SRC techniques that simply merge scripting from a third-party directly into the mashup page, providing the third-party full access to the DOM and non-HttpOnly cookies.

To help developers build more secure mashups, for Internet Explorer 8, we’ve introduced support for the HTML5 cross-document messaging feature that enables IFRAMEs to communicate more securely while maintaining DOM isolation. We’ve also introduced the XDomainRequest object to permit secure network retrieval of “public” data across domains.

While Cross-Document-Messaging and XDomainRequest both help to secure mashups, a critical threat remains. Using either object, the string data retrieved from the third-party frame or server could contain script; if the caller blindly injects the string into its own DOM, a script injection attack will occur. For that reason, we’re happy to announce two new technologies that can be used in concert with these cross-domain communication mechanisms to mitigate script-injection attacks.

Safer Mashups: HTML Sanitization

IE8 exposes a new method on the window object named toStaticHTML. When a string of HTML is passed to this function, any potentially executable script constructs are removed before the string is returned. Internally, this function is based on the same technologies as the server-side Microsoft Anti-Cross Site Scripting Library mentioned previously.

So, for example, you can use toStaticHTML to help ensure that HTML received from a postMessage call cannot execute script, but can take advantage of basic formatting:

document.attachEvent('onmessage',function(e) { 
  if (e.domain == 'weather.example.com') {
      spnWeather.innerHTML = window.toStaticHTML(e.data);
  }
}

Calling:

window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

will return:

This is some <b>HTML</b> with embedded script following... !

Safer Mashups: JSON Sanitization

JavaScript Object Notation (JSON) is a lightweight string-serialization of a JavaScript object that is often used to pass data between components of a mashup. Unfortunately, many mashups use JSON insecurely, relying on the JavaScript eval method to “revive” JSON strings back into JavaScript objects, potentially executing script functions in the process. Security-conscious developers instead use a JSON-parser to ensure that the JSON object does not contain executable script, but there’s a performance penalty for this.

Internet Explorer 8 implements the ECMAScript 3.1 proposal for native JSON-handling functions (which uses Douglas Crockford’s json2.js API). The JSON.stringify method accepts a script object and returns a JSON string, while the JSON.parse method accepts a string and safely revives it into a JavaScript object. The new native JSON methods are based on the same code used by the script engine itself, and thus have significantly improved performance over non-native implementations. If the resulting object contains strings bound for injection into the DOM, the previously described toStaticHTML function can be used to prevent script injection.

The following example uses both JSON and HTML sanitization to prevent script injection:

<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
      var xdr1 = new XDomainRequest();
      xdr1.onload = function(){
           var objWeather = JSON.parse(xdr1.responseText);
           var oSpan = window.document.getElementById("spnWeather");
           oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"
                             + objWeather.Weather.Forecast.Tonight + "</b> in <u>" 
                             + objWeather.Weather.City+ "</u>.");
      };
      xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");
      xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>

…even if the weather service returns a malicious response:

HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1

{"Weather": {
  "City": "Seattle",
  "Zip": 98052,
  "Forecast": {
    "Today": "Sunny", 
    "Tonight": "<script defer>alert('bang!')</script>Dark",
    "Tomorrow": "Sunny"
  }
}}

MIME-Handling Changes

Each type of file delivered from a web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (e.g. image, text, application, etc). For compatibility reasons, Internet Explorer has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. In some cases, Internet Explorer reports a MIME type different than the type specified by the web server. For instance, if Internet Explorer finds HTML content in a file delivered with the HTTP response header Content-Type: text/plain, IE determines that the content should be rendered as HTML. Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain) MIME-sniffing is an important compatibility feature.

Unfortunately, MIME-sniffing also can lead to security problems for servers hosting untrusted content. Consider, for instance, the case of a picture-sharing web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim’s cookies, generate a phony page, etc.

To combat this problem, we’ve made a number of changes to Internet Explorer 8’s MIME-type determination code.

MIME-Handling: Restrict Upsniff

First, IE8 prevents “upsniff” of files served with image/* content types into HTML/Script. Even if a file contains script, if the server declares that it is an image, IE will not run the embedded script. This change mitigates the picture-sharing attack vector-- with no code changes on the part of the server. We were able to make this change by default with minimal compatibility impact because servers rarely knowingly send HTML or script with an image/* content type.

MIME-Handling: Sniffing Opt-Out

Next, we’ve provided web-applications with the ability to opt-out of MIME-sniffing. Sending the new authoritative=true attribute on the Content-Type HTTP response header prevents Internet Explorer from MIME-sniffing a response away from the declared content-type.

For example, consider the following HTTP-response:

HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;

<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>

In IE7, the text is interpreted as HTML:

In IE8, the page is rendered in plaintext:

Sites hosting untrusted content can use the authoritative attribute to ensure that text/plain files are not sniffed to anything else.

MIME-Handling: Force Save

Lastly, for web applications that need to serve untrusted HTML files, we have introduced a mechanism to help prevent the untrusted content from compromising your site’s security. When the new X-Download-Options header is present with the value noopen, the user is prevented from opening a file download directly; instead, they must first save the file locally. When the locally saved file is later opened, it no longer executes in the security context of your site, helping to prevent script injection.

HTTP/1.1 200 OK
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html

Taken together, these new Web Application Defenses enable the construction of much more secure web applications.

Local Browser Defenses

While Web Application attacks are becoming more common, attackers are always interested in compromising ordinary users’ local computers. In order to allow the browser to effectively enforce security policy to protect web applications, personal information, and local resources, attacks against the browser must be prevented. Internet Explorer 7 made major investments in this space, including Protected Mode, ActiveX Opt-in, and Zone Lockdowns. In response to the hardening of the browser itself, attackers are increasingly focusing on compromising vulnerable browser add-ons.

For Internet Explorer 8, we’ve made a number of investments to improve add-on security, reduce attack surface, and improve developer and user experience.

Add-on Security

We kicked off this security blog series with discussion of DEP/NX Memory Protection, enabled by default for IE8 when running on Windows Server 2008, Windows Vista SP1 and Windows XP SP3. DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable. DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. You can read more about this defense in the original blog post: IE8 Security Part I: DEP/NX Memory Protection.

In a follow-up post, Matt Crowley described the ActiveX improvements in IE8 and summarized the existing ActiveX-related security features carried over from earlier browser versions. The key improvement we made for IE8 is “Per-Site ActiveX,” a defense mechanism to help prevent malicious repurposing of controls. IE8 also supports non-Administrator installation of ActiveX controls, enabling domain administrators to configure most users without administrative permissions. You can get the full details about these improvements by reading: IE8 Security Part II: ActiveX Improvements. If you develop ActiveX controls, you can help protect users by following the Best Practices for ActiveX controls .

Protected Mode

Introduced in IE7 on Windows Vista, Protected Mode helps reduce the severity of threats to both Internet Explorer and extensions running in Internet Explorer by helping to prevent silent installation of malicious code even in the face of software vulnerabilities. For Internet Explorer 8, we’ve made a number of API improvements to Protected Mode to make it easier for add-on developers to control and interact with Protected Mode browser instances. You can read about these improvements in the Improved Protected Mode API Whitepaper.

For improved performance and application compatibility, by default IE8 disables Protected Mode in the Intranet Zone. Protected Mode was originally enabled in the Intranet Zone for user-experience reasons: when entering or leaving Protected Mode, Internet Explorer 7 was forced to create a new process and hence a new window.

Internet Explorer 8’s Loosely Coupled architecture enables us to host both Protected Mode and non-Protected Mode tabs within the same browser window, eliminating this user-experience annoyance. Of course, IE8 users and domain administrators have the option to enable Protected Mode for Intranet Zone if desired.

Application Protocol Prompt

Application Protocol handlers enable third-party applications (such as streaming media players and internet telephony applications) to directly launch from within the browser or other programs in Windows. Unfortunately, while this functionality is quite powerful, it presents a significant amount of attack surface, because some applications registered as protocol handlers may contain vulnerabilities that could be triggered from untrusted content from the Internet.

To help ensure that the user remains in control of their browsing experience, Internet Explorer 8 will now prompt before launching application protocols.

To provide defense-in-depth, Application Protocol developers should ensure that they follow the Best Practices described on MSDN.

File Upload Control

Historically, the HTML File Upload Control (<input type=file>) has been the source of a significant number of information disclosure vulnerabilities. To resolve these issues, two changes were made to the behavior of the control.

To block attacks that rely on “stealing” keystrokes to surreptitiously trick the user into typing a local file path into the control, the File Path edit box is now read-only. The user must explicitly select a file for upload using the File Browse dialog.

Additionally, the “Include local directory path when uploading files” URLAction has been set to "Disable" for the Internet Zone. This change prevents leakage of potentially sensitive local file-system information to the Internet. For instance, rather than submitting the full path C:\users\ericlaw\documents\secret\image.png, Internet Explorer 8 will now submit only the filename image.png.

Social Engineering Defenses

As browser defenses have been improved over the last few years, web criminals are increasingly relying on social engineering attacks to victimize users. Rather than attacking the ever-stronger castle walls, attackers increasingly visit the front gate and simply request that the user trust them.

For Internet Explorer 8, we’ve invested in features that help the user make safe trust decisions based on clearly-presented information gathered from the site and trustworthy authorities.

Address Bar Improvements

Domain Highlighting is a new feature introduced in IE8 Beta 1 to help users more easily interpret web addresses (URLs). Because the domain name is the most security-relevant identifier in a URL, it is shown in black text, while site-controlled URL text like the query string and path are shown in grey text.

When coupled with other technologies like Extended Validation SSL certificates, Internet Explorer 8’s improved address bar helps users more easily ensure that they provide personal information only to sites they trust.

SmartScreen® Filter

Internet Explorer 7 introduced the Phishing Filter, a dynamic security feature designed to warn users when they attempt to visit known-phishing sites. For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks millions of phishing attacks per week) and developed the SmartScreen® Filter. The SmartScreen Filter goes beyond anti-phishing to help block sites that are known to distribute malware, malicious software which attempts to attack your computer or steal your personal information. SmartScreen works in concert with other technologies like Windows Defender and Windows Live OneCare to provide comprehensive protection against malicious software.

You can read more about the new SmartScreen Filter in my earlier post: IE8 Security Part III - The SmartScreen Filter.

Summary

Security is a core characteristic of trustworthy browsing, and Internet Explorer 8 includes major improvements to address the evolving web security landscape. While the bad guys are unlikely to ever just “throw in the towel,” the IE team is working tirelessly to help protect users and provide new ways to enhance web application security.

Please stay tuned to the IEBlog for more information on the work we’re doing in Privacy, Reliability, and Business Practices to build a trustworthy browser.

Onward to Beta-2 in August!

Eric Lawrence
Program Manager
Internet Explorer Security

Hi, I'm David Ross, Security Software Engineer on the SWI team.  I’m proud to be doing this guest post on the IE blog today to show off some of the collaborative work SWI is doing with the Internet Explorer team.

Today we are releasing some details on a new IE8 feature that makes reflected / “Type-1” Cross-Site Scripting (XSS) vulnerabilities much more difficult to exploit from within Internet Explorer 8. Type-1 XSS flaws represent a growing portion of overall reported vulnerabilities and are increasingly being exploited “for fun and profit.”

The number of reported XSS flaws in popular web sites has skyrocketed recently – MITRE has reported that XSS vulnerabilities are now the most frequently reported class of vulnerability. More recently, sites such as XSSed.com have begun to collect and publish tens of thousands of Type-1 XSS vulnerabilities present in sites across the web.

XSS vulnerabilities enable an attacker to control the relationship between a user and a web site or web application that they trust. Cross-site scripting can enable attacks such as:

• Cookie theft, including the theft of sessions cookies that can lead to account hijacking
  
  
• Monitoring keystrokes input to the victim web site / application
  
  
• Performing actions on the victim web site on behalf of the victim user. For example, an XSS attack on Windows Live Mail might enable an attacker to read and forward e-mail messages, set new calendar appointments, etc.

While many great tools exist for developers to mitigate XSS in their sites / applications, these tools do not satisfy the need for average users to protect themselves from XSS attacks as they browse the web.

XSS Filter -- How it Works

The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.

With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification like the following:

The page has been modified and the XSS attack is blocked.

In this case the XSS Filter has identified a cross-site scripting attack in the URL.  It has neutered this attack as the identified script was replayed back into the response page.  In this way the filter is effective without modifying an initial request to the server or blocking an entire response.

As you may imagine, there are a number of interesting and subtle scenarios that the filter must handle appropriately. Here are some examples:

• The filter must be effective even if the attack is adjusted to leverage artifacts of common web application frameworks.  Ex: Will an attack still be detected if certain characters in a request are dropped or translated when replayed in the response?
  
  
• In performing filtering our code must not introduce new attack scenarios that would not otherwise exist.  Ex: Imagine the filter can be forced to neuter a closing SCRIPT tag.  In that case, untrusted content on the page might then execute as script.

And of course in addition to all of this we need to effectively counter all the XSS attack vectors not already addressed by other XSS-Focused Attack Surface Reduction measures.

Compatibility is critical. This feature was developed with the understanding that if it were to “break the web,” we could not enable the feature by default. Or if we did, people would turn it off and get no benefit. We really want to provide as much value as possible to the maximum number of users.

If Internet Explorer’s Application Compatibility Logging is enabled, all XSS Filter activity can be viewed using the Microsoft Application Compatibility Toolkit.

Web developers may wish to disable the filter for their content. They can do so by setting a HTTP header:
X-XSS-Protection: 0

Ultimately we have taken a very pragmatic approach – we choose to not to build the filter in such a way that we compromise site compatibility. Thus, the XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea.  This is similar to the pragmatic approach taken by ASP.Net request validation, although the XSS Filter is able to be more aggressive than the ASP.Net feature.

Assuming negligible site compatibility and performance impact, the fact that our filter effectively blocks the common “><script>… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.

Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8. (Not to mention the IFRAME SEO Poisoning attacks we protect against as well!)

I will go into more details on how the filter works, its history, its limitations, and some lessons learned during the development process over on my blog in the coming weeks.

David Ross
Security Software Engineer

As someone whose email address is posted in thousands of forum posts, newsgroup discussions, and blogs, I get a lot of spam. Of the spam I receive, a significant number of messages represent phishing attacks. Most of these lures aren’t very clever or convincing, but phishing has become a simple numbers game—hosting phishing sites is cheap, and even if only a few users fall for any given phishing attack, attackers will profit by increasing the volume of phishing campaigns.

In Internet Explorer 7, we introduced the Phishing Filter, a dynamic security feature designed to warn users when they attempt to visit known-phishing sites, and worked with partners to introduce Extended Validation certificates that light up the address bar when users visit sites with verified identity information. Beyond the Phishing Filter, Microsoft has also published educational materials on identifying phishing scams, and developed a strategy to attack phishing at multiple levels.

For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks over a million phishing attacks weekly) to develop the SmartScreen® Filter, a replacement that improves upon the Phishing Filter in a number of important ways:

• Improved user interface
• Faster performance
• New heuristics & enhanced telemetry
• Anti-Malware support
• Improved Group Policy support

I’ll describe each of these in the sections that follow.

Improved User Interface
First, we’ve simplified the opt-in experience for the SmartScreen Filter, integrating the option into the IE first-run experience. After first-run, you can later change your preferences easily by using the option on the classic Tools menu.

Next, the bold new SmartScreen blocking page offers clear language and guidance to help you avoid known-unsafe websites. Here’s a screenshot from a recent phishing site I encountered:

The “Go to my homepage” link enables you easily to navigate away from the unsafe website to start browsing from a trusted location. If you instead choose to ignore the SmartScreen warning by clicking the “Disregard and continue” link, the address bar remains red as a persistent warning as long as you are on the unsafe site.

If you uncover a new phishing site, you can submit it for analysis using the “Report Unsafe Website” option on the Tools menu. In the unlikely event of a false-positive, you can provide feedback using the “Report that this is not an unsafe website” link on the blocking page or by clicking the “Unsafe Website” flyout in the address bar.

Improved Performance
As a part of our overall investment in improving performance across Internet Explorer, we’ve made several performance tweaks to the SmartScreen Filter to improve its speed and lower its impact on browser performance. Detection of unsafe sites happens in parallel with navigation, so you can confidently surf the web without being forced to make a tradeoff between speed and safety.

New heuristics & telemetry
As attackers have evolved their phishing sites in an attempt to avoid being recognized and blocked, the SmartScreen Filter has also evolved to catch more phish than ever before. New heuristics, developed with help from security research teams across Microsoft, are able to evaluate more aspects of web pages to detect suspicious behavior. These new heuristics, combined with enhanced telemetry, allow the URL Reputation Service to identify and block phishing sites faster than ever.

In rare cases, SmartScreen will request feedback on sites of unknown reputation, as shown in this screenshot:

User feedback about unknown sites is collected by the SmartScreen web service and quickly evaluated to block new phish as they are discovered in the wild.

Anti-Malware Support
The SmartScreen Filter goes beyond anti-phishing to help block sites that are known to distribute malware, malicious software that attempts to attack your computer or steal your personal information. There are many types of malware, but most types can impact your privacy and security. The SmartScreen anti-malware feature is URL-reputation-based, which means that it evaluates the servers hosting downloads to determine if those servers are known to distribute unsafe content. SmartScreen’s reputation-based analysis works in concert with other signature-based anti-malware technologies like the Malicious Software Removal Tool, Windows Defender, and Windows Live OneCare, in order to provide comprehensive protection against malicious software.

If you are lured to a site known to distribute malware, the SmartScreen blocking page is displayed and indicates that the server is known to distribute unsafe software:

On the other hand, if you click on a direct link to a download (from an instant message, for instance) hosted by a known-malicious site, the Internet Explorer download dialog will interrupt the download to warn you of the threat:

SmartScreen’s anti-malware feature complemented by the IE8 features that combat malicious repurposing or exploit of browser add-ons, helps to protect you from a full range of malicious websites.

Group Policy Support
Group Policy can be used to enable or disable the SmartScreen Filter for Internet Explorer users across an entire Windows domain. A new Group Policy option is available that allows domain administrators to block users from overriding SmartScreen Filter warnings. When Group Policy restrictions are enabled, the option to override the SmartScreen warning screen is removed from the blocking pages and download dialog.

Privacy
As outlined in Dean’s post last week, Privacy is a core component of trustworthy browsing. As with IE7, Microsoft remains committed to helping ensure users’ privacy while providing protection from unsafe websites. URL data submitted to the SmartScreen web service for evaluation is transmitted in encrypted format over HTTPS. The data is not stored with a user's IP address or other personally identifiable information. Because user privacy is important in all Microsoft's products and technologies, Microsoft has taken steps to help ensure that no personally identifiable information is retained or used for purposes other than improving online safety; data will not be used to identify, contact, or provide advertising to users. You can read more in our privacy statement.

Conclusion
Web criminals are increasingly relying on social engineering attacks to engage in their criminal enterprises, but we’re working hard to deliver the tools to help keep you safe on the web. The IE8 SmartScreen Filter is designed to combat both phishing and malware sites while protecting your privacy and enabling high-performance browsing. I strongly recommend you enable the SmartScreen Filter and give it a spin in IE8 Beta 2, due in August.

Please stay tuned to the IEBlog for further posts on IE8 Security improvements!

Eric Lawrence
Program Manager
Internet Explorer Security

Dojo does a lot of things, but it can't pull data from just anywhere. The browser won't let it. That's the first heartbreaking lesson you learn in Ajax-land, your bar.com page can't send XHR requests directly to foo.com.

There are ways around it. The hacky-but-in-vogue method is JSONP, which says "run me this little JavaScript script at foo.com, and come back when you're done with the data." Yahoo and Google web services offer JSONP counterparts to their search services, and Dojo has really nice plumbing for calling them. We go over this in Mastering Dojo chapters 3 and 8. The bad news: a very small number of web services support JSONP.

A more universal solution is a proxy server. Your bar.com page will call the server, "Go fetch me this request at foo.com, will you?" bar.com, not subject to the cross-domain restrictions of a browser, will do that and serve back the results. And it's easy. One line of PHP nets you a proxy server. That's fine for starting out, but as you start taking advantage of more services, all the little details start becoming a PITA: security, routing, data conversion, etc.

And that's where Service Oriented Architecture (SOA) comes in. Here I don't mean just SOAP-based web services, but rather services as a way-of-life: loosely-coupled components from the Internet cloud, connected with orchestration glue in the middle. Your Dojo application shouldn't have to know about foo.com. Instead, it should know "answer this question and give me the answer in JSON format." The SOA server knows to ask foo.com, and convert the answer to JSON. And if foo.com is unreachable, it could contact anotherfoo.com for the same question. And so forth.

The point is SOA saves you coding on the middle tier. And let's face it - you really need to write less code there. Back in 1998, you could spend 20 hours a week on ASP, 20 hours a week on the database, let's say. Then Ajax comes along, and you need to do 15 hours of JavaScript (Dojo helps you here - it could be worse!) How do you squeeze 55 hours into a 40 hour work week? Eliminate your social life?

What I advocate is cutting ASP out altogether - adding 5 hours a week to moving logic back to the database tier, and 5 hours a week of SOA configuration. As you create more reusable Dojo components, you can cut 5 hours from your client-programming time. Voila! You're back to 40 hours, and you're building better apps.

So now your middle tier is a combined POWS (plain ol' web server) and SOA server. What do SOA servers look like? What do they do for you? And how do you choose from the veritable swamp of alternatives? I have some thoughts, which I'll share in the next post.

Hi dojoers,

Finally, after bugging around with algorithm to change Quaternion to Euler rotation system... The Opera implementation for GFX 2.0 is out... It is around 90% though (I need mathematician who understand about good camera management).

Since the Firefox and Opera implementation are already out... So I already achieved the unification API feature of GFX 2.0... After mid evaluation, I want to jump into high level of GFX 2.0 to make interactive 3D module... such as loading 3d model... and easy 3d environment loader file... I also want to make a real world example...
Some example:
-Model Viewer
GFX 2.0 supports user to load or create 3D model in 3D environments. For example, a furniture website would like to show 3D model furniture to user. User is able to interact with the 3D model furniture like manipulating the view (rotate, zoom or pan view) and changing 3D model state (opening door of wardrobe).
-Statistic Chart
GFX 2.0 allows user to view charts both in 2D and 3D environments. In 3D environment, user can manipulate view to be rotated and zoomed.
-Mathematic Graph
GFX 2.0 also can be used to display mathematic equation graph in 2D and 3D. User can analyze the equation shape or specific point location.

Some checkpoint:
- Anyone know (book or web page) which tell about good camera management (interaction with the algorithm)?
- Anyone have a thought about nice 3D real world example?
- Any idea about nice 3d model file format? Such as Google Earth model file...

If you guys want to see the test page (sorry no camera rotation for Opera... I cant implement this...), you can see it in this page

Thanks very much! I really appreciate, if you provide suggestions, ideas or critics...

Some sites can defer most, if not all, of their JavaScript-driven progressive enhancements until well after the page has loaded. Even so-called “lightweight” libraries like JQuery are far too heavy for some environments…not because they (like Dojo) pull in all the code needed to use them, but because they do it all up-front. Often the best time to pay the expense of loading, parsing, and executing JavaScript code is when the user takes an action that needs the enhancement to run. Dojo already gives you the best tools available anywhere to defer loading modules until you actually use them; other than those provided by dojo.js itself…but what about dojo.js? What if even the small size of Dojo is too big for your page? This need to load as fast as possible and defer work is never greater than in mobile applications. The best-performing thing to do is always to hand-write all the code you’ll need and never use more script than that…but there are complications. Not being able to share your code between developers (let alone between pages) can be a huge disadvantage. The code is also likely to be slow, buggy, and unmaintainable. There’s a real reason why toolkits like Dojo are so incredibly popular: they make much of this pain go away at the cost of initial download size. Why would anyone want to invite the pain back?

So we need some middle ground: a common, expected API surface area combined with a trivial initial footprint to ensure that pages load as fast as possible. How small could we make such a thing? Turns out, 6K.

Dojo has, for many versions now, provided the ability to use the build system to cut out parts of dojo.js which weren’t in use by the application and load them later. In fact, everything but the package loader and the few functions it needs to operate are located in source packages in the dojo/_base/ directory. When running Dojo from source, these files get pulled in with dojo.require() the same way that any other module might. One possible option then is to use the build system to create a custom version of dojo.js which includes just the modules your application uses at page load. But we’re still faced with the essential problem created by hand-rolling everything: it becomes much harder to work with Dojo. You no longer know what functions and classes might be provided by the dojo.js file loaded in the header of your page, meaning that the advantages of maintainability, shared team knowledge, and dependability are reduced. Code developed for this situation is littered with statements like dojo.require("dojo._base.array"); in order to ensure that the right modules are available.

A better solution might be one which preserves the super-lightweight foot-print of including just the Dojo loader but which also provides access to the full, rich API that is provided by the stock dojo.js without developers needing to spend a lot of time worrying whether a particular base module has already been loaded.

Enter the stub loader.

I’ve prototyped an alternate dojo.js which you can download as part of a build (256K tarball, includes tests) of just Core (the stuff in the dojo.* namespace). When served gzipped, this new version of dojo.js weighs in at roughly 6K, yet it provides the full API of the normal dojo.js, provided off of the AOL CDN at roughly 24K, or 4x the size. Instead of including all of the modules in Dojo’s baseline set of functionality, this new version instead pulls in just the bootstrapping code for the module system and then creates stub functions and constructors for all of the functionality which isn’t included. When a function is first called, the stub loader ensures that dojo.require() is called to pull in the appropriate functionality synchronously. The result is an API which behaves exactly as though all of dojo.js had been loaded up front but which defers loading until the code is actually used.

On an iPhone with a clean cache the stubbed-out dojo.js cut in half the time required to load and evaluate. Sure, it’ll take more time on the network when parts of the toolkit are actually used (say, in response to a click event), but for mobile device scenarios, it’s going to be hard to beat the flexibility and speed of the stub loader when pulling Dojo into a page.

The code to implement this strategy can now be viewed. If you view that file, you’ll note that the first several lines read like this:

dojo.provide("dojo._base");
dojo.provide("dojo._base.browser");
dojo.provide("dojo._base._stubs");

This implies that if some other code subsequently calls dojo.require("dojo._base");, as the build system normally would, then no code will be loaded. In a source version of Dojo, dojo/_base.js reads as such:

dojo.provide("dojo._base");
dojo.require("dojo._base.lang");
dojo.require("dojo._base.declare");
dojo.require("dojo._base.connect");
dojo.require("dojo._base.Deferred");
dojo.require("dojo._base.json");
dojo.require("dojo._base.array");
dojo.require("dojo._base.Color");
dojo.requireIf(dojo.isBrowser, "dojo._base.browser");

By loading our stub loader instead, all of the modules in dojo._base.* which would normally be included are left out of the build and replaced with their stub counterparts. To get some bit of code included in a build instead of the stub, we’d then just add the corresponding require (e.g., dojo.require("dojo._base.lang")) at the top of dojo/_base/_stubs.js, at which point the corresponding stub functions won’t be generated.

In a build which uses dojo/_base/stubs.js, extra code is not loaded until the functions and constructors which are stubbed out there are actually called. You can drop this file into your dojo/_base/ directory if you’re working with Dojo from source and then use the following profile definition to create your own stubbed-out dojo.js. I placed mine in util/buildscripts/profiles/stubs.profile.js:

dependencies = {
	layers: [
		{
			name: "dojo.js",
			customBase: true,
			dependencies: [
				"dojo._base._stubs"
			]
		},
		// your layers here!
	],
 
	prefixes: [
		// uncomment these to copy dijit and dojox into your build output
		// [ "dijit", "../dijit" ],
		// [ "dojox", "../dojox" ]
	]
};

And would normally build with:

%> cd dojo_repo/util/buildscripts/
%> ./build.sh profile=stubs action=clean,release copyTests=false cssOptimize=comments optimize=shrinksafe
clean: Deleting: ../../release/dojo
release: Using profile: profiles/stubs.profile.js
...

As part of Mozilla Corporation’s ongoing stability and security update process, Firefox 2.0.0.15 is now available for Windows, Mac, and Linux for free download from http://www.mozilla.com/firefox/all-older.html.

We strongly recommend that all Firefox users upgrade to this latest release. If you already have Firefox 2.x, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting “Check for Updates…” from the Help menu.

For a list of changes and more information, please review the Firefox 2.0.0.15 Release Notes.

Note: Firefox 2.0.0.x will be maintained with security and stability updates until mid-December, 2008. All users are encouraged to upgrade to Firefox 3.

I was doing some research on script loading speed tests. Each script load required the page to be refreshed, making it difficult to log the time to Firebug and get an average. It was certainly too much trouble to write some PHP scripts and connect to a database; and possibly even worse would be having to pull out a pencil and paper and write the times down. I’m not even sure I have a pencil.

The obvious solution was to write the data to a cookie. I also thought the solution was universal enough to blog about so others could use it too.

The first thing we need is a timer. Firebug has a timer, but it doesn’t return the results so that they can be saved. The timer will be a singleton since we will only need one instance holding all of the data, and it will be a global object so we can access it anywhere. The code is quite simple:

dojo.provide("mikespace.timer");
timer = {
	_map:{},
	start: function(msg){
		this._map[msg] = new Date().getTime();
	},
	end:   function(msg){
		this._map[msg] = new Date().getTime() - this._map[msg];
		return this._map[msg];
	},
	show: function(msg){
		console.log( "---------> " + msg + ": " + this._map[msg]);	
	}
};
// usage:
// timer.start("first test");
// var time = timer.end("first test);

This code is in a directory (or package) named mikespace. As you can see, the times are set and retrieved based on the label parameter, and stored in a hash map. There’s also a show() method - although I’m not going to use it here, I use this often. When conducting speed tests in an application, the timers are usually sprinkled everywhere throughout the code and show in various places in the log messages. By just calling timer.end() I store the time, and after all of the tests have been run, I call timer.show(msg) for each test, and log them all in one place.

Next we need our cookie aggregator. This too could be a singleton, but after considering that there could be multiple tests in a page, I decided to make it a PODO (Plain Old Dojo Object). Here is the full code for cookieData, and I’ll explain after:

dojo.provide("mikespace.cookieData");
dojo.require("dojo.cookie");
 
dojo.declare("mikespace.cookieData", null, {
	cookieName:"scriptTests",
	expires:1,
	testData:[],
	constructor: function(args){
		for (var nm in args){
			this[nm] = args[nm];	
		}
	},
	loadData: function(){
		this.cookie = dojo.cookie(this.cookieName);
		if(this.cookie){
			this.testData = dojo.fromJson(dojo.cookie(this.cookieName));
		}
	},
	getData: function(){
		return this.testData;
	},
	showData: function(){
		console.log("Test Name:", this.cookieName);
 
		var data = this.getData();
		var avr = 0;
		var amt = 0;
		dojo.forEach(data, function(d, i){
			console.log(i, "test:", d);
			avr+=d;
			amt++;
		});
 
		console.log("Average:", Math.ceil(avr/amt));
	},
	saveData: function(data){
		this.testData.push(data);
		 dojo.cookie(
			this.cookieName, 
			dojo.toJson(this.testData),
			{ expires: this.expires }
		);
	},
	clearData: function(){
		dojo.cookie(
			this.cookieName, 
			dojo.toJson([]), 
			{ expires: this.expires }
		);
	},
	deleteCookie: function(){
		dojo.cookie(this.cookieName, null, { expires: -1 });
	}
});

I’m utilizing dojo.cookie, so it is required. I declare mikespace.cookieData, and I’m not extending anything (like dijit._Widget), so the second parameter is null. Because I’m not using dijit._Widget, I’m mixing in the arguments object myself in the constructor. I then instantiate a few variables. expires is set to one day, which could be left as-is if you don’t want to leave the cookie hanging around on your system when your done. Or set it to an arbitrarily large number and use the deleteCookie() method.

The rest of the code should be quite easy to understand. in loadData() we check if the cookie exists, and if not, we create one with new data. In showData() I log each test and number it, so I can easily see how many tests I’ve run, and then I show the average. The showData() method could obviously be any kind of code, including parsing tests within tests. And semantically, it probably should be outside of this cookieData; if we wanted to just use it as a getter and setter and then create another object for displaying the results.

Now we’ll create our HTML page where we will run the tests. After including the Dojo script tag, and the djConfig, I register the mikespace namespace, and then require the files:

dojo.registerModulePath("mikespace", "../../tests/mikespace");
dojo.require("mikespace.timer");
dojo.require("mikespace.cookieData");

Now we’ll build our test. The test I’m conducting is how long it takes to load a script, and I chose dojox.data.jsonPathStore, because it’s nice and big and has a few dependencies. I modified the script to call the end of the test, after it loaded it’s dependent scripts:

...
dojo.require("dojo.date.stamp");
 
if(window.endTest){
	window.endTest();
}
...

And our test functions:

startTest = function(){
	timer.start("script loaded");
}
 
endTest = function(){
	var time = timer.end("script loaded");
	var testName = "dojox.data.jsonPathStore Load";
 
	var c = new mikespace.cookieData({cookieName:testName});
	//c.clearData();
	c.loadData();
	c.saveData(time);
	c.showData();
}

When endTest() is called, the cookieData object is created and the test data is saved and logged. Since the timer has already ended, the amount of time it takes to create this object is not factored into the results. If I want to start the test over, I uncomment c.cleardata() and refresh the page.

Finally, to launch our test, start the timer and load the script:

startTest();
 
dojo.require("dojox.data.jsonPathStore");

Refresh the page ten times and you have a legitimate average of how long it takes to load the script.

And there you have a quick and dirty method for logging tests that involve page refreshes. This example could be taken even farther, enclosing the startTest() and endTest() in its own PODO which requires the timer and cookieData. Then it’s a simple matter of dropping in the one require to conduct some quick tests.

Ext JS is a powerful JavaScript library that simplifies Asynchronous JavaScript + XML (Ajax) development through the use of reusable objects and widgets. This article introduces Ext JS, providing an overview of the object-oriented JavaScript design concepts behind it, and shows how to use the Ext JS framework for rich Internet application UI elements.

The Dojo Foundation has recently decided to support Psych Desktop. Our membership with the foundation will improve ties with Dojo. We will be donating some parts of the desktop, such as the sound api, to dojo as a result of this. The membership also will help us reach out to Dojo's community in order to improve the API, and deliver a better developer experience.

This is also a good time to announce that we will be redoing our site very soon. We understand that the forums we have are not very good, and seldom used. Also, a lot of the content is old, and it's good to start from scratch once 1.0 has been released.

Lastly, I'll tell you all what's happening in trunk. At the moment, it's broken because we're re-writing the server-side code completely using the Zend Framework. The new architecture will feature RPC, XHR long polling, and better server-side apis for apps that require server-side code. The 1.0 branch works, which you can get from http://svn.psychdesktop.net/branches/1.0/.

Development in the past month has been slow, but it seems to be picking up gradually. We really do need some more contributors though, so if you're interested, contact us.

In this issue…

• Our First Issue
• Fennec M4 Available for Testing
• New Fennec Working UI Designs
• New Mobile Networking Profiling Tool
• Aza Raskin’s Mobile Concept Video
• Embedding

Our First Issue

Welcome to the first issue of about:mobile.  This newsletter will cover what’s going on in the Mozilla Mobile community on a monthly basis.  Please send your comments and suggestions to about-mobile@mozilla.com.  You can follow this newsletter from the Mozilla Developer News weblog or via our email list.  You can always unsubscribe from the mailing list with the link at the bottom of the mail.

Fennec M4 Available for Testing

The M4 Milestone release of Fennec is available for testing for the N800 and N810.  The main feature of this release is that it features really good scrolling and panning, largely written by Stuart Parmenter and Gavin Sharp.  Please note that this is still a very early milestone release, and as such this build has many features that are either incomplete or unstable.  Please see the instructions on how to install this Fennec milestone release on the N800-series tablets and Mark’s post on the release.  If you follow the instructions you will also get milestone updates as they become available.  The M5 milestone should be out a few weeks from now.

If you want to get involved remember that you can join the Mozilla mobile community on the mozilla.dev.platforms.mobile newsgroup or join via IRC on #mobile on irc.mozilla.org.

New Fennec Working UI Designs

Madhava Enros has updated the working UI designs for Fennec.   The current designs aim to minimize required typing, make it easy to do quick searches, and also to maximize the amount of screen space dedicated to web content.  Primary browser controls and tab thumbnails are placed out of the way, just beyond a page’s edges, but can be dragged quickly into view when needed.  Please see his updated mockups in the mobile section of the wiki to get the full story.

New Mobile Networking Profiling Tool

Pat McManus is working on measuring network performance for mobile.  As part of this he has created a network emulation tool that lets Fennec on Linux run as if it were connected to the Internet through a variety of different wireless networks.  He’s created configurations for GPRS, 3G, bluetooth and others. Feedback on the tool and especially any pages that interact poorly with any of the provided profiles would be much appreciated. Details on how to get the tool and use it are included in the newsgroup announcement.

Aza Raskin’s Mobile Concept Video

Mozilla Labs’ Aza Raskin has put up a video and blog post outlining some of the ideas he has for navigation on mobile touch devices.  Designed around single finger manipulation, Aza explores some ideas about how people might navigate from tab to tab or from browser to bookmarks.  A focus on visual momentum and realistic physics round out the demo.  To learn more see Aza’s post which includes a great screencast.

Embedding

Pelle Johnsen and Dave Camp have been hard at work on Mozilla’s new Embedding API.  It’s still very very early but Pelle has posted instructions on how to build the embedding APIs for some of our supported platforms.  Right now we have working support for Qt on Windows, a separate native win32 version, GTK+ on Linux and Tristan Van Berkom has been working on support for GTK+ on Windows.  In addition, Pelle posted early doxygen docs that outline the common parts of the API.

If you want to join up with the rest of the embedding community join us on #embedding on irc.mozilla.org or the mozilla.dev.embedding newsgroup.

SMS is a great way to push small amounts of text to mobile users. But what happens when your application needs to send more than 140 characters of information? Most modern phones, including Apple’s iPhone, support the ability to launch the mobile web browser using the URL embedded in the SMS message. Your application can create a short URL that points to the content you need to send and send the URL in the body of the SMS instead of the content itself. The user experience varies from phone to phone. On the iPhone, the user simply touches the link; on other phones, there is usually a menu option that will activate the url.

The URL is subject to the same size limits as any other SMS message. Keeping the URL as short as possible is key, allowing you to send descriptive text along with the message to give the user an idea as to what they will be viewing when they click the link. URL shortening services like tinyurl will keep your URL to around 25 characters. Twitter users are no doubt familiar with this idea, whether they send Tweets from their phone or not.

The web page that the URL points to needs to detect the capabilities of the mobile device and return the appropriate markup. In the case of the iPhone, a full HTML page can be returned, but for many phones, the content needs to be limited to the XHTML mobile profile, or as a worst case with the oldest of phones, WML might be the only supported markup. Device capability databases like WURFL will allow you to look at the user-agent of the devices and return the appropriate markup.

Make sure that your users actually want to receive the SMS before you send it. Most users have to pay for each SMS message, so filling up their phone with messages without their permission is not a good idea. Allow your users to opt-in to receiving SMS messages and allow them to place a maximum cap on the number of messages they can get per day or month. Also include a verification system that ensures that your user actually controls the phone number they give you. This can be as simple as sending an SMS message with a PIN number that they then feed back into your signup form. Lastly, include disclaimer text that lets the user know that standard text messaging rates apply to any messages you send them. Adding these safeguards will help to ensure that your users only receive the messages they want.

Adding SMS notification with embedded URLs has many advantages: you can reach your users wherever they are, provide links to detailed rich content, increase awareness of your mobile web offering, and drive additional traffic deep into your mobile web site. If your application already works on mobile devices and you already have the infrastructure in-place to send email or SMS alerts, then sending URLs in SMS messages is a simple addition that can add significant value to your users. A great example for this is the airline industry. Instead of just sending a user an SMS with their gate information and arrival and departure time, they could also send a link to a convenient, mobile optimized “My Flight” page that would include other essential details such as seat assignment, arrival time, airline phone number, first class update options, and airport map.

In May I presented to students and staff from the University of Auckland as part of the Electrical and Computer Engineering seminar series. What was I talking about? Getting involved in open source software - why would you want to? how to get started? and what to expect once you're there.

| View | Upload your own

As usual, the slides would be a lot more helpful with some words to go along with it :) Basically I talked about my experiences with a number of open source projects, and particularly my work with the Dojo Toolkit.

Google's Summer of Code and Highly Open Participation programmes have been a fantastic source of new contributors to open source, and at Dojo we've been lucky to be involved for the last three years with Summer of Code. GHOP last year showed what a huge range of relatively easy things can be done to make an open source project better and just how many ways there are to get involved.

A few of us have been gently pushing for ECE to get software students to work on open source for their final-year undergraduate projects where it makes sense. This year there are two students adding new features to the Player/Stage robotics project, and it was interesting to talk to them after the seminar and find out how they'd been getting along and what issues they'd run into.

Key things out of all this:

• projects want new contributors
• the best way to get started is to do something
• there are a pile of ways to get involved, of which coding is only one
• what you get out is proportional to what you put in
• anyone can do it, especially you :)

Back in March (yeah, I know) I got invited to do a presentation to a group of high school technology students at Avondale College. So, I decided to talk to about Web 2.0 and why it matters, and what the big deal is anyway. Specifically what the differences between 1.0 and 2.0, and what it practically means for students, as well a company like Koordinates.

| View | Upload your own

The slides are best when they go along with the talk, but hey :) I thought it went really well, and I got some really good questions.

I spend a few minutes afterwards talking more closely to one of the senior classes. The students were working on the process of technology development projects, and we talked about how we work at Koordinates. I was a little disappointed (but not surprised) that the waterfall model is the standard still being taught, and nobody knew what agile was. At Koordinates we do cycles of 1-2 weeks for decent sized work, and we're releasing code every day or two for bug fixes and minor tweaks. It is much easier for us to manage, design, code, test, and deploy many small changes than massive changes that affect everything. In fact, the more changes that stack up the itchier we get to push it out to production. To support all this we've built and tied together a bunch of tools so it is damn simple to push changes between the different environments in controlled ways.

The talk was part of FutureInTech, a programme run by the Institute of Professional Engineers, aiming to get students of all ages interested in science and technology as career options by involving young engineers. The regional facilitators do a really great job getting all sorts of people into schools to talk and work on projects. If you're interested in talking or getting someone into your school, get in touch.

Finally received my Zardoz custom t-shirt I designed and had printed. I’m very happy indeed. Now the guys at the office will all be ordering one. It’s funny that a 40 year old bad Connery movie has caused such a stir at the office, especially since Eric brought it and we watched it over lunch (and the post-lunch conference call (on mute)).

I have to say I just love the logo, it’s almost iconic of the mid 70’s.

I’d forgotten what a truly cult like bad movie it is, it just makes you want to love it all the more for how completely dated and dreadful it is. Finally I’d like to take this opportunity to apologize to the copyright owners of the Zardoz logo for basically stealing it to print the t-shirt. I’d have brought an official one if I could have found an official one, maybe me wearing one and writing this post will make more people buy the Zardoz DVD (unless Eric got the last one).

This is the original trailer…

If anyone is interested in a t-shirt, let me know and I’ll point you to where I got this one made. Just comment below.