If you're self employed, you're both an employer and an employee. So suck it up...
That you are not "really" self-employed is the whole premise of IR35. And that's the whole problem - like you, IR35 wants it both ways: not self-employed for (some) tax purposes, self-employed for everything else.
IR35 isn't a debacle unless you're one of a peculiar minority who believe that independent contractors shouldn't have to pay tax like the rest of us.
Oh really? Do the rest of you pay your "deemed" employer's NI contributions as well as your own, or does your employer do that for you?
Because that's what IR35 does. On the one hand it says you are a "disguised employee" and taxes you accordingly - but when it comes to employer's NI you're the employer again, and you get to pay again. Unlike "the rest of us", you're also the employer when the topic is employee rights and benefits (holiday, sick pay, unfair dismissal, pension, etc).
That's aside from making people's tax position as clear as mud, making it practically impossible to plan ahead and grow a business. Plus having to engage expensive experts to second guess the IR just so you can know how much tax you will have the privilege of paying - just a few other things that don't trouble the "rest of us".
Until someone writes code either way, the issue is unproven
The Ravenous Bugblatter Beast of Traal approach to security:
The Ravenous Bugblatter Beast is so mind-bogglingly stupid that it thinks that if you can't see it, it can't see you. Therefore, the best defense against a Bugblatter Beast is to wrap a towel around your head. - Hitchhiker's Guide to the Galaxy, Douglas Adams
Microsoft used to have the same attitude about dictionary attacks on passwords until l0phtcrack came out. But the underlying issue was proven long before l0phtcrack came out.
Moreover, this general class of attacks was proven about 10 years ago and several times since then. Proven in theory and demonstrated with code.
The normal solution is to store both the the real password and the password supplied by the user in a memory area that is as large as the maximum password length and zero padded
Actually no decent password verification function is comparing against a cleartext password in the first place, so strcmp() doesn't really enter into it. Normally the user-supplied password is concatenated with a random value ('salt') and put through a one-way function (aka 'hash function'). Some implementations add an iteration to that to make dictionary attacks take longer. Maybe there are timing attacks against that too, but if so they are more subtle than the likes of timing strcmp().
Where timing attacks definitely do enter into password verification is if your algorithm takes longer to give a yes or no depending on whether the username is valid. This can help an attacker to verify guessed usernames.
You're right though that adding random delays just makes these types of timing attack work more slowly, it doesn't prevent them.
This "license" is not enough, as it only allows for READING files - you will NOT be allowed to create a Free Software program that can WRITE the files.
What on earth makes you think you need Microsoft's permission to do that?
...Microsoft software can talk to mainframes and minicomputers from IBM and other manufacturers; other operating systems such as the Mac OS and various UNIXes including Linux...
So Microsoft stuff can interoperate with OSS stuff - yet a minute ago he was telling us OSS stuff won't interoperate...
In Europe at least it is an explictly recognised right of a user to reverse engineer software to the extent necessary to make it interoperate with any other software you have. EULAs cannot exclude this right, and you often see it specifically mentioned that you are allowed to do this in European EULAs.
It is equivalently difficult to have it off or on when you install & neither are defaults.
Not really because you need a certificate for SSL - most people won't bother or will install a self-signed certificate (which can be fair enough but is still extra hassle to get right). The nice thing about Kerberos is that the entry level is still a password. And the nice thing about Windows Kerberos is that it's on by default and integrated.
This is actually the big caveat--a lot of apps aren't kerberised (and I would even say most that can be aren't by default), which means all bets are off for client-server communication beyond the login session anyway.
That's true in UNIX terms, but in the MS World anything that was using NTLM gets Kerberos either for nothing, or with a reconfig. This includes some interesting stuff such as file sharing, browser based apps, SQL server apps, remote administration, remote desktop, pretty much anything using Windows access control, which includes a lot of custom applications using high level MS APIs or frameworks. Some others can have it with a minor rewrite - in the knowledge that the infrastructure is a non-optional part of the OS.
MS don't get much right in security, but I think this upgrade path from NTLM, and from passwords, is one thing they did reasonably well. Linux etc don't make it anywhere near as easy to have the same kind of distributed security model - not yet, anyway. Although Apple seems to be heading in a similar direction to MS by adopting Kerberos.
Kerberos allows cryptographic session protection where a simple LDAP type SSO does not.
Sure it does--openldap ships with ssl/tls.
"Shipping with" is not "enabled by default".
Besides, LDAP via SSL protects the login session only. It does not provide any session keys that the application client and server can then use to protect their own conversations. Kerberos does do that.
Not only that but you can use two-factor auth (securID and so on) or PKI to replace some or all of the logins, and any kerberised apps will still have cryptographic protection for their sessions.
Again, Linux et al could do all this by default and make it easy too. Lots of the building blocks exist. They just don't.
I can say exactly what authentication methods are used for which servers & have consistent user/pass for many of them. You can KIND of do this with ActiveDirectory & other "enterprise-level" features, but I really don't think it is as good (and certainly no better than) PAM.
Well, yes it is. If your applications integrate with windows login properly (a big if, but a lot do) you get kerberos authentication for nothing. Kerberos allows cryptographic session protection where a simple LDAP type SSO does not. I'm no fan of Windows, but that is one aspect of its security architecture that is actually pretty good.
There's no reason why Linux et al can't have similar of course, lots of the building blocks exist, it just isn't a default like it is on Windows (recent Windows anyway).
I don't see why people haven't adopted the OGG format yet: it has better compression and it's open source
Mainly lack of support in players and software - also the increase in compression is good but not so huge as to be compelling. I know that you can find both players and software that handle it very easily if you know what you are doing - but that lets most people out.
I only heard of it/began using it myself when I got an iRiver player. Pretty impressed with it so far - great sound and somewhat smaller file sizes than mp3.
How long do you think the RIAA will allow the existence of a portable music player with wireless p2p functionality that has NO OTHER PURPOSE but to allow people to "steal" music?
You are assuming that RIAA gets to "allow" devices, which much as RIAA might like that, is not the case.
You are also assuming that every media file in the world is subject to a copyright that forbids sharing.
Who would you trust? A respected journal or a single author with a well-known reputation for publishing half-baked ideas?
I certainly would not trust in appeals to ad hominem attacks and argument from authority.
If this stuff is so uncontroversial, what's the problem with just referencing convincing data and evidence?
(Please note I'm not saying there isn't any - just why does the argument always seem to boil down to demonisation of opponents and "most scientists agree...".)
"...scientific consensus...a majority of scientists agree that we are doing this..."
Science is not a democracy. A theory's predictions check out or not...it does not matter at all what the majority of scientists think about it. When was the last time you heard about a 'consensus' around E=mc^2 or the like?
Michael Crichton's latest book, State of Fear, is quite thought provoking on this stuff. As he says, "scientific consensus" is not science, it is marketing.
I suspect there will be machines out there vulnerable to this for "weeks and months from their publication" anyway. That's because it's not really "fixed" until people apply the patch.
Unfortunately people don't tend to do that unless it's damn near automatic, or actually is automatic, and the word is not being put out very well either.
In my case, I just happened to stumble across the story on/. - even though I have one of my homepage tabs on mozilla/products/firefox, for exactly the reason that I wanted to hear about updates, security related or otherwise. So now I've updated one of my computers. Maybe I'll remember to do all of the others.
Basically for a lot of people out there this fix may as well not exist.
"How many people have had their machines turned into spam zombies because of this exploit?"
Wrong question.
How many thunderbird users COULD have their machines turned into zombies because of this kind of exploit?
Until THAT number is zero then saying "it hasn't happened yet" is like a 5 year old saying "but I didn't get run over" when told he shouldn't run across the road because he might get run over.
Slashdot Mirror
No it is not, any more so than having curtains on your window entitles the police to enter your home.
That you are not "really" self-employed is the whole premise of IR35. And that's the whole problem - like you, IR35 wants it both ways: not self-employed for (some) tax purposes, self-employed for everything else.
Oh really? Do the rest of you pay your "deemed" employer's NI contributions as well as your own, or does your employer do that for you?
Because that's what IR35 does. On the one hand it says you are a "disguised employee" and taxes you accordingly - but when it comes to employer's NI you're the employer again, and you get to pay again. Unlike "the rest of us", you're also the employer when the topic is employee rights and benefits (holiday, sick pay, unfair dismissal, pension, etc).
That's aside from making people's tax position as clear as mud, making it practically impossible to plan ahead and grow a business. Plus having to engage expensive experts to second guess the IR just so you can know how much tax you will have the privilege of paying - just a few other things that don't trouble the "rest of us".
The Ravenous Bugblatter Beast of Traal approach to security:
The Ravenous Bugblatter Beast is so mind-bogglingly stupid that it thinks that if you can't see it, it can't see you. Therefore, the best defense against a Bugblatter Beast is to wrap a towel around your head. - Hitchhiker's Guide to the Galaxy, Douglas Adams
Microsoft used to have the same attitude about dictionary attacks on passwords until l0phtcrack came out. But the underlying issue was proven long before l0phtcrack came out.
Moreover, this general class of attacks was proven about 10 years ago and several times since then. Proven in theory and demonstrated with code.
Just like it's better to hang out in sniper's alley and wait and see if you get shot, before investing in heavy armour.
Actually no decent password verification function is comparing against a cleartext password in the first place, so strcmp() doesn't really enter into it. Normally the user-supplied password is concatenated with a random value ('salt') and put through a one-way function (aka 'hash function'). Some implementations add an iteration to that to make dictionary attacks take longer. Maybe there are timing attacks against that too, but if so they are more subtle than the likes of timing strcmp().
Where timing attacks definitely do enter into password verification is if your algorithm takes longer to give a yes or no depending on whether the username is valid. This can help an attacker to verify guessed usernames.
You're right though that adding random delays just makes these types of timing attack work more slowly, it doesn't prevent them.
What on earth makes you think you need Microsoft's permission to do that?
So Microsoft stuff can interoperate with OSS stuff - yet a minute ago he was telling us OSS stuff won't interoperate...
Indeed.
In Europe at least it is an explictly recognised right of a user to reverse engineer software to the extent necessary to make it interoperate with any other software you have. EULAs cannot exclude this right, and you often see it specifically mentioned that you are allowed to do this in European EULAs.
Not really because you need a certificate for SSL - most people won't bother or will install a self-signed certificate (which can be fair enough but is still extra hassle to get right). The nice thing about Kerberos is that the entry level is still a password. And the nice thing about Windows Kerberos is that it's on by default and integrated.
This is actually the big caveat--a lot of apps aren't kerberised (and I would even say most that can be aren't by default), which means all bets are off for client-server communication beyond the login session anyway.
That's true in UNIX terms, but in the MS World anything that was using NTLM gets Kerberos either for nothing, or with a reconfig. This includes some interesting stuff such as file sharing, browser based apps, SQL server apps, remote administration, remote desktop, pretty much anything using Windows access control, which includes a lot of custom applications using high level MS APIs or frameworks. Some others can have it with a minor rewrite - in the knowledge that the infrastructure is a non-optional part of the OS.
MS don't get much right in security, but I think this upgrade path from NTLM, and from passwords, is one thing they did reasonably well. Linux etc don't make it anywhere near as easy to have the same kind of distributed security model - not yet, anyway. Although Apple seems to be heading in a similar direction to MS by adopting Kerberos.
Like Windows can be configured not to use IE and Outlook?
Can be. But aren't. Defaults matter.
"Shipping with" is not "enabled by default".
Besides, LDAP via SSL protects the login session only. It does not provide any session keys that the application client and server can then use to protect their own conversations. Kerberos does do that.
Not only that but you can use two-factor auth (securID and so on) or PKI to replace some or all of the logins, and any kerberised apps will still have cryptographic protection for their sessions.
Again, Linux et al could do all this by default and make it easy too. Lots of the building blocks exist. They just don't.
Well, yes it is. If your applications integrate with windows login properly (a big if, but a lot do) you get kerberos authentication for nothing. Kerberos allows cryptographic session protection where a simple LDAP type SSO does not. I'm no fan of Windows, but that is one aspect of its security architecture that is actually pretty good.
There's no reason why Linux et al can't have similar of course, lots of the building blocks exist, it just isn't a default like it is on Windows (recent Windows anyway).
Mainly lack of support in players and software - also the increase in compression is good but not so huge as to be compelling. I know that you can find both players and software that handle it very easily if you know what you are doing - but that lets most people out.
I only heard of it/began using it myself when I got an iRiver player. Pretty impressed with it so far - great sound and somewhat smaller file sizes than mp3.
You are assuming that RIAA gets to "allow" devices, which much as RIAA might like that, is not the case.
You are also assuming that every media file in the world is subject to a copyright that forbids sharing.
This is not so either.
I certainly would not trust in appeals to ad hominem attacks and argument from authority.
If this stuff is so uncontroversial, what's the problem with just referencing convincing data and evidence?
(Please note I'm not saying there isn't any - just why does the argument always seem to boil down to demonisation of opponents and "most scientists agree...".)
Science is not a democracy. A theory's predictions check out or not...it does not matter at all what the majority of scientists think about it. When was the last time you heard about a 'consensus' around E=mc^2 or the like?
Michael Crichton's latest book, State of Fear, is quite thought provoking on this stuff. As he says, "scientific consensus" is not science, it is marketing.
iRiver or somebody needs to do a remake of the 1984 commercial.
This time all the drones will be wearing white earphones...
I suspect there will be machines out there vulnerable to this for "weeks and months from their publication" anyway. That's because it's not really "fixed" until people apply the patch.
Unfortunately people don't tend to do that unless it's damn near automatic, or actually is automatic, and the word is not being put out very well either.
In my case, I just happened to stumble across the story on /. - even though I have one of my homepage tabs on mozilla/products/firefox, for exactly the reason that I wanted to hear about updates, security related or otherwise. So now I've updated one of my computers. Maybe I'll remember to do all of the others.
Basically for a lot of people out there this fix may as well not exist.
"How many people have had their machines turned into spam zombies because of this exploit?"
Wrong question.
How many thunderbird users COULD have their machines turned into zombies because of this kind of exploit?
Until THAT number is zero then saying "it hasn't happened yet" is like a 5 year old saying "but I didn't get run over" when told he shouldn't run across the road because he might get run over.