news aggregator

Hi! It’s Bill Hill here again, still fighting the good fight to make typography on the Web as good as we’re used to seeing in print. We made significant progress this week, when one of the USA’s most prestigious font companies announced its support for the Embedded OpenType format for font embedding on the Web, and launched a new website to promote other browsers to support it in addition to Internet Explorer (which has had EOT support built-in since 1996).

At the same time, Ascender Corporation and its collaborators in the typographic community also warned of the legal dangers of using the Font Linking mechanism currently supported by other browsers.

Read the announcement in full or visit the new Ascender site for further details.

Font Embedding with EOT

Embedded OpenType (EOT) is currently before the W3C in a submission to make it an open Web Standard. The format was previously proprietary to Microsoft. We created it to enable font embedding within Microsoft Word documents in the early 1990s, and it was later extended for use on the Web by Internet Explorer.

In its introduction to the technologies of font embedding on the Web, Ascender says, ”Fonts play a critical role in the display, printing and manipulation of text-based information and content. Font embedding is a broad and complex topic, and we hope this website becomes a valuable resource for everyone who creates or uses fonts to learn more about proper font usage and licensing.”

The website has sections covering issues such as:

• Fonts and the Law
• Document Font Embedding
• Fonts and the Web (a comparison of the various embedding technologies)
• Shipping Fonts with Applications, Digital Content, and Devices

In the section on Fonts and the Web, Ascender compares EOT, sIFR and Font Linking, and welcomes the move by Microsoft and Monotype Imaging to propose EOT as a W3C standard (Monotype Imaging, another prestige font company, developed MicroType® Express compression to reduce the size of EOT files). The proposal has been with W3C for several months.

“EOT offers several advantages for type designers, and web designers. For type designers EOT creation tools must respect the embedding permissions built-into their fonts and EOTs are bound to a specific web page or site. For web designers an EOT can contain a subset of the glyphs, and it can be compressed – both of these features can shrink EOT file sizes to reduce download times and improve performance,” says Ascender.

Font Linking, in which raw font files are stored on a server and downloaded using the @font-face mechanism, falls outside the realm of fonts embedded in documents, Ascender warns. ”Web page designers should be very careful to avoid violating commercial font EULAs (end-user licensing agreements) by placing fonts on Web servers”. Ascender’s own EULA, for instance, prohibits installing fonts on servers without purchasing an extended license.

In concluding its comparison, the website continues, “Ascender believes that although not perfect, EOT represents the best current solution for type designers and font foundries to protect their Intellectual Property. It is the only web font embedding solution that respects font embedding permissions, uses an industry-proven subsetting and compression mechanism, and ties embedded fonts to specific web sites. Ascender hopes that other web browsers will make it a priority to support EOT once it becomes a W3C standard.”

The site also has some free fonts to promote the technology, and the first Web-based EOT creation tool.

This endorsement prompted me to go back and start playing around with font embedding, since I hadn’t looked at it in some time. I started by downloading WEFT, the Windows Embedding Font Tool, from the Microsoft website.

Before you try to use the tool in earnest, it’s really worthwhile going through the tutorial on the same page, which has some code samples. There’s also more good information in the “Troubleshooting and Testing” section on the WEFT page.

Don’t expect the tool to do all the work, though. It’s great at creating EOT files and the CSS Font Declarations used to link your pages to them. But - depending on the complexity of the source files for your pages - you may have to do some manual coding to get them to work properly.

Give it a Try, with a Caveat 

Here, I have to do a huge mea culpa.

Creating a set of pages using EOT allowed me to experiment with what a blog, for instance, might look like if it was designed for readability. But I’m a type and font guy – not a Web code jockey. I just wanted to see, quickly, what readable pages might look like. This was an experiment. I didn’t want to start hand-crafting pages. So I took the easy route, and used a publishing application with which I’m very familiar to generate the multicolumn pages.

This is “throwaway code”. It’s verbose, arcane and in lots of places it’s proprietary. A real Web guru like Chris Wilson takes one look, and you just know he’s controlling the urge to scream. The W3C HTML Validator, though, doesn’t manage to control the urge to scream: “85 coding errors, you moron! Starting with no <Doc Type>!”

My pages offended Chris so much, he immediately made a start at re-coding them so they’ll validate and meet Web standards. If I was a sensitive soul I’d be offended, but like I said, I’m no coder. And what a great way to recruit a very busy guy to do some coding for you. My pages are like a crooked picture on a wall which Chris passes every day – if he doesn’t straighten it, it’ll drive him mad…

Just his first pass at making a “legitimate” version of the first page took its size down to only 25% of the original. And even I can tell the code’s a lot better. We’ll work to get “legitimate versions” of the pages posted. We’d have preferred to do this before this blog post, but Chris said something about wanting to spend the weekend with his family or something :), and I wanted to highlight the Ascender announcement while it was timely."

Anyway, if you’re going to blame anyone for the code, blame me.

With that huge caveat, you’ll find my pages at:

http://billhillsite.com

They’re definitely a work in progress, so expect the odd glitch. For example, one or two people have reported mild clipping issues on some displays. I’ll need to investigate.

They were designed to be viewed on a 1400 x 900 display, and should be viewed using the F11 key to make Internet Explorer go FullScreen, to get rid of menus, address bars and anything else that distracts from reading. I’ve got into the habit of toggling F11 to go from my personal “reading” mode to “browsing” mode – where I want all those menus and toolbars…

I had to manually tidy up and paste the @font-family declarations, which look like this:

<style>
   @font-face {
   font-family: Cambria;
   font-style: normal;
   font-weight: normal;
   src: url(CAMBRIA2.eot);
   }

I’ve given feedback on these issues to the team, and we’re working out what can be done to reduce the need for manual tweaking.

Of course, since we’ve opened up the EOT format, we hope other tools will soon be generating EOTs as well, such as the Ascender site. Since the W3C submission includes sample code, it would be great if the tools you use to author pages would integrate EOT generation into the process. Then the code would be more tightly integrated as well.

The good news is that if you have to do some manual tweaking, once you’ve got it right for one page, the code can be easily copied and pasted into your other pages. Even better, you can put it in a Style Sheet, and have all the pages reference it.

Working with WEFT and EOT

One performance tip for embedding fonts in your pages is to use the subsetting capability available in the WEFT tool to generate the font objects with only the characters you need. They’ll be smaller, and faster to download.

For instance, if you write in English, then you’re unlikely to use the Cyrillic or Greek characters, and you could use “language-based” subsetting. There are seven subsetting options in the tool, including “per page” and “per site”. Since my test site’s a blog which should be frequently updated, I opted at first for “no subsetting”, which creates the largest font objects - but means I’ll never need to update them whatever new content I create in future.

However, on reflection, I thought this might be overkill, and tried language-based subsetting, and got a huge performance improvement!

Calibri and Cambria, for instance, are big fonts with four true weights each, all of them painstakingly hinted for maximum readability at small sizes. The four weights ended up as font objects of ~175K each without subsetting. With language-based subsetting, they were only one-third the size of the original EOTs and the page rendered just the same – only a lot faster.

Nice thing is, as long as I made sure the names of the objects for each font and style remained the same, I was able to just swap out the objects in the root directory of my site, without having to change the code in any of my pages.

Another production tip from my experience which can save you a lot of time: WEFT will let you analyze pages on your Web server – but you can tell it to create the font objects on your local hard drive. Generating the objects on the Web can take a loooong time. Using your local machine it’s very quick, and you can then FTP them to your site.

Font embedding is critical not just to allow designers to make distinctive pages, but for readability. Building fonts that work for text at normal reading sizes of 11 and 12 points requires a lot of work. It could take a designer anywhere from a year to three or more years to develop a full character set, hint it properly to work at screen resolution, and so on.

However, anyone who has a copy of Windows Vista, Office 2007 or Mac Office 2008 already has a great set of fonts they can embed in Web pages. They’re called the C* fonts (because they were optimized for ClearType, and thus all given names which began with “C” J): Calibri, Candara, Consolas (a monospaced font for coding), Cambria (which also contains a set of 4000 Math characters), Constantia and Corbel.

I know personally how much effort went into creating them, because at the time I was managing the group which ran the project. Outside designers created the outlines from their winning entries for a competition we ran, and then the fonts were hinted by the best in the business.

The project took a long time and cost a lot of money – which is why we don’t just give these fonts away. They add a lot of value to the applications (and operating systems) which ship them. But they all have Embedding permissions set to “Editable”, which means you can freely embed them using EOT, as long as you bought one of the products in which they shipped – although you are not allowed to just copy the .TTF font files to a server.

My absolute favorites for reading on screen are Cambria and Calibri. I use them for body text at 12point because I sit a little farther away from the screen than I would read from paper (where the optimum size is 11point). The faces also all have true italics, bold, and bold italics – none of your ugly, synthetic, machine-generated rubbish! A true italic face has unique characters, which are not just a skewed regular or Roman…

The Future of EOT

Remember, these pages will work only in Internet Explorer right now, because it’s the only browser which supports EOT font embedding. EOT was a great idea for Word back in the 1990s, and it was a great idea for the Web in 1995. But because Netscape at that time adopted another standard, and we kept EOT proprietary, no-one used either.

That’s why, last year, I gathered a group of folks together and began a campaign to make EOT an open standard and put a full proposal in front of the W3C.

I really hope it will become a standard, and other browsers will also implement it, because it’s a much-needed solution to the problem of using fonts on the Web that meets the needs not only of end-users and Web designers (who get to use the commercial fonts they already know), but also commercial font creators, more of whom will start enabling embedding as a result.

We have to solve the issue of fonts on the Web in a way that’s fair to everyone in the ecosystem.

Try experimenting with EOT embedding. I’d love to see some samples from people who actually know what they’re doing…

Bill Hill
Program Manager

edit: added two additional headers for readibility

We have previously released experimental Labs builds containing File I/O, and 3D . For the first time we now have bundled them all into one build. On all of our desktop platforms.

Head over to the Labs to read more about the newest singing, dancing labs build… and to download your build!


WARNING: These are development snapshots: they contain the latest changes, but they also have severe known issues, including crashes and data loss situations. In fact, they may not work at all.

Today's post will be a bit unusual in the sense that it won't be about Opera itself, but rather about how Opera is brought to you. This post will attempt to explain to you how we get from a lump of source code that can be compiled in a lot of different ways with many different options to the Opera packages that you can download and install from this blog.

Install? That is already a complex process on its own. You do it once and never think about it again, but the fact is that installation is a crucial process and it has to work properly, otherwise you can't enjoy your favorite software! So, how do we fit all our code in an executable, then pack it in an installer?

There are essentially two processes that take part here: Building and packaging. We have a build system that realizes both of them. The first part of it is a web interface that collects build requests from everyone and then dispatches them to our build servers, each of which can make a build for the requested OS. The second part is a script, partly different for each OS, running on each build server which takes care of building and packaging.

The building part is pretty much the same on each platform: it obtains the requested version of the source code, compiles it with the right options and builds it into an executable (and libraries). The compilation part is taken care of by a compiler specific to the platform on which the build is made and it mostly takes care of itself, as long as the source code is correct.

At that point, everything is ready for packaging, and the script becomes very different depending on the OS. I will talk more specifically about packaging on Windows, since I am responsible for the Windows part of the build system.

There are two kind of packages on Windows: MSI packages made with InstallShield and "Classic" packages made using an old version of the WISE installer. The WISE installer is relatively easy to configure. It takes a sort of installation script, written in its own scripting language, and just executes it. It uses an additional DLL to realize functions that are not possible with only the script itself (like detecting Windows Vista). Although it is nice and easy, the WISE installer is not very well adapted to Windows versions more recent than Windows 98.

InstallShield is a much more powerful tool and MSI installers are a lot more complicated to put together. I won't get into much details here, but there is a huge amount of configuration that can be applied to an InstallShield package. It relies on an ISM file (Installer definition) which is XML formatted and indicates what the package should do, once compiled.

The packaging script starts by opening the installer definition file and set up a few things in it, preparing languages and translations of the installer itself. It enumerates all the files that need to be in the package and puts them in the right place. After a few more tweaks it builds the MSI package. The process is done once for each MSI package. The WISE installer is built along with the english-only MSI package but the process is trivial in comparison.

Maintaining and improving the build system and packaging scripts is no small task, but also an important task. Without it all builds and packages would have to be made manually!

This was it, a small peek at a hidden, but important part of Opera development.

In other news, our QA team has started their own blog - head over to the new QA blog for more peeks "under the hood".



Changelog:

• Fixed a URL encoding issue in javascript: URLs
  
• Fixed an issue with the BBC iPlayer RealPlayer plugin not working
  
• Several stability fixes
  
• Fixed a problem where GMail would not load
  

Download
Windows
Windows Classic
Macintosh
UNIX

Join members of the Internet Explorer team for an Expert Zone chat next Thursday, July 17th  at 10.00 PDT/17.00 UTC. These chats are a great opportunity to have your questions answered by members of the IE product team. Thank you to all who have attended the chats to date!

If you can’t join us online, all chat transcripts are published here. Allow approximately 7-10 days following a chat for the transcript to go live.

Hope you can join us on Thursday!

Kristen Kibble
Program Manager

P.S. Upcoming IE chat dates are posted here.

Hi, I’m Sharath Udupa, developer on the IE team focusing on AJAX features for IE8. One of the AJAX improvements we adopted in IE8 from HTML5 is AJAX page navigations. In IE8 mode, we provide support for script to update the travel log components (for e.g. back/forward buttons, address bar) to reflect client-side updates to documents. This allows a better user experience where users can navigate back and forth without messing the AJAX application state.

For more information regarding the feature and sample code, refer to the Internet Explorer MIX08 Hands-on Labs for AJAX and IE8 Beta 1 for Developers. For an example of how this can be used to hook navigation in Silverlight (with sample code!), see Michael Scherotter’s blog  posts titled How IE8 Enables Silverlight Deep Linking and Browser Back/Forward Navigation and IE8 Forward/Back in a Silverlight 2 (Beta 2) Application for further details.

Sharath Udupa
Internet Explorer Developer

Hei
We are still doing polishing on Kestrel and have some more crashfixes etc for you all to play with.
Please look for regressions since 9.50

Changelog:

• Lots of stability fixes
  
• Fixed an issue with history navigation: an iframe with document.write is not added to history anymore
  
• Fixed an issue where IRC would disconnec users without informing them
  
• Fixed window.close() not functioning after invoking context menu - now also in widgets :whistle:
  
• Fixed an issue where "Mark all as read" in M2 would also mark as read some mails not visible in the current view
  
• Fixed creation of POP aim.com account
  

Download
Windows
Windows Classic
Macintosh
UNIX

The British Standards Institution (BSI) has invited two members of the WaSP, Bruce Lawson and Patrick Lauke, to join the drafting committee for the first British Standard for Web Accessiblity.

Two years ago, the BSI was sponsored by the Disability Rights Commission to write a Publicly Available Specification (PAS) called PAS 78: Guide to Commissioning Accessible Websites. Publicly Available Specifications are written quickly and “expire” after two years, but because of the popularity of PAS 78, the BSI have decided to update it to become a full British Standard.

We’ve just started work on the draft, which doesn’t yet have a title, although our working title is “encouraging the development of fantastic user experiences for disabled people online”.

Consequently, it’s too early to say what will be in BS8878, which will be released next spring. I can say that it will not tread on the toes of whichever version of WCAG is live then, as it’s a document to help site owners rather than developers. Like PAS 78, it will encourage adherence to current web standards.

Neither can I say who else is on the committee, except that it’s chaired by Julie Howell, and there are representatives from all over industry—broadcasting, banking, legal, education and (crucially) representatives of disability groups, including groups working with those with cognitive disabilities.

Patrick and I gratefully acknowledge our employers, Opera Software and the University of Salford, who are supporting us by paying our travel expenses and giving us time off to attend meetings and write the drafts. They have nothing material to gain by supporting us, and are exercising no editorial control, but are helping to make disabled people’s experiences of the web better.

As a procedural footnote, now that Derek Featherstone has moved role within WaSP to be Group Lead, I’m working with Patrick to be co-lead of the Accessiblity Task Force. Our main projects will be the British Standard, continuing to work with the microformats community testing various date-time patterns with screenreaders, and monitoring the developments in HTML5.

Tell us how you overcome isolation, distractions, and temptation. How you deal with kids and deadlines. How you walk the blurry line between work and home. Share your best practices on working from home so we can present them in an upcoming issue of A List Apart.

 

Hide Your Shame: The A List Apart Store and T-Shirt Emporium is back. Hot new designs! Old favorites remixed! S, M, L, XL. Come shop with us!

Working from home as a freelance contractor or remote employee can be a great thing, particularly if you live alone. But what if you have a spouse and/or children at home with you while you work? Every work environment offers distractions, but those who work from home with their families face a unique set of issues—and need equally unique ways of dealing with them.

 

Hide Your Shame: The A List Apart Store and T-Shirt Emporium is back. Hot new designs! Old favorites remixed! S, M, L, XL. Come shop with us!

The curriculum is intended to provide a comprehensive set of tutorials designed to raise the level of education and Web Standards awareness. The curriculum has been released under a Creative Commons license and is free to use and share.

Chris states:

We think it will be useful to anyone who wants to learn or teach client-side web design/development “the right way”, including students and teachers at schools or universities, trainers and employees inside companies, etc. It already has support from several universities and large companies, including Yahoo!

Translations and packaging of the curriculum as PDFs is on the to-do list.

User Agent Accessibility Guidelines (UAAG) provides guidance on designing Web browsers, media players, assistive technologies, and other 'user agents' to increase accessibility of the Web to people with disabilities. Plans for new work on a second generation of UAAG was published in the UAAG 2.0 Requirements Working Draft on 31 October 2007. WAI encourages you to review this document, submit any comments, and consider participating in the UAAG Working Group. See: Call for Review: UAAG 2.0 Requirements;UAAG Overview;How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute. Please send comments by 14 December 2007. (2007-10-31)

Web Accessibility: WCAG 2.0 at a Glance provides a summary of Web Content Accessibility Guidelines (WCAG) 2.0. We welcome your comments on this draft, preferably by 15 July 2008. (2008-07-07)

Web sites can be designed more efficiently to be accessible for people with disabilities and also for people using mobile devices when developers understand the significant overlap between the two design goals and guidelines. W3C recently published updated material describing this overlap. See: Call For Review: Relationship Between Mobile Web and Web Content Accessibility Updated announcement e-mail;Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices introductory page;Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG) Working Draft. We welcome your comments on the documents, preferably by 15 August 2008. (2008-07-07)

We released 9.51 today, which addresses a few security and lots of stability issues. This release is a recommended upgrade for all those running the latest stable releases.

Changelogs are available:
Windows
Mac
Linux/UNIX

Go download it!

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

And one more RC for the upcoming 9.51! Lots of nice fixes in this one - and we need your feedback, specially on:

• upgrading (we did some more tweaks to the installer)
  
• saving (of images, of web pages, of "stuff")
  

Changelog:

• Fixed proper clearing of textarea when no-cache is set.
  
• Fixed a crash on print preview.
  
• Saving of images is not recorded in transfers anymore.
  
• Fixed window.close() not functioning after invoking context menu… :doh: (this also fixes closing Dragonfly…)
  

Unix specific:

• Fixed printing on Linux :pingu:
  

Download
Windows
Windows Classic
Macintosh
UNIX

More fixes in the pipeline for 9.51! As always, we appreciate constructive feedback. Main focus was on stability and the installer - some issues that users have encountered when upgrading from 9.27 should now be finally solved.

Changelog:

• Security status should be now always correctly set when navigating from HTTP to HTTPS.
  
• Fixed an issue related to OCSP and CRLs that would lower security level - Yngve has a detailed article. You'll have to manually check for updates to activate this fix.
  
• Fixed an issue in the content blocker that might cause no page to be loaded anymore. :doh:
  
• Fixed a crash on Yahoo! Mail (now really!).
  
• Fixed a crash with userjs.
  
• Fixed a crash related to Dragonfly.
  
• Fixed a crash on Print Preview.
  
• Fixed an issue that caused unwanted line breaks in rich text editors.
  
• Fixed loading of stylesheets when navigating in history.
  

UNIX specific:

• Fixed an issue that would prevent pages from closing on Qt4 builds.
  
• Fixed saving of changes to plugin configuration.
  

Download
Windows
Windows Classic
Macintosh
UNIX

Every wonder who you really are? Congratulations! You have a lot in common with JavaScript. Learn once and for all how to train your JavaScript to remember who it is and what it's doing.

 

Hide Your Shame: The A List Apart Store and T-Shirt Emporium is back. Hot new designs! Old favorites remixed! S, M, L, XL. Come shop with us!