The dot-bomb is calling. You're infringing on the intellectual property of all those web company business plans, and they want to make sure you don't go any further and buy any Aeron chairs before you've written a line of code.
It's not you personally: but since you apparently don't consider your idea sophisticated or protectable in court enough to be able to admit what it is, you apparently have no way to protect it and have Microsoft or any of the patent trolls steal your work. If you have a genuine workable, talk to a competent business lawyer and a genuine programmer you trust enough to discuss your idea with, and see if it is really worth anything. Then watch a few episodes of 'the Dragon's Den' to learn how not to do a business plan.
My reading skills seem to be fine, thank you. You wrote:
> The solution to this problem is to ignore proprietary codecs.
MP3 is patented in various ways, and still remains an extremely popular, perhaps even the most popular, audio codec. It hasn't 'gone away', and ignoring it will ignore a huge amount of both the available audio material and the available hardware. Simply 'ignoring' it doesn't work.
And unfortunately, 'ignoring' codecs by converting files from one codec to another can run you afoul of the DMCA in the USA, for breaking the protection on the original documents. So you can't just 'ignore proprietary codecs' any more than you can 'ignore traffic laws'. You may not get caught, but you're taking a real risk if you just ignore them.
To run it all? It's not feasible. But to step in for a few days and take the help requests, or help the company limp along when a critical employee steps in front of a bus? That is a good manager's job. The idea that a manager is a purely 'people person' and that this makes them somehow better able to manage if they do _not_ have the technical skills is a fallacy of a lot of empire-building little bureaucrats.
I don't expect a hospital supervisor to do heart surgery, but I do expect them to be able to do CPR and apply pressure to a bleeding wound. And I expect my supervisor to be able to actually _read_ my reports, and understand why we're using a central source control system rather than a lot of source tarballs.
_GOOD_. I'm glad that OpenFire does it closer to correct. Nevertheless, that doesn't fix the protocol, which allows for it. Protocols that stupid should not be supported by other tools, whether open source or closed source.
It's not difficult at all to forbid unencrypted password storage, or handling, in the protocol. That it existed in the reference application, and remains supported as a compatible standard, in the other clients speaks volumes about the foolishness of the authors.
Mailman and Subversion suffer from similar issues: Mailman, at least, has the excuse of being older, although it sends passwords to users in the clear by default. Subversion stores passwords for HTTP and HTTPS access on the client side, in clear text. There is _no excuse_ for that kind of stupidity, and being built right into the reference codebases, it's very difficult to eliminate. It's precisely why I dislike them.
Security is not something you can add on the way you'd paint your bedroom or choose the way you'd choose a 'skin' for your inteface. It needs to be paid attention to, up front.
He wasn't a white-hat. He was installing keystroke loggers. Without explicit permission, that's straightforward black-hat behavior, because many of those interfere with other programs on the system.
You were not dishonest, merely negligent that your password was discoverable with a dictionary attack. That's not numeric bad luck, that's a bad password: you should know better. Whether it's malice or carelessness does not matter much: the scale of the invasion should matter more, especially if someone could nab your passwords from other, more critical services.
Now, if you had laid the groundwork in previous reports that the password handling was poor and that a properly synchronized Kerberos or RSA key login approach sould be used, you'd be in better shape now.
No, some anger is justified. The Morris Worm was not written to ruin systems, it was written to probe them and report its results. Nevertheless, it brought down UNIX servers worldwide becuase it was badly written. Doing 'harmless' security cracks against a badly secured network can in fact trash that network, by accident, as you tweak local settings in 'harmless' ways.
As well meant as it was, this is why you don't put your name on that paper about the flaws. You send copies to the core administrators and money providing bureaucrats, from their own email accounts, and possibly to the staff of the school newspaper.
_GOOD_. That looks like a serious step up. Does the protocol still allow unencrypted password handling? I'll admit to not having taken apart a source code base for it in years, since my complete disgust with the reference server version.
jabberd2 is the reference application, is it not? Much like sendmail is the reference application for SMTP. And whether or not it is, the protocol _permits_ this sort of handling, along with unencrypted communications channels. No, I'm sorry, but any chatting protocol written in this century should not start with that foolish of a base. It's conceivable to try and upgrade to something usable, but I'm afraid that folks like the Crossfire authors are stuck with the same problem that Linus Torvalds described when reviewing Subversion as CVS redone correctly: it's like gold-plating dogshit.
Most of the scalability, security, and management problems of Jabber, AIM, etc., etc. were dealt with more than a decade ago with the 'Zephyr' protocol. Supporting dozens of such protocols and trying to make a client, or server, work with all of them is like putting an anchor and a barometer on a motorcycle: it's pretty silly and unbalances the client, making it unwieldy and liable to break down.
Just because it can do things right, with extra work, doesn't mean it should be used. That additional work is burdensome, and thee is no excuse for storing clear-text passwords on a server. _None_. Any software on which the default was, and still is, such bad behavior should not be used for _anything_ until the behavior is addressed. Correcting it on the old, antique jabber servers is not something the current maintainers can easily do. That's a mistake so fundamental that the protocol should be thrown out.
This is what happens when new people, intent on making their own tool that does things their way, forget the hard-won lessons of the rest of the tools and simply ignore security as 'something to be done later'. The same applies to scalability, portability, and source control. Products inventing their own, individual lessons of each of those factors wind up learning the hard way why the old, bulkier products do things certain ways, and lose much of their own simplicity when they have to deal with the same factors.
Jabber is the worst applicaton I've seen for security in the last 15 years. Storing passwords on the server, in plain-text, by default, is what you expect when some excited youngster says 'let's make an application that does things my way' and doesn't realize the pitfalls.
Security, scalability, and compatibility are issues with all new software which cannot be stapled on after the fact. A lot of new protocols try to do exactly that, though, and should stop wasting our time when incrememental changes to existing systems will work far better and be more functional. So it is in fact a very bad idea to have your new clients support every protocol under the sun: it makes you vulnerable to the flaws, and have to work around those flaws, of each of those protocols.
You've never dealt with the NVidia Geforce series of chipsets, then. They most certainly _do_ exist, and integrating NVidia drivers gets into a nasty licensing issue with their binary-blob-only drivers, which cannot be directly distributed in a Linux kernel due to its conflicts with the GPL.
Yes, I've had to deal with this several times for avid Linux users.
Some of us do. Unfortunately, laptops often have strange new combinations of components that are not yet stable in Linux, such as scrollbars, new graphics chipsets, strange RAID controllers, etc., that were only tested with Windows by the manufacturers. Maintaining good quality for such components, and making sure the drivers work well together, takes real effort by competent people. And if you're trying to trim costs, those people may not stick around.
Take a good look at your End User License Agreement. That's contract law, and often restricts you from duplicating the media except for 'backup purposes'.
Yes, they should be known. In many poorly administered networks, they are not, nor is there a good hardware inventory to tie MAC addresses to particular hardware. Given that the former employee had profound network access and some skill, it's a simple matter to filter ICMP packats, filter all traffic to the device except from select hosts, and otherwise confound casual scanning efforts.
I've had enough things occur by negligence and accident that I see no reason to have confidence that it could not be concealed even better, deliberately.
Comcast engages in unannounced interference in Bittorrent traffic, forging RST packagets to cause the connections to hang. And they lie about it. For these reasons alone, they should be avoided: such behavior is, itself, illegal, and interferes with legal, reasonable use such as downloading Linux DVD ISO images.
Maybe they can rehire the Cobol programmers from the retirement homes in Florida? The ones they brought out of retirement for the Year 2000 crisis? I bet that 8 years later, their skills haven't rusted a bit. _Congealed_, perhaps, but not rusted.
Really? Have you ever seen portraits of Ben Franklin? Now, _there_ is an archetypal geek. The man _invented_ public libraries, and bi-focal glasses for us older geeks.
Slashdot Mirror
Captain! Kirk! Must Date! Green! Alien! Women! In Bikinis!
Actually, a few pics of that might triple the actual traffic to Yahoo not faked by the Yahoo toolbar bundled with things people actually do want.
The dot-bomb is calling. You're infringing on the intellectual property of all those web company business plans, and they want to make sure you don't go any further and buy any Aeron chairs before you've written a line of code.
It's not you personally: but since you apparently don't consider your idea sophisticated or protectable in court enough to be able to admit what it is, you apparently have no way to protect it and have Microsoft or any of the patent trolls steal your work. If you have a genuine workable, talk to a competent business lawyer and a genuine programmer you trust enough to discuss your idea with, and see if it is really worth anything. Then watch a few episodes of 'the Dragon's Den' to learn how not to do a business plan.
My reading skills seem to be fine, thank you. You wrote:
> The solution to this problem is to ignore proprietary codecs.
MP3 is patented in various ways, and still remains an extremely popular, perhaps even the most popular, audio codec. It hasn't 'gone away', and ignoring it will ignore a huge amount of both the available audio material and the available hardware. Simply 'ignoring' it doesn't work.
And unfortunately, 'ignoring' codecs by converting files from one codec to another can run you afoul of the DMCA in the USA, for breaking the protection on the original documents. So you can't just 'ignore proprietary codecs' any more than you can 'ignore traffic laws'. You may not get caught, but you're taking a real risk if you just ignore them.
I see. So when exactly did MP3 go away? I must have missed it.
To run it all? It's not feasible. But to step in for a few days and take the help requests, or help the company limp along when a critical employee steps in front of a bus? That is a good manager's job. The idea that a manager is a purely 'people person' and that this makes them somehow better able to manage if they do _not_ have the technical skills is a fallacy of a lot of empire-building little bureaucrats.
I don't expect a hospital supervisor to do heart surgery, but I do expect them to be able to do CPR and apply pressure to a bleeding wound. And I expect my supervisor to be able to actually _read_ my reports, and understand why we're using a central source control system rather than a lot of source tarballs.
_GOOD_. I'm glad that OpenFire does it closer to correct. Nevertheless, that doesn't fix the protocol, which allows for it. Protocols that stupid should not be supported by other tools, whether open source or closed source.
I got this idea where he said: "The person used a brute-force ssh attack, and compromised my account,"
The claim that a good password is vulnerable to a brute force SSH attack is, in my observation and opinion, nonsense.
It's not difficult at all to forbid unencrypted password storage, or handling, in the protocol. That it existed in the reference application, and remains supported as a compatible standard, in the other clients speaks volumes about the foolishness of the authors.
Mailman and Subversion suffer from similar issues: Mailman, at least, has the excuse of being older, although it sends passwords to users in the clear by default. Subversion stores passwords for HTTP and HTTPS access on the client side, in clear text. There is _no excuse_ for that kind of stupidity, and being built right into the reference codebases, it's very difficult to eliminate. It's precisely why I dislike them.
Security is not something you can add on the way you'd paint your bedroom or choose the way you'd choose a 'skin' for your inteface. It needs to be paid attention to, up front.
He wasn't a white-hat. He was installing keystroke loggers. Without explicit permission, that's straightforward black-hat behavior, because many of those interfere with other programs on the system.
You were not dishonest, merely negligent that your password was discoverable with a dictionary attack. That's not numeric bad luck, that's a bad password: you should know better. Whether it's malice or carelessness does not matter much: the scale of the invasion should matter more, especially if someone could nab your passwords from other, more critical services.
Now, if you had laid the groundwork in previous reports that the password handling was poor and that a properly synchronized Kerberos or RSA key login approach sould be used, you'd be in better shape now.
No, some anger is justified. The Morris Worm was not written to ruin systems, it was written to probe them and report its results. Nevertheless, it brought down UNIX servers worldwide becuase it was badly written. Doing 'harmless' security cracks against a badly secured network can in fact trash that network, by accident, as you tweak local settings in 'harmless' ways.
As well meant as it was, this is why you don't put your name on that paper about the flaws. You send copies to the core administrators and money providing bureaucrats, from their own email accounts, and possibly to the staff of the school newspaper.
_GOOD_. That looks like a serious step up. Does the protocol still allow unencrypted password handling? I'll admit to not having taken apart a source code base for it in years, since my complete disgust with the reference server version.
jabberd2 is the reference application, is it not? Much like sendmail is the reference application for SMTP. And whether or not it is, the protocol _permits_ this sort of handling, along with unencrypted communications channels. No, I'm sorry, but any chatting protocol written in this century should not start with that foolish of a base. It's conceivable to try and upgrade to something usable, but I'm afraid that folks like the Crossfire authors are stuck with the same problem that Linus Torvalds described when reviewing Subversion as CVS redone correctly: it's like gold-plating dogshit.
Most of the scalability, security, and management problems of Jabber, AIM, etc., etc. were dealt with more than a decade ago with the 'Zephyr' protocol. Supporting dozens of such protocols and trying to make a client, or server, work with all of them is like putting an anchor and a barometer on a motorcycle: it's pretty silly and unbalances the client, making it unwieldy and liable to break down.
Just because it can do things right, with extra work, doesn't mean it should be used. That additional work is burdensome, and thee is no excuse for storing clear-text passwords on a server. _None_. Any software on which the default was, and still is, such bad behavior should not be used for _anything_ until the behavior is addressed. Correcting it on the old, antique jabber servers is not something the current maintainers can easily do. That's a mistake so fundamental that the protocol should be thrown out.
This is what happens when new people, intent on making their own tool that does things their way, forget the hard-won lessons of the rest of the tools and simply ignore security as 'something to be done later'. The same applies to scalability, portability, and source control. Products inventing their own, individual lessons of each of those factors wind up learning the hard way why the old, bulkier products do things certain ways, and lose much of their own simplicity when they have to deal with the same factors.
Jabber is the worst applicaton I've seen for security in the last 15 years. Storing passwords on the server, in plain-text, by default, is what you expect when some excited youngster says 'let's make an application that does things my way' and doesn't realize the pitfalls.
Security, scalability, and compatibility are issues with all new software which cannot be stapled on after the fact. A lot of new protocols try to do exactly that, though, and should stop wasting our time when incrememental changes to existing systems will work far better and be more functional. So it is in fact a very bad idea to have your new clients support every protocol under the sun: it makes you vulnerable to the flaws, and have to work around those flaws, of each of those protocols.
You've never dealt with the NVidia Geforce series of chipsets, then. They most certainly _do_ exist, and integrating NVidia drivers gets into a nasty licensing issue with their binary-blob-only drivers, which cannot be directly distributed in a Linux kernel due to its conflicts with the GPL.
Yes, I've had to deal with this several times for avid Linux users.
Some of us do. Unfortunately, laptops often have strange new combinations of components that are not yet stable in Linux, such as scrollbars, new graphics chipsets, strange RAID controllers, etc., that were only tested with Windows by the manufacturers. Maintaining good quality for such components, and making sure the drivers work well together, takes real effort by competent people. And if you're trying to trim costs, those people may not stick around.
Take a good look at your End User License Agreement. That's contract law, and often restricts you from duplicating the media except for 'backup purposes'.
Yes, they should be known. In many poorly administered networks, they are not, nor is there a good hardware inventory to tie MAC addresses to particular hardware. Given that the former employee had profound network access and some skill, it's a simple matter to filter ICMP packats, filter all traffic to the device except from select hosts, and otherwise confound casual scanning efforts.
I've had enough things occur by negligence and accident that I see no reason to have confidence that it could not be concealed even better, deliberately.
And how much 'Esc-x psychoanalyze-pinhead' you can tolerate. For you Emacs users, try it.
Questions that also get the answer added, 'talk to my lawyer about this'.
Comcast engages in unannounced interference in Bittorrent traffic, forging RST packagets to cause the connections to hang. And they lie about it. For these reasons alone, they should be avoided: such behavior is, itself, illegal, and interferes with legal, reasonable use such as downloading Linux DVD ISO images.
There is already such a bounty. It's called 'finding a job'.
Maybe they can rehire the Cobol programmers from the retirement homes in Florida? The ones they brought out of retirement for the Year 2000 crisis? I bet that 8 years later, their skills haven't rusted a bit. _Congealed_, perhaps, but not rusted.
Really? Have you ever seen portraits of Ben Franklin? Now, _there_ is an archetypal geek. The man _invented_ public libraries, and bi-focal glasses for us older geeks.