- Today we updated on HTML5 Labs the previously released Media Capture prototype to better align it to the latest W3C editor draft.
The HTML Media Capture working draft continues to evolve alongside related discussions in the Web RTC workgroup, and we have blogged previously about why this feature is important and how our Media Capture prototype implemented it in the past.
Because the API surface for this feature is far from final, we are supporting a simple capture syntax with this update, which is based on the most current proposal. We expect the capture syntax to change as the requirements for media capture are clarified in the task force.
Latest Updates
In this update, we are specifically adding support for a version of thegetUserMediamethod (function names are ms-prefixed for prototyping purposes), theMediaStreaminterface, and its associated events and callbacks.getUserMediaallows Web developers to suggest what specific capture devices are desired. This then allows end users to authorize the browser to access the device they selected for the duration of the capture session.
The advantage of this is two-fold: it protects user security and privacy and lets them pick the optimal device for the capture task from the many options available to them on a modern PC.function onLoad() {navigator.msGetUserMedia(options, cameraStarted);}
function cameraStarted(mediaStream) {msMediaStream = mediaStream;getReady();document.getElementById("previewWindow").style.display = "block";document["imgPreview"].src = URL.createObjectURL(mediaStream);}
Looking back at our earlier proposals, we believe those scenarios are still important and relevant to this update: last March we released a prototype implementation of the audio portion of a working draft of the W3C Media Capture API on HTML5 Labs. This prototype publicized some proposed API enhancements described in section 6.1 of Microsoft’s HTML Speech XG Speech API Proposal. We then updated the prototype to include the image and video capture features described in the proposal to support scenarios we’ve heard are important for Web developers, and incorporated your feedback on audio.
This past November, we took our experience with the development of this prototype and interest in media capture for the browser to the W3C's technical plenary meeting (TPAC). Travis Leithead shared some of our feedback with the Device APIs (DAP) Working Group and we continued existing discussions within the HTML Speech Incubator Group. One result of our engagement was the formation of a media capture joint task force in order to bring the best of local media capture and real-time communication scenarios together. We are actively participating in the task force and support the getUserMedia approach to capture.
We then released an updated prototype in December that gives Web developers early access to photo, video and audio media capture APIs in the browser. We anticipate evolving the prototype to share implementation feedback and experience with the new media capture task force. The end goal remains to create the best possible standard for the benefit of the whole Web community.
Then, as discussed earlier, today we have updated the previously released Media Capture prototype to better align it to the latest W3C editor draft, which supports a simple capture syntax that is based on the most current proposal.
Microsoft remains actively engaged in the Media Capture task force and continues to advocate for the creation of the highest quality API to support these scenarios.
We Welcome Your Feedback
As always, we look forward to hearing from you, especially your questions and comments on how we can make this feature as good as possible for both the Developer community and end users. Please contact us either in the comment section on this blog or here.
—Adalberto Foresti, Senior Program Manager, Interoperability Strategy Team
Travis Leithead, Program Manager, Internet Explorer
-
Spring into St. Patrick’s Day with HTML5
Posted 1 day ago
Another holiday brings us another opportunity to celebrate it with you. We’re pleased to mark the transition into spring as well as St. Patrick’s Day with Irish Spring, a new hardware-accelerated HTML5 experience that shows the benefits of Internet Explorer 10 on Windows 8 Consumer Preview.
Irish Spring incorporates HTML5 canvas and CSS gradients, opacity, transforms, and animation along with HTML5 audio. With the Windows Consumer Preview and IE10’s support for multi-touch you can propel the clovers and leaves around in a strangely satisfying fashion. Try it with multiple fingers on your touch device. Alternatively, you can use your mouse to move the clovers around the screen.
If you aren’t using Internet Explorer 10 and think your browser can still handle the heat, give it a shot. But don’t be surprised if the lack of multi-touch and full hardware acceleration leaves you wanting to install the Windows 8 Consumer Preview.
Put a little spring in your friends’ step by clicking the share controls at the top of the demo.
This video shows IE10's support for multi-touch and hardware acceleration in action with Irish Spring.
From the entire IE team, we wish you a happy, safe, and lucky St. Patrick’s Day!
—Tobin Titus, Program Manager, Internet Explorer
-
Enhanced Protected Mode
Posted 3 days agoEvery release of Internet Explorer includes new security enhancements to help keep you safe as you browse the Internet. The new Enhanced Protected Mode in Internet Explorer 10 helps keep your data safe even if an attacker has exploited a vulnerability in the browser or one of its add-ons.
There is no single thing that can keep you secure by itself, so we pursue multiple strategies, including:
Protection from socially-engineered attacks
There are a variety of miscreants that want to steal your personal information or take over your computer by impersonating Web sites that you trust. SmartScreen Filter provides the best protection available against malware attacks and phishing. In Windows 8, this protection was added to the Windows Shell, to help keep you safe from malware no matter how it was downloaded.
Protection from attacks designed to exploit vulnerabilities in Web sites
“Good” Web sites can have security vulnerabilities that can allow evil Web sites to steal your data or perform actions as if they were you. We protect you with the XSS Filter, which automatically prevents certain types of attacks, and make it easier for Web sites to secure themselves with Declarative Security features, like IE10’s new support for the HTML5 Sandbox.
Protection against attacks designed to exploit the browser or operating system
Automatic updating ensures that you have the latest updates installed. This protects you against security issues that have been fixed. IE9 added memory protection features to make it harder to exploit certain types of vulnerabilities and we enhanced these features in IE10. We also added a new layer of protection in IE10 called Enhanced Protected Mode.
Enhanced Protected Mode
Protected Mode, which was added in IE7 for Windows Vista, is defense in depth feature that helps prevent attackers from installing software or modifying system settings if they manage to run exploit code. It is an extra layer of protection that locks down parts of your system that your browser ordinarily doesn’t need to use. For example, your browser doesn’t usually need to modify system settings or write to your Documents folder. Protected Mode is based on the principle of least privilege -- by reducing the capabilities that Internet Explorer has, the capabilities available to exploit code are reduced as well.
“Enhanced” Protected Mode takes this concept further by restricting additional capabilities. Below is a list of some of the new ways that Enhanced Protected Mode helps keep you safe:
64-bit processes
Most PCs shipped in the last few years have 64-bit CPUs, and many have a 64-bit version of Windows installed. “64-bit” is usually thought of as a way to extend the amount of memory that a program on your computer can use: because 64-bit processors use 64-bit memory addresses instead of 32-bit ones, a program can “address,” or use, more memory if it’s available.
A 32-bit number is large – it’s a little more than 4 billion. A 64-bit address is much larger number – roughly 18 pentillion and change (18,446,744,073,709,551,616). Not only does a 64-bit number let you address more memory, it also makes existing memory protection features such as ASLR (Address Space Layout Randomization) much more effective. Heap spray attacks, which are used by attackers to plant malicious code at predictable locations, become much more difficult because it isn’t practical to “fill up” a 64-bit address space – you’ll run out of memory and disk space long before any sizable fraction of the address space is sprayed.
Protecting your personal information
When you run a program, it has access to anything on the computer that you have access to, including your personal documents. Enhanced Protected Mode restricts Internet Explorer from locations that contain your personal information until you grant permission to it. This helps prevent exploit code from accessing your personal information without your permission.
For example, consider Web-based email. If you want to attach a file from your Documents folder to the email, then Internet Explorer needs permission to access the file and upload it to your email provider. With Enhanced Protected Mode, a “broker process” will grant Internet Explorer temporary access to the file only if you actually click on “Open” on the file upload dialog:
Notice that there are no extra prompts. Brokering is done automatically after you choose to open a file. This is like providing a single safe deposit box to Internet Explorer when requested, instead of giving access to the entire safe all of the time.
Protecting your corporate assets
Most corporate networks, or “intranets,” contain valuable information that must be protected from attackers. Enhanced Protected Mode restricts an exploit’s ability to access corporate network resources in three ways. First, Internet tab processes, which is where untrusted Internet pages load, do not have access to a user’s domain credentials. Second, they cannot operate as local webservers, which makes it more difficult to impersonate an Intranet site. Third, Internet tabs cannot make connections to intranet servers.
Default Settings and Compatibility
Metro style Internet Explorer always runs with Enhanced Protected Mode enabled – there isn’t anything that you need to configure – just browse. Because Metro style Internet Explorer offers plug-in free browsing, the compatibility impact of this security feature is minimal.
Many add-ons, such as Adobe Flash and certain toolbars are not yet compatible with Enhanced Protected Mode. Some Web sites still require Adobe Flash in order to work, and some users enjoy the additional functionality offered by some toolbars. In Windows 8 Beta, Enhanced Protected Mode can be enabled in the desktop under Internet Options->Advanced:
After you enable Enhanced Protected Mode, incompatible add-ons will automatically be disabled. If you encounter a site that needs an add-on such as Flash in order to work, you can disable Enhanced Protected Mode just for that particular Web site.
This allows you to continue using the site, and have Enhanced Protected Mode enabled on the rest of the Internet. Keep in mind that you should only do this if you know and trust the Web site.
Of course, if you prefer to browse without add-ons, you can always turn on ActiveX Filtering, which will prevent you from seeing this prompt.
Summary
Defense-in-depth is an area of continual investment for the Windows team. It’s a widely-applied principle in the real world as well. Safety deposit boxes have locks on them. But they are also kept inside of a locked room, inside of a bank, which is locked and is armed with an advanced security system. Enhanced Protected Mode is another layer of protection that helps protect your data from malicious attackers.
—Andy Zeigler, Senior Program Manager, Internet Explorer
-
Enhanced Memory Protections in IE10
Posted 4 days agoInternet Explorer 10 introduces significant improvements in memory protections to help make vulnerabilities harder to exploit, helping to keep users safe on the sometimes-hostile Web. These improvements will increase the difficulty and development cost of exploits, making life harder for the bad guys.
While socially-engineered malware is the primary way that bad guys get their code onto victims’ computers, that is largely because browser vulnerabilities have become less common and harder to exploit over the last few years. However, as more and more users upgrade to IE9 and benefit from the protection provided by SmartScreen Filter, bad guys have a renewed interest in attacking the browser and its add-ons directly.
In today’s post, I explain the threat environment, survey the existing protections available in IE9, and explain how IE10’s new memory protections provide even more security.
Attacking Web Browsers
The goal of an attacker exploiting a memory-related vulnerability is to cause the browser’s path of code execution to deviate into code of the bad guy’s choosing. To achieve this, the attacker needs two things to be successful. They need to have code available on the victims’ machine that they wish to run. The techniques used to obtain such code can be grouped into two classes. An attacker can place their own malicious code into memory using techniques like heap spraying. Or an attacker can select code to execute that is already present in memory using a technique called Return Oriented Programming.
The attacker also needs to be able to exploit a vulnerability that allows the flow of code execution to be altered from design, such as a buffer overflow vulnerability. Then they can change the code path to “jump to” the address of the code they want executed.
In a typical buffer overflow attack, a carefully crafted data set is placed on the thread’s stack, overflowing its assigned buffer and overwriting other data structures. Attackers attempt to overwrite structures like exception handler records, or the return address of the function, which would allow them to change the flow of code to a location in memory of their choosing.
Other types of attacks include use-after-free vulnerabilities, in which the application is tricked into accessing a released object whose memory has been reused for some other purpose.
Defending the Browser
Memory protection technologies provide a front line of defense to block attackers from achieving their goals. These technologies exist to make exploiting vulnerabilities more difficult, less reliable, and in some cases impossible. Memory protections aim to safely terminate a browser process under attack before a vulnerability can be successfully exploited to run the attacker’s code. In many cases, protections allow vendors time to produce and distribute a fix before a vulnerability can be exploited to cause damage.
The Memory Mitigation Technologies employed by Internet Explorer have evolved over time to help defend against new attack techniques as they are developed and popularized. Many defenses, like the /GS compiler flag, have been used by previous versions of Internet Explorer but are updated and enhanced over time. Some defenses, like ForceASLR (described shortly) are new to IE10 and rely on new operating system features.
Compile time mitigations
Compiler mitigations are available to software developers and should be applied as part of a development best practice. The Internet Explorer team includes these mitigations during the development Internet Explorer as a requirement of our Security Development Lifecycle. We encourage software developers to adopt their own SDL process that include implementation of these compile time mitigations.
The /GS flag was first introduced in Visual Studio .NET 2002 and has been used by all supported IE versions. It is a compiler technology which adds a Buffer Overrun Detection capability to an application’s stack. Security secrets known as “canaries” are added to application’s stack boundaries at runtime. For example, a canary placed between a stack buffer and a return address, will be overwritten by a buffer overflow attack targeting the return address. This provides a means for the process to detect that an overflow has occurred. An exception will be raised and the process can be safely terminated before the attacker’s code is run.
This basic protection concept has been improved in each new version of Visual Studio. The latest version of Enhanced /GS, used by Internet Explorer 9+, includes greatly improved heuristics to protect more functions, including Non-Pointer arrays and pure data structures. In addition, improved optimization has eliminated unnecessary checks, decreasing the performance cost of the defense.
The /SAFESEH flag is a linker option that provides a mechanism for an application’s registered exception handlers to be stored in a lookup table in a secure memory location. In the event of an exception, the exception handler addresses on the application’s stack are validated against the lookup table. If the values do not match, the process will be terminated.
One problem with the /SAFESEH flag is that it requires all DLL modules to opt-in to the protection to reliably protect the process. If any module does not opt-in, protection is less effective. While the SDL requires that all of Microsoft’s code be compiled with SAFESEH, third-party add-ons might not be compiled with the flag.
The /DYNAMICBASE flag is a linker option that opts an application into an operating system mitigation known as Address Space Layout Randomization (ASLR), discussed in more detail later in this post.
Similarly to the /SAFESEH limitation, a problem with the /DYNAMICBASE flag is that any DLL module that doesn’t opt-in to this protection reduces the value of ASLR as an exploit mitigation. Any module at a predictable location can be targeted by an attacker, and an exploit may only require one such predictable target. Many recent exploits target browser add-ons that don’t opt-in to the protection of ASLR. For instance, an Adobe Reader and Acrobat 0-day exploit in 2010 relied on the predictable location of functions within a module named icucnv36.dll that failed to opt-in to ASLR.
Run time mitigations
Runtime mitigations allow the operating system to help participate in keeping the process secure.
DEP/NX is an operating system mitigation that relies upon key security features (Data Execution Prevention or No eXecute) of modern CPUs. This mitigation enables memory pages to be marked as non-executable (Data); the processor will refuse to run code on a memory page so marked.
In the second stage of a memory exploit, an attacker may try to execute their own code which they have added to a data page in memory. In scenarios where the data page has been marked as non-executable, the attacker’s code will fail to run and the process will be safely terminated.
DEP/NX support was first enabled by default in IE8, and remains enabled in IE10.
SEHOP is a runtime mitigation that provides an exception-handler tamper-protection mechanism much like the /SAFESEH compiler flag. This protection works by inserting a symbolic exception record as the tail record in the thread’s exception handler list. In the event of an exception, the exception handler list is walked to ensure that the symbolic record can be reached. If it cannot be reached, this indicates that the exception handler chain is corrupted and the process will be safely terminated. Unlike SafeSEH, SEHOP does not require each individual module to opt-in, and thus it provides protection even if add-ons were not compiled with the most secure flags.
SEHOP was first enabled in IE9 and remains enabled in IE10.
Address Space Layout Randomization was first introduced in Windows Vista and has been greatly improved in Windows 8. ASLR assigns applications a random base memory address when they are initially loaded into memory. In addition, other memory structures such as the Process Environment Blocks (PEB), Thread Environment Blocks (TEB), Stacks and Heaps are also assigned to random locations in memory.
Randomizing the location of objects and functions in memory helps prevent an attacker from discovering where they are, which helps prevent a technique called Return Oriented Programming. This randomization can be thought of as securing the attacker’s payload with a combination lock. If an attacker doesn’t have the combination, they only get one guess. Guessing wrong means the attack will fail and the process will safely be terminated.
The following illustration depicts how core system components are loaded in random memory addresses on system startup.
ASLR in Windows 8 has seen a number of improvements, all of which are utilized by Internet Explorer 10.
All Bottom-Up and Top-Down allocations are now randomized using 8 bits of entropy. This improvement significantly reduces predictable memory regions including VirtualAlloc and MapViewOfFile.
High Entropy Address Space Layout Randomization (HEASLR) takes advantage of the increase in 64bit address space and assigns more bits to entropy. This has the effect of drastically increasing the number of potential addresses that may be assigned to a 64bit process. All 64bit processes can opt-in to the increased entropy made available by HEASLR. Processes can opt-in either at link time (/HIGHENTROPYVA) or at load time via a new Image File Execution Option.
By default, the Metro style browser runs in 64bit mode on 64bit computers, providing a much larger address space and thus more random memory layout.
ForceASLR is arguably the most important change to ASLR in Windows 8. ForceASLR is a new loader option used by Internet Explorer 10 to instruct the operating system to randomize the location of all modules loaded by the browser, even if a given module was not compiled with the /DYNAMICBASE flag. The ForceASLR protection was added to the Windows 8 kernel, and the feature is now available as an update to Windows 7 that will be installed when Internet Explorer 10 is installed on that platform.
To help ensure compatibility with this feature, and to provide memory-randomization protection to older Internet Explorer versions that don’t support ForceASLR, we continue to recommend that add-on developers make use of the /DYNAMICBASE flag.
Summary
I hope this brief overview of the memory protections present in Windows 8 and Internet Explorer 10 has proven valuable. Under the covers, we’ve made many other tweaks for enhanced security, but many of them are so esoteric that we don’t even have names for them. We do have a few more security-related announcements coming, so stay tuned for updates as we continue our mission to deliver a secure Web browsing platform.
—Forbes Higman, Security Program Manager, Internet Explorer -
Web Platform Features in Windows Consumer Preview
Posted 15 days agoInternet Explorer 10 in the Windows Consumer Preview introduces a number of new or updated Web platform features when compared to the IE10 in the Windows Developer Preview released September 13, 2011. Some of these shipped in the fourth IE10 platform preview released November 29, 2011, and have been blogged about since; some are new in the Consumer Preview.
New or Updated Web Platform Features
The following Web platform capabilities in the Consumer Preview were not in the Developer Preview:- Cross-Origin Resource Sharing (CORS) for XMLHttpRequest (spec / post / dev guide)
- CSS
-ms-user-selectproperty (post / dev guide) - CSS3
font-feature-settingsproperty to access advanced OpenType® features (spec / post / dev guide) - Document setting to enable floating point values in CSS-OM (post / dev guide)
- HTML5 BlobBuilder API and new APIs to save or open files (spec / post / dev guide)
- HTML5
trackelement for HTML5 video captions (spec / post / dev guide) - Interoperable HTML5 Quirks mode (post / dev guide)
- JavaScript Typed Arrays (post)
- Meta tag to alert user that site requires ActiveX add-ons available only in desktop IE10 (post)
- Removal of legacy graphics features from IE10 standards mode (post)
- Changes to support latest HTML5 WebSocket API (spec)
- Web Worker thread pooling
Across the board, we’ve improved performance and addressed feedback on the platform features that were available in the Windows Developer Preview but not IE9:- CSS-OM media query list listeners (spec / dev guide)
- CSS3 3D transforms (post / dev guide)
- CSS3 gradients (post / dev guide)
- CSS3 grid, flexible box, and multi-column layout and exclusions (post / grid / flexbox / multicol / exclusions)
- CSS3 regions and hyphenation (post / regions / hyphenation)
- CSS3
text-shadowproperty (post / dev guide) - CSS3 transitions and animations (post / transitions / animations)
- HTML5 AppCache and IndexedDB (post / appcache / indexeddb)
- HTML5
asyncattribute of thescriptelement (spec / dev guide) - HTML5 drag and drop APIs (spec / post / dev guide)
- HTML5 File API (spec / dev guide)
- HTML5 forms and validation (dev guide)
- HTML5 History API (post)
- HTML5 parsing algorithm (post / dev guide)
- HTML5 sandbox (post / dev guide)
- HTML5 Web Workers (spec / post / post / dev guide)
- HTML5 WebSocket API (spec / post / dev guide)
- Pointer events and multi-touch input (post / post / dev guide)
- SVG filter effects (post / dev guide)
- XMLHttpRequest enhancements (dev guide)
- and more. See Windows Internet Explorer 10 Consumer Preview Guide for Developers
More to Come: User Interface Improvements
Metro style Internet Explorer in the Windows Consumer Preview contains many user interface changes and additions compared to the Windows Developer Preview. You can get a taste for these in what Gizmodo wrote about Internet Explorer 10. We will be blogging about these new features in the coming days both here and on Building Windows 8.
—Ted Johnson for IEBlog -
Windows Consumer Preview: The Fifth IE10 Platform Preview
Posted 17 days agoWith IE10 in Windows 8, we reimagined the browser. We designed and built IE10 to be the best way to experience the Web on Windows. Consumers can now enjoy more touch-friendly and beautiful, fast and fluid Web applications with the updated IE10 engine included in the Windows Consumer Preview. This fifth Platform Preview of IE10 delivers improved performance and support for more HTML5:
You can read more about the improvements to the Metro style browsing experience on the Building Windows 8 blog. The remainder of this post discusses the underlying HTML5 engine.
This video shows some of the touch-friendly HTML5 technologies in the fifth IE10 Platform Preview, included with the Windows Consumer Preview.
View this video on YouTube
Windows 8 includes one HTML5 browsing engine that powers both browsing experiences (the Metro style one and desktop one) as well as Metro style applications that use HTML5 and JavaScript. The common HTML5 engine provides consistently fast, safe, and powerful support for Web standards and the Web programming model, for both browser experiences as well as for Metro style applications.
Consumers experience this power with rich, beautiful visual effects that take full advantage of the underlying hardware safely. Some examples that you can try at the IE Test Drive site with the Consumer Preview include fast and fluid multi-touch support in Web pages and the latest database APIs, which enable you to take photos from a Web site offline. The Test Drive site demonstrates how much better the Web can be with rich visual effects, sophisticated page layouts, and the advances to the Web programming model. You can read the full list in the IE10 developer guide.
A Better Web Ahead
Working closely with the developer community, we see a much better Web ahead.
IE10 in the Metro style experience is plug-in free. Almost all phones and devices are already plug-in free and many sites already run plug-in free for them. To deliver the richest experience, and one experience that scales across different devices, we continue to recommend that developers detect when plug-ins are not available and rely on native browser patterns.
Similarly, we recommend that developers update their sites’ older, out of date libraries (like this one) that don’t work well with new browsers like IE10.
We also recommend that developers use feature, not browser, detection. Often, the compatibility problem reports we receive have more to do with sites detecting IE and sending it different content than they send other browsers than any particular issue in IE. You can see some examples of how IE makes up for certain sites by adjusting the information it sends to particular sites (e.g. sending an iPad identification token) based on the Compatibility View (CV) list in the post script to this blog entry.
Developers can find sample feature detection code patterns in several IE blog posts, including this one.
The quality and correctness of different browsers’ HTML5 engines continue to vary widely. We continue to contribute to the test suites under development at the HTML5 standards bodies to further the goal of interoperability and same markup. We’ve submitted 456 new tests to them that you can view at the IE Test Center as well. As different browsers improve their support of the same markup to produce the same results, we can all realize the promise of HTML5.
You can find a full list of new functionality available to developers in the IE10 developer guide here. Download the Windows 8 Consumer preview to try this update to IE10. We look forward to continued engagement with the developer community and your feedback on Connect.
―Dean Hachamovitch, Corporate Vice President, Internet Explorer -
Protecting Consumers’ Privacy Online
Posted 23 days agoThis morning in the United States, the White House announced a new “Consumer Privacy Bill of Rights” as part of the effort to improve consumers’ online privacy. As I’ve mentioned before, Microsoft is actively participating in the industry initiative for Tracking Protection at the W3C to produce Web standards for online privacy.
The Tracking Protection Working Group is chartered to work on two complementary initiatives: Tracking Preference Expression (Do Not Track) and Tracking Selection Lists (TSL). The TSL editor’s draft defines a format for interchangeable lists for blocking or allowing tracking elements from Web pages. Last month, at the W3C face-to-face meeting, the working group decided that a sub-group (or “task force”) of those interested in TSLs should work on the specification together.
Work on Do Not Track (DNT) is continuing and the W3C expects this to become a standard sometime in 2012. In the meantime, IE’s Tracking Protection feature is available to IE9 and IE10 users today. This is the only technology that can filter out unwanted cookies, beacons, and other tracking devices without requiring Web sites, advertisers, and publishers to change.
At the CPDP 2012 conference in Brussels, Simon Davies and Alexander Hanff of Privacy International launched two new tracking protection lists designed to protect consumers from Web Analytics and Behavioural Tracking. These lists are available from http://www.privacyonline.org.uk/. Check out the complete set of Tracking Protection Lists available from the IE Gallery (including the popular EasyPrivacy and Fanboy lists).
--Adrian Bateman, Program Manager, Internet Explorer
Note: Correction in last paragraph -
Google Bypassing User Privacy Settings
Posted 26 days agoWhen the IE team heard that Google had bypassed user privacy settings on Safari, we asked ourselves a simple question: is Google circumventing the privacy preferences of Internet Explorer users too? We’ve discovered the answer is yes: Google is employing similar methods to get around the default privacy protections in IE and track IE users with cookies. Below we spell out in more detail what we’ve discovered, as well as recommendations to IE users on how to protect their privacy from Google with the use of IE9's Tracking Protection feature. We’ve also contacted Google and asked them to commit to honoring P3P privacy settings for users of all browsers.
We’ve found that Google bypasses the P3P Privacy Protection feature in IE. The result is similar to the recent reports of Google’s circumvention of privacy protections in Apple’s Safari Web browser, even though the actual bypass mechanism Google uses is different.
Internet Explorer 9 has an additional privacy feature called Tracking Protection which is not susceptible to this type of bypass. Microsoft recommends that customers who want to protect themselves from Google’s bypass of P3P Privacy Protection use Internet Explorer 9 and click here to add a Tracking Protection List. Customers can find additional lists and information on this page.
Background: Google Bypassing Apple’s Privacy Settings
A recent front page Wall Street Journal article described how Google “bypassed Apple browser settings for guarding privacy.” The editor and CEO of Business Insider, a business news and analysis site, summarized the situation:
Third-party cookies are a common mechanism used to track what people do online. Safari protects its users from being tracked this way by a default user setting that blocks third-party cookies. Here’s Business Insider’s summary:Google secretly developed a way to circumvent default privacy settings established by a… competitor, Apple… [and] Google then used the workaround to drop ad-tracking cookies on the Safari users, which is exactly the sort of practice that Apple was trying to prevent.
Google’s approach to third-party cookies seems to have the side effect of Safari believing they are first-party cookies.What Safari does NOT allow, by default, is for third-party … cookies on users' computers without their permission. It is these ad-tracking cookies that cause lots of Internet users to freak out that their privacy is being violated, so it's understandable that Apple decided to block them by default.But these default settings have created a problem for Google, at least with respect to its goals for its advertising business.
What Happens in IE
By default, IE blocks third-party cookies unless the site presents a P3P Compact Policy Statement indicating how the site will use the cookie and that the site’s use does not include tracking the user. Google’s P3P policy causes Internet Explorer to accept Google’s cookies even though the policy does not state Google’s intent.
P3P, an official recommendation of the W3C Web standards body, is a Web technology that all browsers and sites can support. Sites use P3P to describe how they intend to use cookies and user information. By supporting P3P, browsers can block or allow cookies to honor user privacy preferences with respect to the site’s stated intentions.
It’s worth noting that users cannot easily access P3P policies. Web sites send these policies directly to Web browsers using HTTP headers. The only people who see P3P descriptions are technically skilled and use special tools, like the Cookie inspector in the Fiddler tool. For example, here is the P3P Compact Policy (CP) statement from Microsoft.com:
Each token (e.g. ALL, IND) has a specific meaning for a P3P-compliant Web browser. For example, ‘SAMo’ indicates that ‘We [the site] share information with Legal entities following our practices,’ and ‘TAI’ indicates ‘Information may be used to tailor or modify content or design of the site where the information is used only for a single visit to the site and not used for any kind of future customization.’ The details of privacy are complex, and the P3P standard is complex as well. You can read more about P3P here.P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
Technically, Google utilizes a nuance in the P3P specification that has the effect of bypassing user preferences about cookies. The P3P specification (in an attempt to leave room for future advances in privacy policies) states that browsers should ignore any undefined policies they encounter. Google sends a P3P policy that fails to inform the browser about Google’s use of cookies and user information. Google’s P3P policy is actually a statement that it is not a P3P policy. It’s intended for humans to read even though P3P policies are designed for browsers to “read”:
P3P-compliant browsers interpret Google’s policy as indicating that the cookie will not be used for any tracking purpose or any purpose at all. By sending this text, Google bypasses the cookie protection and enables its third-party cookies to be allowed rather than blocked. The P3P specification (“4.2 Compact Policy Vocabulary”) calls for IE’s implemented behavior when handling unknown tokens: “If an unrecognized token appears in a compact policy, the compact policy has the same semantics as if that token was not present.”P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Similarly, it’s worth noting section “3.2 Policies” from the P3P specification:
P3P is designed to support sites that convey their privacy intentions. Google’s use of P3P does not convey those intentions in a manner consistent with the technology.3.2 Policies
In cases where the P3P vocabulary is not precise enough to describe a Web site's practices, sites should use the vocabulary terms that most closely match their practices and provide further explanation in theCONSEQUENCEfield and/or their human-readable policy. However, policies MUST NOT make false or misleading statements.
Because of the issues noted above, and the ongoing development of new mechanisms to track users that do not involve cookies, our focus is on the new Tracking Protection technology.
Next Steps
After investigating what Google sends to IE, we confirmed what we describe above. We have made a Tracking Protection List available that IE9 users can add by clicking here as a protection in the event that Google continues this practice. Customers can find additional lists and information on this page.
The premise of Tracking Protection in IE9 is that tracking servers never have the opportunity to use cookies or any other mechanism to track the user if the user never sends anything to a tracking server. This logic underlies why Tracking Protection blocks network requests entirely. This new technology approach is currently undergoing the standardization process at the W3C.
This blog post has additional information about IE’s cookie controls, and shows how you can block all cookies from a given site (e.g. *.google.com) regardless of whether they are first- or third-party. This method of blocking cookies would not be subject to the methods Google used. We recommend that users not yet running IE9 take steps described in this post.
Given this real-world behavior, we are investigating what additional changes to make to our products. The P3P specification says that browsers should ignore unknown tokens. Privacy advocates involved in the original specification have recently suggested that IE ignore the specification and block cookies with unrecognized tokens. We are actively investigating that course of action.
―Dean Hachamovitch, Corporate Vice President, Internet Explorer -
Sub-pixel Rendering and the CSS Object Model
Posted 0 months agoWith Windows 8, you have an unprecedented choice of devices for browsing the Web, from large desktop screens to small slates. In order to accommodate this range of devices, the browser must be able to scale and layout the Web at many different screen sizes and dimensions. We've previously blogged about some of the features in IE that support these scenarios. Sub-pixel positioning (of text and layout) is one of the core platform technologies which enable Web pages to look beautiful and consistent at any scale.
In this post, we describe changes made in IE10 to better support sub-pixel positioning through the CSS-OM.
Web developers can build beautiful layouts through a variety of platform technologies. Generally, developers use CSS style sheets to describe the layout a Web site. In some scenarios, Web developers also depend on JavaScript code to measure, align, or position elements of a Web page withpixel-perfectprecision. For example, some online editors carefully position an edit box exactly over the top of existing content so that it only appears as if you are directly editing the existing content. Scenarios such as this one may use the CSS object model (CSS-OM) APIs to read and/or set element position. The CSS-OM is a set of JavaScript APIs for programmatically manipulating CSS.
Measuring and aligning layout elements using the CSS-OM APIs can be problematic because of the way that those APIs round or truncate sub-pixel positioned values to whole-pixel numbers.
A Quick Note about Pixel-perfect Layouts
In general, pixel-perfect layouts on the Web tend to conflict with the goals of enabling accessible, compatible, and adaptable content, and consequently are not a best practice. The following collage illustrates some of the bugs that can occur when the Web designer attempts to create a pixel-perfect design but unexpected Web platform differences cause their designs to go awry.
When using the CSS-OM to dynamically generate a layout, Web developers should allow for a few pixels of potential error. Better yet, IE10 provides several new layout options that developers can use to better achieve many of these desired layouts without requiring pixel-perfect alignment using the CSS-OM.
Examples of pixel-perfect designs gone wrong
An Illustration
To illustrate how the CSS-OM APIs may cause subtle positioning problems, consider a simple example. Sub-pixel positioning allows four boxes to be evenly distributed inside of the container, despite the container's size not being evenly divisible by four.
Consider the following HTML markup fragment:
with this partial CSS markup:<footer><div>content 1div><div>content 2div><div>content 3div><div>content 4div>footer>
Now, let’s add a function that runs on load and reports the widths of these items:footer { width: 554px; border: 1px solid black; text-align: center; }footer div { display: inline-block; width: 25%; }footer div:nth-child(even) { background-color: Red; }footer div:nth-child(odd) { background-color: Orange; }
The result of running this markup and code in IE9 is something like this:onload = function () {var footerBoxes = document.querySelectorAll("footer div");var s = "";var totalSize = 0;for (var i = 0; i < footerBoxes.length; i++) {// Reportingvar offsetWidth = footerBoxes[i].offsetWidth;s += "content " + (i + 1) + " offsetWidth = " + offsetWidth + "px" + "
";totalSize += offsetWidth;}s += "Total calculated offsetWidth = " + totalSize + "px" + "
";s += "Container width = " + document.querySelector("footer").clientWidth + "px" + "
";document.querySelector("#message").innerHTML = s;}
content 1content 2content 3content 4 content 1 offsetWidth = 139
content 2 offsetWidth = 139
content 3 offsetWidth = 139
content 4 offsetWidth = 139
Total calculated offsetWidth = 556
Actual container width = 554
Note that summing the values returned by the CSS-OM APIoffsetWidthresults in the total calculated offsetWidth differing from the actual container width by two pixels, due to rounding that occurs in theoffsetWidthof the individualdivelements.
The results in other browsers show a similar discrepancy, though sometimes the total is less than the actual and sometimes greater.
When the rounding/truncation leads to a sum total that overflows the container size (as illustrated), content will start to wrap or cause unwanted scroll-bars to appear. Additionally, many containers are sized according to the text and the font used to render the text, and those font metrics may be different across browsers or alternate fonts may be selected if the requested font isn't available.
TheoffsetWidthAPI, along with many other widely used CSS-OM properties (most dating back to IE4 in 1997), provide a convenient and fast way to extract integer pixel values for an element from a variety of different coordinate systems. All major browsers implement most of these APIs for compatibility and they are also part of the CSS-OM View module, a W3C draft standard.
New browser features continue to demonstrate the shortfall of limiting CSS-OM properties to whole-value pixels. For example, features like SVG and CSS 2D/ 3D Transforms allow an element's dimensions to easily fall between pixels.
Addressing the Problem
Recognizing this limitation (in part), the W3C CSS-OM View spec describes the coordinates returned via thegetBoundingClientRect()API to befloats; in other words, in values that can represent sub-pixel precision. (getBoundingClientRect()is another CSS-OM API that provides an element's bounding-box position and dimension using the same origin as theoffsetWidthAPI.)
In IE10 we've updated thegetBoundingClientRect()API to return sub-pixel resolution by default in IE10 standards mode in order to be interoperable with other browsers and align with the W3C standard.
Updating our example above to report thewidthcomponent of the rectangle returned bygetBoundingClientRect(), IE10 now reports these fractional values:
content 1content 2content 3content 4 content 1 offsetWidth = 139, getBoundingClientRect().width = 138.5
content 2 offsetWidth = 139, getBoundingClientRect().width = 138.5
content 3 offsetWidth = 139, getBoundingClientRect().width = 138.5
content 4 offsetWidth = 139, getBoundingClientRect().width = 138.5
Total calculated offsetWidth = 556
Total calculated getBoundingClientRect().width = 554
Actual container width = 554
Taking Sub-pixel Values Everywhere
In addition togetBoundingClientRect, we also report sub-pixel position for mouse/pointer events in IE10 standards mode by default. It's only possible for the mouse/pointer to landbetweenpixels when the zoom factor is set to a value other than 100%. Specifically, the affected mouse/pointer APIs are:MouseEvent.offsetX/YMouseEvent.layerX/YMouseEvent.clientX/YMouseEvent.pageX/YMouseEvent.x/y
To continue our commitment to compatibility with legacy Web pages (pages which may not be prepared to handle sub-pixel values from the CSS-OM in general), IE10 continues to reports whole-value pixel units by default for the other CSS-OM properties. These APIs are:Element.clientHeightElement.clientWidthElement.clientLeftElement.clientTopElement.scrollTopElement.scrollLeftElement.scrollWidthElement.scrollHeightHTMLElement.offsetWidthHTMLElement.offsetHeightHTMLElement.offsetTopHTMLElement.offsetLeftTextRange.offsetLeftTextRange.offsetTop
When enabled by settingdocument.msCSSOMElementFloatMetrics = true;document.msCSSOMElementFloatMetricstotrue, all CSS-OM APIs in the previous list will begin reporting their values in sub-pixel precision that will reflect exactly the calculations used internally by the layout and rendering engine. Note that JavaScript will convert 1.00 into 1 so you may not always see a decimal point in returned values.
Going back to our example and settingdocument.msCSSOMElementFloatMetricstotrueresults in this in IE10:
content 1content 2content 3content 4 content 1 offsetWidth = 138.5, getBoundingClientRect().width = 138.5
content 2 offsetWidth = 138.5, getBoundingClientRect().width = 138.5
content 3 offsetWidth = 138.5, getBoundingClientRect().width = 138.5
content 4 offsetWidth = 138.5, getBoundingClientRect().width = 138.5
Total calculated offsetWidth = 554
Total calculated getBoundingClientRect().width = 554
Actual container width = 554
Note the fractional values returned byoffsetWidthand that all totals now match.
Summary
It is sometimes helpful (and, in rare cases, necessary) to be able to use the CSS-OM properties for pixel-perfect layout calculation. When using the CSS-OM, be aware of the whole-pixel-reporting characteristics of those APIs. When designing layouts either with CSS or the CSS-OM APIs, be sure to accommodate a few pixels of tolerance in order to ensure a more robust site across multiple browsers and/or devices.
—Travis Leithead, Program Manager, Internet Explorer
Editor's note: Updated to correct a few typographic errors.
суббота, 17 марта 2012 г.
Media Capture Prototype: Improved Support for Real World Web Apps
Подписаться на:
Комментарии к сообщению (Atom)
Комментариев нет:
Отправить комментарий