Slashdot Mirror
Security a Concern As HTML5 Advances
Trailrunner7 writes "Every technology innovation has its coming out party, and Google Inc.'s recent 'dancing balls' logo experiment was widely interpreted as a high-impact debut for HTML5. But web security experts are warning that the sprawling new web standard may favor functionality over security, enabling a new generation of powerful web-based attacks. They agree that there are security enhancements in HTML5, but all expressed the same concern: that the new specification will greatly increase the 'attack surface' of HTML — providing more avenues by which malicious code can be delivered through the web. 'HTML5 has an enormous amount of functionality. The (specification) is just huge,' said Jeremiah Grossman of security firm WhiteHat. The breadth of the new specification gives him concern. 'I know that we're still finding vulnerabilities in HTML4,' Grossman said."
should also complain about a hyperText markup language document with scripts
But I'm really sick of hearing about HTML5. Maybe it's because every other day I see/hear a high level exec coming around and going crazy with statements like "HTML5 IS THE FUTURE WE HAVE TO BE ON IT. RIGHT NOW." Then I have to spend an hour explaining why it's not even currently usable for any serious enterprise application, and how the spec is not yet solidified.
The entire disarray of this, and the mobile space, makes up upset.
"Google Inc.'s recent 'dancing balls' logo experiment "
If that's a sing of what's coming in HTML 5, I don't want it. That stupid thing dragged my machine to a crawl and I had to be sure I didn't have any google tabs open.
The last thing I want is for more &*^%*() CPU-hogging crap to be added to the friggin' web.
web security experts are warning that the sprawling new web standard may favor functionality over security, enabling a new generation of powerful web-based attacks.
MS will Embrace and Extend, but not Extinguish the potential for security holes.
Apple will probably do much the same, but might do the enhanced functionality bit also.
The BSD and *nix variants will only take on the functionality, most foolishly (using MBA "forced-upgrade-income" definition).
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
While I'm sure some of the new functionality will be exploited, I expect most of the abuse will be from folks who want to push ads and track users.
Where can we find this 'dancing balls' logo experiment? Link please. I did a search but came up with nothing.
Google's "dancing balls" wasn't HTML5, it was divs, javascript and CSS border radius.
When HTML spec is extended that obviously increases the attack surface since popular browsers will have to support it. But in time it may replace a number of other technologies (Flash comes to mind), that -combined- may have a larger attack surface. And since displaying HTML is the core function of a browser, implementations are likely to be pretty solid compared to some add-ons.
So you'd have to look forward, and compare [average setup now] with [average setup in XX years from now]. If that comparison turns out positive, HTML5 is a move in the right direction.
stop using technology
Wow, who would have thought of that? Yes I do understand that security is an issue hard to cope with, but with that mentality we could also just stop progress because it might have risks ...
How are the "concerns" over HTML5 any different than any other platform? Flash, ASP, javascript, etc have all had and continue to have vulnerabilities. The only way to stay 100% safe is to stay off the internet. Did anyone expect people who make their living by addressing both real and imagined security risks to not comment with an angle that puffed up their importance in the net ecosystem?
i didn't see them! is there a link where that still exists, or perhaps a video?
weinersmith
The article points out no specific flaws. It just says that HTML is growing, therefore the chance of a hole (the "attack surface") also is growing.
Choose your poison. The same can be said about writing an app for an operating system. "Windows/Mac OS/Linux has an enormous amount of functionality. Therefore I'm concerned that there could be a lot of vulnerabilities."
Yes.
But the growth of the browser will not simply add to the overall size of the computer. Because of a big browser, you may have a smaller operating system. This is the idea behind Chrome OS.
It is not a perfectly equal replacement. If the browser grows 15 MB, that does not mean the operating system will shrink 15 MB. But one thing that is better about putting a feature in the browser is that more eyes are on it. There will be a lot more users who try to write a program in JavaScript than against even the Windows, even the iPhone, API. HTML 5 will bring about a lot more software developers and a lot more software development.
Seriously, sandboxing is in almost every browser by default now, you wouldn't even need to run external ones.
But if you want to be safe from pretty much every useful attack out there, just run the damn thing in a sandbox / virtual OS.
Pardon me, I meant flashblock
said Jeremiah Grossman of security firm WhiteHat.
So you really need to buy their security solutions! NOW! Meanwhile, Goodyear tires said to really safe on the road (and to keep your CHILDREN! safe) you should get new tires every 5000 miles, and the Head & Shoulders folks claim washing your hair three times a day will avoid a stinky head. And the government said they taking blood and tissue samples at the airport will protect us from engineer^H^H^H^H^H^H terrorists ever more so.
It's true that the HTML5 spec is huge on functionality but they've put in some very simple Unix type philosophies to achieve security.
The suggestion should not be to decrease HTML5 functionality - the web can't stand still on that - but to increase focus on and mitigate security threats through more policies in the HTML5 spec.
The increased functionality also allows developers to do away with some crazy workarounds (read security loop holes) to get some generally expected experiences on their web page.
Plus, as it has been pointed out earlier, the surface area for Flash and other plugins will also come down. So while the net surface area for attacks increase, the implementations are going to be a lot more secure by design.
.. isn't an increase in functionality and thus the addressable attack area natural evolution of any technology ?
The Modern Techie will now by definition reject all new technology no matter what advancements are in it. While adopting any new technology will have tradeoffs the modern will hold on to whatever tradeoff negative effect and call it a horrible plan. Any new tech is now a threat to their way of life and no longer a new interesting field to study...
I think us techs have gotten too old.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Pardon me, I meant flashblock
Stop drinking the Apple-hate koolaid.
Something like NoScript or an add-in could emulate Flashblock for video/audio in HTML5. And that's assuming the browser developers don't add that directly into the browser settings.
Audio/visual info playing only when clicked is not a hard problem to solve.
For myself, having to use jQuery and always be mindful of the variation in scripting code for each browser is the headache neverending. I want to see more HTML5 (and then 6) integrate more of the features and functions users are coming to enjoy and demand. Then, we only have to worry and complain about the browsers not implimenting the standards...like always.
jsut athnoer menagiensls ltitle psrhae for you to dcoede. Why do we wtsae our tmie dnoig tihs?
CERT® Advisory CA-2012-01 HTML5 Vulnerability ... we recommend disabling HTML until the fix is installed.
Shock! The attack surface is proportional to the amount of functionality offered! Ergo, we can build more secure applications by eliminating functionality!
I have a lot of respect for the security community, but sometimes they confuse the newsworthy with the merely obvious.
Proud member of the Weirdo-American community.
Let me start out by reminding everyone that when Netscape came up with Cookies, everyone thought they were fine. Now, thanks to 1 pixel images and other tracking methods, cookies are the key to online companies aggregating bits of "anonymous" data into an identifiable profile of a person. Does Google know only as much about you as you would like? In fact, they know far more about you than you would expect, even if you don't use GMail.
The single biggest shot across the bow to privacy in HTML5 is the ping attribute. It may seem innocuous at first glance, but according to MozillaZine, it sends an HTTP POST request to each url. Why not GET instead?
This will allow Google, Alexa, FaceBook, or any "partner" to track users, if a site implements ping, easier than ever before. Some say trackers will migrate away from redirect URLs, but I say they will do both, if only to sop up every last piece of data they can.
I can see ping being used as a stealth DDOS attack, if enough malicious links can be distributed. Some content provider web API gets hacked, thousands of sites load up links (via AJAX) that ping slashdot.org, and Slashdot goes down. Will ping implementations be smart enough to reduce the list of URLs down to unique values? How many times does ping="slashdot.org slashdot.org/foo slashdot.org/comments.pl slashdot.org/article.pl" actually hit the poor, unsuspecting server? There's no apparent limit to how many URLs can be stuffed into a single ping, either.
I'm sure the black hats will think of other ways to exploit this. I agree that tools are neither evil nor good, but this is ripe for unintended consequences.
Is that the more core to the spec it is, the less you can do to mitigate it. With Flash there's a simple solution: Block it. You can use a plugin like Flashblock that allows you to run it only as needed, you can set it to only run on some sites, or you can shut it off entirely. It is easy to restrict access to it when ti isn't needed and thus increase security.
When the features are in HTML itself... Well then what do you do?
let Doug Crockford lead a new draft committee. he seems to be competent to do it right.
Thanks Apple.
All because you wanted to be greedy and only let media be delivered through you, instead of other websites being able to deliver it.
So instead of being able to use adblock, to block malware and only view video when we chose, we're screwed. We have no recourse.
I saw this coming a mile away the second Apple fanboys began defending Apple's position.
So your basic premise is:
1. Apple wants to control all media everywhere
2. Apple supposedly creates HTML 5, a standard that it doesn't control
3. Apple somehow gets Google and a bunch of other organizations it doesn't control to implement the standard that it doesn't control. You know, because Google and the rest want to help Apple control everything
4. ???
5. Profit (for Apple, obviously, and maybe Google, and...Microsoft?)
6. This is all Apple's fault.
if an idiot developer wants to make an application in an insecure way, the platform can not stop them.
I find your statement ambiguous. Did you mean that in the sense of the web browser as an application and a device's operating system as a platform? Or did you mean it in the case of a web app as an application and the web browser as a platform? The article, as I understand it, is about the latter sense.
Just because a spec isn't finalized doesn't mean some of the feature haven't been implemented. You can find what's been implemented and just maybe, impress your boss.
The web page you linked is an example of what can go wrong with HTML5 in the wrong hands: it ends up just like Flash in the wrong hands has ended up for years. Not only does it use mystery meat navigation, but it also takes literally four seconds from when I move the pointer to when another wedge of the graph lights up. I'm using the latest release version of Firefox (3.6.10) on Windows XP.
It doesn't even contain any code, being a markup language? It's not even Turing complete.
[italic attribute="question"]Is this invented markup language of mine also vulnerable?[/italic]
*shrug*
Beware: In C++, your friends can see your privates!
Implementing stuff before the spec is finalized. That just seems weird. :P :)
A proper spec isn't finalized until a reference implementation is ready. One of the reasons that some of the HTML 4.01 features never entered wide use is that absolutely nothing supported them correctly for years after HTML 4.01 became a W3C Recommendation. Take the <col> and <colgroup> elements for example; those still aren't consistent even in browsers that do support them.
Browsers, IM tools, Skype, and other such tools should ALWAYS run under very restrictive permission levels. I don't need my browser writing anywhere on my computer except for maybe one folder (usually). I don't need it changing the registry. I don't need it to be able to unsandboxed execute code.
So keep it isolated using permissions. That is the the last line of defense against malicious sites.
That would solve a great number of problems.
You misread the summary; the article is not about an idiot developer building an insecure application that compromises the developer's server's security. It's about malicious developers building seemingly benign websites that compromise a user's home computer
if the platform implements something insecurely, then relying on that implementation is not building a secure application... it doesn't mean that a secure application can not be built on that platform.
As far as I know, formal verification of the security of a computer program as large as a platform is nowhere near prime time. This means you can't be sure that any platform implements every necessary feature 100% securely, and relying on any implementation is not building a secure application, unless perhaps your application requires so few platform features that it would work in HTML 1.0.
.except when a Flash page behaves the same way. See Pandora for example: it's one big applet
Typically, only media players (such as Pandora) and corporate brochureware (such as Pop-Tarts.com) act that way. Other sites have accessibility concerns that preclude putting the whole site in an SWF.
I disagree. For example:
1. System has ability to delete your files.
2. System loads file from the Internet. File from the Internet contains instructions.
3. System is designed to accept delete() instructions from users, but not from files downloaded from the Internet.
My idea for quite some time is that in the long run, all file formats become programming languages. A web page should have always been regarded as an application that is sandboxed by the browser, even before we started building apps with them.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
security is built in the application just as malice is built in the application. the platform is irrelevant.
I don't get it, are we all that paranoid,
Naturally we favor functional above secure
oh wait, security experts.
Fuck them
I'm not an expert of any kind, but my general concern with the web has been growing as static documents have become applications. It's the same reason I don't like the idea of javascript in PDFs. I like the idea of a static document that doesn't do anything, but is merely viewable. Yes, yes, I know that it's possible for malformed documents to trigger exploits in the document viewer, but that seems like it should be more rare and easy to protect against.
At you upgrade HTML to make web applications more and more powerful, it seems likely to me (from a non-expert standpoint) that you're increasing the variety of security concerns we need to worry about. There's a part of me that wishes we had two different things: a web browser that allowed for safe passive viewing of relatively static content, and an application that supported an application framework similar to current web applications.
Ok, I'm ready for people to yell at me for being stupid now.
Give me a break. You'd rather lash yourselves to Adobe rather than the open HTML5 standard?
Besides, there will be an adblock for HTML5 eventually. There's no structural limitations on it.
And yet again, you still miss the point. The article states that the scope of HTML5 is so huge, that it will be difficult for browser developers to fully secure their browser against exploits. The scope of HTML5 makes securing the browsers more difficult, and as a counter point, they compare it against HTML4, which was far simpler, but exploits are still being found to this day.
This in no way suggests that HTML5 sucks or is evil, it is just something that people need to consider.
Unless in your original point, by developer you meant Firefox, Chrome, Opera or IE dev teams and by application you meant the aforementioned browsers, then your point was, at best, vague.
oh really? new tech new problems!
who would have thunk it!
Nothing to see here people, please move along.
oh really? new tech new problems!
alert(1)
Effectively there is a need for web browsers to isolate different parts of the page from each other.
A look into what Netscape had earlier with "Data Tainting" and also the "Same Origin Policy" should be considered, which would limit the interaction between content with different origin.
Another catch is the thread based model in applications (mostly a problem for C and C++ applications) instead of a process based model where interprocess communication has to be defined stricter. Any coding mistake in a thread based coding can cause one thread to trample unhindered into areas of another.
New functionality means a range of new interesting bugs.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
No there won't. Flash was a singular fixed object. HTML5 is an entire markup.
Let me know how easy it is to block every and on each page. Let me know how that works out for ya
so the HTML5 spec includes the requirement to delete any file on the host file system?
this has absolutely nothing to do with HTML5 as a platform layer spec or as a platform layer implementation... this has everything to do with furthering an acceptance and expectation of incompetent developers.
you are all idiots.
Pretty easy actually. About as easy as blocking gifs
I was just using file delete as an example of something that a system must be able to do; but that you don't want being done at the request of an arbitrary application.
Perhaps window creation would have been a better example. I don't know how HTML5 is put together. I would hope that creation of new windows outside the frame of the existing browser (ie, popups) would be easy enough to trap in the browser and subject to permissions.
A browser has to be capable of creating popups at the request of the user (otherwise how would you even set your preferences?) but it should be capable of limiting popup requests by anything under its process hierarchy.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
the new specification will greatly increase the 'attack surface' of HTML -- providing more avenues by which malicious code can be delivered through the web. 'HTML5 has an enormous amount of functionality. The (specification) is just huge
If HTML was an API, not only security would be handled much more easily, but the functionality could be enhanced and extended much faster...
an application implementation of the HTML5 platform layer is itself an application, and then the recursive confusion begins.
this is a MARKETING story... a smear campaign by the incumbents... completely ignorant and irrelevant.
I took "platform" to mean "operating system and its installed applications". I probably skimmed too quickly somewhere or something. If so, my bad, sorry. Hopefully that clears up any confusion about where the confusion over the confusion over what was confusing came from.
(foghorn-leghorn (Ahh say, that's a joke, son.))
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
We have all the functionality of a supercomputer sitting in more than a few machines as nVidia has so lovingly demonstrated with CUDA, Fermi and Tesla. Now we have the browser able to harness that hardware functionality via the DirectX and OpenGL API's. Should it be any surprise that given a new threat vector right into the heart of the machine with API's that are most definitely not designed with security in mind, that something bad can happen?
I'm just waiting for the hijack that takes over your graphics card and does SETI@Home or Folding@Home behind your back.
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
Believe me, there's a lot of security stuff in the HTML5 specs. Want to get an image from behind a firewall and AJAX the data out? The spec disallows it. (Nothing in the JS code makes it impossible--you can absolutely code it up. The only thing that stops you is the spec says a security exception must occur when the JS program attempts to access the pixel data.) That's just one example of many.
So, actually, the platform can stop security-unaware developers. Security is in both the platform and the app which runs upon it. In a later post, you say "if the platform implements something insecurely, then relying on that implementation is not building a secure application." This is true. But there's nothing stopping us from building a more secure platform, as well.
Like with SMTP, being built with implicit trust causes all kinds of problems with HTML/JS. Strides are being made, and specs are being produces by W3C to address the issues.
I have been engineering formally verified code for almost four decades now, it's part of my mental toolkit here. Frankly, I'm surprised that not everyone does it but given the sheer amount of buggy crap out there, I suppose I really shouldn't be surprised.
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
Which is what separates, in my not so humble opinion, software 'developers' from software engineers. Then again, if I fragged up and someone was hurt or died, or there was a large amount of damage, as a result of negligent software engineering on my part, I was going to a federal prison to be guarded by a bunch of pissed off Marines (who really don't want to be there in the first place!). "The prospect of being hanged in a fortnight concentrates the mind wonderfully."
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
when you have things like OpenID and facebook connect running rampant because THERE IS DEMAND, a "more secure platform" that disallows such things has no chance.
Demand for these things plays a role, sure, but nevertheless the HTML5 platform still makes an effort to enforce security policy below the JavaScript/HTML layer. See CORS, for instance, or the Same-Origin Policy.
eventually 2 distinct services will exists... at the same time the mutually inclusive users will develop a framework with the intent of utilizing both services within a new interface. which "origin" relative to either service does that new interface exist within? this story is pure marketing... slander from the incumbents
The killer feature of HTML 5 is the canvas which permits client-side drawing. Unfortunately, the only way to enjoy this rich functionality is by having JavaScript enabled. If memory serves, JavaScript was at the base of ALL serious security vulnerabilities in the recent past. Unfortunately as well, there is no other standardized way to provide this kind of interactivity (no, Flash is not a standard). So at some point, we're going to have to choose between limiting functionality (not an option), using a nonstandard solution (introducing cross-browser compatibility problems) and/or fixing the possible security holes. Originally JavaScript was pretty well thought-out, as scripts could only be included in the header of an HTML page. This at least made script injection in HTML pages impossible. We've got a fine company in Redmond to thank for allowing scripts in the body of HTML pages as well. Now that the can of worms has been opened, there's no way we're gonna be able to close it again. So this is a typical case where we're just going to have to deal with things. If security is an issue, don't allow JavaScript- and therefore, don't use the canvas tag.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Hum..."that the new specification will greatly increase the 'attack surface' of HTML — providing more avenues by which malicious code can be delivered through the web"
What specification ??
"greatly increase the 'attack surface' of HTML"
Omg. sounds horrible to me :(
Sounds like its gonna turn my browser into remote desktop with a blank password..oh shit!!
I have been engineering formally verified code for almost four decades now, it's part of my mental toolkit here. Frankly, I'm surprised that not everyone does it
I wrote under the impression that formal verification was at least an order of magnitude more expensive than the shortcut that Mozilla already uses: a spot-check (r= and sr=) and an automated test suite. Revenue from home PC software, whether paid for by users or by advertisers, isn't enough to cover formal verification of anything except possibly a few low-level operating system components. So instead, they use the shortcut and offer the software with ABSOLUTELY NO WARRANTY, as seen in any free software license or any proprietary COTS software EULA. The license of some software, such as the Java player, even has a specific disclaimer against using the product for systems where a failure could cause loss of life. So the YET to which the subject of your comment alluded will need a breakthrough in efficiency of formal verification.
(...) the sprawling new web standard may favor functionality over security, enabling a new generation of powerful web-based attacks.
Well, duh. But does that mean that we should keep all development at a standstill, just because that means that there won't be any more new attacks? Of course not.
I am not devoid of humor.
Wow. What wonderful universe did you just slide in from? This one sucks ass *and* balls, dude. Slide back out as soon as you can, because this one is toxic as all hell.
Newsflash: smart people can crack the platform and find insecurities at that level.
I am not devoid of humor.
the mention of HTML5 in such a story is irrelevant and the product of a marketing smear campaign run by the HTML vendor incumbents.
just because a specific group of developers working on a specific implementation of a specific platform layer spec can't securely implement that spec, does not imply anything other than the group of developers is incompetent.
How so? The developers should be following the security policy as defined by the spec, also the spec defines such things as when and where security exceptions should be raised, which is what a spec should do.
it's not about flaws in the spec creating exploit potential... it's about flaws in the implementation of the spec creating exploit potential. if you can't understand the difference, you're an idiot. i can't help you.
it's not about flaws in the spec creating exploit potential... it's about flaws in the implementation of the spec creating exploit potential. if you can't understand the difference, you're an idiot. i can't help you.
No, actually i understand that it's BOTH. And if you can't understand that then you're just an epic fail.
you are NOTHING.
a platform allowing interfaces to tie multiple services together is not a flaw in the platform... ignorant users trusting malicious service providers is not a flaw in the platform.
I never said they were. But the platform spec is much more than that, it includes security policies, which you would know if you'd actually read it.
Security is a part of BOTH the platform implementation AND spec, inherent flaws in the spec can lead to exploits in the implementation regardless of the platform which is precisely why the specification includes the security exceptions and security policies. Pretty obvious.
i understand you are BOTH ignorant and hypocritical.
exactly how am i hypocritical? just because i don't agree with you doesn't mean im ignorant and your use of that as an argument just shows how little you know about the subject matter. when you're trying to sway people to your way of thinking the method of 'im right and if you can't understand that you're an idiot' simply shows that you think you're right but have no idea why.
you are NOTHING.
lol, what are you replying to then? All you're giving out is baseless personal attacks, you have no facts so the more you post the stupider you look.
what you really have a problem with is such users existing and demanding such "inherently exploitable" interfaces.
as long as you continue to argue about the argument instead of providing facts, you will continue to be NOTHING
what flaws in the HTML5 spec can lead to exploits that users of modern web based applications which tie multiple secure external services together don't already require?
Im not saying there specifically are any, but that there certainly is scope for them, which is exactly what TFA is about. Hence the reason we have security policies in the spec, otherwise they wouldn't exist. So security is a part of BOTH the spec AND implementation.
what you really have a problem with is such users existing and demanding such "inherently exploitable" interfaces.
So what you're saying is that the W3C are developing an inherently insecure platform spec because it's what people demand? Those potential exploits - which is what TFA is referring to - are closed by properly defining security policies that implementations follow.
as long as you continue to argue about the argument instead of providing facts
The facts are right there in the spec, the security policies. These are there to prevent implementation-agnostic security exploits.
you will continue to be NOTHING
Patently false, otherwise you wouldn't be reading this. Your reply will prove yourself wrong.
Im not saying there specifically are any...
i'm done.
you're an idiot... once again pushing your ignorance and hypocrisy and then ignorantly and hypocritically claiming you don't, all the while demanding for facts concerning a point that has already been proven, implying facts exist to disprove that point, but then conceded you can offer no such facts.
you PROVIDE nothing, THUSLY...
you are NOTHING
i'm done.
Yet im fairly confident you'll reply...again.
you're an idiot... once again pushing your ignorance and hypocrisy and then ignorantly and hypocritically claiming you don't
Again, you fail to use with your use of the term 'hypocrisy', in no way is anything i said hypocritical. I told you there are security policies in the spec and the reason for them is that there are security concerns outside of the individual implementations of the platform, otherwise why are they there? You don't know do you.
all the while demanding for facts concerning a point that has already been proven
you didn't prove anything, except that you haven't read the HTML5 spec, nor know what a security policy is.
implying facts exist to disprove that point, but then conceded you can offer no such facts.
i gave you facts, the HTML5 spec has security policies, that is a fact that proves that security is a part of the spec. Explain to me why they are there if security isn't a necessary component of BOTH the spec AND implementation.
you PROVIDE nothing, THUSLY...
you are NOTHING
Well it's obvious you aren't an engineer of any sort if you fail to see that statement is illogical.
ur mum's face'll reply...again
it's more obvious that you have no concept of relativity.
ur mum's face didn't read the HTML5 spec.
you are NOTHING
if the spec says USER A can choose to allow HOST A to interact with HOST B using USER A's secure credentials... and your only argument is that such a policy is not a "valid security policy"
Which is why it's an issue with BOTH the spec and the implementation. If that security policy is specified in the specification then it will implemented in the implementation. You see, the clue is in the names. If it isn't in the specification then it shouldn't be in the implementation, this is how we ensure different implementations of the same specification have the same behavior.
there is nothing flawed in the spec or inherently flawed in any implementation...
If they have missed a spot where a security policy should be this would be a security flaw, and - assuming the developers correctly followed the specification - would be present in the implementations. There absolutely is scope for this to happen, have a look at the revisions of earlier HTML standards for examples.
ur mum's face didn't read the HTML5 spec.
oh dear, why can't you just discuss this like an adult instead of this childish bullshit?
you are NOTHING
then who's typing this? grow up.
you are NOTHING
not a SINGLE fact.
what you just showed in the last post was a perfect example of a security problem in a platform specification. Hence proving that to have a secure platform you must consider security in BOTH the specification and the implementation.
you are NOTHING
you really don't seem to know what that means do you.
if the spec says USER A can choose to allow HOST A to interact with HOST B using USER A's secure credentials... and your only argument is that such a policy is not a "valid security policy"
Which is why it's an issue with BOTH the spec and the implementation.
NO, you gimpy idiot. it's why YOU BELIEVE there is an issue.
there is no implicit exploitable security flaw in allowing a user to have a system do what they wish of it. the max OS X interface allows me to enter a "Speak Text" dialog... i could put my password in and everyone in earshot would know it. does that mean it's an issue with the OS?
NO. it means you're an idiot.
SUCK MY TOES.
Are you really truly incapable of expressing your point intelligently like an adult? Dispense with the childish name-calling, it only shows your lack of intelligence that you have to stoop to that level instead of discussing the topic like an adult.
it's why YOU BELIEVE there is an issue.
there is no implicit exploitable security flaw in allowing a user to have a system do what they wish of it.
That's user error, that is the user doing something stupid, absolutely nothing to do with the spec whatsoever. It is merely ANOTHER failure point of security.
The specification needs security - proof of that is that there are security policies. The implementation needs security - to protect from thing such as buffer overflows, etc... And the user needs to have some intelligence. All 3 of those are layers of security, not one or two but all 3
So let's try this another way:
Can a specification be wrong? Yes, the proof of that is the fact that specifications are revised many many times
Can security policies be wrong? Yes of course they can.
If the security policy is wrong could this lead to an exploit in the implementation? Absolutely, because the implementation should implement the specification as it is written.
you're an ignorant hypocrite.
until you provide a SINGLE PROVABLE FACT, you are NOTHING
you're a presumptuous IDIOT.
the policy of a computer letting a user do EXACTLY what they want to do CAN NEVER BE "WRONG".
Why were these changes made? Because the spec was wrong, that's why.
Have you ever engaged in an online discussion that didn't devolve into you flinging shit like a retarded zoo ape?