Slashdot Mirror

There already is a browser which is crushing in terms of standards support, technology, flexibility... http://www.w3.org/Amaya/

Excellent for web testing, not so great for day to day use.

Because there is a separate W3C spec for 2D canvas:
http://www.w3.org/TR/2dcontext/

as new shiny stuff is added by the competing browsers (Internet Explorer is not one of these).

It is, actually. Here is one example (introduced by IE10 beta).

Ian Hickson is the editor of both docs (he's actually the editor of the main HTML standard, the WHATWG one; the draft hosted by the W3C is really nothing more that an old and incomplete copy that nobody among browser vendors takes seriously).

He explained very clearly the past and current situation: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0119.html

And, yes, the WHATWG has done an excellent job so far, bringing much needed features to the web and creating an era of faster and more interoperable browsers. If they had just waited for the W3C we would still be stuck with HTML 4.01, IE6, Flash and other plugins.

Also this is not a new development, HTML (from WHATWG) has started gradually leaving the HTML5 (from W3C) behind a long time ago. Where the two differ, all major browsers (including IE) either already follow HTML or plan to. See this post from more than a year ago: http://blog.whatwg.org/html-is-the-new-html5

When people talk about HTML5 features in browsers and websites, they actually refer to the HTML standard. The HTML5 "working draft" on the W3C website doesn't even support the old 2D canvas API, which is implemented by all browsers!

I think he meant "on the web" as in "accessible from the web"

No, he meant what he wrote. No need to twist his words.

Yes, a web page may link to a mailto: URI, but at least traditionally that would always launch an e-mail client that speaks other protocols like SMTP, POP3 and IMAP. It's just a way to hand you off to a specific spot outside the web by passing parameters, not part of the web.

Just because a web browser doesn't handle a particular protocol natively, it doesn't mean that it's not part of the web. Some web browsers support FTP, some do not. Does that mean a resource accessible through FTP is or is not part of the web depending on which browser is used to access it? Of course not.

Once more, from Tim Berners-Lee:

The access scheme is by definition the highest point of flexibility. What does that mean? It means that if the whole Web develops problems which we cannot solve within the existing protocols, or if new spaces are designed which really can't be accessed through or mapped into existing spaces, then we can create a new space. We have faith that we will be able to use this flexibility point in the future, because it worked successfully for integrating the older spaces such as Gopher and FTP spaces into the Web.

...and from the W3C's Architecture of the World Wide Web :

The Web's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP)

The web has always been more than simply "what you read over HTTP in a web browser". That's the opinion of its creator, the opinion of the organisation that manages is, and the description detailed by myriad defining documents.

I think he meant "on the web" as in "accessible from the web"

No, he meant what he wrote. No need to twist his words.

Yes, a web page may link to a mailto: URI, but at least traditionally that would always launch an e-mail client that speaks other protocols like SMTP, POP3 and IMAP. It's just a way to hand you off to a specific spot outside the web by passing parameters, not part of the web.

Just because a web browser doesn't handle a particular protocol natively, it doesn't mean that it's not part of the web. Some web browsers support FTP, some do not. Does that mean a resource accessible through FTP is or is not part of the web depending on which browser is used to access it? Of course not.

Once more, from Tim Berners-Lee:

The access scheme is by definition the highest point of flexibility. What does that mean? It means that if the whole Web develops problems which we cannot solve within the existing protocols, or if new spaces are designed which really can't be accessed through or mapped into existing spaces, then we can create a new space. We have faith that we will be able to use this flexibility point in the future, because it worked successfully for integrating the older spaces such as Gopher and FTP spaces into the Web.

...and from the W3C's Architecture of the World Wide Web :

The Web's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP)

The web has always been more than simply "what you read over HTTP in a web browser". That's the opinion of its creator, the opinion of the organisation that manages is, and the description detailed by myriad defining documents.

What's not on it: Lots of stuff. E-mail, smartphone apps, peer-to-peer file-sharing networks, instant messaging programs, FTP, and Usenet, for example.

The web is not simply whatever is transmitted over HTTP. It's an information space, where anything addressable by URI is a leaf in the node. For instance, a telephone number is part of the web because of tel: URIs. Most of the things on his list are part of the web too - there are FTP and NNTP protocols. And in fact, some P2P networks work over HTTP anyway.

From Tim Berners-Lee himself, writing in 1996:

An information object is "on the web" if it has a URI.

But, if you are the average developer do you really care? Toolkits, libraries and widget sets are most important to you

The toolkit available to an iOS application developer who has not paid Apple's ransom is HTML5 in Safari. Unfortunately, this toolkit includes no way of accessing the camera or microphone of an iPhone because Safari for iOS 5 does not support HTML5 Media Capture. Good luck making a barcode scanning web application without the camera or a VoIP application without the microphone.

Isn't there any concerns about privacy with this ? I'm not really sure how the state or the USA works with this but here is some info on how the geolocation suppose to work if this is what they use anyway (not sure but should be).

4 Security and privacy considerations

The API defined in this specification is used to retrieve the geographic location of a hosting device. In almost all cases, this information also discloses the location of the user of the device, thereby potentially compromising the user's privacy. A conforming implementation of this specification must provide a mechanism that protects the user's privacy and this mechanism should ensure that no location information is made available through this API without the user's express permission.

year after year they have added more support to help HTML apps look and feel like native apps and able to use the same APIs.

Let me know when iOS supports access to the camera and microphone from HTML without having to use PhoneGap (which requires a Mac and a paid dev cert).

Mobile Safari uses a closed-source fork of WebKit which implements certain features that Apple certainly considers "proprietary" (as in, they are unwilling to even submit them to the W3C for standardization, much less disclose how they implement them). See the transcript from a CSS working group meeting at http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html and search for comments from "smfr", who's the Apple representative.

But yes, nothing "proprietary" about iOS.

Large sums of irrelevant information does not constitute proof of anything. Here's proof! More proof! *Sigh* an all time low for critical thinking here at slashdot.

Flash is alive only in the same sense that a chicken which has had its head cut off is alive.

Mike lived for 18 months after his beheading. How does that figure into your analogy?

Adobe management decided it would be better to throw in the towel and shift resources to writing HTML5 authoring tools.

Let me know when it becomes possible to make Homestar Runner or Weebl and Bob with those tools. Or to make an application that uses a device's camera or microphone because unlike Flash's media capture API, HTML5's has gone largely unimplemented. Without media capture, how would one make video chat or a barcode scanner app?

Yeah, which enables apps to do things like load up and modify files they didn't create, just as they can on a general-purpose computer.

Ideally, the end user would tell the application what files and folders it is allowed to modify through a file chooser displayed by a secure system process. That's what the OLPC Bitfrost sandbox does, that's what Mac OS X's App Store sandbox does, and that's what the JavaScript file API does.

I imagine the demand for that sort of feature is fairly low.

Demand will be low for anything the general public doesn't know about. The demand for smartphones themselves was low before the first-generation iPhone was introduced.

The HTTP 1.1 specification doesn't even contain the word 'destination'. The closest definition for what is happening here is a 'Gateway':

gateway
        A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.

Do note that a gateway is also defined to be a server too.

It's not accurate because the server didn't even recieve the request. The request was intercepted in transit and blocked by third party.

The "502 Bad Gateway" seems to be the correct code for the behavior. The definition may not be 100% accurate in that it implies the proxy (which is what this censorship is) actually received a reply from the target server.

It would be quite funny if an ISP set the following response:
305 Use Proxy
Location: https://tpb.pirateparty.org.uk/

I was going to suggest this also as it would be a great tribute to the late Ray Bradbury. I think censorship falls under the 4xx HTTP response codes given 410 Gone is for situations when the server's owner wants to remove a url "... The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed ..." If you take the definition of what a 410 error is and replace "server owners" with "government" it would be appropriate for censorship.

Yeah, both the FTC guidelines and the current W3C DNT draft both state that users should opt-out of tracking, not opt-in. Furthermore, the advertizing industry groups like that have had the most successful with self-regulation efforts have flat-out said that while they will respect the user's chose to opt-out, they will ignore any system that opts users out automatically.

Microsoft's decision here is completely counter productive. At best, it means that sites will add code to ignore theDNT header if the UA is IE. At worst it will derail the entire process.

I think Microsoft's action here is simply intended to reduce Google's ad profits.

And you forgot one more argument: ad companies would not mind to respect an opt-in DNT program because users who cared to opt-in would be those few paranoid NoScript types who don't click on ads anyway. So following the DNT program would cost them nearly nothing, and would be good PR.
But thanks to Microsoft, any ad company who follows DNT will be losing serious money. Hopefully they will ignore DNT only when the UA is MSIE so the rest of people can still get DNT.

As Roy pointed out to them on Twitter, this is a blatant violation of the spec; DNT is designed to reflect the USER's preference, not a default.

http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/#determining

"""
The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they communicate with via HTTP, thereby allowing each service to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy all parties.

Key to that notion of expression is that it must reflect the user's preference, not the preference of some institutional or network-imposed mechanism outside the user's control. Although some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled, the user is at least able to choose whether to make use of those user agents. In contrast, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment, aside from blanket limitations on what sites can or cannot be accessed through that network.
"""

Yeah, both the FTC guidelines and the current W3C DNT draft both state that users should opt-out of tracking, not opt-in. Furthermore, the advertizing industry groups like that have had the most successful with self-regulation efforts have flat-out said that while they will respect the user's chose to opt-out, they will ignore any system that opts users out automatically.

Microsoft's decision here is completely counter productive. At best, it means that sites will add code to ignore theDNT header if the UA is IE. At worst it will derail the entire process.

When it comes to DRM peddlers, it isn't clear that that will be the choice.

. Take a look at this 'Encrypted Media Extensions' proposal. Most of it just lays out a bunch of proposed javascript for requesting keys and passing them to a decryption module whose implementation is left vague(aside from the one, seemingly completely pointless, 'simple' case where a static, known, key is used for no obvious reason).

Now, have a look at the goodies: In the diagram at the beginning "CDM may use or defer to platform capabilities". And look also at section 8.5:

"Can I ensure the content key is protected without working with a content protection provider?"

"No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support."

"Can a user agent protect the rendering path or protect the uncompressed content after decoding?"

"Yes, a user agent could use platform-specific capabilities to protect the rendering path."

So, unless you want to use the (seemingly entirely pointless) 'clear-key' case, this 'open' proposal boils down to a mixture of hot air and admissions that the good stuff would necessarily be implemented in closed (probably 'platform', which increasingly means 'cryptographically locked firmware') sections.

Can an OSS browser protect the key from the user? No. The specification explicitly says as much. And if the key is known and the cyphertext has been downloaded, the game is over. Period. So, right there, only closed (either binary-only or OSS-tivoized) implementations of key handling need apply. Can an OSS media rendering path protect the content from the user? No. The specification says as much. Only if media rendering is handed off to a binary or hardware/firmware component can that be provided.

Essentially, this proposal achieves the magnificent breakthrough of allowing a DRM streaming stack to use the browser's HTTP transfer mechanisms instead of those in the flash plugin. Key handling and media path? Those are either completely in the clear, or necessarily handed off to user-opaque sections.

Further, if you want to 'protect the media path' and ensure key security(even in a binary module) that implies such radical capabilities as protected memory regions that cannot be read by even the highest-privilege user-controlled processes(so, either a locked kernel, or an 'open' kernel under a locked hypervisor, PS3 linux style) as well as locked audio and video output paths, potentially locked cache areas on mass storage devices, and so forth.

Given this, it really comes down one of two ways: The first option is Tivoization: Yeah, it's 'open'; as in 'you could build the code and run it on some other hardware without a locked bootloader'. The second is some sort of TPM-style 'secure remote attestation' setup: It's 'open' as in "yes, you can modify it if you want; but remote hosts will refuse to deal with you if your attestation signatures come back nonstandard"(see also: Google/android DRM and what happens if you root your device...)

For good or ill, you can't make a piece of hardware serve two masters. If you want DRM to work, the platform must ultimately be controlled by the vendor, possibly with little sandbox areas for the user to amuse himself. If you want the user to control the platform, DRM cannot be more than a (perhaps frustrating, perhaps trivial) exercise in obfuscation and cat-and-mouse trickery.

As a web developer I can tell you you're correct. I have CSS and jQuery that work perfectly with FireFox, Chrome, Opera and Safari. Then I have special case CSS files for IE 6, 7, 8 and general case IE. Other browsers rarely need special case rules and never at all require special case rules for every version of the browser.

I deal with a lot of scientific data and dynamically generate graphs and plots based on variables selected in forms written in PHP. Almost guaranteed when I develop something in IE, it won't displayed correctly in FireFox, Chrome, Opera and/or Safari. If I develop something in FireFox I can't say I've ever had a problem with Chrome, Opera, or Safari, but it almost never works in IE and special case rules need to be written.

Just as an example, I have a page where a user determines the type of species they're looking at by answering questions. My organizations web standards group provided me the jQuery and CSS for the feature. The questions are contracted links in a tree like structure and are formatted as "Does the species have XXX?" or "Does the species have YYY?". When the user clicks on a link the section expands and asks another question until the user gets to the linked name of the species they're looking for, which takes them to a page with more information on the species.

The page works fine in FireFox, Chrome, Opera, and Safari, but doesn't work the same way in any IE browser. The progress enhancement solution for IE is to have all elements in the tree automatically expanded. The fact that this doesn't work in IE is a real pain in my ass. I demoed the page in FireFox and the content owner liked how it worked, but he uses IE and wasn't happy when I told him it didn't work the same way in that browser. So now he expects me to go through all the jQuery code and CSS to make it work the same way in not just IE, but every version of IE, which I'm not doing because 1) I've been told I'm not to modify features provided by the web standards group in order to ensure our web content complies with Web Content accessibility Guidelines 2.0 and 2) when the web standards group provides me with updates for jQuery features like this I'd have to go and re-update all the code again.

The alt attribute is strictly an IE thing? No. It's part of the HTML5 standard as well as XHTML. The title attribute should be used for captioning an image, while the alt attribute should be descriptive of the image. The end goal is the alt tag should not provide additional, nor leave out information whether the images are displayed nor not. The meaning of the page should not change.

As in, things that run from a web browser and have no care about the underlying OS?
You serious?

Apparently Mozilla missed the Standards Meeting.
These aren't web apps at all. If they were, the browser should be able to run them if the browser itself works on the OS in question.
So is Firefox working on Linux or not?

These are the Web Apps, Mozilla
What the hell are you doing that somehow makes them broken?

Glad I went away from that mess. Mozilla don't know left from blue anymore.

So how should a developer write a web browser that allows users to view sites that use a feature of HTML that the latest version of WebKit does not implement? One such feature is the HTML Media Capture.

First, I have better apps to develop than a web browser, so I can't answer your technical question. Second, being able to implement a particular feature on a particular platform does not a legal case make.

So how should a developer write a web browser that allows users to view sites that use a feature of HTML that the latest version of WebKit does not implement? One such feature is the HTML Media Capture.

well, there's this: http://www.w3.org/2009/dap/ (devices api)

the basis seems to be the nokia web runtime stuff, then there's stuff like phonegap too(which is basically a 3rd party webruntime with support for different platforms).

in case you're wondering if the nokia implementation was ever practical choice for apps.. well.. not really, no. and if you're wondering if it's blatantly obvious that you're using a phonegap sw when you are.. yes it is.

what blackberry is really doing is just APING TOTALLY WHAT NOKIA DID 3-4 YEARS AGO! even down to demoing automobile systems, dunno what would be different this time.

Gnome actually enforces this out of the box, if I remember correctly

How do GTK and GNOME enforce resolution independence when image editing controls (e.g. in GIMP) aren't forced to be "not dot-for-dot"?

though of course that requires that it can obtain the real DPI value from the monitor.

Even if a widget toolkit can obtain the real DPI by querying the monitor's firmware, that won't help it query the distance to the eye, which is the other side of DPI. An "inch" when setting effective DPI for window systems isn't 0.0254 m; it's 1/28 of the viewing distance. This reference inch can be larger for a device placed far away from the eye (such as a TV) or smaller for one held closer to the eye (such as a tablet or phone). See the "nominal arm's length" in the definition of the CSS reference pixel.

Something as basic as vertically centering text is impossible.

Putting things left, right, in a horizontal row or in a vertical row is a nightmare that usually involves creating more HTML elements anyway instead of being able to use pure CSS.

CSS3 Grid Layout - which is basically an adaptation of the traditional desktop UI layout model as seen in Swing, Qt etc - finally fixes that. The only catch is that, so far, the only supporting browser is IE10 beta...

The aligning problems you cite are exactly the sorts of new features that are subject to the prefix problem -- see the flexbox spec (at http://www.w3.org/TR/css3-flexbox/)... and then see the 2009 flexbox spec (at http://www.w3.org/TR/2009/WD-css3-flexbox-20090723). Most browsers (minus the IEs) support the old version. A few Chrome versions -- NOT -webkit-*, just Chrome -- support the new syntax (see http://caniuse.com/flexbox).

So, to sum up: we have this new standard you desire, but the problem addressed by the FA is directly to blame for the lack of adoption.

The aligning problems you cite are exactly the sorts of new features that are subject to the prefix problem -- see the flexbox spec (at http://www.w3.org/TR/css3-flexbox/)... and then see the 2009 flexbox spec (at http://www.w3.org/TR/2009/WD-css3-flexbox-20090723). Most browsers (minus the IEs) support the old version. A few Chrome versions -- NOT -webkit-*, just Chrome -- support the new syntax (see http://caniuse.com/flexbox).

So, to sum up: we have this new standard you desire, but the problem addressed by the FA is directly to blame for the lack of adoption.

What happened with those specs is that Apple proposed the drafts and Apple employees were the original editors (which all makes sense so far)... and then they did absolutely nothing for a while. Completely ignoring feedback mail, not fixing obvious bugs in the text (e.g. the text totally not matching what every browser, including WebKit, implements).

Hard to expedite the standardization process when some participants sandbag.

After a bit of this, new editors got assigned to the drafts, and they're making better progress now.

Note that you should not be confusing "whatever happens to be published under /TR" with "the current state of the spec. The current state of CSS transforms (2d and 3d got folded into a single document) is at http://dev.w3.org/csswg/css3-transforms/ and pretty much no one involved in the working group or the browsers that are implementing these specs pays any attention to what's happening in /TR land.

One last comment: there have in fact been pretty major changes to 2d and 3d transforms since they first appeared, both in terms of browser behavior (esp. around transitions between transforms) and even more in terms of the actual spec (because the initial drafts submitted by Apple didn't even match WebKit's behavior).

I'd bet Tim and a few of the other early visionaries might disagree with you.

http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Frss.slashdot.org%2FSlashdot%2Fslashdot

How come modern ... web browsers don't do decent line breaking?

Because the page designer didn't specify the required CSS. Browsers have supported automatic hyphenation for at least a couple of years.

TBL has already apologised for that:

http://www.w3.org/People/Berners-Lee/FAQ.html#etc

Don't you know that higher resolution means smaller text?

Only if your applications are hardcoded to display fixed pixel sizes. For example, Windows can be set to a different DPI, which well-behaved applications will respect. I've written instructions on how to set DPI when using a TV as a PC monitor. Even CSS doesn't actually use pixel distances anymore; instead, it uses "reference pixels" (abbreviated px) of 1/2688 of the distance from the viewer to the document's plane, based on a nominal 96 dpi and 28 inch viewing distance for a desktop PC monitor.

This is the reason that CSS 2.1 isn't bug free yet in any browser. CSS 2 change list. It's a moving target. Granted there are some browsers with very terrible CSS support, but the CSS Spec is very complicated. Add that to the fact that most pages don't even start out with standards compliant HTML, so the browser has to guess what to do because you didn't close your tags properly, or you put a div inside a span.

Well W3c defines speech input here: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html and Webkit provides support. Voice controlled video players are already out there using HTML5. I have seen a facial recognition demo in HTML5 that uses a local computer webcam. I would much rather support Chrome or Firefox as a browser then Flash as a plugin. I wouldnt bother targeting IE anything, all the browsers microsoft makes are shit. Getting the boneheads who would use Microsoft at an enterprise level convinced of this is going to be hard, I agree. But if they are on XP and IE they dont give a rats ass about security anyway.

Gyah; apologies, correct spec was edited the 12th ( http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html ).

Please don't confuse the World Wide Web Consortium with the shitty spam farm known as W3Schools.

There is no confusion. The satire benefits from the brevity of the w3schools and jquery links rather than the firehose of information at http://www.w3.org/Submission/web-forms2/#for-javascript, for example.

Please don't confuse the World Wide Web Consortium with the shitty spam farm known as W3Schools.

There is no confusion. The satire benefits from the brevity of the w3schools and jquery links rather than the firehose of information at http://www.w3.org/Submission/web-forms2/#for-javascript, for example.

Please don't confuse the World Wide Web Consortium with the shitty spam farm known as W3Schools.

There are many digital annotation systems with distribution means prior to 2005. Just for a example is the very general-purpose Annotea RDF vocabulary and support implemented in the W3C Amaya web browser. 2001 http://www.w3.org/2001/Annotea/

uhm?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

or am I missing something? it seems to me that the only thing needed is a local cache/proxy -- and ISP's (or *anyone* upstream for that matter) are also free to cache stuff marked as "public", if (and that is a big if I guess... and won't happen in the case of google either way, because that would kill their whole usage tracking stuff) the sites send the appropriate headers on those resources. So, just install that local proxy, then write emails to all those webmasters who make it nearly useless... good luck! :P

The lead contributor to the working group is not Microsoft, genius. Does that mean they didn't write or propose the spec in the first place?

I'll even help you out. Try this page and then tell me who appears on the list of signatories?

I counter your bullshit with actual cited facts. While you are poking around there, look at all the rest of the historical documents, and see how many times the 'minor contributors' at Microsoft show up.

suggest not polluting HTML5 with this stuff.

They aren't. Encrypted Media Extensions are described in a completely separate document, which is built on but does not modify the underlying HTML spec. You can find the draft proposal here.

If DRM is really that necessary, then they can make a plugin or standalone app to do it.

They have, several times over. That's the problem. It's wasteful, because there is no standard.

This is about what is appropriate and correct to have in a public standard.

Proprietary standards are useful too. As long as nothing is mandated in an open standard that makes it no longer open, I don't see the problem. In this case, for example, nothing would compel Mozilla (for example) to incorporate support for this technology in Firefox if they didn't want to, and Firefox users could still visit any HTML5 page and view any other content (including video content) exactly the same way.

I don't consider a tool that is used for 90% of commercial video streaming, with no migration path to other tools to be "on its deathbed".

http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

Bullshit. You know where P3P actually comes from? The World Wide Web Consortium (W3C). The people who brought us HTML, and CSS. Where does it not come from? Microsoft. In fact, Microsoft isn't even one of the contributors (AT&T, IBM, ETH, MIT and the University of Venice are though). Funnily enough, the author didn't even imply in that G+ post you link to that Microsoft invented P3P.

So, your focus on "ohhh, Microsoft!" is a false focus in comparison.

Consider the following (from http://www.w3.org/TR/P3P11/#ua_compact;

6.4 Compact Policy Processing

P3P user agents MUST NOT rely on P3P compact policies that do not comply with the P3P 1.0 or P3P 1.1 specifications or are obviously erroneous. Such compact policies SHOULD be deemed invalid and the corresponding cookies should be treated as if they had no compact policies.

As I understand this, IE should actually search the Google P3P header for a valid statement of what Google intends to do with regard to tracking cookies. If it does not find those, it should apply the default behaviour for web sites without any P3P header. As described by Dean Hachamovitch (the author of the blog post):

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 sites use does not include tracking the user.

Fine. So your browser sees a Google P3P header without any valid policies. At this point, the clause "unless the site presents..." should kick in and cookies should be blocked. To me this looks like a bug in IE, as they failed to implement the default behavior in this case. It would be appropriate for Microsoft to fix this bug, send the fix as update on next patch day and otherwise be very humble about their error.

  Instead, Dean Hachamovitch tries to paint this as conspiracy by Google to circumvent IE's security protection. FAIL.