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.
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. 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'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.
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.
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.
Wow...you don't get much more ignorant than that. You don't know it wasn't exploited, you just assume that because you didn't hear about it, and - assuming it was done right - you wouldn't hear about it.
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.
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.
How many times do you see mountains of undocumented, obfuscated, hacked code?
Plenty, if you stray from the 'popular' projects on sourceforge or googlecode.
I learned coding by reading code, so I have no problems with the lack of documentation - it gets in my way and usually gets deleted.
That's just inefficient though, documentation is a good when you want to get stuff done or understand how something works. Deleting it is not a good idea.
I certainly see your point, but I wonder what would happen to things like say big-budget games. If no-one had to pay for it - and they could just share it as they see fit - then would this sort of content even get produced?
I understand the FOSS idea is that companies that use software are the ones that also have to maintain and contribute to it, but I don't see how that applies to software that is exclusively used by home users.
Oh no, the C runtime must also be crap since I've found an application that maxes out my CPU and doesn't run smooth. Seriously why do people bother with this 'it uses too much CPU' rubbish, it depends almost entirely on the site you're looking at and how it's been implemented. Any comments about 'it's too slow' or 'it's too much of a resource hog' are bullshit without a context.
Everybody hates documentation if you're a coder, but having an attitude of RTFC helps no one if you are looking to compare an OS project to a paid alternative.
That's absolutely right, of course it's not the case with all OSS projects but the 'you can find and fix problems' argument is useless if you have to sift through a mountain of undocumented, obfuscated, hacked code just to figure out where the problem is.
She was always getting viruses on her Windows XP box, and after years of trying to keep her up and running I finally installed Firefox to get her used to the browser, and then a while later installed Ubuntu. I used a theme similar to XP, she loved it, and my workload dropped about 90%. She doesn't know Linux from Windows from a bag of frogs, and doesn't care as long as it works.
The problem is that for the most part you don't even need an exploit in the OS, you just need some social engineering. Your typical user probably will run some random file as root if it asks for it anyway so moving OSes is only ever a temporary solution, some basic education on accounts and privileges is all you need.
I wouldn't hold the Xbox of a shining example of good business. While the Xbox has a good marketshare, it does not appear MS will make money on the project. Basically all MS did was pay for marketshare with billions of dollars.
They have actually been making a profit on the xbox console for the last 4 years, despite that it's well-known that console hardware is generally sold at a loss (particularly in its early life) and made up for with game sales. MS have been making a profit on the hardware sales, game sales and xbox live subscriptions so it seems they are doing quite nicely in the console business.
Its not because he's rich, its because its his own fucking plane and quite honestly he should be able to do whatever he wants to with his own property, just like there are rules in buses and taxis that don't apply to your own personal cars.
He can do whatever he wants with his own plane, in the same way that you can do whatever you want with your own car. However if you choose to drive that car on public roads you are subject to the relevant transport, road, police, etc... authority regulations/laws, just as if you choose to fly your plane from a public airport in public airspace you are subject to the relevant transport and aviation authorities rules and regulations as well as the policies of that airport and their security. Pretty obvious if you think about it.
the amount of software that would run on it was rather limited.
Perhaps there were a couple of apps that wouldn't run on XPx64 - though I can't think of any off the top of my head - but the extremely vast majority of applications ran perfectly.
Slashdot Mirror
since the iPhone has never been exploited
So you really think that if someone was stealing your contact details, messages, emails, etc...they would notify you beforehand?
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.
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. 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.
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.
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.
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.
I don't think I would go so far as call the Mac inferior.
Neither did he, and i'd certainly agree it did make them look inferior.
I would say that the Mac was targeted toward the "serious" desktop publishing crowd.
As opposed to the "jocular" desktop publishing crowd?
And good lord god almighty, what 12 year old wrote this code, that they think having function names like put_your_hands_up_hooker() makes them cool?
gees, it's like he's written the first program that his teacher isn't going to look at so he call his functions whatever he wants. how exciting.
Except it was never actually exploited.
Wow...you don't get much more ignorant than that. You don't know it wasn't exploited, you just assume that because you didn't hear about it, and - assuming it was done right - you wouldn't hear about it.
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.
*whoosh*
See definition of 'literally', it ceases to be a 'figure of speech' - or taken figuratively - if you prefix it with 'literally'.
where there were literally only a handful of manufacturers
where there were figuratively only a handful of manufacturers
Commercial games would simply...
a: be offered as a service, eg world of warcraft, eve online etc
Not all games lend themselves to such a model, in fact the majority of them don't.
b: be offered in arcades
That's annoying, i don't want to have to go to an arcade just to play, that's going backwards like 15years.
c: come with (more) in game advertising
That's a possibility, but you can't enforce that because the game is open source, the advertising can just be disabled.
d: be offered built in to hardware (so copying it would necessitate cloning the entire hardware)
oh come on, so a separate console for each game? I don't think so. Also, being open source, you can't tie the software to the hardware anyway.
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.
How many times do you see mountains of undocumented, obfuscated, hacked code?
Plenty, if you stray from the 'popular' projects on sourceforge or googlecode.
I learned coding by reading code, so I have no problems with the lack of documentation - it gets in my way and usually gets deleted.
That's just inefficient though, documentation is a good when you want to get stuff done or understand how something works. Deleting it is not a good idea.
I certainly see your point, but I wonder what would happen to things like say big-budget games. If no-one had to pay for it - and they could just share it as they see fit - then would this sort of content even get produced?
I understand the FOSS idea is that companies that use software are the ones that also have to maintain and contribute to it, but I don't see how that applies to software that is exclusively used by home users.
some crappy InstallShield-like program
What's wrong with InstallShield?
Is it still using 100% CPU
Oh no, the C runtime must also be crap since I've found an application that maxes out my CPU and doesn't run smooth. Seriously why do people bother with this 'it uses too much CPU' rubbish, it depends almost entirely on the site you're looking at and how it's been implemented. Any comments about 'it's too slow' or 'it's too much of a resource hog' are bullshit without a context.
Everybody hates documentation if you're a coder, but having an attitude of RTFC helps no one if you are looking to compare an OS project to a paid alternative.
That's absolutely right, of course it's not the case with all OSS projects but the 'you can find and fix problems' argument is useless if you have to sift through a mountain of undocumented, obfuscated, hacked code just to figure out where the problem is.
I have to say that Adobe Flash is horrible on Linux, it uses far more CPU time and its not as smooth either.
That said, there are plans (according to another /. article) for Steam to move into Linux too. And not even home user is there to play games.
Specifically what is it that isn't running smoothly? And on what system.
She was always getting viruses on her Windows XP box, and after years of trying to keep her up and running I finally installed Firefox to get her used to the browser, and then a while later installed Ubuntu. I used a theme similar to XP, she loved it, and my workload dropped about 90%. She doesn't know Linux from Windows from a bag of frogs, and doesn't care as long as it works.
The problem is that for the most part you don't even need an exploit in the OS, you just need some social engineering. Your typical user probably will run some random file as root if it asks for it anyway so moving OSes is only ever a temporary solution, some basic education on accounts and privileges is all you need.
I wouldn't hold the Xbox of a shining example of good business. While the Xbox has a good marketshare, it does not appear MS will make money on the project. Basically all MS did was pay for marketshare with billions of dollars.
They have actually been making a profit on the xbox console for the last 4 years, despite that it's well-known that console hardware is generally sold at a loss (particularly in its early life) and made up for with game sales. MS have been making a profit on the hardware sales, game sales and xbox live subscriptions so it seems they are doing quite nicely in the console business.
Its not because he's rich, its because its his own fucking plane and quite honestly he should be able to do whatever he wants to with his own property, just like there are rules in buses and taxis that don't apply to your own personal cars.
He can do whatever he wants with his own plane, in the same way that you can do whatever you want with your own car. However if you choose to drive that car on public roads you are subject to the relevant transport, road, police, etc... authority regulations/laws, just as if you choose to fly your plane from a public airport in public airspace you are subject to the relevant transport and aviation authorities rules and regulations as well as the policies of that airport and their security. Pretty obvious if you think about it.
the amount of software that would run on it was rather limited.
Perhaps there were a couple of apps that wouldn't run on XPx64 - though I can't think of any off the top of my head - but the extremely vast majority of applications ran perfectly.