NAT is a security _step_, not a security solution: I'll certainly agree with that.
Neither are firewalls a security solution. The tendency of sites to say "we trust the people we work with" and leave their interior network wide open is a gross violation of basic security principles, and a constant source of rootkitted laptops and poorly maintained servers imperiling business networks, and most sensible firewall configurations can even exacerbate the problem by providing an illusion of security. NAT suffers from the same risk.
Yes, it really does. Many of the groups I work with are staffed by newbies, even in their IT departments. Maintaining Internet exposed firewalls is as fragile, and dangerous, as handling electrical power directly off the power grid before it's been stepped down to 120 Volt. Errors are very common, and profoundly dangerous. It should be avoided by anyone who doesn't absolutely need it
> Are you seriously making such a suggestion in 2013 when we are knee deep in virtual machines or are you joking? It doesn't take much complexity before you end up wanting to have two separate things running the same service and then you've got to do some arcane mucking about with non-standard ports and port forwarding if you've only got one real IP address.
No, I'm suggesting that in 2013 we have load balancers and proxies that do an excellent job of distributing exposed services to arbitrary numbers of internal hosts. The hosts generally have no need, or excuse, to be exposed directly to the Internet. Therefore they do not need a routable IP address. There are a few services, such as SMTP, that deal well with multiple available public IP addresses. And there are some web services that deal very well with multi-homed IP addresses in multiple physical locations. Google is an excellent example of that.
But none of those services require anything approaching the number of exposed IP addresses as the number of back end hosts, easily managed with even the simplest of load balancers or proxies. And those, coupled with the effective use of NAT to conceal internal IPv4 addresses, have effectively pushed back the requirement for IPv6 by years. It's only when the need for 24x7 externally exposed unique addresses approaches 2^32 that we'll actually need IPv6, and we've simply not hit that threshold yet.
I wasn't going to get into this, but the single bottleneck is why you deploy them in high availability failover pairs, or multi-hosted sites for international high availability environments. IPv6 doesn't really help this problem in any way: you still need some kind of a router to protect your publicly exposed services, unless you're interested in maintaining local routers for _every single exposed environment_.
The support benefits, and corporate political benefits, of having a chokepoint for all Internat services is profound and extremely helpful to large environment management.
Not a single business partner, client, or home user that I've dealt with for the last 3 year has an active IPv6 DNS registration. _None_.
The critical factor for IPv4 exhaustion was the lack of "/24" addres spaces for businesses and buildings. This has been impressively ameliorated by the use of NAT, which shares numerous intenral and protected IP addresses behind a single or pair of public addresses and should be the _default_ configuraiton in most businesses and organizaitons, simply to reduce the constant external vulnerability scanning of any host directly connected to the Internet.
The growth of high capacity load balancers for web servers and other network services has also helped tremendously, allowing a wide set of behind the scenes hosts to be serviced by a single exposed device and reducing the IPv4 footprint of these services. Also, people have learned how to economize in the ir IPv4 use: They _do no tneed_ a different IP address for their email server, their FTP server, their web server, their phone server, their chat server, and their IRC server. The services are being easily funneled through a single exposed router or firewall, far more efficiently than before.
The result has been that the great need for IPv6 simply has not yet occurred, and is unlikely to occur for another 10 years. The foundation of the need for IPv6 is basically that of ubiquitous comuputing: the idea that every single device scattered around the home or around the workplace will have its own IP address for remote communications, and they _should not have_ public IP addresses. Providing public, routable IP addresses puts them at risk of attack at all times: putting them in the unroutable, easily tracked and maintained IPv4 address space handles almost all internal network needs quie effectively and is a signigicant security advantage and eases scanning and tracking of local resources.
> config file to enable a post-update hook, and you're pretty much done setting up an "in-house source code repository".
This kind of thing is _precisely_ why many developers,and many IT departments, don't get along well. For example, any developer can instlal sendmail: or Apache or a file server. Running a 24x7 critical high availability service with backup, account management, and user support is a larger task, and the IT department really has to think in those terms if they're skilled.
github has been a critical central repository for thousands of open source projects, hundreds of which I've had to work with in the last few years. Your personal home repository doesn't do me any good, nor will it collect and merge the changs from other developers.
Actually, I referred both to open source repos and to corporate sponsored, private repositories which are the _reference_ clones for other git users to update or clone from. this is particularly important for automatic build systems, which should only be _pulling_ changes form the common repository, never publishing changes to that reference repository.
git does not force this approach, you can switch to other repositories, but it is nonetheless extremely common and just how most people wind up using git.
It's news. I've corporate partners who rely heavily on gitbub.com for access to their open source tools and even for their corporate git repositories, since they're more reliable than almost any in-house source code repository I've dealt with. This especially includes the hand-built, written by the CIO source control systems, that are surprisingly common in startups before they mature. I know companies whose automated software continuous build environments because of this, so it's certainly news.
I certainly have, but they were very skilled in multiple fields, filling particular niches for the products that are the core of a company's business. And they worked very hard.
The recruiter getting 20-25% of the employee's annual salary matches my experience, from both sides. Referral bonuses of $30,000 is unheard: I've seen plenty of referral bonuses offered of $500 to $1000 in the last year for work involving six figure salaries, including contracting work of more than six months duration.
Both Cambridge, MA and Dublin, Ireland are very expensive places to live with some of the highest developer salaries I've seen offered. My colleagues and I have gotten recruiting calls for both areas with salaries consistently over $100,000/year, even during the recent bank crisis. But if you factor in high housing costs, very high vehicle costs, or the additional housing cost of easy commuting access, they become much less appealing.
And comments can be true while code is completely wrong. I've found, far too often that developers who say "read the code" have written complete nonsense. If the code is at complete variance with the comments, then it's a helpful warning that _both_ are wrong.
The Linux _kernel_ was new. The Linux _operating system_ was primarily GNU tool based, using precisely that GPL licensing model that has been so effective in fostering open development. And even the GNU toolchains were not entirely from scratch: key tools like gcc and glibc were written with new code, but clearly written to emulate the behavior of the existing tools from BSD UNIX.
It's always seemed unfortunate to me that the core toolchains, such as C compilers and critical system tools like "make" and "cp" have different behavior in the different UNIX and Linux environments. It makes cross-platform suppoprt much more awkward. It's also helped pay my salary as my colleagues and I resolve such diffeences, but there are more interesting tasks we'd prefer to spend our time on in almost every project.
The main reason that Linux is considered "UNIX-like" isn't the software history. It's that getting certified as "UNIX" is expensive, and the stndards can be quite difficult to follow after a dozen years of free software and open source evolution. The standards are described at "https://en.wikipedia.org/wiki/Single_UNIX_Specification".
Some of we older workers try to stay current. It can be awkward and expensive in productive time and energy. In fact, as an older programmer, I've often used age and treachery to defeat youth and skill in the kind of "my new tool is better than your old tool" challenge so common in the workplace. Thee are few moments as pleasant for an older engineer as when a younger engineer says they've found an exciting way to do something, and you can not only prove the old way is better, but, but you can point out your own signature on the documentation where it says why you rejected that approach.
Fortunately, it's often easy for us to stay abreast of new software fads by tying the new technology to its ancestor and bringing that experience to bear. But if this programmer is not interested in evolving their skills to meet the project or the company's needs, then let that employee know personally. Please don't just insult them behind their backs, or ask Slashdot advice about them. Let them know, to their face, that their difficulties with code review or source control make it harder for their work to be accepted or their work to be useful. If you have to, bring it to their manager.
And if you can, help them find a new role or a new job that is better suited to their skillsets. I've certainly worked with, and even once managed, someone whose core computer language skills were about to be phased out at our company. I let him know we'd have a problem, offered some access to retraining, and was generous with time of for him to do interviews elsewhere and with recommendations. He was quite good with the older skillsets, just not that excited about abandoning almost 20 years of experience and knowledge to start over. The last thing I heard was that he'd retired from the new role he found, and he still does related open source projects for the challenge.
> Uhhh...you ever actually TRY to switch over a large firm with a shitload of one off and small company software to a new OS? that shit AIN'T fun, hell I'd rather get kicked in the nuts with steel toed boots, the pain won't last as long.
I have: it's one of the more painful, but profitable, tasks that my group does. It can be even more exciting when the original designers are long gone and never used the source control, if any, and took to hand-editing system libraries. Unfortunately, the continuing "must use IE6" problem is usually an oversignt, not an actual design problem. It's usually a refusal to _allow_ any engineering time to port the critical application, and any time spent even looking at the system or attempting to secure it is challenged and the bill refused.
Ever since they disbanded the office of the Devil's Advocate in the Vatican, everybody and their circus of performing poodles has been getting sainthood granted. It's a shame: being the official Catholic Church's lawyer for Satan, there to cast doubt on the claims of sainthood was not only the coolest job I could imagine, but should have been staffed by James Randi or one of his students.
It was traditionally staffed by Jesuits, so I suppose that's close enough.
> I seem to recall that rumor used to have it that only all calls in and out of the USA were monitored,
That looks like the NSA's legal requirements to monitor only foreign communications. They were prohibited from monitoring domestic communications, that was the responsibility of the FBI. Unfortunately, "Homeland Security" was created in the wake of 9/11 specifically to merge and organize data among the various intelligence services, and part of the result is that you can't effectively prosecute one agency for overstepping its bounds by going to the other agencies. They can all rely on Homeland Security to cover for them with "Patriot Act" court free search orders, or groundless "national security" orders that prevent even disclosing that your clients have been monitored.
Homeland Security is an extremely dangerous concentration of monitoring and investigation power. I sincerely hope that the antipathy of the more specialized intelligence agencies continues to hinder their growth.
AT&T doing warrant free capture of arbitrary domestic communications is a matter of legal record. They were granted immunity from prosecution when their cooperation with NSA monitoring was exposed by a whistleblower employee. One of the critical facilities was referred to as "Room 641A". There's a reasonable Wikipeda article at http://en.wikipedia.org/wiki/Room_641A.
I've seen no reason to believe that this practice has stopped, merely to believe that they've gotten a bit more subtle about it. The bent fiber optics they were tapping to gather optic signals caused noticeable signal loss. But with more modern fiber optic hardware, it should be much easier to replicate the signals digitally at the fiber optic switches, with the direct cooperation of the telco. And with more recent "Pariot Act" style warrant free search orders, AT&T and other telcos could be legally prohibited from ever admitting that such tapping has occurred.
Thank you for espousing this approach. A great deal of my income comes from the cleanup when management wasn't presented with the available options, and IT chose the wrong ones due to concealed biases or unawareness of other requirements. The result is software churn, and large projects that soak up the entire resources of a company but miss a critical requirement that one side, or the other, didn't even know was available.
The reverse, of course, also happens as well. But since management usually does the consultant hiring, and allocates the budget for it, they're the ones who hire my group. Making peace between IT and management is a huge social part of our work.
Common spam problems such as "Ease of searching tiny alphanumeric address space" and "Jurisdictional problems" translate easily to the common password problems of "sending passwords via email is inherently insecure" and "requiring unique passwords for each trivial new website creates enormous keychains that are not safely portable to new computers or software clients"..
And you'll send them the passwords email, which is consistently monitored for passwords and stored with poor security? And your "keychain" program is tied to one client, and a graphical environment, and that one web browser, with no way to extract the password for putting in your other web browsers?
This is just organizing a fresh set of security holes. It's not a solution. And it wouldn't have solved _this_ event which involves plain text passwords stored on the server side for millions of users.
This has only been true for games that are online to actually play. The others only require on-line to originally download or register the games, to get updates, and to save your games. They also allow you to connect and download the game to any device you log in with, on any OS that the game will play on, and to save your games in their cloud. So you actually get something in return for being online.
Interrupting a game to go offline is usually seamless, but not always, if the game is being saved and doing autosaves to the cloud. Again, you actually get something and something well identifiable for that online connection. It's been useful to me to be able to play the same game at home, and later on a work machine during a long break or on a trip.
I remember fondly when the audio taps were being quietly installed at Dunkin Donuts. It was _amazing_ how police gathering for discussions over coffee on a cold night changed to be outside those cafes, or in the police cruisers.
Those tend to be shredded by cart wheels. And they do soak up spills and get scary if coffee or blood are spilled on them. So those are an ongoing expense. They can help prevent some very expensive static issues.
There are a few other things that I, personally, forgot. A broom, with regular sweeping. It's painful, and even dangerous, when dropped screws wind up embedded point first in your shoes as you transfer a heavy box to a cart for delivery. It's not the janitors' job to sweep that room, there are likely to be too many electrical cords in use. It's the assemblers' job.
Don't use vacuum cleaners if it can be avoided. Those put ridiculous power draws on whichever outlet they use when they start, and can cause dangerous power droops in equipment on the same outlet or on overloaded power systems, and you _know_ the staff will overload their favorite outlets.
Also, an UPS for systems that are being BIOS updated or having other reboot sensitive work being done can save entire projects when a fuse goes out and a system is in the midst of the "do not turn off power" part of an update.
I don't get to do as much hands-on work as I used to. (I'm too senior and usually am in software work, but I still occasionally teach anti-static techniques and electrical safety to engineers who need some brush-up. Some low-end manufacturing employees have a lot to unlearn.) But no, it's really not just "slapping some cards on some pc". The workshop needs depend a lot on what the relevant tasks are. Good tool placement, for example, saves a lot of work walking back and forth to get the needed tool. Good electrical outlet placement means safer electrical wiring for connecting systems and tools, Clear paths around the work tables going to the door means safer, and easier, delivery of equipment on carts. Good shelving, preferably strong enough to take the overloading common in most shops, will make it easy to set aside equipment or systems not being worked on and organize the workflow. Parts bins that are small enough to separate out components into searchable bins, but large enough to hold all of particular types of components, can be very helpful. And I've not even touched on the relevant test equipment. Good voltmeters, cable testers, good quality cable termination tools and connectors, even good quality thumbscrews to replace the horrible, horrible screws a lot of low cost vendors use can profoundly improve system reliability and, in the end, performance.
Good labelmakers are priceless, and an always full bin of label tape cartridges makes it work right. Good quality metal shaping tools to make things fit when the manufacturer put the holes in the wrong place or a new layout needs to be tested. Access to a networked console where you can look up specification sheets, manufacturer's instructions, blueprints, or order numbers is invaluable.
What makes it all work really well, though, isn't in the room. It's the workflow. Work order systems that get the information you need, as you need it, and let you easily record the work done and any special modifications are invaluable for such work and are often ignored. A ticket system that wastes the first screen with irrelevant data and makes you scroll down to get the relevant facts is _wasting your time_ every time you use it. Having to click through 3 different screens to find out a part number is even worse: And recording your typing as you type it, without a "commit" button is the worst sin of all (which is why Google Docs is useless for this).
Slashdot Mirror
Really? Then ping my home machine from where you are, I dare you. It's IP address is 192.168.1.5.
NAT is a security _step_, not a security solution: I'll certainly agree with that.
Neither are firewalls a security solution. The tendency of sites to say "we trust the people we work with" and leave their interior network wide open is a gross violation of basic security principles, and a constant source of rootkitted laptops and poorly maintained servers imperiling business networks, and most sensible firewall configurations can even exacerbate the problem by providing an illusion of security. NAT suffers from the same risk.
> Yes, NAT saves newbies arses
Yes, it really does. Many of the groups I work with are staffed by newbies, even in their IT departments. Maintaining Internet exposed firewalls is as fragile, and dangerous, as handling electrical power directly off the power grid before it's been stepped down to 120 Volt. Errors are very common, and profoundly dangerous. It should be avoided by anyone who doesn't absolutely need it
> Are you seriously making such a suggestion in 2013 when we are knee deep in virtual machines or are you joking? It doesn't take much complexity before you end up wanting to have two separate things running the same service and then you've got to do some arcane mucking about with non-standard ports and port forwarding if you've only got one real IP address.
No, I'm suggesting that in 2013 we have load balancers and proxies that do an excellent job of distributing exposed services to arbitrary numbers of internal hosts. The hosts generally have no need, or excuse, to be exposed directly to the Internet. Therefore they do not need a routable IP address. There are a few services, such as SMTP, that deal well with multiple available public IP addresses. And there are some web services that deal very well with multi-homed IP addresses in multiple physical locations. Google is an excellent example of that.
But none of those services require anything approaching the number of exposed IP addresses as the number of back end hosts, easily managed with even the simplest of load balancers or proxies. And those, coupled with the effective use of NAT to conceal internal IPv4 addresses, have effectively pushed back the requirement for IPv6 by years. It's only when the need for 24x7 externally exposed unique addresses approaches 2^32 that we'll actually need IPv6, and we've simply not hit that threshold yet.
I wasn't going to get into this, but the single bottleneck is why you deploy them in high availability failover pairs, or multi-hosted sites for international high availability environments. IPv6 doesn't really help this problem in any way: you still need some kind of a router to protect your publicly exposed services, unless you're interested in maintaining local routers for _every single exposed environment_.
The support benefits, and corporate political benefits, of having a chokepoint for all Internat services is profound and extremely helpful to large environment management.
Not a single business partner, client, or home user that I've dealt with for the last 3 year has an active IPv6 DNS registration. _None_.
The critical factor for IPv4 exhaustion was the lack of "/24" addres spaces for businesses and buildings. This has been impressively ameliorated by the use of NAT, which shares numerous intenral and protected IP addresses behind a single or pair of public addresses and should be the _default_ configuraiton in most businesses and organizaitons, simply to reduce the constant external vulnerability scanning of any host directly connected to the Internet.
The growth of high capacity load balancers for web servers and other network services has also helped tremendously, allowing a wide set of behind the scenes hosts to be serviced by a single exposed device and reducing the IPv4 footprint of these services. Also, people have learned how to economize in the ir IPv4 use: They _do no tneed_ a different IP address for their email server, their FTP server, their web server, their phone server, their chat server, and their IRC server. The services are being easily funneled through a single exposed router or firewall, far more efficiently than before.
The result has been that the great need for IPv6 simply has not yet occurred, and is unlikely to occur for another 10 years. The foundation of the need for IPv6 is basically that of ubiquitous comuputing: the idea that every single device scattered around the home or around the workplace will have its own IP address for remote communications, and they _should not have_ public IP addresses. Providing public, routable IP addresses puts them at risk of attack at all times: putting them in the unroutable, easily tracked and maintained IPv4 address space handles almost all internal network needs quie effectively and is a signigicant security advantage and eases scanning and tracking of local resources.
> config file to enable a post-update hook, and you're pretty much done setting up an "in-house source code repository".
This kind of thing is _precisely_ why many developers,and many IT departments, don't get along well. For example, any developer can instlal sendmail: or Apache or a file server. Running a 24x7 critical high availability service with backup, account management, and user support is a larger task, and the IT department really has to think in those terms if they're skilled.
github has been a critical central repository for thousands of open source projects, hundreds of which I've had to work with in the last few years. Your personal home repository doesn't do me any good, nor will it collect and merge the changs from other developers.
Actually, I referred both to open source repos and to corporate sponsored, private repositories which are the _reference_ clones for other git users to update or clone from. this is particularly important for automatic build systems, which should only be _pulling_ changes form the common repository, never publishing changes to that reference repository.
git does not force this approach, you can switch to other repositories, but it is nonetheless extremely common and just how most people wind up using git.
It's news. I've corporate partners who rely heavily on gitbub.com for access to their open source tools and even for their corporate git repositories, since they're more reliable than almost any in-house source code repository I've dealt with. This especially includes the hand-built, written by the CIO source control systems, that are surprisingly common in startups before they mature. I know companies whose automated software continuous build environments because of this, so it's certainly news.
I certainly have, but they were very skilled in multiple fields, filling particular niches for the products that are the core of a company's business. And they worked very hard.
The recruiter getting 20-25% of the employee's annual salary matches my experience, from both sides. Referral bonuses of $30,000 is unheard: I've seen plenty of referral bonuses offered of $500 to $1000 in the last year for work involving six figure salaries, including contracting work of more than six months duration.
Both Cambridge, MA and Dublin, Ireland are very expensive places to live with some of the highest developer salaries I've seen offered. My colleagues and I have gotten recruiting calls for both areas with salaries consistently over $100,000/year, even during the recent bank crisis. But if you factor in high housing costs, very high vehicle costs, or the additional housing cost of easy commuting access, they become much less appealing.
And comments can be true while code is completely wrong. I've found, far too often that developers who say "read the code" have written complete nonsense. If the code is at complete variance with the comments, then it's a helpful warning that _both_ are wrong.
The Linux _kernel_ was new. The Linux _operating system_ was primarily GNU tool based, using precisely that GPL licensing model that has been so effective in fostering open development. And even the GNU toolchains were not entirely from scratch: key tools like gcc and glibc were written with new code, but clearly written to emulate the behavior of the existing tools from BSD UNIX.
It's always seemed unfortunate to me that the core toolchains, such as C compilers and critical system tools like "make" and "cp" have different behavior in the different UNIX and Linux environments. It makes cross-platform suppoprt much more awkward. It's also helped pay my salary as my colleagues and I resolve such diffeences, but there are more interesting tasks we'd prefer to spend our time on in almost every project.
The main reason that Linux is considered "UNIX-like" isn't the software history. It's that getting certified as "UNIX" is expensive, and the stndards can be quite difficult to follow after a dozen years of free software and open source evolution. The standards are described at "https://en.wikipedia.org/wiki/Single_UNIX_Specification".
Some of we older workers try to stay current. It can be awkward and expensive in productive time and energy. In fact, as an older programmer, I've often used age and treachery to defeat youth and skill in the kind of "my new tool is better than your old tool" challenge so common in the workplace. Thee are few moments as pleasant for an older engineer as when a younger engineer says they've found an exciting way to do something, and you can not only prove the old way is better, but, but you can point out your own signature on the documentation where it says why you rejected that approach.
Fortunately, it's often easy for us to stay abreast of new software fads by tying the new technology to its ancestor and bringing that experience to bear. But if this programmer is not interested in evolving their skills to meet the project or the company's needs, then let that employee know personally. Please don't just insult them behind their backs, or ask Slashdot advice about them. Let them know, to their face, that their difficulties with code review or source control make it harder for their work to be accepted or their work to be useful. If you have to, bring it to their manager.
And if you can, help them find a new role or a new job that is better suited to their skillsets. I've certainly worked with, and even once managed, someone whose core computer language skills were about to be phased out at our company. I let him know we'd have a problem, offered some access to retraining, and was generous with time of for him to do interviews elsewhere and with recommendations. He was quite good with the older skillsets, just not that excited about abandoning almost 20 years of experience and knowledge to start over. The last thing I heard was that he'd retired from the new role he found, and he still does related open source projects for the challenge.
> Uhhh...you ever actually TRY to switch over a large firm with a shitload of one off and small company software to a new OS? that shit AIN'T fun, hell I'd rather get kicked in the nuts with steel toed boots, the pain won't last as long.
I have: it's one of the more painful, but profitable, tasks that my group does. It can be even more exciting when the original designers are long gone and never used the source control, if any, and took to hand-editing system libraries. Unfortunately, the continuing "must use IE6" problem is usually an oversignt, not an actual design problem. It's usually a refusal to _allow_ any engineering time to port the critical application, and any time spent even looking at the system or attempting to secure it is challenged and the bill refused.
Ever since they disbanded the office of the Devil's Advocate in the Vatican, everybody and their circus of performing poodles has been getting sainthood granted. It's a shame: being the official Catholic Church's lawyer for Satan, there to cast doubt on the claims of sainthood was not only the coolest job I could imagine, but should have been staffed by James Randi or one of his students.
It was traditionally staffed by Jesuits, so I suppose that's close enough.
> I seem to recall that rumor used to have it that only all calls in and out of the USA were monitored,
That looks like the NSA's legal requirements to monitor only foreign communications. They were prohibited from monitoring domestic communications, that was the responsibility of the FBI. Unfortunately, "Homeland Security" was created in the wake of 9/11 specifically to merge and organize data among the various intelligence services, and part of the result is that you can't effectively prosecute one agency for overstepping its bounds by going to the other agencies. They can all rely on Homeland Security to cover for them with "Patriot Act" court free search orders, or groundless "national security" orders that prevent even disclosing that your clients have been monitored.
Homeland Security is an extremely dangerous concentration of monitoring and investigation power. I sincerely hope that the antipathy of the more specialized intelligence agencies continues to hinder their growth.
AT&T doing warrant free capture of arbitrary domestic communications is a matter of legal record. They were granted immunity from prosecution when their cooperation with NSA monitoring was exposed by a whistleblower employee. One of the critical facilities was referred to as "Room 641A". There's a reasonable Wikipeda article at http://en.wikipedia.org/wiki/Room_641A.
I've seen no reason to believe that this practice has stopped, merely to believe that they've gotten a bit more subtle about it. The bent fiber optics they were tapping to gather optic signals caused noticeable signal loss. But with more modern fiber optic hardware, it should be much easier to replicate the signals digitally at the fiber optic switches, with the direct cooperation of the telco. And with more recent "Pariot Act" style warrant free search orders, AT&T and other telcos could be legally prohibited from ever admitting that such tapping has occurred.
Thank you for espousing this approach. A great deal of my income comes from the cleanup when management wasn't presented with the available options, and IT chose the wrong ones due to concealed biases or unawareness of other requirements. The result is software churn, and large projects that soak up the entire resources of a company but miss a critical requirement that one side, or the other, didn't even know was available.
The reverse, of course, also happens as well. But since management usually does the consultant hiring, and allocates the budget for it, they're the ones who hire my group. Making peace between IT and management is a huge social part of our work.
The old spam solution form at http://craphound.com/spamsolutions.txt covers most of the solutions being proposed here.
http://craphound.com/spamsolutions.txt
Common spam problems such as "Ease of searching tiny alphanumeric address space" and "Jurisdictional problems" translate easily to the common password problems of "sending passwords via email is inherently insecure" and "requiring unique passwords for each trivial new website creates enormous keychains that are not safely portable to new computers or software clients"..
And you'll send them the passwords email, which is consistently monitored for passwords and stored with poor security? And your "keychain" program is tied to one client, and a graphical environment, and that one web browser, with no way to extract the password for putting in your other web browsers?
This is just organizing a fresh set of security holes. It's not a solution. And it wouldn't have solved _this_ event which involves plain text passwords stored on the server side for millions of users.
This has only been true for games that are online to actually play. The others only require on-line to originally download or register the games, to get updates, and to save your games. They also allow you to connect and download the game to any device you log in with, on any OS that the game will play on, and to save your games in their cloud. So you actually get something in return for being online.
Interrupting a game to go offline is usually seamless, but not always, if the game is being saved and doing autosaves to the cloud. Again, you actually get something and something well identifiable for that online connection. It's been useful to me to be able to play the same game at home, and later on a work machine during a long break or on a trip.
I remember fondly when the audio taps were being quietly installed at Dunkin Donuts. It was _amazing_ how police gathering for discussions over coffee on a cold night changed to be outside those cafes, or in the police cruisers.
http://www.apnewsarchive.com/1994/Dunkin-Donuts-Advises-Franchisees-to-Stop-Audio-Surveillance/id-d7e29ace8f0cfdd8e4377e70ef26eff8
Those tend to be shredded by cart wheels. And they do soak up spills and get scary if coffee or blood are spilled on them. So those are an ongoing expense. They can help prevent some very expensive static issues.
There are a few other things that I, personally, forgot. A broom, with regular sweeping. It's painful, and even dangerous, when dropped screws wind up embedded point first in your shoes as you transfer a heavy box to a cart for delivery. It's not the janitors' job to sweep that room, there are likely to be too many electrical cords in use. It's the assemblers' job.
Don't use vacuum cleaners if it can be avoided. Those put ridiculous power draws on whichever outlet they use when they start, and can cause dangerous power droops in equipment on the same outlet or on overloaded power systems, and you _know_ the staff will overload their favorite outlets.
Also, an UPS for systems that are being BIOS updated or having other reboot sensitive work being done can save entire projects when a fuse goes out and a system is in the midst of the "do not turn off power" part of an update.
I don't get to do as much hands-on work as I used to. (I'm too senior and usually am in software work, but I still occasionally teach anti-static techniques and electrical safety to engineers who need some brush-up. Some low-end manufacturing employees have a lot to unlearn.) But no, it's really not just "slapping some cards on some pc". The workshop needs depend a lot on what the relevant tasks are. Good tool placement, for example, saves a lot of work walking back and forth to get the needed tool. Good electrical outlet placement means safer electrical wiring for connecting systems and tools, Clear paths around the work tables going to the door means safer, and easier, delivery of equipment on carts. Good shelving, preferably strong enough to take the overloading common in most shops, will make it easy to set aside equipment or systems not being worked on and organize the workflow. Parts bins that are small enough to separate out components into searchable bins, but large enough to hold all of particular types of components, can be very helpful. And I've not even touched on the relevant test equipment. Good voltmeters, cable testers, good quality cable termination tools and connectors, even good quality thumbscrews to replace the horrible, horrible screws a lot of low cost vendors use can profoundly improve system reliability and, in the end, performance.
Good labelmakers are priceless, and an always full bin of label tape cartridges makes it work right. Good quality metal shaping tools to make things fit when the manufacturer put the holes in the wrong place or a new layout needs to be tested. Access to a networked console where you can look up specification sheets, manufacturer's instructions, blueprints, or order numbers is invaluable.
What makes it all work really well, though, isn't in the room. It's the workflow. Work order systems that get the information you need, as you need it, and let you easily record the work done and any special modifications are invaluable for such work and are often ignored. A ticket system that wastes the first screen with irrelevant data and makes you scroll down to get the relevant facts is _wasting your time_ every time you use it. Having to click through 3 different screens to find out a part number is even worse: And recording your typing as you type it, without a "commit" button is the worst sin of all (which is why Google Docs is useless for this).