In most science, the evidence comes FIRST. Then you try to explain it
I referred to this as "some occurrence", and I did indeed describe it as coming first. However there is a difference between phenomena that need explaining and evidence gathered experimentally to test a hypothesis, which is why I didn't call the phenomena that need explaining "evidence", to contrast it.
To say you perform experiments to find evidence is misleading. Science is basically about trying to prove an idea wrong, rather than trying to find evidence that supports an idea.
Evidence can point in either direction. I didn't say that you look for evidence that supports an idea, I merely said that you look for evidence. You are mischaracterising what I said.
Saying reality as we know it is just a simulation is not falsifiable.
That is true of perfect simulations, where this theory looks for imperfect simulations.
Even if you come up with a clever test that would pierce the illusion, one would have to assume whoever maintains the illusion would simply fix it so that didn't work a second time.
Not necessarily. As a developer, when you run a bunch of testcases, if you find a bug, you don't halt everything in the debugger and fix the bug immediately, you just wait until it's all over, fix the bug, and re-start the test run. If this guy's theory is correct, then I would assume that any such flaws would persist until the end of our universe and then get fixed for the next one.
Personally, when I first read about the double-slit experiment, it reminded me of short-circuiting in if statements, so I can see the appeal of this line of thought. But I think it's silly to purposefully investigate it rather than simply wait and see what we can deduct from the ToE, if and when we figure it out.
Just because there is no currently workable theory for some occurrence, there is no reason to invent a wild explanation that just makes it go away.
Without some compelling proof (which he lacks) this is nothing more than a conversational topic over a bag of weed.
Er, that's exactly how science is supposed to work. You don't have a theory for some occurrence, so you invent an explanation, you don't have proof, so you perform experiments to get evidence.
I remember when Netscape introduced frames, they changed the netscape.com website to use them. It lasted a few months, then they realised how silly they were and changed their website back.
Silverlight may be good for embedded applets and for applications, but it's ludicrous to use it for an entire website. I expect that Microsoft will shortly figure this out.
OLPC produced a couple of semi-solid deals out of their usual fog of hype
The project was only announced in 2005! How can they have a "usual fog of hype"? Isn't two years to bring something like that to fruition pretty damn reasonable?
And, from what I've read before, it tests how browsers handle incorrect code as much as anything else
No. This is a persistent myth. Please stop repeating rumours you hear on Slashdot!
It's true that it tests how browsers handle incorrect code. That is one single aspect of the test. There's a hell of a lot more than that it tests. The erro-handling aspect is quite minor in comparison to the rest.
if it deals with errors correctly. I'd rather have it handle every bit of the spec correctly in the first place, and if it fails gracefully, that's nice too.
The error handling is part of the spec. It's not possible to "handle every bit of the spec correctly" without handling errors in this way. That's why it's in the Acid2 test — to test compliance with this part of the specification.
verifiable responses are preferred
Click the links you provided yourself. Read the technical guide. Note how rarely error handling is mentioned.
The problem is that as soon as the Acid2 test was announced, a bunch of newbie web developers went over to the validator and realised it wasn't valid. They then proceeded to repeat this ad nauseum until it was hammered into the Slashdot psyche that the Acid2 test was all about error handling. In fact, it's a tiny part of it, so please stop propagating this misinformation.
It'll also be nice it it handles transparent PNGs properly with nothing more than an <img> tag
Transparent PNGs worked fine from Internet Explorer 4 onwards. The problem you are referring to is non-binary alpha channel support, and that was already fixed in Internet Explorer 7.
No, Internet Explorer 7 fixed the most annoying bugs, and added PNG alpha channel support and CSS 2 selectors, but apart from the latter two things, there was virtually no change in its standards support.
Sure, and when Internet Explorer 9 rolls around, they'll use the fact that Internet Explorer 8 supports this old junk as an excuse to keep the proprietary behaviour around. And then when Internet Explorer 10 is released, they'll be telling us that they need to keep it because that's the way Internet Explorer 9 worked.
By the time Internet Explorer 8 is released, the CSS 1, 2 and HTML 4 specifications will all be a decade old. That's more than long enough to support behaviour that only existed because the specifications weren't published yet.
I haven't looked at it for quite a while, but at least for many years, the "CSE HTML Validator" wasn't actually a validator, but rather a linter that told you whether your document conformed to what the creator's personal opinions about good HTML were. Plenty of people pointed this out to him, so he stuck a little disclaimer in the FAQ and then complained when people kept pointing out that it wasn't a validator. Consider this Usenet thread for example, in which the creator attempts to defend the name, or this one where he defends himself against accusations of conning people.
Maybe he's finally incorporated a real validator these days, but given his attitude, I doubt it.
Microsoft actually made the first webbrowser with decent CSS support (IE3).
No, the first browser with decent CSS support was Internet Explorer 5 on the Mac, which used a completely different rendering engine to Internet Explorer for Windows. Internet Explorer 3 was the first major browser with any CSS support, but it was terrible; for instance, 1em was treated as 1px. Even Netscape 4 had better support for CSS than Internet Explorer 3.
Back then Netscape with their huge market share had no intent to support CSS.
To be fair, that was because they were betting on JSSS instead, which they submitted to the W3C, who chose CSS instead. So it's not like they eschewed a standard stylesheet language, it's just the W3C preferred CSS instead so they had to scramble to catch up with Netscape 4 by transcoding CSS into JSSS.
Lack of support [...] exclude the technology from practical use
This is exactly what I am arguing.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 2, Interesting
Not saying you are wrong, but why are there so many XSS issues if it is easy?
A combination of ignorance, apathy, and poor quality learning materials.
is there a "here is how to let your users make their comment pretty and link to other websites and not get hosed" FAQ?
Well the real answer to this is to point them to the sanitising features available for their particular platform/language/framework/etc. Generic advice is low-level by its very nature, for example XSS (Cross Site Scripting) Cheat Sheet or perhaps OWASP.
I'm a pretty smart guy, I think... at least open minded or something. I mean, at least I seem to know enough to worry about XSS issues but yet I dont find it easy at all. What am I missing here?
You're trying to do it yourself. Don't. Hand it off to a library.
Slashdot doesn't even do HTML filtering "elegantly". How can I type in those two fake tags as a comment AND quote you without escaping the brackets myself? I dont think this is as easy of a problem to solve as you think it is:-)
Slashdot is a mess all around, a lot of their problems are because their design strategy seems to be "accumulate features over time, never refactor, offer options instead of taking away obsolete features or being non-backwards-compatible". I mean, they have three different commenting systems, three different display systems and three different comment formats. That's hardly something to emulate. Having said that, they are probably one of the highest targets around for crapflooders, and they won that battle conclusively, which is clear evidence that it's not impossible to sanitise input. Slashcode is open-source, if there were a gap in its sanitation procedure, then Slashdot would quickly be overrun by trolls screwing up every page.
If you want to handle situations like this, then normalise the code, and escape every tag not on the whitelist. But the feature itself isn't really ideal because the user expectation of their comments being markup-but-not-in-some-cases is confusing.
I've just checked by loading up Firebug to monitor and clicking around on Google Maps for a while, and it didn't use XMLHttpRequest at all. The basic functionality is done by dynamically loading and positioning images. I'm sure there are parts of the API available through XMLHttpRequest, but the major functionality and what it is famous for is not done with XMLHttpRequest as far as I can see.
Re:No standard without reference implementation
on
HTML V5 and XHTML V2
·
· Score: 2, Informative
The worst thing about W3C standards is the lack of a reference implementation.
For a few years now, the W3C publication process has included an additional final step. It is not possible for a specification to reach final Recommendation stage unless it has two complete interoperable implementations.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 1
Your implication is basically that web-developers are more competent in terms of security than those who design the clients
Not at all. I expect the web developers in both cases to hand off the problem to third-party code. I just think that server-side code that has been maturing for a decade fills the role better than non-existent client-side code.
Also, you're not looking at this from the point of view of the user. I might want to tell my browser to trust John Smith not to put malicious stuff into his webpage, but that doesn't mean I trust him to be capable of finding all known and unknown exploits some of the third parties may have sent him. In this situation I would very much appreciate it if John Smith had marked the data on his webpage saying "this is from me" , "this is from somebody else".
If you don't trust John Smith's judgement, then that's not going to save you. For instance, JavaScript provided by him could be tricked by the untrusted content into doing what they want, and the attack would succeed because the JavaScript would be marked as coming from John Smith and therefore trusted.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 1
It look three tries (and three fucking functions) for PHP/mysql to get their escape code right and I'm sure you can still inject SQL with "mysql_real_escape_string()" in some new unthought of way.
Escaping SQL isn't even close to the same problem. In that case, you virtually always want the user-submitted data to be treated as opaque data. The analogous situation with HTML would be escaping all the HTML and displaying it as raw code to the end user. The problem being talked about here is when you do actually want the HTML to be partially rendered. And really, PHP's approach to SQL has always been pathological.
How many ways can you make an angle bracket and have it interpreted as a legit browser tag? How many ways can you inject something to the end of a URL to close the double quote and inject your javascript? How many ways, including unicode, can you make a double quote? Dont forget, your implementation cannot strip out the Unicode like I've seen some filters do - I need the thing to handle every language! I would guess there are thousands of known ways to inject junk into your trusted HTML.
Remember, you are normalising this to a valid subset of HTML first. I think virtually all the attacks you describe only work when you are treating it as tag soup, with the exception of Netscape 4's well-known, long-fixed Unicode bugs. Can you give any examples of valid HTML that is misparsed by a maintained browser in an insecure way?
Don't kid yourself and thinking filtering user generated content is easy. It is very, *very* hard.
It's a hell of a lot simpler if you normalise to a valid subset of HTML.
That's one of them, yes. It really depends on what you want to do; for example you don't need anything other than typical mousedown event handlers for things like Google Maps, and you can use things like dynamically generated image URIs to send data back to the server asynchronously, which is compatible all the way back to Netscape 2. There are lots of options, the value in XMLHttpRequest is more convenience than functionality.
now hear this folks! it wasn't ford, dimler and benz that should be praised for the automobile. it's the people that use them.
One of my points was that XMLHttpRequest was never the only option for Ajax-like effects. It just happens to be the most convenient. Your analogy simply doesn't work.
stop being such a google shill.
If you had ever read my previous comments concerning Google you would know that I am in no way a shill for them; in fact I think the quality of their client-side code sucks and have said so many times.
Please re-read the original comment. It was saying that you can use JavaScript without being backwards-incompatible. You seem to have confused this with avoiding JavaScript altogether. Every single point you make is good against an argument that JavaScript should be avoided, but completely irrelevant to somebody asking for it to degrade gracefully, which is the distinction BlueParrot was trying to explain to you.
you ever use anything with ajax? i.e. u like google maps? u can thank MS for bringing that out of javascript...
Ajax-like techniques are possible without XMLHttpRequest and I don't believe Google Maps uses XMLHttpRequest anyway. If any organisation is responsible for the popularity of Ajax, it's Google, as it was when they started using it extensively that it really took off.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 1
While it is true that the server should validate the inbound (and really outbound) HTML, you have to admit it isn't easy.
On the contrary, it's very easy. There's plenty of tools out there to do this for you.
In perl land, there are some CPAN modules to help, but none of them ever feel right.
What do you mean by "feel right"?
I think the OP's idea was for a couple extra "hey Mr. Browser, yeah, we suck about validation... please dont trust this crap here.. we tried our best on the server, but really, you shouldn't trust it either".
What do you think the browser is going to do that you can't?
Those are not XHTML.
That was what I thought.. just guessing. MathML or whatever? I'm not sure, but does IE do that?
That's not XHTML either. Once more, XHTML 1.1 is XHTML 1.0 broken up into modules. The OP wanted to be able to specify permitted features of XHTML in a fine-grained manner. XHTML 1.1 defines modules you can use, or you can define your own DTD. Stop thinking about non-XHTML features like Atom and MathML! This is about normal XHTML like <script> , <table> , etc.
Technologies like SVG and MathML are XML-based, so there is a big advantage to having xhtml support in browsers
Yes, but the advantage is only there if you give up on Internet Explorer compatibility or put in a lot of extra work by coding an additional Internet Explorer version without SVG and MathML, i.e. the version you are supposedly skipping by using XHTML.
Because MS doesn't support xhtml, SVG and MathML have basically been killed as practical browser technologies.
Yes, so you can't really count them as advantages XHTML brings, can you?
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 1
this new XHTML modular thingy we are talking about would still need to be supported by the browser, right?
No. If the server validates the untrusted data, what's the point in the browser doing it too? Validation is deterministic, you don't get double the security by doing it twice.
Can you name any existing XHTML modules implemented by both browsers?
All of them. XHTML 1.1 is XHTML 1.0 Strict broken up into modules.
HTML 5 has two serialisations, a quasi-HTML serialisation and an XML serialisation.
XHTML "failed" to replace HTML because it satisfies the needs of professionals to have a standardized approach to minimize cross-browser issues, but lacks the simplicity needed for amateurs and lousy professionals.
XHTML failed to replace HTML because a browser with a dominating market share doesn't support it and using it in a backwards-compatible way confers very few advantages over HTML and none whatsoever for typical developers.
Slashdot Mirror
I referred to this as "some occurrence", and I did indeed describe it as coming first. However there is a difference between phenomena that need explaining and evidence gathered experimentally to test a hypothesis, which is why I didn't call the phenomena that need explaining "evidence", to contrast it.
Evidence can point in either direction. I didn't say that you look for evidence that supports an idea, I merely said that you look for evidence. You are mischaracterising what I said.
That is true of perfect simulations, where this theory looks for imperfect simulations.
Not necessarily. As a developer, when you run a bunch of testcases, if you find a bug, you don't halt everything in the debugger and fix the bug immediately, you just wait until it's all over, fix the bug, and re-start the test run. If this guy's theory is correct, then I would assume that any such flaws would persist until the end of our universe and then get fixed for the next one.
Personally, when I first read about the double-slit experiment, it reminded me of short-circuiting in if statements, so I can see the appeal of this line of thought. But I think it's silly to purposefully investigate it rather than simply wait and see what we can deduct from the ToE, if and when we figure it out.
Er, that's exactly how science is supposed to work. You don't have a theory for some occurrence, so you invent an explanation, you don't have proof, so you perform experiments to get evidence.
I remember when Netscape introduced frames, they changed the netscape.com website to use them. It lasted a few months, then they realised how silly they were and changed their website back.
Silverlight may be good for embedded applets and for applications, but it's ludicrous to use it for an entire website. I expect that Microsoft will shortly figure this out.
The project was only announced in 2005! How can they have a "usual fog of hype"? Isn't two years to bring something like that to fruition pretty damn reasonable?
No. This is a persistent myth. Please stop repeating rumours you hear on Slashdot!
It's true that it tests how browsers handle incorrect code. That is one single aspect of the test. There's a hell of a lot more than that it tests. The erro-handling aspect is quite minor in comparison to the rest.
The error handling is part of the spec. It's not possible to "handle every bit of the spec correctly" without handling errors in this way. That's why it's in the Acid2 test — to test compliance with this part of the specification.
Click the links you provided yourself. Read the technical guide. Note how rarely error handling is mentioned.
The problem is that as soon as the Acid2 test was announced, a bunch of newbie web developers went over to the validator and realised it wasn't valid. They then proceeded to repeat this ad nauseum until it was hammered into the Slashdot psyche that the Acid2 test was all about error handling. In fact, it's a tiny part of it, so please stop propagating this misinformation.
Transparent PNGs worked fine from Internet Explorer 4 onwards. The problem you are referring to is non-binary alpha channel support, and that was already fixed in Internet Explorer 7.
No, Internet Explorer 7 fixed the most annoying bugs, and added PNG alpha channel support and CSS 2 selectors, but apart from the latter two things, there was virtually no change in its standards support.
Sure, and when Internet Explorer 9 rolls around, they'll use the fact that Internet Explorer 8 supports this old junk as an excuse to keep the proprietary behaviour around. And then when Internet Explorer 10 is released, they'll be telling us that they need to keep it because that's the way Internet Explorer 9 worked.
By the time Internet Explorer 8 is released, the CSS 1, 2 and HTML 4 specifications will all be a decade old. That's more than long enough to support behaviour that only existed because the specifications weren't published yet.
It looks at the doctype. If it's missing or an old doctype, it uses "quirks mode". If it's unrecognised or a modern doctype, it uses "standards mode".
I haven't looked at it for quite a while, but at least for many years, the "CSE HTML Validator" wasn't actually a validator, but rather a linter that told you whether your document conformed to what the creator's personal opinions about good HTML were. Plenty of people pointed this out to him, so he stuck a little disclaimer in the FAQ and then complained when people kept pointing out that it wasn't a validator. Consider this Usenet thread for example, in which the creator attempts to defend the name, or this one where he defends himself against accusations of conning people.
Maybe he's finally incorporated a real validator these days, but given his attitude, I doubt it.
Nitpick: You can omit the XML prolog when you are using XML 1.0 and either the UTF-8 or UTF-16 character encoding.
No, the first browser with decent CSS support was Internet Explorer 5 on the Mac, which used a completely different rendering engine to Internet Explorer for Windows. Internet Explorer 3 was the first major browser with any CSS support, but it was terrible; for instance, 1em was treated as 1px. Even Netscape 4 had better support for CSS than Internet Explorer 3.
To be fair, that was because they were betting on JSSS instead, which they submitted to the W3C, who chose CSS instead. So it's not like they eschewed a standard stylesheet language, it's just the W3C preferred CSS instead so they had to scramble to catch up with Netscape 4 by transcoding CSS into JSSS.
This is exactly what I am arguing.
A combination of ignorance, apathy, and poor quality learning materials.
Well the real answer to this is to point them to the sanitising features available for their particular platform/language/framework/etc. Generic advice is low-level by its very nature, for example XSS (Cross Site Scripting) Cheat Sheet or perhaps OWASP.
You're trying to do it yourself. Don't. Hand it off to a library.
Slashdot is a mess all around, a lot of their problems are because their design strategy seems to be "accumulate features over time, never refactor, offer options instead of taking away obsolete features or being non-backwards-compatible". I mean, they have three different commenting systems, three different display systems and three different comment formats. That's hardly something to emulate. Having said that, they are probably one of the highest targets around for crapflooders, and they won that battle conclusively, which is clear evidence that it's not impossible to sanitise input. Slashcode is open-source, if there were a gap in its sanitation procedure, then Slashdot would quickly be overrun by trolls screwing up every page.
If you want to handle situations like this, then normalise the code, and escape every tag not on the whitelist. But the feature itself isn't really ideal because the user expectation of their comments being markup-but-not-in-some-cases is confusing.
I've just checked by loading up Firebug to monitor and clicking around on Google Maps for a while, and it didn't use XMLHttpRequest at all. The basic functionality is done by dynamically loading and positioning images. I'm sure there are parts of the API available through XMLHttpRequest, but the major functionality and what it is famous for is not done with XMLHttpRequest as far as I can see.
For a few years now, the W3C publication process has included an additional final step. It is not possible for a specification to reach final Recommendation stage unless it has two complete interoperable implementations.
Not at all. I expect the web developers in both cases to hand off the problem to third-party code. I just think that server-side code that has been maturing for a decade fills the role better than non-existent client-side code.
If you don't trust John Smith's judgement, then that's not going to save you. For instance, JavaScript provided by him could be tricked by the untrusted content into doing what they want, and the attack would succeed because the JavaScript would be marked as coming from John Smith and therefore trusted.
Escaping SQL isn't even close to the same problem. In that case, you virtually always want the user-submitted data to be treated as opaque data. The analogous situation with HTML would be escaping all the HTML and displaying it as raw code to the end user. The problem being talked about here is when you do actually want the HTML to be partially rendered. And really, PHP's approach to SQL has always been pathological.
Remember, you are normalising this to a valid subset of HTML first. I think virtually all the attacks you describe only work when you are treating it as tag soup, with the exception of Netscape 4's well-known, long-fixed Unicode bugs. Can you give any examples of valid HTML that is misparsed by a maintained browser in an insecure way?
It's a hell of a lot simpler if you normalise to a valid subset of HTML.
That's one of them, yes. It really depends on what you want to do; for example you don't need anything other than typical mousedown event handlers for things like Google Maps, and you can use things like dynamically generated image URIs to send data back to the server asynchronously, which is compatible all the way back to Netscape 2. There are lots of options, the value in XMLHttpRequest is more convenience than functionality.
One of my points was that XMLHttpRequest was never the only option for Ajax-like effects. It just happens to be the most convenient. Your analogy simply doesn't work.
If you had ever read my previous comments concerning Google you would know that I am in no way a shill for them; in fact I think the quality of their client-side code sucks and have said so many times.
Please re-read the original comment. It was saying that you can use JavaScript without being backwards-incompatible. You seem to have confused this with avoiding JavaScript altogether. Every single point you make is good against an argument that JavaScript should be avoided, but completely irrelevant to somebody asking for it to degrade gracefully, which is the distinction BlueParrot was trying to explain to you.
Ajax-like techniques are possible without XMLHttpRequest and I don't believe Google Maps uses XMLHttpRequest anyway. If any organisation is responsible for the popularity of Ajax, it's Google, as it was when they started using it extensively that it really took off.
What do you mean by "feel right"?
What do you think the browser is going to do that you can't?
That's not XHTML either. Once more, XHTML 1.1 is XHTML 1.0 broken up into modules. The OP wanted to be able to specify permitted features of XHTML in a fine-grained manner. XHTML 1.1 defines modules you can use, or you can define your own DTD. Stop thinking about non-XHTML features like Atom and MathML! This is about normal XHTML like <script> , <table> , etc.
Yes, but the advantage is only there if you give up on Internet Explorer compatibility or put in a lot of extra work by coding an additional Internet Explorer version without SVG and MathML, i.e. the version you are supposedly skipping by using XHTML.
Yes, so you can't really count them as advantages XHTML brings, can you?
It's not an idea, it's been a published Recommendation for over six years.
No. If the server validates the untrusted data, what's the point in the browser doing it too? Validation is deterministic, you don't get double the security by doing it twice.
All of them. XHTML 1.1 is XHTML 1.0 Strict broken up into modules.
Those are not XHTML.
HTML 5 has two serialisations, a quasi-HTML serialisation and an XML serialisation.
XHTML failed to replace HTML because a browser with a dominating market share doesn't support it and using it in a backwards-compatible way confers very few advantages over HTML and none whatsoever for typical developers.