Google Tricks Internet Explorer into Accepting Tracking Cookies, Microsoft Claims
Google was caught last week bypassing default privacy settings in the Safari browser in order to serve up tracking cookies. The company claimed the situation was an accident and limited only to the Safari web browser, but today Microsoft claimed Google is doing much the same thing with Internet Explorer.
In a blog post titled “Google bypassing user privacy settings” Microsoft’s IE Corporate Vice President Dean Hachamovitch states that “When 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.”
Hachamovitch explains that IE’s default configuration blocks third-party cookies unless presented with a “P3P (Platform for Privacy Preferences Project) Compact Policy Statement” indicating that the site will not use the cookie to track the user. Microsoft accuses Google of sending a string of text that tricks the browser into thinking the cookie won’t be used for tracking. “By sending this text, Google bypasses the cookie protection and enables its third-party cookies to be allowed rather than blocked,” Microsoft said.
The text allegedly sent by Google actually reads “This is not a P3P policy” and includes a link to a Google page which says cookies used to secure and authenticate Google users are needed to store user preferences, and that the P3P protocol “was not designed with situations like these in mind.”
Microsoft said it has contacted Google to ask the company to “commit to honoring P3P privacy settings for users of all browsers.” Microsoft also updated the Tracking Protection Lists in IE9 to prevent the tracking described by Hachamovitch in the blog post. Ars has contacted Google to see if the company has any response to the Microsoft allegations, and we’ll update this post if we hear back.
UPDATE: It turns out Facebook and many other sites are using an almost identical scheme to override Internet Explorer’s privacy setting, according to privacy researcher Lorrie Faith Cranor at Carnegie Mellon University. “Companies have discovered that they can lie in their [P3P policies] and nobody bothers to do anything about it,” Cranor wrote in a recent blog post.
UPDATE 2: Google has gotten back to us with a lengthy reply, arguing that Microsoft’s reliance on P3P forces outdated practices onto modern websites, and points to a study conducted in 2010 (the Carnegie Mellon research from Cranor and her colleagues) that studied 33,000 sites and found about a third of them were circumventing P3P in Internet Explorer.
“Microsoft uses a ‘self-declaration’ protocol (known as ‘P3P’) dating from 2002 under which Microsoft asks websites to represent their privacy practices in machine-readable form,” Google Senior VP of Communications and Policy Rachel Whetstone says in a statement e-mailed to Ars. “It is well known—including by Microsoft—that it is impractical to comply with Microsoft’s request while providing modern web functionality.”
Facebook’s “Like” button, the ability to sign into websites using your Google account “and hundreds more modern web services” would be broken by Microsoft’s P3P policy, Google says. “It is well known that it is impractical to comply with Microsoft’s request while providing this web functionality,” Whetstone said. “Today the Microsoft policy is widely non-operational.”
That 2010 research even calls out Microsoft’s own msn.com and live.com for providing invalid P3P policy statements. The research paper further states that “Microsoft’s support website recommends the use of invalid CPs as a work-around for a problem in IE.”
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.
Apache 2.4: A Major Update for the Web’s Most Popular Server
The Apache Software Foundation has announced the release of version 2.4 of its namesake Apache HTTP Server. The new version is the first major release for Apache since 2005. During that time several new servers, including the increasingly popular Nginx server, have emerged to challenge Apache’s dominance. However, while Nginx may have surpassed Microsoft IIS to become the second most used server on the web, it still trails well behind Apache, which powers nearly 400 million web sites.
To upgrade your servers to the latest release, head over to the Apache HTTP Server Project and download a copy of Apache 2.4.
Much of the focus in Apache 2.4 is on performance. The Apache Software Foundation blog touts reduced memory usage and better concurrency among the improvements in this release. Apache 2.4 also offers better support for asynchronous read/write operations and much more powerful Multi-Processing Module (MPM) support. Multiple MPMs can now be built as loadable modules at compile time and the MPM of choice can be configured at run time, making Apache 2.4 considerably more flexible than its predecessors.
There have also been numerous updates for Apache’s various modules, as well as a host of new modules that are available with this release — including mod_proxy_fcgi, a FastCGI protocol backend for mod_proxy.
For a complete rundown of everything that’s new in Apache 2.4, be sure to check out the documentation.
The iPhone Monoculture Is in Your Mind
Photo: Ariel Zambelich/Wired.com 
In the recent kerfuffle over the prevalence of the -webkit CSS prefix and the lack of corresponding prefixes for other browsers, we told you that the problem was with developers, not WebKit browsers. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit and that’s a problem.
But mobile expert Peter-Paul Koch, better known in the web developer community as just PPK, argues that the real problem is not WebKit, nor is it even web developers’ fascination with WebKit. The real problem is the developer-created monoculture of the iPhone.
According to Koch, “web developers don’t care about WebKit…. They care about the iPhone.”
The interesting thing about Koch’s argument is that he doesn’t claim there is actually a monoculture of the iPhone on the web. In fact, he cites some of Mozilla’s web crawler stats which seem to say just the opposite. Instead Koch believes the problem is in our heads, so to speak.
“What we have here is an iPhone monoculture; not in the stats, but in web developers’ minds,” writes Koch. “This is the fundamental problem we must address.”
The cure, says Koch, is to diversify tutorials and examples. “Start talking about testing in mobile non-WebKit browsers (i.e., Opera),” he writes. “Start talking about other platforms besides iPhone (and Android). Start talking about mobile diversity, instead of showing the iPhone over and over and over again.” What do you do if the only phone you have to test on is the iPhone? Well, there are emulators available for most phones, including Opera’s very powerful mobile emulator which can simulate all kinds of phones and connections. And don’t forget that Opera Mini is available for the iPhone if you’d like to at least test your site in something other than Mobile Safari.
Future Chrome Version May Choose Your Passwords, and Change Them When You’ve Been Hacked
Google’s Chrome development team is working on a system to automatically generate passwords, which would help users secure their online identities with passwords that would be diversified across different sites, and are randomized and thus harder to guess. Detailed in developer documentation on the Chromium Project site, the system would detect account sign-up pages and “add a small UI element to the password field” giving the user the option of letting Chrome manage the password for them.
Initial versions of the system would create passwords on an individual basis, at the user’s request. But Google’s development team states that “At some point in the future it might also be possible for us to automatically change all of a user’s passwords when we realize that their account is hijacked.” The developer documentation notes that the feature would make Google “a higher value hijacking target,” than it already is, although “Google is already a high value target so this shouldn’t change much.”
Chrome can already store passwords, a common feature in modern browsers, and it syncs them across computers, with the passwords encrypted in transit and at rest in Google data centers. The idea of auto-generating passwords is not new, either. Password management software such as 1Password and LastPass can already generate passwords and automatically input them into web forms. But these tools cost money and require additional software downloads. Although it’s not clear when it will become available, Google’s scheme would make storing and generating passwords a pre-installed feature of the browser.
Mockup of a potential future version of Chrome which would auto-generate passwords. Image from the Chromium Project.
The first challenge noted by the Chrome development team is detecting sign-up pages, which is accomplished by looking for elements such as “an account name field and two password fields.” Next, the Chrome password generator must come up with a secure password that meets the site’s requirements—many sites require digits, special characters or certain lengths. Because the password generator may choose a password that doesn’t meet the site’s requirements, the user is given a chance to review the suggested password before selecting it.
“If they accept the prompt then we pop up a small box which is prepopulated with what we think is an acceptable random password,” the Chromium development document says. “The reason we don’t just choose a password for them is that many sites have requirements (e.g. must have one digit, must be alphanumeric, must be between 6 and 20 characters) some of which may be contradictory between sites. So we will choose a default generator that will work on most sites, but users may need to change our password if it doesn’t work.”
The Chromium team is still looking for a “way to authenticate to the browser to enable this feature,” and will have to find a workaround for sites that have autocomplete turned off.
“Any website that has autocomplete turned off will not be able to be protected,” the document states. “Going by current phishing attacks, this means that 40-70% of phishing pages can’t be protected against. Once this feature is rolled out we probably want to see if we can get around this problem. Maybe we can get users to re-authenticate to the browser before logging into such sites.”
How much do you trust Google?
Google is often criticized for invading users’ privacy, as the company makes much of its revenue by serving up personalized ads to users based on their web browsing habits and even the contents of their e-mail. However, the development of technology to generate more secure passwords seems like a good-faith effort to protect users from online attacks, and isn’t so far removed from the already-existing practice of browsers storing passwords.
Google’s password-generator will likely be appealing to many because of the sheer convenience of it. But users will have to decide for themselves just how much of their online activities they want to trust with Google.
In the long run, Chrome developers say the solution should be browser sign-in coupled with the OpenID authentication standard. However, “getting most sites on the Internet to use OpenID will take a while,” the Chrome team states. “In the meantime it would be nice to have a way to achieve the same affect of having the browser control authentication.” Since many people re-use passwords across sites, randomization will go a long way toward better security, making it harder for attackers to steal a user’s entire online identity.
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.
Google’s New ‘Dart’ Language to Get a Starring Role in Chrome
Google has released an experimental version of the Chromium web browser with support for the company’s new Dart programming language. Dart, which is Google’s attempt to improve on JavaScript, has thus far not enjoyed much support outside of Google, but the company continues to push forward with its own efforts.
The new development preview version of the Chromium browser, the open source version of Google’s Chrome browser, contains the Dart Virtual Machine. This release, which Google is calling “Dartium,” can be downloaded from the Dart language website. At the moment it’s available only for Mac OS X and Linux. Google says a Windows version is “coming soon.” Keep in mind that this is a preview release and intended for developer testing, not everyday use.
Google originally created Dart to address the shortcomings of JavaScript and ostensibly speed up the development of complex, large-scale web applications.
While there is much programmers might like about Dart, it is, like Microsoft’s VBScript before it, a nonstandard language from a single vendor created without any regard for the existing web standards process. The new Dartium release is the first browser to include a Dart Virtual Machine and, based on the response from other browser makers to the initial release of Dart, likely the only browser that will ever ship with a Dart VM. For its part Google says it plans to incorporate the experimental Dart VM into Chrome proper in the future.
The company also has a plan for all those browsers that aren’t jumping on the Dart bandwagon — a compiler that translates Dart to good old JavaScript. In this scenario Dart ends up somewhat like CoffeeScript, a JavaScript abstraction that makes more sense to some programmers.
For more details on the new Dartium browser and the latest improvements to the Dart VM, be sure to check out the Google Code Blog announcement.
The HTML5 Time Element Is Back and Better Than Ever
The HTML5 time element pulled a disappearing act last year. HTML5 editor Ian Hickson deleted it from the specification, but then the W3C, the group that oversees HTML5, stepped in to override Hickson’s decision, adding time back to HTML5. Now you see it, now you don’t, now you do again.
The W3C didn’t just add time back though; they’ve improved it considerably. While nothing has changed with the human-readable part — that is, anything between <time> and </time> — the datetime attribute has been imbued with new superpowers.
The original version of the time element was rather strict; under the original spec datetime data needed to refer to a specific date. For example, to mark up today’s date you might do something like this:
That’s all good and well for days, but what if you just wanted to specify a month? Or a year? What do you do when trying to mark up date-based blog archives, or something in history where the precise date is unknown? The new date spec allows for just that.
To specify a date no more precise than a month you’d do something like this: <time datetime="2012-02">. Take away the month and it would refer to just the year. Other options include the week of the year and a date without a year (for referring to reoccurring events, e.g. holidays).
To see some more examples of the datetime attribute and what you can do with it, head over to Bruce Lawson’s blog. Lawson, who is part of Opera’s developer relations team, recently looked at just about everything you can do with datetime, including specify durations (which uses a somewhat confusing set of abbreviations).
There are two things to keep in mind when using the time element. First, you still can’t represent dates before the Christian era, and second, the pubdate attribute may be cut from the HTML5 spec. Pubdate, which is a boolean attribute for indicating publication dates, is still present in the WHATWG version of HTML5, but there’s a proposal to drop it.
First Look: Mozilla’s Boot2Gecko Mobile Platform and Gaia UI
Mozilla launched a new project last year called Boot2Gecko (B2G) with the aim of developing a mobile operating system. The platform’s user interface and application stack will be built entirely with standards-based web technologies and will run on top of Gecko, the HTML rendering engine used in the Firefox web browser. The B2G project has advanced at a rapid pace this year and the platform is beginning to take shape.
The B2G team at Mozilla is preparing to give a demo of the platform’s user experience at the upcoming Mobile World Congress (MWC) event. Mozilla’s Brendan Eich told us via Twitter that the B2G project has already attracted partners, including one that is developing its own custom home screen. This suggests that multiple parties, possibly hardware vendors, are interested in adopting the platform.
According to a roadmap recently published by Mozilla, the B2G project could potentially reach the product stage by the second quarter of 2012. That’s a highly ambitious target, but the project’s impressive rate of development suggests that it can be done. The pervasive use of HTML and JavaScript to build the user interface and application stack is no doubt speeding the project along. Web technologies are very conducive to rapid development.
The B2G platform consists of three main layers. The bottom layer, which is called Gonk, includes the Linux kernel, the hardware abstraction layer, the telephony stack, and other low-level system components. The middle layer is the Gecko rendering engine, which has been improved with new APIs that expose device capabilities. The top layer is Gaia, the B2G user interface, which is built entirely with HTML and JavaScript.
The Linux kernel that is used in Gonk is said to be “reasonably close” to upstream Linux. According to Mozilla’s documentation, Gonk uses some of the underlying bits of the Android open source project, including some minor kernel customizations, in order to make it easier for hardware vendors to get B2G running on Android hardware. B2G is not based on Android, however, and will not run Android applications. It’s currently possible to replace the Android environment on a Samsung Galaxy S II with a B2G build.
Much of the interaction between the Gecko and Gonk layers will be mediated by a B2G process that runs with a high privilege level and acts as a sort of Gecko server. The B2G process will paint to the framebuffer and interact with hardware components like a built-in GPS antenna or camera.
The wireless modem functionality is implemented in a radio interface layer (RIL) daemon, which B2G will interact with through a simple proxy process. Actual web content and multimedia playback will be handled by separate processes that communicate with the B2G process.
Mozilla aims to build the entire B2G user interface and application stack with native HTML and JavaScript. In order to accomplish that, Mozilla launched the WebAPI project, which exposes device functionality to web content through JavaScript APIs. Mozilla has already previously introduced APIs for accessing certain device capabilities, such as the accelerometer and geolocation APIs that are supported in the mobile versions of Firefox.
The WebAPI project goes a step further and adds a great deal of additional functionality for tasks like taking pictures with the built-in camera, dialing the phone, accessing the device’s battery level and status, sending and managing SMS messages, accessing the user’s address book, and making a device vibrate. These capabilities are largely made accessible to web content through a set of JavaScript APIs. This means that the B2G dialer interface, for example, is just a web page that uses a JavaScript function to initiate a call.
Mozilla is working to standardize these APIs through the W3C Device APIs working group. In theory, the same underlying JavaScript APIs that are used to enable access to underlying platform features on B2G could eventually be supported natively in the default web browsers that ship with other platforms.
The standardization effort around device APIs is especially significant. If the APIs gain widespread adoption, it would make it possible for large portions of the B2G user experience and application stack (which are, essentially, just web content) to run in web browsers on other platforms. At that heart of Mozilla’s agenda for B2G is a vision of the future in which browser-based mobile applications, built with standards-based HTML and JavaScript, will be capable of doing everything that can be done today with the native mobile application development frameworks.
Because B2G’s Gaia user interface layer is implemented in HTML and JavaScript, it can technically run in a regular desktop web browser. Of course, the device-related capabilities will only work when the content is run in an environment that has WebAPI support.
We tested the Gaia home screen user interface and several of the platform’s applications in a Firefox nightly build. All we had to do to get it running was download the code from the relevant GitHub repository and then open the homescreen.html file in Firefox.
When the page loads, the user will see the B2G lock screen, which displays the current date and time. The home screen interface can be accessed by dragging the lock screen up. The home screen displays a grid of application launchers and has a notification bar at the top. You can drag a notification slider down from the bar, much like the equivalent user interface element in Android.
B2G lock screen
If you look at the source code of the homescreen.html page, you will see that the contents of the interface, including the lock screen, are created with HTML div tags with some JavaScript code to handle interaction and populate the values. It’s quite simple and predictable web content.
The B2G home screen
Individual applications run inside of a frame in the homescreen interface. We tested several applications, including a dialer, a web browser, and a map application. Like the home screen, these are all implemented in HTML and CSS. The web browser is basically a web page with an HTML input element for the URL bar and an embedded iframe element where the page content loads.
B2G sample map application
B2G's Web browser. It's practically begging for a Yo Dawg joke
The B2G dialer
The current implementation of the Gaia environment is still simplistic and incomplete, but it offers a compelling demonstration of how conventional web content can be used to create a smartphone user experience. It’s possible to do anything in the B2G user interface that can be done with HTML and CSS, so the possibilities for styling and theming are prodigiously extensive. Such intrinsic flexibility could help make B2G appealing to hardware vendors because it would make it easier for them to create custom user interfaces that differentiate their products.
Mozilla hasn’t created an HTML-based widget toolkit for application development. The applications currently included in Gaia are just straight markup with CSS for design. It’s theoretically possible to use existing HTML widget toolkits in B2G, however, such as jQuery Mobile and Sencha Touch.
The B2G project is off to an impressive start. The underlying concept of bringing native application capabilities to the standards-based web technology stack is also tremendously compelling. It hints at the possibility that the open web could someday provide a unified application platform for mobile devices.
It’s also worth noting that the project is entirely open. As Eich pointed out to us yesterday in response to our coverage of Open webOS, the B2G project has had open governance and public source code since its first day. B2G also benefits from Mozilla’s engineering talent and potential partners. The B2G platform has an opportunity to bring positive disruption to the mobile landscape and be a serious contender.
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.
Video: Inventing on Principle
We just had a moment similar to the time we first saw content-aware scaling in action, but this time it’s even better — we’ve seen the future of programming tools and it looks awesome.
Check out the video above of Bret Victor‘s recent talk, “Inventing on Principle.” Victor has worked on experimental UI concepts at Apple and also created the interactive data graphics for Al Gore’s book, Our Choice. The video above of Victor’s keynote at the Canadian University Software Engineering Conference, captures a wonderful talk on living your life based on principles, but for many developers what’s most arresting are the software development tools demoed.
Do your current tools suddenly feel incredibly outdated? Perhaps you thought you were using a well-tuned coding machine but suddenly realize you’re really just hitting two stones together? Thought so. Sadly, the apps demoed in the video aren’t available. That’s all right, though; it just means someone needs to build them. Be sure to let us know if you do.
A Guide to Understanding Page-Speed Tests
Photo: tobias.munich/Flickr
Anyone who’s ever tried to optimize a website has faced the very basic question — how long does your site take to load?
The answer seems like it would be easy to discover: Load your site in a page speed crawler like WebPagetest and soon you’ll have your numbers. But that’s just it; you won’t have a number, you have numbers and figuring out which numbers to listen to is trickier than you might think.
Strangeloop’s Joshua Bixby recently tackled the performance metric question in a blog post titled a Non-Geeky Guide to Understanding Performance Measurement Terms. The whole article is well worth reading, but perhaps the best advice is to make a video of the page load. “If you want to get a ground-zero look at your site’s performance,” writes Bixby, “capturing videos and filmstrip views of your pages’ load times are one of the best ways to go.”
The filmstrip view Bixby refers to is part of the WebPagetest results and shows what the visitor sees in a progressive series of page captures. To create a filmstrip or video test of your website, head over to WebPagetest and select the “visual comparison” tab.
Some common performance mistakes Bixby cautions against include using “response time” and “load time” interchangeably and “not realizing that ‘response time’ can mean any number of completely different things.”
To help those unfamiliar with the nuances of loading metrics, Bixby then breaks down and defines all the terms, including what exactly is meant by “start render” or “time to first byte,” as well as some caveats to bear in mind when going over the numbers for your website.
While Bixby’s post can be extremely helpful, especially to those who are just starting out in the often confusing world of website optimization, bear in mind that testing sites like WebPagetest are no substitute for real-world tests. “As a matter of due course, you always need to gather large batches of data and rely on median numbers,” writes Bixby, “but you also need to periodically get under the hood and take a real-world look at how your pages behave for real users.”
Mozilla Experiments With Fancier New Tab Page in Firefox 13
The proposed new tab page in Firefox 13
Mozilla is considering a fancier new tab page that will replace the current blank page presented when users create a new tab in Firefox. Like other browsers, Firefox will soon offer users a set of thumbnails on the new tab page with website recommendations based on the most frequently and recently visited pages in Firefox’s history.
If you’d like to see the new page in action you’ll need to download the Aurora channel build of Firefox. (Alternatively you can use the Nightly channel.) The new tab page will be enabled by default in Aurora until Feb. 16 for testing purposes. After that the feature will be hidden away while more work is done. Head over to Firefox Engineer Tim Taubert’s blog for details on how to re-enable the new tab page if you’d like to keep using it after that date.
The new tab page in Firefox looks similar to what you’ll find in Chrome and Opera. Indeed, every web browser’s new tab page is essentially a variation on what Opera pioneered with its “speed dial” page. The basic idea is to provide a quick way to access sites you frequently visit. Mozilla’s take thus far is to pull a mixture of your most frequently and most recently visited sites and display them in a 3-by-3 grid of thumbnails.
The goals for Firefox’s new tab page are ensuring that the page loads instantly, that it isn’t distracting and that it requires zero configuration. The latter explains why, thus far, the new tab features don’t offer much in the way of customization.
There are options to “pin” a site permanently to the grid, delete a site and rearrange the order of the sites. Each site will display a thumbnail once you’ve click on it. Or at least that’s the theory. As the screenshot above demonstrates there are clearly still some bugs in the screenshot feature.
The new tab page may be a little bit of a me-too feature at this point, but for those who have been wanting it, rest assured it’s coming. Firefox 13, which is when the fancier new tab page is slated to arrive is due in June 2012.
Connect with ZionCG