Slashdot Mirror

The entire Internet, including (especially, in this case) the WWW, is based on published specifications that describe how clients and servers are supposed to interact with each other. Some of these specifications relate to privacy. In particular, there is a thing called a "compact privacy policy" which is a very shorthand way of indicating many of the most salient points of a privacy policy in a machine-readable format. This is a published specification, part of the Platform for Privacy Preferences (P3P), described in http://www.w3.org/TR/P3P/.

The goal of P3P is to provide a way for the user of an HTTP client (generally, a web browser) to specify automatic behaviors based on privacy settings. It's not a security feature at all; it's a convenience feature for sites where the user trusts the server to not lie about what its privacy policy is. The idea is that the server sends a compact privacy policy, and the user agent decides what to do based on that policy. It removes the need for the user to manually review each cookie, etc. and decide, based on the info it contains and the policy of the site, what to do with it.

Google, in their infinite not-evilness, decided that P3P is old and broken (somewhat debatable, but they make some good points) and they weren't going to respect the specification. Of course, the usual way that somebody would do this is to not implement it on their end at all; i.e. don't send any compact privacy policy and let the browser do whatever it does with cookies that don't come with privacy info attached. Google thought differently, and decided to instead send a CPP that is interpreted in the following way by P3P-compliant user agents:
We have a privacy policy, it is all-inclusive and has no exceptions.
Of course, this is a complete lie - Google does do various things which may compromise your privacy, such as track you with cookies. However, they decided that rather than indicate this in the machine-readable format specified in P3P, they would instead send a human-readable English text string, utterly meaningless under the specification, telling people to go read their actual privacy policy. The problem is, the user is never supposed to read the raw CPP. It's a bunch of meaningless characters to anybody unfamiliar with the specification, and generally isn't ever displayed to the user. The end result is that, if the user's browser is configured to use P3P to decide how to handle cookies, Google's cookies are going to be automatically accepted regardless of whether what Google uses those cookies for is actually acceptable to the user.

In a very real sense, Google has published a false security policy. It's not a security exploit - the entire specification is built on trust, as is true of any security policy - but it's a very flagrant violation of that trust and, in the EU, is illegal. That's what they're in hot water for. Apple is only relevant to this story because they use P3P, presumably by default (how many Safari users are going to customize their privacy settings?), and adhere to the specification as written.

"Don't be evil" my ass. By the way, I own zero Apple products and am generally not a fan of the way they treat their users. That does not absolve Google of this kind of bullshit, however.

Javascript can access and process file data directly with the HTML5 File API which is supported by recent versions of most major browsers.

well we didn't cover java bytecode verification in my compiler classes because java didn't exist then, but I worked on the java team at one of my past jobs, i wrote a java debugger for them, and i worked closely with the team that wrote the VM.

I assume you're referring to the bytecode verification as outlined here: http://www.w3.org/Conferences/WWW4/Papers/197/40.html#1

I don't think that's simpler than compiling javascript from source.

How the hell does slashdot.org not support IPV6, I thought this was a tech website?

Forget IPV6 ... it doesn't have valid HTML, valid CSS and looks terrible on mobile devices.

How the hell does slashdot.org not support IPV6, I thought this was a tech website?

Forget IPV6 ... it doesn't have valid HTML, valid CSS and looks terrible on mobile devices.

If anything, I would expect visible="hidden" to be worse since: "With ‘visibility’ set to hidden, however, processing occurs as if the element were part of the rendering tree and still taking up space, but not actually rendered onto the canvas." I don't have time to verify that at the moment, but maybe I'll test it later and post an update.

I've noticed that for large SVG files where much of the content has display='none' (so it is only displayed when something is clicked to trigger a change in the display property) Chrome seems to take several seconds to become responsive after the SVG page load is initiated, while other browsers seem to handle it almost instantly. Since a display value of none "indicates that the given element and its children shall not be rendered directly (i.e., those elements are not present in the rendering tree)" it seems Chrome shouldn't be spending so much time processing such stuff. Version 24 doesn't seem to fix that issue.

Its not W3C standard.

It's a candidate recommendation, which is a lot more than can be said for any of the IE6-exclusive features.

"well, now I have to write markup that's actually standards-compliant and that's just too hard! I want HTML that will render even if it's horribly broken!"

Of course they do. They miss the days of things like the following when they move to XML/XHTML, and I only added the doctype to get rid of "quirks mode" in IE:

<!DOCTYPE HTML "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<title>Page Title</title>
<p>Under construction!<br>(Isn't it pretty?)

Instead, you have this with XHTML:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Page Title</title>
</head>
<body>
<p>Under construction!<br />(Isn't it pretty?)</p>
</body>
</html>

For the most part, that's about as minimal as you can get in both cases while still having some content. There is no indication of language, so it could be English or Arabic or whatever. The character set and MIME type are both missing as well, so either of those documents could be a Windows-1252 document with text/html by default or perhaps a KOI8-R document with application/xhtml+xml, regardless of validity.

The point is that XHTML encourages more easily read mark-up. For example, the only way to know that a paragraph (<p> tag) ends in HTML is when a non-inline element (e.g. the DIV element or </body>) is encountered or when its end tag (</p>) is encountered.

The only point that I dislike is that you cannot have paragraphs inside paragraphs. If you have logical divisions such as a paragraph with a quote inside that contains multiple paragraphs, you must (logically) split it up into multiple paragraphs. Alternatively, the blockquote element was supposed to remedy such a situation. You'd end your paragraph and use a blockquote element after that to contain the quote.

That is the big reason why I really liked XHTML 2.0. It had some actual useful improvements. Another example is the combination of section and the generic h elements rather than people using h1 first, then h2 second, etc. Those were old concepts that differed only by presentation in rendering, which could be fixed thanks to the invention of CSS. In other words, you could use h6 first, then h3 second, then h2 third, etc. and use CSS to change how they appeared, making them less semantic because any heading element would do. Also, the "any element can be a link" idea was really nice!

One downside to XHTML 2.0 was the fact that it involved so many working groups. XForms, XFrames, XML Events, Ruby, RDFa, etc. I think XHTML should have stuck to semantics. Others could have been included using namespaces. Additionally, XFrames and XML Events had to be finished in order for XHTML 2.0 to be finished, so it was a simple case of having too much to do with so little time in which to do it. And of course there were the little things that still needed attention like how generic things ought to be. After simplifying h1, h2, etc. to combinations of section and h elements, why not do the same with lists? After all, it's a general construct, right? Why have specific things for lists when they can be used for shopping or whatever, ordered or not? In case nobody knows about it, I'm referring to this proposal, which got some official replies on IRC and resulted in this e-mail and this response to that e-mail.

The "need to discuss the principle, and the philosophy" was a big part of what made XHTML 2.0, and I think that was its real downfall. It was very slow-moving because it was to define the building blocks of the Semantic Web, and what exactly was needed t

"well, now I have to write markup that's actually standards-compliant and that's just too hard! I want HTML that will render even if it's horribly broken!"

Of course they do. They miss the days of things like the following when they move to XML/XHTML, and I only added the doctype to get rid of "quirks mode" in IE:

<!DOCTYPE HTML "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<title>Page Title</title>
<p>Under construction!<br>(Isn't it pretty?)

Instead, you have this with XHTML:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Page Title</title>
</head>
<body>
<p>Under construction!<br />(Isn't it pretty?)</p>
</body>
</html>

For the most part, that's about as minimal as you can get in both cases while still having some content. There is no indication of language, so it could be English or Arabic or whatever. The character set and MIME type are both missing as well, so either of those documents could be a Windows-1252 document with text/html by default or perhaps a KOI8-R document with application/xhtml+xml, regardless of validity.

The point is that XHTML encourages more easily read mark-up. For example, the only way to know that a paragraph (<p> tag) ends in HTML is when a non-inline element (e.g. the DIV element or </body>) is encountered or when its end tag (</p>) is encountered.

The only point that I dislike is that you cannot have paragraphs inside paragraphs. If you have logical divisions such as a paragraph with a quote inside that contains multiple paragraphs, you must (logically) split it up into multiple paragraphs. Alternatively, the blockquote element was supposed to remedy such a situation. You'd end your paragraph and use a blockquote element after that to contain the quote.

That is the big reason why I really liked XHTML 2.0. It had some actual useful improvements. Another example is the combination of section and the generic h elements rather than people using h1 first, then h2 second, etc. Those were old concepts that differed only by presentation in rendering, which could be fixed thanks to the invention of CSS. In other words, you could use h6 first, then h3 second, then h2 third, etc. and use CSS to change how they appeared, making them less semantic because any heading element would do. Also, the "any element can be a link" idea was really nice!

One downside to XHTML 2.0 was the fact that it involved so many working groups. XForms, XFrames, XML Events, Ruby, RDFa, etc. I think XHTML should have stuck to semantics. Others could have been included using namespaces. Additionally, XFrames and XML Events had to be finished in order for XHTML 2.0 to be finished, so it was a simple case of having too much to do with so little time in which to do it. And of course there were the little things that still needed attention like how generic things ought to be. After simplifying h1, h2, etc. to combinations of section and h elements, why not do the same with lists? After all, it's a general construct, right? Why have specific things for lists when they can be used for shopping or whatever, ordered or not? In case nobody knows about it, I'm referring to this proposal, which got some official replies on IRC and resulted in this e-mail and this response to that e-mail.

The "need to discuss the principle, and the philosophy" was a big part of what made XHTML 2.0, and I think that was its real downfall. It was very slow-moving because it was to define the building blocks of the Semantic Web, and what exactly was needed t

"well, now I have to write markup that's actually standards-compliant and that's just too hard! I want HTML that will render even if it's horribly broken!"

Of course they do. They miss the days of things like the following when they move to XML/XHTML, and I only added the doctype to get rid of "quirks mode" in IE:

<!DOCTYPE HTML "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<title>Page Title</title>
<p>Under construction!<br>(Isn't it pretty?)

Instead, you have this with XHTML:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Page Title</title>
</head>
<body>
<p>Under construction!<br />(Isn't it pretty?)</p>
</body>
</html>

For the most part, that's about as minimal as you can get in both cases while still having some content. There is no indication of language, so it could be English or Arabic or whatever. The character set and MIME type are both missing as well, so either of those documents could be a Windows-1252 document with text/html by default or perhaps a KOI8-R document with application/xhtml+xml, regardless of validity.

The point is that XHTML encourages more easily read mark-up. For example, the only way to know that a paragraph (<p> tag) ends in HTML is when a non-inline element (e.g. the DIV element or </body>) is encountered or when its end tag (</p>) is encountered.

The only point that I dislike is that you cannot have paragraphs inside paragraphs. If you have logical divisions such as a paragraph with a quote inside that contains multiple paragraphs, you must (logically) split it up into multiple paragraphs. Alternatively, the blockquote element was supposed to remedy such a situation. You'd end your paragraph and use a blockquote element after that to contain the quote.

That is the big reason why I really liked XHTML 2.0. It had some actual useful improvements. Another example is the combination of section and the generic h elements rather than people using h1 first, then h2 second, etc. Those were old concepts that differed only by presentation in rendering, which could be fixed thanks to the invention of CSS. In other words, you could use h6 first, then h3 second, then h2 third, etc. and use CSS to change how they appeared, making them less semantic because any heading element would do. Also, the "any element can be a link" idea was really nice!

One downside to XHTML 2.0 was the fact that it involved so many working groups. XForms, XFrames, XML Events, Ruby, RDFa, etc. I think XHTML should have stuck to semantics. Others could have been included using namespaces. Additionally, XFrames and XML Events had to be finished in order for XHTML 2.0 to be finished, so it was a simple case of having too much to do with so little time in which to do it. And of course there were the little things that still needed attention like how generic things ought to be. After simplifying h1, h2, etc. to combinations of section and h elements, why not do the same with lists? After all, it's a general construct, right? Why have specific things for lists when they can be used for shopping or whatever, ordered or not? In case nobody knows about it, I'm referring to this proposal, which got some official replies on IRC and resulted in this e-mail and this response to that e-mail.

The "need to discuss the principle, and the philosophy" was a big part of what made XHTML 2.0, and I think that was its real downfall. It was very slow-moving because it was to define the building blocks of the Semantic Web, and what exactly was needed t

You might be interesting in the work of the W3C Private User Agent Community Group that is exploring solutions to prevent such leaks. One option for limiting the capability to leak the mouse positions is to limiting the back channels available to leak the state out to the web. A web browser that resists such leaks can still support rich client side Javascript content. Not surprisingly, early results demonstrate that much web advertising is caught by such protections - for example Google search ads still work but most content network ads violate security and are blocked. Other options are being explored such as declarative web actions to offload interactive tasks to trusted apps, and a curated database of trusted scripts that implement widely used features such as slide shows etc. There is a lot of resistance from shills wanting to entangle our computing use with web services and even offload web browser security to the cloud, and they are currently winning, so if people are interested in such solutions then please consider supporting this group, see: http://www.w3.org/community/pua/

If you were likewise confused by this blurb about clicking on friends' names in the browser, what WebRTC actually is at a technological level, at least, is basically a collection of real-time P2P streaming-media stuff that is currently usually implemented via browser plugins or 3rd-party software. W3C is trying to standardize and expose it via more normal javascript APIs.

The basic functionality will include things like: users opening video or audio streams with each other (which includes NAT-punching, negotiating codecs, etc.) to support Skype-style video chat in the browser; streaming logic to deal with sending/buffering/etc. for P2P streams; support for data connections directly between users, to allow browser-based multiplayer gaming to bypass a central server; and some kind of management of local multimedia resources that I don't fully understand.

The draft standard is here.

First, get written specifications from a town official who has the authority to approve the results. The specifications should indicate the sources of content and how the town expects the Web site to be hosted. The specifications should be testable; that is, it should be possible to determine whether or not the result indeed implements what was wanted. You definitely do not want to put in any effort that will then be rejected. If you get a negative response, you want to point to the specification as justification for what you created.

Second, read what experts have said about proper Web design. The most important thing is to adhere to W3C specifications; see http://www.w3.org/. That way, any problems by end-users in viewing the result can be attributed to the users' browsers and not to your creation. Also peruse Jacob Nielsen's Web site at http://www.useit.com/, especially his http://www.useit.com/alertbox/9605.html and http://www.useit.com/homepageusability/guidelines.html. While the Viewable with Any Browser Campaign at http://www.anybrowser.org/campaign/index.html is somewhat dated, much of it is still relevant. Finally, there are my own "Professional" Web Developers at http://www.rossde.com/internet/Webdevelopers.html (where I dissect the errors committed by professional Web developers) and My Web Page Design Criteria at http://www.rossde.com/internet/web_design.html (where I describe how I design my own Web pages). In my "Professional" Web Developers, pay special attention to Accessibility to make sure you do not violate the Americans with Disabilities Act. My two Web pages that I cite here contain links to external Web sites with more information that may prove quite valuable.

Third, test your results. Use the W3C validators. Use http://validator.w3.org/ to make sure you have no HTML/XHTML errors. Use http://jigsaw.w3.org/css-validator/ to make sure you have not CSS errors.

First, get written specifications from a town official who has the authority to approve the results. The specifications should indicate the sources of content and how the town expects the Web site to be hosted. The specifications should be testable; that is, it should be possible to determine whether or not the result indeed implements what was wanted. You definitely do not want to put in any effort that will then be rejected. If you get a negative response, you want to point to the specification as justification for what you created.

Second, read what experts have said about proper Web design. The most important thing is to adhere to W3C specifications; see http://www.w3.org/. That way, any problems by end-users in viewing the result can be attributed to the users' browsers and not to your creation. Also peruse Jacob Nielsen's Web site at http://www.useit.com/, especially his http://www.useit.com/alertbox/9605.html and http://www.useit.com/homepageusability/guidelines.html. While the Viewable with Any Browser Campaign at http://www.anybrowser.org/campaign/index.html is somewhat dated, much of it is still relevant. Finally, there are my own "Professional" Web Developers at http://www.rossde.com/internet/Webdevelopers.html (where I dissect the errors committed by professional Web developers) and My Web Page Design Criteria at http://www.rossde.com/internet/web_design.html (where I describe how I design my own Web pages). In my "Professional" Web Developers, pay special attention to Accessibility to make sure you do not violate the Americans with Disabilities Act. My two Web pages that I cite here contain links to external Web sites with more information that may prove quite valuable.

Third, test your results. Use the W3C validators. Use http://validator.w3.org/ to make sure you have no HTML/XHTML errors. Use http://jigsaw.w3.org/css-validator/ to make sure you have not CSS errors.

First, get written specifications from a town official who has the authority to approve the results. The specifications should indicate the sources of content and how the town expects the Web site to be hosted. The specifications should be testable; that is, it should be possible to determine whether or not the result indeed implements what was wanted. You definitely do not want to put in any effort that will then be rejected. If you get a negative response, you want to point to the specification as justification for what you created.

Second, read what experts have said about proper Web design. The most important thing is to adhere to W3C specifications; see http://www.w3.org/. That way, any problems by end-users in viewing the result can be attributed to the users' browsers and not to your creation. Also peruse Jacob Nielsen's Web site at http://www.useit.com/, especially his http://www.useit.com/alertbox/9605.html and http://www.useit.com/homepageusability/guidelines.html. While the Viewable with Any Browser Campaign at http://www.anybrowser.org/campaign/index.html is somewhat dated, much of it is still relevant. Finally, there are my own "Professional" Web Developers at http://www.rossde.com/internet/Webdevelopers.html (where I dissect the errors committed by professional Web developers) and My Web Page Design Criteria at http://www.rossde.com/internet/web_design.html (where I describe how I design my own Web pages). In my "Professional" Web Developers, pay special attention to Accessibility to make sure you do not violate the Americans with Disabilities Act. My two Web pages that I cite here contain links to external Web sites with more information that may prove quite valuable.

Third, test your results. Use the W3C validators. Use http://validator.w3.org/ to make sure you have no HTML/XHTML errors. Use http://jigsaw.w3.org/css-validator/ to make sure you have not CSS errors.

Tim Berners-Lee promotes the idea of linked data everywhere. Wikipedia is on board with wikidata. The Nokia N9 features a triple store, the same one that is used in Gnome. KDE implements Nepomuk. The UK is linking all legislature with RDF.

Ubuntu could make a large contribution by making the data graph of the user and of the distribution visible and searchable. Do you see a future for the semantic web and will you participate in it?

Yes. Key management is surprising difficult, and does not scale.

Key management is surprisingly difficult, but to say it does not scale is too strong.

Existing CA-based PKI has proven to have a number of deficiencies, but in spite of those it still works pretty well and has proven to scale extremely well. For e-mail, we already have a great solution in place (S/MIME) but unfortunately it's not widely used and isn't even widely supported on the most widely-used e-mail clients -- webmail providers like Gmail, Yahoo Mail, Hotmail, etc.

Ignoring the issue of web-based clients for the moment, there's really no reason S/MIME encrypted/signed e-mail couldn't be used by everyone, if we could streamline the process of S/MIME certificate issuance. Given certificates for everyone (yeah, that's not handwaving, that's whole body waving), all e-mail with previous correspondents could be trivially encrypted and it we could even establish a protocol for dynamically retrieving certificates for addresses which have never been e-mailed before.

The two problems, webmail clients and certificates, can, I think, be solved together, and "the cloud" can further be used to facilitate key management.

There is a W3C proposal for a Web Cryptography API that would enable web applications to perform cryptographic operations using keys that are stored and managed by the web browser -- and unavailable to the web apps that are using them. This will address the single biggest obstacle to useful S/MIME on webmail -- the fact that it doesn't do you much good to have all your e-mail encrypted if Google has the keys. But with the Web Crypto API, Gmail (or Yahoo mail, etc.), could do all of the crypto in the browser with the keys stored only on your computer.

Further, it would be trivial for a webmail provider, who has already authenticated you for purposes of access to your e-mail account, to certify your public key as authentically being associated with your e-mail address. Additional, optional, certification processes could be used to validate other aspects of your identity if desired, but the core association between certificate and address can be trivially verified by the e-mail provider.

There's another problem, though, which is backup and availability of the decryption keys. Having the browser store them only on the local machine is great from a security perspective, but sucks if you're using some other computer, or if your computer dies. In fact it defeats most of the greatest advantages of webmail, and worse, could actually cause you to lose access to all of your e-mail forever.

The cloud offers a solution to that as well, though. Consider the Chrome "sync" feature, which creates an encrypted bundle of all of the passwords and other information that Chrome stores locally for users and synchronizes it all to the cloud. The encryption key is derived from a user-provided password. This could be leveraged to provide secure cloud storage of your e-mail decryption and signing keys, ensuring they're safely backed up to the cloud but unavailable to either the cloud service provider or the mail provider.

Obviously, this approach would place the security of your e-mail in the password used to encrypt your cloud-based key bundle, and it would mean that forgetting this password would effectively destroy all of your e-mail, unless you had arranged for some other secure key escrow service. There are many ways the latter could be done, with various tradeoffs. I think a reasonable starting point, though, would simply be to tell people that forgetting that password would cause permanent loss of access to all their encrypted e-mail, then let them make the decision about whether or not to activate the feature.

There are a number of ways this scheme could be subverted, but most boil down to subverting the web browser. It would be possible for the webmail service provider to certify a new key (known to t

You did see Knuth's reply to that right?

http://lists.w3.org/Archives/Public/www-validator/2005Sep/0074.html

The W3C has few resources of its own; the pace of the W3C is largely a function of the efforts of its contributors, who for CSS are mostly browser vendors. In fact, the main reason CSS transitions, animations and transforms progressed very slowly was because the editors of those specs, Apple employees, did not work on them. One of them writes here:
http://lists.w3.org/Archives/Public/www-style/2012Feb/0356.html
"Despite having billions in the bank, we don't have the luxury of full-time W3C editors like Hixie and Tab."
I.e., Apple chose not to invest in standardizing their inventions.

There are other cases, for example -webkit-text-size-adjust, where Apple has shown no interested in standardizing the property at all.

It was a good thing to introduce innovative -webkit-prefixed features. It was a bad thing to not prioritize their standardization.

Note that for various reasons, policy consensus is shifting towards the view that we should try to ship experimental features unprefixed but disabled by default, so Web developers can experiment with them but not use them in production sites. This creates pressure for every vendor to assist in standardization --- a very good thing.

border-radius is part of the CSS Backgrounds and Borders Module of CSS 3, and as such, is still just a candidate recommendation -- hence is NOT a standard yet at least as of July 24, 2012.

http://www.w3.org/TR/css3-background/

Really? Why does it still say draft with updates provided just this month? Why has slashdot featured bickering about HTML5 video support in something that is ready to be ratified for the last 3-4 years?

Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code .

There FTFY. This can never be said loudly enough. If you don't believe me, please at least believe Donald Knuth

I wonder where all these people got the idea that breaking software is a good idea? Apple used to (and probably still does) break backwards compatibility. However they did this; for unpublished interfaces; where they gave warnings not to use them; where they broke them regularly and where they had a reasonable alternative that worked. That is the only exception; you told people from the very beginning, very explicitly not to do the thing that you are about to stop them doing. You also told them explicitly how to avoid it.

You must always make it possible for the old way to work in parallel with the new way. You have no idea how and where your software is used and why someone may need to keep it working in the old way and for how long. You may not be willing to maintain the old way, but you must leave space for someone else to do that.

Or Microsoft isn't following the spec, so people are ignoring the setting for them: http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#determining

They do 100% the opposite of what the draft "standard" says...

http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#determining

"A user agent must have a default tracking preference of unset (not enabled) unless a specific tracking preference is implied by the decision to use that agent. For example, use of a general-purpose browser would not imply a tracking preference when invoked normally as "SuperFred", but might imply a preference if invoked as 'SuperDoNotTrack' or 'UltraPrivacyFred'."

IE 10 does not imply a tracking preference.

To be fair this was changed recently, but on the other hand Microsoft has had plenty of time to change the default setting. The could have the browser start the first time on a page that let's the user change the setting and be complaint.

Exactly, DNT is useless and the whole concept may have been deliberately designed to be useless.

Really?

So, you've read all the W3C papers? You've been to the workshops? You are aware of the discussions inside the Tracking Protection Working Group?

No, wait, you just have an opinion based on reading a few badly researched online magazine articles.

Actually I have a mind which can think critically. None of your links adequately addresses the issue of compliance. In order to enforce it, you must resort to either a regulatory body or some form of "public shame". The problem with the debate is that DNT wouldn't be an issue if browsers stopped leaking data all over the place. It's a waste of time arguing about a mediocre solution when good solutions could already exist.

Exactly, DNT is useless and the whole concept may have been deliberately designed to be useless.

Really?

So, you've read all the W3C papers? You've been to the workshops? You are aware of the discussions inside the Tracking Protection Working Group?

No, wait, you just have an opinion based on reading a few badly researched online magazine articles.

Actually I have a mind which can think critically. None of your links adequately addresses the issue of compliance. In order to enforce it, you must resort to either a regulatory body or some form of "public shame". The problem with the debate is that DNT wouldn't be an issue if browsers stopped leaking data all over the place. It's a waste of time arguing about a mediocre solution when good solutions could already exist.

Exactly, DNT is useless and the whole concept may have been deliberately designed to be useless.

Really?

So, you've read all the W3C papers? You've been to the workshops? You are aware of the discussions inside the Tracking Protection Working Group?

No, wait, you just have an opinion based on reading a few badly researched online magazine articles.

Actually I have a mind which can think critically. None of your links adequately addresses the issue of compliance. In order to enforce it, you must resort to either a regulatory body or some form of "public shame". The problem with the debate is that DNT wouldn't be an issue if browsers stopped leaking data all over the place. It's a waste of time arguing about a mediocre solution when good solutions could already exist.

Exactly, DNT is useless and the whole concept may have been deliberately designed to be useless.

Really?

So, you've read all the W3C papers? You've been to the workshops? You are aware of the discussions inside the Tracking Protection Working Group?

No, wait, you just have an opinion based on reading a few badly researched online magazine articles.

Exactly, DNT is useless and the whole concept may have been deliberately designed to be useless.

Really?

So, you've read all the W3C papers? You've been to the workshops? You are aware of the discussions inside the Tracking Protection Working Group?

No, wait, you just have an opinion based on reading a few badly researched online magazine articles.

Exactly, DNT is useless and the whole concept may have been deliberately designed to be useless.

Really?

So, you've read all the W3C papers? You've been to the workshops? You are aware of the discussions inside the Tracking Protection Working Group?

No, wait, you just have an opinion based on reading a few badly researched online magazine articles.

Team Marketing is on tactical thermonuclear crack. I don't know where the hell they got it; but damn if it isn't the good stuff. Consider the below, from a 'Rachel Thomas' working on behalf of the "Direct Marketing Association":

"Marketing fuels the world. It is as American as apple pie and delivers relevant advertising to consumers about products they will be interested at a time they are interested. DNT should permit it as one of the most important values of civil society. Its byproduct also furthers democracy, free speech, and – most importantly in these times – JOBS. It is as critical to society – and the economy – as fraud prevention and IP protection and should be treated the same way.

Marketing as a permitted use would allow the use of the data to send relevant offers to consumers through specific devices they have used. The data could not be used for other purposes, such as eligibility for employment, insurance, etc. Thus, we move to a harm consideration. Ads and offers are just offers – users/consumers can simply not respond to those offers – there is no associated harm.

Further, DNT can stop all unnecessary uses of data using choice and for those consumers who do not want relevant marketing the can use the persistent Digital Advertising Alliance choice mechanism. This mechanism has been in place for 2 years."

Yes, she actually said that. In public.

This is a sincere question, by a naive end-user...
http://www.w3.org/Amaya/
open-source, and efficient even to me...

Oh, come on, Slashdot! I'm not allowed to use an ordered list in my comments?

You are, but their POS stylesheet hides the numbers. If, for example, I "Disable Styles" in Safari 6's Develop menu, your list magically becomes numbered - the page looks completely like ass, but at least the fucking ordered lists are numbered, not just ordered. At least as I read, for example, the HTML 4 section on lists, "visual user agents" should "number ordered list items". I guess a stylesheet are supposed to be able to override any aspect of presentation in the spec, but it's still really bogus to have a stylesheet that turns off numbering for ordered list items.

(And Slashdot should allow titles to be a bit longer, assuming this isn't some unfortunate interaction between Slashdot and Safari - the box in which to type the title has some extra space at the end even with my longest-I-could-type title which, alas, required me to abbreviate "rendered" as "rendered".)

It seems not.
Oh, snap!

You mistyped "Mozilla Developer Network" and "W3C".

Get it from the source, fool!

No, they are "in" the browser. First of all, only GET and POST are supported as values in action for HTML4.

Secondly, the difference between GET, POST, PUT, etc. is not that the browser requests a URL, and merely passes along the "action" parameter, no matter what it is "get", "put", "mickymouse", "goofy".

Rather, what happens is that the browser makes an entirely different type of HTTP request depending on the action param.

GET /path/to/file/index.html HTTP/1.0

POST /path/script.cgi HTTP/1.0
(and then the data)

and PUT and DELETE.

The browser must support the methods. It will not pass along just whatever.

That is exactly what the Unhosted project is all about:

http://www.unhosted.org/

"Unhosted web apps do not harvest user data onto a server. For both users and web developers this has many advantages over the more server-centric web 2.0 architecture that's typically used in web-based Software-as-a-Service (hosted web apps), and in same-origin AJAX apps (so called "one-page apps") that use one tightly coupled backend."

"Because unhosted web apps don't force the use of their servers on you, you can sync your data yourself, to a place that you trust. Dutch universities already run such a 'remote storage' service, specifically designed to be compatible with unhosted web apps."

"With your data living outside the app, you can switch back and forth between apps without even exporting and importing. Better than data liberation, this is personal data freedom brought to the web."

There is even a W3C specification:
http://www.w3.org/community/unhosted/wiki/RemoteStorage

... why doesn't the W3C make a browser (or a rendering engine) that implements 100% of the spec 100% perfectly? (No, Amaya isn't quite it.)

The semantic meaning of the element according to W3C's HTML5 draft is a paragraph-level tHematic bReak.

Right. HTML5 local storage is a fairly recent addition. You might also have been able to use a cookie with the "secure" flag set, which means the cookie is sent only over HTTPS connections, but AFAIK can be accessed in JavaScript code locally. I'm not certain whether such cookies are accessible through JavaScript that arrived over unencrypted HTTP, though, so that might not work.

Regarding cross-origin XHR, it's pretty straightforward. It works just like regular XHR. The only difference is that the server has to send out an Access-Control-Allow-Origin header to indicate that the browser should be allowed to make the request. And the browser makes two requests—a HEAD request to check the ACAO header and an actual request for the URL. As a small caveat, unless they have fixed it recently, Internet Explorer requires you to use a different object, XDomainRequest.

I believe both Firefox and Chrome have support for:

http://www.w3.org/TR/CSP/

Which allows for more control on where code should be loaded from.

Actually I think having crypto as part of the browser is a bigger chance of success then just implementing the crypto in Javascript as some people clearly have already done. You don't want to implement a cryptographically secure pseudorandom number generator in Javascript it will never be secure.

Basically it's for when your so paranoid that you fear even your cloud service app provider.

Maybe. The W3C draft lists "Cloud Storage" as one of its use cases, but remember that the app provider is also delivering the JavaScript that runs the decryption and loads up the DOM, so it could intercept the plaintext or decryption key if it wished. It doesn't protect against a malicious cloud service app provider, but it does make it easier for them to secure against data breeches (if their backups were stolen, for instance) and/or rely on 3rd party storage providers.

This has really interesting implications for online privacy, but the more practical/mundane benefits will be in reducing server CPU and making backend storage more secure.

You will create keypairs and exchange public keys via a web app. Via the API, you will be able to create digital signatures to help with user verification. This API is not being promoted as a silver bullet for security and privacy, however, when used in conjunction with other browser features like CSP ( http://www.w3.org/TR/CSP/ ) - and I imagine new browser features we still need to figure out (perhaps secure input and reading widgets), we hope to enable more secure web applications. I want to underscore that this API is just the first piece of the pie. Taming and being able to trust the DOM is not going to be easy.

I've already conceded that it is no longer supposed to be possible.

The point is that it's not a strong security technique. If you look at the first release of the spec you linked, you'll find that there is no mention of the Referer header, and according to the spec, the opposite behavior is what was specified, and that specification was in fact followed. Do some googling, you'll find many references to this working. And XMLHttpRequest came out in 1999, so it's spent most of its life in its insecure incarnation.

Even if relying on the server to not accidentally send malicious content based on a header that the client sent was a good idea, redefining a header from insecure to secure is an inherently bad idea.

You're also trying to argue both sides here, by saying that browsers need to deal in the real world, but at the same time they should make assumptions that could only be valid if every browser instantly followed specifications as they were released. In the real world, the header was redefined, and the redefinition caused years later as developers "missed spots" when securing it. In the real world, it's easier to create an entirely new header that is supposed to be secure from the beginning--if the header is there, you are safe to assume it's secure. If it's not, you don't have that security and can make an informed decision as to whether or not to continue. In redefining the header, they took that choice away and created a situation where you had to rely on browser sniffing to determine if you're dealing with the secure or insecure version of the header (although, in the real world, nobody bothered with that because it was so spectacularly difficult to get right). It's terrible security practice all around, and this should be obvious to anyone who's actually done development.

I invite anyone to provide an objective reason or reference to the same why this would not work in the "real world".

It didn't work in the real world, as evidenced by the years spent where referer spoofing was a common attack. Just because we slogged through and came out on the other side eventually doesn't mean that we couldn't have done better by taking the obviously better tack of creating a new header.

I personally think that we could do one better by not relying on any sort of referrer mechanism, but at the very least, saying the way it was done is the best way in light of the history of the issue is silly.

All in all, basing security on a header that was never secure is a dumb idea. Instead of redefining an old header, make a new one. This is security we're talking about, not opening a Word 97 document on Word 2008. If it's not secure, it should break, it shouldn't make a best effort.

Please see the specification which explicitly exempts Referer and a host of other fields in request from being user changable.

http://www.w3.org/TR/XMLHttpRequest

All in all, basing security on a header that was never secure is a dumb idea.

The browser is expected to moderate certain activity protecting the end user from an "anything goes" scripting environment.

There were security bugs that got fixed but I don't understand the assertion being made about this field never being secure. The specifications for xmlhttprequest seems pretty clear to me on the intent to protect this field.

If it's not secure, it should break, it shouldn't make a best effort.

You seem to be making a philosophical or political argument. While I respect your opinion no specification is perfect and people often don't have the luxury of always doing what "sounds good" on paper.

I invite anyone to provide an objective reason or reference to the same why this would not work in the "real world".

I suggested something like that 10 years ago: http://lists.w3.org/Archives/Public/www-html/2002May/0021.html
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html
But hardly anyone was interested. If implemented it could have prevented the Hotmail, MySpace, yahoo and many other XSS worms.

There's Content Security Policy now:
https://developer.mozilla.org/en-US/docs/Security/CSP/Introducing_Content_Security_Policy

As far as I see security is not a priority for the browser and W3C bunch.

If they are, then having them adopted by the W3C would mean having to give a royalty free license to those patents: W3C Patent Policy

because at some point, you need to say "good enough for version 1.0" and move forward with an implementation. google and firefox have already done this. should they back up and re-write their impls because someone came along with something better (on paper)?

If a browser is going to implement non-standard stuff, then yes they should rewrite it when the standard proves to be something different. If the roles were reversed and it was Internet Explorer that had the non-standard elements, then nobody would argue that their ideas should automatically adopted by the W3C just because they had already made the implementation.

there's always 2.0, and MSFT should be getting involved in the existing standard to influence the 2.0 effort to get the features they need.

But surely that is exactly what Microsoft are doing, except that the standard is nowhere near 1.0 so that is the milestone they want to influence. According to the WebRTC draft spec:

This document is the second working draft of the WebRTC specification, and is still subject to major changes that have been discussed but not yet incorporated in the specification (e.g. the inclusion of a data channel API, the JSEP signalling proposal and others). Since the previous draft, the getUserMedia API was moved into a document of its own [GETUSERMEDIA], and a number of clarifications were made.

While early experimentations are encouraged, the document is therefore not intended for implementation. The API is based on preliminary work done in the WHATWG. The Web Real-Time Communications Working Group expects this specification to evolve significantly.

So the W3C said that it was not ready to implement because it could change significantly. It seems to me that Microsoft are doing exactly what the process should be: identifying flaws in the existing spec and coming up with alternatives while it is still in the early stages.

Google's WebRTC proposal is very narrowly tailored, relies on stateful SIP, and is tied to their WebM video standard.

Microsoft's proposal is more flexible, stateless, simpler to implement, and is more "web-ish", eg: Relying on an exchange where my browser says "I can accept h264, webm, mpeg2" and the baby monitor says "I speak h264" so we use negotiated h264.

Basically Microsoft is saying that we should adopt a standard that makes it easy to interact with non-browser devices, phone/cell networks, etc. We should also make the API easier to use and stateless. The original WebRTC proposal is only concerned with letting Google+ users video-chat with other Google+ users and it shows.

I would urge you to go read the actual proposals before commenting on this:
Microsoft: http://html5labs.com/cu-rtc-web/cu-rtc-web.htm
Google's http://dev.w3.org/2011/webrtc/editor/webrtc.html

I would also point out that Microsoft is following the correct W3C procedure by making a proposal and asking for comments. In the past they would have just shipped it in IE and/or rolled it out automatically to all Windows users, thus making their standard the de-facto standard. We should reward this kind of participation and interaction, not condemn it.

I would also point out that Microsoft invented AJAX by just rolling out their own standard... the same way JSON was invented. Design by committee sucks in most cases and we'd be far better served by selecting from competing proposals or merging two competing proposals rather than requiring 15 people to sit down and agree on the definition of the draft standard of the proposal to consider altering the document title.