My chief complaint, both on Windows and Linux is that probably 99% of applications have no concept of anything other than the default sound card, making multiple cards useless for all but a few niche applications. Apps that use sound need to provide a way to specify which device is used in case the user wants to use other than the default, period. None of the solutions for audio so far have really done anything to make this better (or they make it worse in the process) - granted, it's mostly an application issue, but control of device selection in the mixer as well would help.
This is actually very, very, very bad. The reason we have a secret ballot is to make it difficult to obtain votes by coercion. You should be able to tell for sure at the polling booth how your vote was counted - but only at the moment you are standing there should there be any possibility for a vote to be connected to an individual voter.
While this seems far-fetched now, if votes were individually traceable, we'd have far greater problems of election fraud to concern ourselves with - which would include the use of violence to force people to vote a certain way.
Previously compromised accounts (email/chat/google web history)
Email forwarding settings (yes this is overt, but how many users actually look at their forwarding rules)
Recoverable "deleted" files on disk
Browser plugins
Saved passwords - even if they are "encrypted" any encryption that allows the application to read the password lets someone else do so as well.
Solutions to these additional threats:
Every time a compromise is suspected, change all passwords from a secure computer immediately.
Check forwarding rules, particularly to web-based email services.
Always use SSL/TLS encryption whenever they are available. Learn not to give passwords over unencrypted channels - this won't help you against a keylogger, but it will help you against sniffing.
Be aware that "deleting" files doesn't really delete them unless you use specialized tools
Further protection against keyloggers.
Reformat.
Make your computer as tamper-evident as possible. Buy a UPS so that if the computer reboots, there will be a reason for it. Keep the computer turned on. Secure all accounts on the computer with a password. If it's Windows, encrypt the SAM database with a password that you have to enter at bootup. Remove your own administrator rights, and have a separate administrator account that you only use to install software. Use a BIOS password. Disable booting from anything other than the hard drive. Install physical locks on the case to prevent it from being opened. Epoxy over the screws on the keyboard (after you've bought a new one).
Use an alternative web browser.
Be careful about opening links and attachments in email. Learn about phishing, particularly the type of targeted phishing that can be attempted by someone with intimate knowledge of their target. (Don't trust the return address on mails in particular - many of the keyloggers out there get on via a trojan horse that you have to be tricked into running)
If any evidence of tampering is found, start over.
Learn about computer security. http://www.cert.org/homeusers/ is one of the best starting places for non-technical users. Even if you don't understand it all, you have a starting place to ask questions.
Remember, trust is the enemy of security. Look for it. Understand how it makes you vulnerable, and decide if the risks are acceptable or not. This mindset extends all the way from the bare metal up to the human being at the keyboard. You have to start to think that way to really be able to keep a computer secure.
OpenPGP and OTR encryption are offered in many clients, and only have to be supported on the client. Clients supporting OpenPGP can also used signed presence. http://www.xmpp.org/extensions/xep-0027.html, although historical, is used by a few of the more popular clients, although, certainly not universally. OTR also has a strong following - I'm not sure if it's as broad as OpenPGP support. Finally, S/MIME support over XMPP apparently exists in RFC form, but I'm not aware of any widespread implementation.
This is in addition to TLS/SSL being used whenever available between client-server and server-server (which, still lets the server inspect messages, but at least protects from casual eavesdropping on the wire).
The problem really remains getting people to use encryption properly on their clients, and as email has shown, despite OpenPGP and S/MIME being available for more than a decade, they aren't widely used outside certain communities, because the average end user values convenience above security.
Time-of-use rates kindof do this - encouraging cutbacks at peak times. Most power companies that do this offer this as an option, so adoption has probably been slower than expected. Basically, the way it works, the power company installs a meter that records not only power consumption, but when that consumption occurs. In exchange for allowing the power company to meter usage in this manner, the customer gets a sharply discounted rate during off-peak hours. However, during on-peak hours, rates are significantly higher.
The utility companies, with the consent of regulators, could make these rates mandatory. The resulting jumps from say, $0.08/KwH to, $0.75/KwH or more would probably encourage enough "voluntary" cutbacks to allow time for a long term solution.
Here's an idea. Instead of the current typical 200amp service, everybody gets a 20amp service that is "always on", and a 200 amp service that's subject to rolling blackouts. That gives consumers the power to choose what loads will be shit down. It would be a little more complex for metering, but, much more effective, and easier to "convince" homeowners to retrofit. (Look... we can give you SOME power that doesn't go out...).
First off, as many people have commented, you don't want to blindly give management what they are looking for here, but you also don't want to ignore such a situation, as they are probably trying to justify the cost of IT.
You need to turn this around in favor of your department, and it would be a very good idea to take a look at what metrics you can apply that will serve a twofold purpose - to set a baseline of current performance, and to set a moving target for constant improvement. In other words, the things you measure should paint a picture of things that your department can and should improve on, if given the resources to do so. An open ended reporting task like this is a setup from the start, but you need to turn it into a chance to show both how well the department is working with what it has, and how much better it could be working if management would let it. That means finding out where your human resources are being wasted, and making recommendations for refocusing those efforts, finding out what parts of your infrastructure are money sinks, finding support costs that can be reduced with changes, and justifying expenditures that will have a concrete benefit to your department's ability to meet the business needs.
If you don't have them already, now's also a good time to start setting realistic SLAs and tracking compliance with them - for everything from backup/recovery time, recovery time objectives, recovery point objectives, helpdesk call resolution times, server reliability, etc. Just make sure they are realistic, and within reach, and re-evaluate them frequently.
Formal statistical process control methodology such as Six Sigma can be useful in the IT department, but only with the people to make it work, and an organization large enough that it can see enough cost savings to justify having a formal quality team. In order for statistical process control to help, everybody has to be onboard, from management to the lowliest member of the department. If you can achieve this, the rigid define, measure, analyze, improve, control methods of Six Sigma can probably create a savings of cost, labor, and sanity within your department.
I would also look at regulatory compliance as a benchmark. Even if your company is not publicly traded, the tight controls that are necessary for public companies to comply with Sarbanes Oxley (SoX) often lend themselves to better IT practices - formal validation of your IT controls (access to information, physical and logical access to systems, authentication credentials, least privilege, auditing, etc) is a good idea. Do users have local administrator access to their desktops? If so, why? What applications are requiring it? Do you have an audited software inventory? If not, what's stopping you? Do you have controls to prevent unauthorized software installation? Do you have controls to insure virus scanning and security patching are done appropriately? Do you have controls to make sure than users have no more access rights than their responsibilities require? Do you have controls to keep track of why users have the access rights they have, and who approved it?
Measuring your disaster recovery capabilities, and realistic evaluation of the scenarios they have to survive are also a must: What are your worst single-failure scenarios? What are your worst two-failure scenarios? What can be done to mitigate the above? What has already been done to mitigate the above?
I'd also take a good look to see whether your department is spending it's time putting out fires, or keeping them from starting - if you are just barely keeping up, then it would be good to look at why, and what can be done to change that. Take a good hard look at your helpdesk, and apply the 80/20 principle - roughly 20% of the causes will be responsible for 80% of the calls - what can be changed that will improve the situation there?
From the end user perspective, what issues are most disruptive to users? What issues are hurting the productivity of use
I don't know if that completely solves it, but it comes close.
My only big concern is about people that are controlled more tightly than simple coercion - those in cults, under control of possessive spouses (some of whom are known to keep their partners essentially under lock and key without any unsupervised access to any communication devices), and the like.
As an additional safeguard, I think it's necessary that the voting system be structured in such a way that either only the voter knows the meaning of their ballot, or that only the voter knows whether or not they have recorded their ballot successfully.
A challenge/response step with a PIN might partially perform such a function - the PIN would constitute both the challenge, and the "signature" on the ballot, and the response you would receive back would be a sequence of numbers based on that PIN, such that some quick mental arithmetic could validate the response, but only if a certain secret were known.
In this way, so long as the PIN and secret were not compromised, the person could pretend to vote, and it would look like a successful vote each time. Certain values of the PIN and secret could also convey additional meanings, such as to covertly shut down the online voting account until the user appears in person before election officials to reset their PIN and secret.
I'm not sure how much additional security this gives against more sophisticated attacks - keyloggers and the like could still expose the PIN being used unless the PIN had to also be permuted. While I think the problem of maintaining a secret ballot can at least be partially solved in online elections, I'm not sure if the degree of assurance required can ever truly be met.
I should probably rephrase and clarify, attacking them directly without legal action to back that up is bad - ie, if you are going after a bot runner, it needs to be in a manner that not only takes away their toys, but also puts them in jail, for a long period of time. If you can't take away their freedom in the process, then you aren't doing us any favors by teaching them how not to get caught -- botnets, and their means of control get more and more sophisticated, with overall trends towards plausible deniability and robust survivable command and control networks, designed to either resist attack, or be reconfigured after the fact to retain control of compromised hosts.
This is a far cry from when botnets were controlled "in the open" on public IRC networks - the kiddies are clearly learning something with each iteration, and they are sharing that knowledge amongst themselves. Also of note is more use of packers, executable encryption and anti-debugger routines, which were completely absent from early botnet executables. Use of rootkits, as well as secondary backdoors (to regain access after the system owner detects the intrusion) are also on the rise.
1) Don't contribute to the problem. Attacking botrunners directly, or vigilante action doesn't help, and may actually be harmful - by teaching them how to build better drones. See http://fm.vix.com/internet/security/superbugs.html
2) As for US gov't agencies, if you or the attacker seem to be in the US, http://www.ic3.gov/ is likely to be interested. http://www.cert.org/csirts/national/contact.html can also put you in touch with nationial computer security incident response teams, who will also be interested (you only need to contact the one local to you, please don't shotgun complaints to all of them.)
3) As for private companies and research organizations, if the bot isn't already clearly and specifically detected by antivirus, report it to them, following their reporting guidelines. Shadowserver (http://www.shadowserver.org) seems to be interested in researching and gathering intelligence on botnets also.
I shouldn't have to point this out, but if you feel strongly about this or other issues before the house, you can easily write your Congressman from the contact form on the House web site - http://www.house.gov/writerep/ While members of Congress may or may not read Slashdot, they or their staff do presumably read their Inbox, and I've gotten at least cursory replies (usually by snail mail) before. I've posted the letter I just wrote below as an example, but it's probably more effective if you write your own words rather than using mine:
To the Honorable Walter B. Jones:
I just became aware of pending legislation via a number of technical industry news sites including Slashdot and Arstechnica that I feel is long overdue, H.R. 811: Voter Confidence and Increased Accessibility Act of 2007.
As a constituent of your district, and as a registered voter, the integrity and transparency of election processes deeply concerns me.
Of particular importance and interest to me are provisions which provide for voter-verifiable paper trails in elections, provisions that require random auditing to insure that paper records match electronic ones, provisions that require the software used within electronic voting machines be open to public inspection, and provisions that provide for the emergency use of paper ballots in the event of system or equipment failure.
I realize that these measures create an additional burden on the states, however, I strongly believe they are needed to restore accountability, auditability, and voter confidence lost by the widespread adoption of electronic voting machines.
I urge you to strongly consider voting for this legislation when it comes before you, and to resist amendments which weaken or eliminate the strong provisions on election integrity it contains.
Lets go further - open reading during which you have line item voting of each clause, and another full reading after any reading in which a clause us stuck or an amendment made. This would dramatically slow congress down at first, but if upheld, within short time would practically abolish bundled legislation and pork barrel projects, as once the "vote on exactly one thing at a time" mentality took hold, things could no longer be slipped into bills.
Alternatively, require the bills to be written entirely on the floor, motion by motion starting from a blank piece of paper and only introducing changes in the exact form in they are read. Same effect.
Of course, this would actually protect the mechinisms of democracy from the corruption that is so rampant, so this would never happen...
What it is most useful for is stopping privileged operations from happening behind your back - malware theoretically has to make at least some noise to infect at a systemwide level with user account control turned on. If it's turned off entirely, you might not get that extra "something's not right here" warning before your antivirus gets disabled and that nasty rootkit gets installed.
Also, as someone already pointed out, this makes programs that require administrator rights unnecessarily much noisier, and provides a support incentive to software publishers to fix their software so it works unescalated.
Not great from a usability perspective but for a company that's almost ignored security until recently it's a start.
There's more to Mozilla than coding - volunteers also do quality assurance, documentation, and other things that aren't reflected in these numbers, but are just as important to the finished product.
Now the question is whether this will just be a defense against missile threats from rogue states, or the start of another arms race. How long before we start to see missiles with the kind of sophisticated countermeasures against interception that military aircraft have against missile threats?
It's really too bad that this is coming out now, rather than in 3-6 months when it would make more of an impact. While the article raises some issues that won't be easy to solve, right now this seems to give M$ a head start on tightening the DRM noose even more or insisting on TPM.
I wonder if the same can be done for distributing OLPC's software platform easily. If a large part of the cost of computers in schools is the software and the continual upgrades that come with it, wonder what can be done for schools that already have computers, just not the latest and greatest...
Very easy solution - sealed bidding - working exactly as it is now, but don't resolve the bids until the auction closes. Sellers would usually make a bit more this way, because of the uncertainty and shill bidding would be actively discouraged by the fact that you'd be stuck with the having to transfer funds and pay associated paypal etc fees if you try to shill bid above what someone's willing to pay. Buyers would be more likely to pay a fair price, because they would continue to bid a fair price, and not have that price jacked up at the end by sniping and shill bids.
Sniping would become a good bit harder also, so the days of people refreshing the page every 2 seconds would go away. Sounds like a win for everybody.
It still begs the question... Should you really have to build software for a production server environment?
(Yes, I know that Gentoo has the ability for binary packages, but their use seems to be actively discouraged by the culture, if not the documentation and the support channels as well.)
Real production environments, at least at the enterprise level, are built around stable, well tested binary packages that just work, change control processes, updates that can be applied safely with minimal technical skill and minimal configuration work, environments which may have one sysadmin for every 500 servers. Server builds should be able to be left to operations staff instead of sysadmins without fear of things going wrong.
Gentoo's strategy of bleeding edge continuous upgrades also doesn't fly in the enterprise world, which insists, for good reason, that functionality shouldn't change at all in production environments except as dictated by the organization's needs. This means that patches have to be back ported, release cycles are a requirement, and product support lifecycles are expected to be measured at least in months, preferably years. Functionality changes require a different kind of risk assessment and planning mentality in the business datacenter world than they do in the workstation world, and this is even more so with laws on the books regulating IT controls such as section 404 of the Sarbanes-Oxley act.and HIPPA in the US alone, and extensive data protection laws in other countries.
Not to mention, the difficulty of one person rolling back changes to 500 servers in an environment built on everything compiled from source is a huge drawback.
While I think that Gentoo is a tremendous technical achievement, it's design places it firmly in the hobbyist and developer workstation realm, and I strongly agree with the article that this leaves it no place in the datacenter for anything other than development work.
This is almost trolling, but just far enough away from it that I'll entertain it with a reply.
The more bad press DRM gets, the more chance the average consumer will reject it.
Granted, speaking out against it on/. is like preaching to the choir, but the word needs to get out unless we are to be stuck under the cloud of it forever.
It would have far more value for us to push for these kind of stories where they are more likely to be seen by regular consumers - write letters to the editor at your favorite newspaper, send letters to congresspeople, etc... those kind of things have far more reach than Slashdot does, at least where this is concerned.
Electromigration takes some time to show up though. If they are just announcing this process now, what problems are going to show up 3, 4, 5 years down the road?
But how much further will that get them before RFI makes it a moot point? At that small of a pathway, I'd think that random radio signals and electrical noise would be disastrous.
Also, how well does this survive long term? Is it resistant to electromigration over time?
All great to hear, but I'm not sure how long this will let them keep pace with Moore's law, at best it buys a couple more years of progress on current processor designs I guess.
Filters are evil, and so is anything that even has the potential to make them more effective.
First it will be.xxx, then it will be.drugs, then it will be.violence, and then it will be.government-criticism.
This is a slippery slope, and the only way to keep from sliding down it is to recognize the slightest slip towards censorship and fight tooth and nail against it, in whatever form it may appear. Sure, the motives now may be pure, but the mere ability to censor effectively must not exist if we are to preserve free speech.
Yes, there's a lot we find distasteful. But we have to realize that the cost of keeping that which we find distasteful under wraps is that we create the ability to one day take away the right of free expression, and that someday, those very measures that we supported to curb "distasteful" expression may be used to squash political expression - as ALREADY happens in some countries such as China.
This doesn't just apply to open-source projects, you vet internal bugs the same way. It's just that open-source projects tends to have a larger group of users who now can change code, but only really need to support themselves. That's great. Make your patch for yourself, that's what we want you to do! But getting it accepted upstream is hard, and should be hard, because we are supporting more people than just you.
This attitude is one thing that erodes the strengths of both Free software and Open source software - the ability to function as a community. Once you start cathedral building, your project, and therefore your user base starts to suffer from many of the same ills that befall commercial software.
The submission of a patch is generally a sign that someone wants to work with you. Keep the dialog open. Work with the submitter to get their patch to where it's acceptable, or at least to explain reasonably why it's not going to be acceptable no matter how much work is done.
All but the most trivial patches are nearly unmaintainable against any large code base with active development. This means that, the alternatives are to fork, or to invest significant developer time - arguably much more than it would take to integrate the patch upstream to begin with. Don't force people to reinvent the wheel.
While not every patch is suitable for inclusion, if your development process isn't as open as your license, you are doing the community a disservice by promoting duplication of effort, and do your project a disservice by driving others to fork or create rival projects with only minimal differences between them. How many different implementations of "foo" do we really need - 2-3 is healthy competition, 20-30 or more leads me to believe there's a lot of reinventing the wheel going on.
Slashdot Mirror
My chief complaint, both on Windows and Linux is that probably 99% of applications have no concept of anything other than the default sound card, making multiple cards useless for all but a few niche applications. Apps that use sound need to provide a way to specify which device is used in case the user wants to use other than the default, period. None of the solutions for audio so far have really done anything to make this better (or they make it worse in the process) - granted, it's mostly an application issue, but control of device selection in the mixer as well would help.
This is actually very, very, very bad. The reason we have a secret ballot is to make it difficult to obtain votes by coercion. You should be able to tell for sure at the polling booth how your vote was counted - but only at the moment you are standing there should there be any possibility for a vote to be connected to an individual voter. While this seems far-fetched now, if votes were individually traceable, we'd have far greater problems of election fraud to concern ourselves with - which would include the use of violence to force people to vote a certain way.
- Previously compromised accounts (email/chat/google web history)
- Email forwarding settings (yes this is overt, but how many users actually look at their forwarding rules)
- Recoverable "deleted" files on disk
- Browser plugins
- Saved passwords - even if they are "encrypted" any encryption that allows the application to read the password lets someone else do so as well.
Solutions to these additional threats:- Every time a compromise is suspected, change all passwords from a secure computer immediately.
- Check forwarding rules, particularly to web-based email services.
- Always use SSL/TLS encryption whenever they are available. Learn not to give passwords over unencrypted channels - this won't help you against a keylogger, but it will help you against sniffing.
- Be aware that "deleting" files doesn't really delete them unless you use specialized tools
Further protection against keyloggers.OpenPGP and OTR encryption are offered in many clients, and only have to be supported on the client. Clients supporting OpenPGP can also used signed presence. http://www.xmpp.org/extensions/xep-0027.html, although historical, is used by a few of the more popular clients, although, certainly not universally. OTR also has a strong following - I'm not sure if it's as broad as OpenPGP support. Finally, S/MIME support over XMPP apparently exists in RFC form, but I'm not aware of any widespread implementation.
This is in addition to TLS/SSL being used whenever available between client-server and server-server (which, still lets the server inspect messages, but at least protects from casual eavesdropping on the wire).
The problem really remains getting people to use encryption properly on their clients, and as email has shown, despite OpenPGP and S/MIME being available for more than a decade, they aren't widely used outside certain communities, because the average end user values convenience above security.
Time-of-use rates kindof do this - encouraging cutbacks at peak times. Most power companies that do this offer this as an option, so adoption has probably been slower than expected. Basically, the way it works, the power company installs a meter that records not only power consumption, but when that consumption occurs. In exchange for allowing the power company to meter usage in this manner, the customer gets a sharply discounted rate during off-peak hours. However, during on-peak hours, rates are significantly higher. The utility companies, with the consent of regulators, could make these rates mandatory. The resulting jumps from say, $0.08/KwH to, $0.75/KwH or more would probably encourage enough "voluntary" cutbacks to allow time for a long term solution.
Here's an idea. Instead of the current typical 200amp service, everybody gets a 20amp service that is "always on", and a 200 amp service that's subject to rolling blackouts. That gives consumers the power to choose what loads will be shit down. It would be a little more complex for metering, but, much more effective, and easier to "convince" homeowners to retrofit. (Look... we can give you SOME power that doesn't go out...).
First off, as many people have commented, you don't want to blindly give management what they are looking for here, but you also don't want to ignore such a situation, as they are probably trying to justify the cost of IT.
You need to turn this around in favor of your department, and it would be a very good idea to take a look at what metrics you can apply that will serve a twofold purpose - to set a baseline of current performance, and to set a moving target for constant improvement. In other words, the things you measure should paint a picture of things that your department can and should improve on, if given the resources to do so. An open ended reporting task like this is a setup from the start, but you need to turn it into a chance to show both how well the department is working with what it has, and how much better it could be working if management would let it. That means finding out where your human resources are being wasted, and making recommendations for refocusing those efforts, finding out what parts of your infrastructure are money sinks, finding support costs that can be reduced with changes, and justifying expenditures that will have a concrete benefit to your department's ability to meet the business needs.
If you don't have them already, now's also a good time to start setting realistic SLAs and tracking compliance with them - for everything from backup/recovery time, recovery time objectives, recovery point objectives, helpdesk call resolution times, server reliability, etc. Just make sure they are realistic, and within reach, and re-evaluate them frequently.
Formal statistical process control methodology such as Six Sigma can be useful in the IT department, but only with the people to make it work, and an organization large enough that it can see enough cost savings to justify having a formal quality team. In order for statistical process control to help, everybody has to be onboard, from management to the lowliest member of the department. If you can achieve this, the rigid define, measure, analyze, improve, control methods of Six Sigma can probably create a savings of cost, labor, and sanity within your department.
I would also look at regulatory compliance as a benchmark. Even if your company is not publicly traded, the tight controls that are necessary for public companies to comply with Sarbanes Oxley (SoX) often lend themselves to better IT practices - formal validation of your IT controls (access to information, physical and logical access to systems, authentication credentials, least privilege, auditing, etc) is a good idea.
Do users have local administrator access to their desktops? If so, why? What applications are requiring it?
Do you have an audited software inventory? If not, what's stopping you?
Do you have controls to prevent unauthorized software installation?
Do you have controls to insure virus scanning and security patching are done appropriately?
Do you have controls to make sure than users have no more access rights than their responsibilities require?
Do you have controls to keep track of why users have the access rights they have, and who approved it?
Measuring your disaster recovery capabilities, and realistic evaluation of the scenarios they have to survive are also a must:
What are your worst single-failure scenarios?
What are your worst two-failure scenarios?
What can be done to mitigate the above?
What has already been done to mitigate the above?
I'd also take a good look to see whether your department is spending it's time putting out fires, or keeping them from starting - if you are just barely keeping up, then it would be good to look at why, and what can be done to change that. Take a good hard look at your helpdesk, and apply the 80/20 principle - roughly 20% of the causes will be responsible for 80% of the calls - what can be changed that will improve the situation there?
From the end user perspective, what issues are most disruptive to users? What issues are hurting the productivity of use
I don't know if that completely solves it, but it comes close.
My only big concern is about people that are controlled more tightly than simple coercion - those in cults, under control of possessive spouses (some of whom are known to keep their partners essentially under lock and key without any unsupervised access to any communication devices), and the like.
As an additional safeguard, I think it's necessary that the voting system be structured in such a way that either only the voter knows the meaning of their ballot, or that only the voter knows whether or not they have recorded their ballot successfully.
A challenge/response step with a PIN might partially perform such a function - the PIN would constitute both the challenge, and the "signature" on the ballot, and the response you would receive back would be a sequence of numbers based on that PIN, such that some quick mental arithmetic could validate the response, but only if a certain secret were known.
In this way, so long as the PIN and secret were not compromised, the person could pretend to vote, and it would look like a successful vote each time. Certain values of the PIN and secret could also convey additional meanings, such as to covertly shut down the online voting account until the user appears in person before election officials to reset their PIN and secret.
I'm not sure how much additional security this gives against more sophisticated attacks - keyloggers and the like could still expose the PIN being used unless the PIN had to also be permuted. While I think the problem of maintaining a secret ballot can at least be partially solved in online elections, I'm not sure if the degree of assurance required can ever truly be met.
I should probably rephrase and clarify, attacking them directly without legal action to back that up is bad - ie, if you are going after a bot runner, it needs to be in a manner that not only takes away their toys, but also puts them in jail, for a long period of time. If you can't take away their freedom in the process, then you aren't doing us any favors by teaching them how not to get caught -- botnets, and their means of control get more and more sophisticated, with overall trends towards plausible deniability and robust survivable command and control networks, designed to either resist attack, or be reconfigured after the fact to retain control of compromised hosts.
This is a far cry from when botnets were controlled "in the open" on public IRC networks - the kiddies are clearly learning something with each iteration, and they are sharing that knowledge amongst themselves. Also of note is more use of packers, executable encryption and anti-debugger routines, which were completely absent from early botnet executables. Use of rootkits, as well as secondary backdoors (to regain access after the system owner detects the intrusion) are also on the rise.
1) Don't contribute to the problem. Attacking botrunners directly, or vigilante action doesn't help, and may actually be harmful - by teaching them how to build better drones. See http://fm.vix.com/internet/security/superbugs.html
2) As for US gov't agencies, if you or the attacker seem to be in the US, http://www.ic3.gov/ is likely to be interested. http://www.cert.org/csirts/national/contact.html can also put you in touch with nationial computer security incident response teams, who will also be interested (you only need to contact the one local to you, please don't shotgun complaints to all of them.)
3) As for private companies and research organizations, if the bot isn't already clearly and specifically detected by antivirus, report it to them, following their reporting guidelines. Shadowserver (http://www.shadowserver.org) seems to be interested in researching and gathering intelligence on botnets also.
I shouldn't have to point this out, but if you feel strongly about this or other issues before the house, you can
easily write your Congressman from the contact form on the House web site - http://www.house.gov/writerep/
While members of Congress may or may not read Slashdot, they or their staff do presumably read their Inbox, and I've gotten at least cursory replies (usually by snail mail) before.
I've posted the letter I just wrote below as an example, but it's probably more effective if you write your own words rather than using mine:
To the Honorable Walter B. Jones:
I just became aware of pending legislation via a number of technical industry news sites including Slashdot and Arstechnica that I feel is long overdue, H.R. 811: Voter Confidence and Increased Accessibility Act of 2007.
As a constituent of your district, and as a registered voter, the integrity and transparency of election processes deeply concerns me.
Of particular importance and interest to me are provisions which provide for voter-verifiable paper trails in elections, provisions that require random auditing to insure that paper records match electronic ones, provisions that require the software used within electronic voting machines be open to public inspection, and provisions that provide for the emergency use of paper ballots in the event of system or equipment failure.
I realize that these measures create an additional burden on the states, however, I strongly believe they are needed to restore accountability, auditability, and voter confidence lost by the widespread adoption of electronic voting machines.
I urge you to strongly consider voting for this legislation when it comes before you, and to resist amendments which weaken or eliminate the strong provisions on election integrity it contains.
Sincerely,
Stephanie Daugherty
Lets go further - open reading during which you have line item voting of each clause, and another full reading after any reading in which a clause us stuck or an amendment made. This would dramatically slow congress down at first, but if upheld, within short time would practically abolish bundled legislation and pork barrel projects, as once the "vote on exactly one thing at a time" mentality took hold, things could no longer be slipped into bills.
Alternatively, require the bills to be written entirely on the floor, motion by motion starting from a blank piece of paper and only introducing changes in the exact form in they are read. Same effect.
Of course, this would actually protect the mechinisms of democracy from the corruption that is so rampant, so this would never happen...
What it is most useful for is stopping privileged operations from happening behind your back - malware theoretically has to make at least some noise to infect at a systemwide level with user account control turned on. If it's turned off entirely, you might not get that extra "something's not right here" warning before your antivirus gets disabled and that nasty rootkit gets installed.
Also, as someone already pointed out, this makes programs that require administrator rights unnecessarily much noisier, and provides a support incentive to software publishers to fix their software so it works unescalated.
Not great from a usability perspective but for a company that's almost ignored security until recently it's a start.
There's more to Mozilla than coding - volunteers also do quality assurance, documentation, and other things that aren't reflected in these numbers, but are just as important to the finished product.
Now the question is whether this will just be a defense against missile threats from rogue states, or the start of another arms race. How long before we start to see missiles with the kind of sophisticated countermeasures against interception that military aircraft have against missile threats?
It's really too bad that this is coming out now, rather than in 3-6 months when it would make more of an impact. While the article raises some issues that won't be easy to solve, right now this seems to give M$ a head start on tightening the DRM noose even more or insisting on TPM.
I wonder if the same can be done for distributing OLPC's software platform easily. If a large part of the cost of computers in schools is the software and the continual upgrades that come with it, wonder what can be done for schools that already have computers, just not the latest and greatest...
Very easy solution - sealed bidding - working exactly as it is now, but don't resolve the bids until the auction closes. Sellers would usually make a bit more this way, because of the uncertainty and shill bidding would be actively discouraged by the fact that you'd be stuck with the having to transfer funds and pay associated paypal etc fees if you try to shill bid above what someone's willing to pay. Buyers would be more likely to pay a fair price, because they would continue to bid a fair price, and not have that price jacked up at the end by sniping and shill bids.
Sniping would become a good bit harder also, so the days of people refreshing the page every 2 seconds would go away. Sounds like a win for everybody.
It still begs the question... Should you really have to build software for a production server environment? (Yes, I know that Gentoo has the ability for binary packages, but their use seems to be actively discouraged by the culture, if not the documentation and the support channels as well.)
Real production environments, at least at the enterprise level, are built around stable, well tested binary packages that just work, change control processes, updates that can be applied safely with minimal technical skill and minimal configuration work, environments which may have one sysadmin for every 500 servers. Server builds should be able to be left to operations staff instead of sysadmins without fear of things going wrong.
Gentoo's strategy of bleeding edge continuous upgrades also doesn't fly in the enterprise world, which insists, for good reason, that functionality shouldn't change at all in production environments except as dictated by the organization's needs. This means that patches have to be back ported, release cycles are a requirement, and product support lifecycles are expected to be measured at least in months, preferably years. Functionality changes require a different kind of risk assessment and planning mentality in the business datacenter world than they do in the workstation world, and this is even more so with laws on the books regulating IT controls such as section 404 of the Sarbanes-Oxley act.and HIPPA in the US alone, and extensive data protection laws in other countries.
Not to mention, the difficulty of one person rolling back changes to 500 servers in an environment built on everything compiled from source is a huge drawback.
While I think that Gentoo is a tremendous technical achievement, it's design places it firmly in the hobbyist and developer workstation realm, and I strongly agree with the article that this leaves it no place in the datacenter for anything other than development work.
This is almost trolling, but just far enough away from it that I'll entertain it with a reply. The more bad press DRM gets, the more chance the average consumer will reject it. /. is like preaching to the choir, but the word needs to get out unless we are to be stuck under the cloud of it forever.
Granted, speaking out against it on
It would have far more value for us to push for these kind of stories where they are more likely to be seen by regular consumers - write letters to the editor at your favorite newspaper, send letters to congresspeople, etc... those kind of things have far more reach than Slashdot does, at least where this is concerned.
In the case of DRM, theres one very strong way to fight it - with your wallet. Use alternatives where possible. Spread the word about products that contain oppressive DRM. Encourage others to do the same.
Electromigration takes some time to show up though. If they are just announcing this process now, what problems are going to show up 3, 4, 5 years down the road?
But how much further will that get them before RFI makes it a moot point? At that small of a pathway, I'd think that random radio signals and electrical noise would be disastrous.
Also, how well does this survive long term? Is it resistant to electromigration over time?
All great to hear, but I'm not sure how long this will let them keep pace with Moore's law, at best it buys a couple more years of progress on current processor designs I guess.
Filters are evil, and so is anything that even has the potential to make them more effective.
.xxx, then it will be .drugs, then it will be .violence, and then it will be .government-criticism.
First it will be
This is a slippery slope, and the only way to keep from sliding down it is to recognize the slightest slip towards censorship and fight tooth and nail against it, in whatever form it may appear. Sure, the motives now may be pure, but the mere ability to censor effectively must not exist if we are to preserve free speech.
Yes, there's a lot we find distasteful. But we have to realize that the cost of keeping that which we find distasteful under wraps is that we create the ability to one day take away the right of free expression, and that someday, those very measures that we supported to curb "distasteful" expression may be used to squash political expression - as ALREADY happens in some countries such as China.
This attitude is one thing that erodes the strengths of both Free software and Open source software - the ability to function as a community. Once you start cathedral building, your project, and therefore your user base starts to suffer from many of the same ills that befall commercial software.
The submission of a patch is generally a sign that someone wants to work with you. Keep the dialog open. Work with the submitter to get their patch to where it's acceptable, or at least to explain reasonably why it's not going to be acceptable no matter how much work is done.
All but the most trivial patches are nearly unmaintainable against any large code base with active development. This means that, the alternatives are to fork, or to invest significant developer time - arguably much more than it would take to integrate the patch upstream to begin with. Don't force people to reinvent the wheel.
While not every patch is suitable for inclusion, if your development process isn't as open as your license, you are doing the community a disservice by promoting duplication of effort, and do your project a disservice by driving others to fork or create rival projects with only minimal differences between them. How many different implementations of "foo" do we really need - 2-3 is healthy competition, 20-30 or more leads me to believe there's a lot of reinventing the wheel going on.