Am I being overly paranoid and resistant to change? You're not being "overly" paranoid, but your paranoia is poorly focused. The remote access issue doesn't increase your exposure to unethical sysadmins. If the admins are going to steal your data, all they have to do is make a "bad" backup tape and walk out of the building with it. The remote access increases your exposure to hackers and other Slashdot readers due to the open port on the internet. If you already have a remote access feature for your own employees, letting the outsourcing company use that gateway isn't really adding to your risk.
Should we just trust our administrator because they have a reputation to uphold? No you should trust your system administrator because your contract specifies stringent penalties they will be required to pay if they violate your trust. You should trust them because they are contractually obligated to provide on demand network access logs for all of their personnel showing the systems, directories, files, databases and tables that were accessed. You trust them because you vet their remote employees accessing your systems with the same security scrutiny you would perform on their employees with physical access to your site. You trust them because your firewall rules can restrict access to your most critical systems to specific addresses on the contractor's space. You trust them because your contract manager has the technical chops or the technical staff to know when you're being bullshitted.
In other words, don't just trust them. Treat them like any other "arms length" business partner.
Or should we lock them out and make them administer the network in person so we can stand behind and watch them? If you go this way, your cost savings pretty much disappear. Cost will be comparable to leasing your computer HW and having your own IT staff. The lease option may be better for your peace of mind.
But that's really a problem with the platform and the app store, which you haven't created. And, at the end of the day, anybody else is still free to pay for the developer license - like you did - then put the resulting work onto app store for free.
If the platform is incompatible with the GPL, you can't release GPL software on it. They aren't violating the spirit or the letter of the GPL by charging for the software, but I think the "installer" issue is more critical. Unless they start distributing the jailbreak software and its source code, along with installation scripts required to load their app on a jailbroken phone, the end user has no way to install a modified version of the program on the target platform by building from the source code they provide. Since providing the jailbreak software is a violation of Apple's TOS, it looks like they are caught between the App Store TOS and the GPL.
If they were distributing their app for another platform that didn't encrypt the installation process, they'd be in the clear.
Items created/published by the U.S. government are in the public domain at least in the U.S. I'm not sure if the rights are granted abroad as well.
However, items created under a contract to the U.S. government may or may not be in the public domain. There's a section of US law that companies have to invoke in their contract or the software license regarding U.S. government "limited rights" to keep their code or other work private. On the other hand, NIST DATA shouldn't be copyrightable in any case, although companies still like to test the theory that their databases are copyrighted fairly frequently.
I am not a lawyer. Even if I were a lawyer, I'm not YOUR lawyer. The above discussion is mostly intended to point out that you're more likely to get a better deal for data out of the government than out of a private company. If you need pre-built software from a private firm, you're likely to be tied into a license agreement that affirms copyright over the data or its storage format (or both), which could be a source of disagreement with the software vendor if you decide to follow your plan of extracting the data for your own use.
Asking someone to sign a non-disclosure contract to vet an idea is only crass if you don't offer to pay them. If your idea is "interesting" enough to go to the effort of an NDA, it should be interesting enough to put a little cash down to support.
But maybe before going to a subject matter expert, you can do a little informal market and pricing research. Ask your friends how much they would pay for a product based on your idea, if they would buy it at all. See if that fits in the ballpark for how much it would take to manufacture and deliver it. If something will cost $20 to make, it probably won't fly even if your friends are willing to pay $20 for it, since you still have to cover overhead, advertising and so on. Your margins have to be high enough to cover those costs plus recover your startup costs within about a year to a year and a half depending on your sales volume. High margins are a double-edged sword, though. It makes it harder to justify the price in the consumer's mind, plus it provides an incentive for competitors to enter the market.
But the main thing is, if you want to vet your idea, there are several aspects to explore informally before you have to shell out for expert opinion.
There isn't any security tool in the world that adequately protects against interception by a keylogger or any other tool that can read the "cleartext", the way you describe here. So knocking it for risk due to interception the way you describe is a bit of a strawman argument. There are several factors in this tool that give it bigger security than you describe: 1) If the entire transaction is handled in SSL, they have to crack a layer of encryption just to be able to see the challenge pattern and response code. 2) The number of combined challenges and responses is bigger than you describe, since it depends a) the challenge pattern, b) the alignment of the challenge pattern within the screen template and c) the decoding pattern on the card. 3) The lifetime of the "onetime pad" is limited to the CC expiration date when a new card would be issued. If you're a business user that does hundreds of online transactions a month, this won't help. But for the average consumer that maybe does 10 online transactions a month, you generate less than 500 CC transactions in 4 years (the life of a typical card). So as long as the number of available combinations is on the order of 1,000 they won't be repeated for most users and can replace the entire set of available CCVs on a single card. And what hacker is going to wait around 4 years to gather enough encrypted data to crack the card when all they need is a couple months worth of transactions from a card using a CCV?
On the flip side, the possible pattern combinations will probably not turn out to be completely random, so if there are only 1,000 combinations, the response to a pattern could probably be predicted after only 100 or 200 observations.
But looking at a sample pattern on the demo site, it looks like the number of patters is more on the order of 100,000 or higher. It looks like they overlay a 10-digit 7-segment pattern with another 9-digit one (i.e. the right hand side of the first digit of the 10-digit pattern lines up with the left segment of the 9-digit pattern). Since the return value is 6 digits, it's probably designed so that the entire 1 000 000 value space for 6 digit numbers is available for any given card. That would make the security of the system on the same order as battery-powered PIN cards, without relying on a timer (which required clock alignment) or a push-button (which can be thrown off if the button is pushed without using the code). Not to mention enviro-friendliness of not putting lithium batteries out there.
When considered relative to the CC Card CCV and PIN that is commonly in use, it's hundreds of times better, since those are constant, so any MITM automatically knows that every response with the same CC number has the same cleartext.
So: no, not a perfect security solution, but hundreds of times better than constant-valued CCV or PIN.
Unless they're on an old COBOL system or a derivative of such. In which case, they're probably storing as compact BCD (2 decimal digits per byte). Which could be how the spaces passed validation.
A senior technical person and a junior manager or project manager in the tech team basically have to deal with the same political, financial and people management issues anyway. If there's a problem with the schedule, or the skill set of one of the junior team members, both the tech lead and the manager have to come up with a plan and deal with it. The difference is in the perspective they need to bring to the table. The tech lead should be focused more (but not exclusively) on the "best possible" resolution to an issue, whether that is more training for the team or adjusting the schedule to ensure a quality product. The manager/PM will be more concerned with the costs and deadlines and getting the most out of the team possible within those constraints. The two need to have enough common ground to understand the constraints and requirements from both perspectives and recognize which ones take precedence in a given situation. So would you rather risk dealing with a lousy tech lead as a manager, or dealing with a lousy manager as a tech lead?
The promotion ladder is longer in management, but it's harder to get a job back if you get cut, because management skills tend to be more common. So apart from which job is more enjoyable, you might want to think about weighing your future promotion chances vs. the risk of job cuts. Also, if you're thinking long-term of starting your own company, a management (or accounting) skill set is more useful for keeping your partners honest.
The other problem with the role ascribed to flash memory in the article is the write-wearing of flash. If flash memory decays with fewer writes than disk memory, there's a trade-off between the overall lifetime of the disk subsystem and the use of flash memory for caching/buffering. If you do most of your active writes to flash as a buffer before doing sector-based writes to magnetic disk, sure your performance is better, but you shorten the lifetime of the disk subsystem.
A more likely scenario is to have an SRAM or DRAM cache buffering the Flash memory and use a combination of flash and magnetic disk for secondary storage. Magnetic disks would also serve as offline storage.
Another impact of the continuing miniaturization of CPU features is going to be some truly humongous on-board L2 and L3 caches. I figure 6-8 cores on a single die is probably the most that is practical for connecting to a 64-bit memory and I/O system so after that point you have to start integrating more motherboard features onto the CPU die, or go to a 128-bit data bus. Eventually we may do away with system RAM completely and just have multi-gig memory modules on CPU, using flash drives as secondary storage.
Agreed that 95% isn't enough to do the job on its own and that's a pain in the butt.
But on the other hand the war between the malware and the anti-virus tools is basically the same as the war between infectious diseases and our immune systems. Our bodies are still susceptible to things like MRSA and plague, and we don't have a cure for the common cold (or the flu) yet either.
So this isn't a software _quality_ issue, it's a software _adaptability_ issue. As long as you face a moving target that mutates its behavior as you change your own, you are never going to achieve 100% detection or eradication. Think of it as the world's longest software development project with unending requirement changes and scope creep.
Well technically the protocol only changes the data based on the ascii/binary toggle. It's the FTP client that correlates these with the file type/extension, and sets the protocol mode accordingly.
In the days when all text data was ASCII, or at least standard 8-bit code pages, the ascii/binary switch was a convenience that saved running a manual step for dos2unix or whatever. Nowadays, it can still be convenient in that particular siuation, but there are so many text formats other than ascii out there now that it really doesn't make sense. The usage is too limited in comparison with the risk of corruption. Try running in ascii mode for a UTF-16 file or some other such format.
Symantec has cleaned up their performance and bloat issues in internet security 2009. I have some machines running Norton, some running McAfee, using freeware stuff like Spybot, AVG and NoScript as additional lines of defense. Norton is definitely faster and smaller than McAfee this year and doesn't put perceptible overhead on any of the machines where I have it installed, including the old Athlon single core. McAfee chews up a full core of a CPU for a minute or so when it installs updates and the full scan can take days.
The detection rates for both are still mediocre, but those vary from month to month and vendor to vendor so much that I accept anything in the 95-99% detection range. There are too many new threats to rely on reported detection rates that are more than a couple of months old. The only major vendor that I've completely ruled out for a while is CA, and a few years ago they had the best detection rates in the (pay) industry. Compensate for mediocre detection by multi-layer defenses: NoScript to prevent website attacks, Spybot to provide a cross-check against spyware (especially "commercial" spyware that commercial vendors turn a blind eye to) and so on.
On the other hand, the Symantec exec IS spreading FUD saying that the free stuff can't do the job. I just ignore that kind of crap, it's endemic to the industry. The main reason I pay for commercial products is convenience (all other things being equal on the quality front). The free stuff is either nagware that wants you to upgrade to a pay version or it isn't an integrated suite, so I have to monitor separate installations for Antivirus, Anti-spyware, Intrusion Detection, Firewall and so on.
Except OP says he's going from Windows to Windows. So unless the FTP server is configured to respond with a system type as Unix, that doesn't really fly.
I used to get dropped characters and groups of characters in text files using FTP back in the 1990s and early 21st century. It seemed to be a bug in the FTP client, because it only happened when we used the Windows Explorer interface for the product. When we did command line or used the native GUI there was no problem. If you're seeing this type of a pattern where you can see that characters are missing, switch to a different FTP client or try the Windows command line FTP.
Another possibility is that the target Windows system is mimicking a Unix system, so that an ASCII transfer is stripping the CR characters from CR/LF sequences.
On the other hand, if you really want a "guaranteed delivery" with formal acknowledgment and validation, try using a secured protocol like SSH or SFTP or a messaging system like JMS with a handshaking architecture around it. There are plenty of Open Source architectures you can build around (xBus for example), but I don't know of any ready-built executables. Commercially, vendors like IBM (MQ) and Tibco have products that deal with the messaging at a similar level.
And here we have the extremely sharp, contentious edge of the censorship debate. Is it justifiable to publish this kind of information if it will endanger someone's life? If someone decides to go ahead and publish, is it OK to erase their publication?
Slide down the razor blade of life, anyone? (Apologies to Tom Lehrer).
If the phase between the transmitters is random, which it will become if not positively locked to a reference beam, all interference disappears and the energy is dissipated in all directions.
Yeah, just what we need: direct warming of the atmosphere at a rate of 2000MW per orbital station.
It's called a phase-locked loop. The beam resonates at the desired wavelength to generate the required power levels. Without the reflection there is no resonance and hence no power.
Of course, I don't think any of these clowns really knows how well the phasing would work through 20 miles or so of turbulent atmosphere. I think maybe the technique that astronomers use to compensate for atmospheric distortion would work, but it would be complicated due to the surface area affected by the beam (more distortions to account for) plus the transmission delay between geosynchronous orbit and the ground. It's probably possible, but not a trivial issue.
I don't care about the frickin animals. I care about the fact that it's an overblown, overpriced technical solution to a problem that can be solved by less expensive means. I also disagree about the burden of proof mentioned by the GP. The burden of proof is on the developers of the new technology to show that it's (reasonably) safe, cost-effective and doesn't create more problems than it solves. Microwaving moisture-laden air just increases the level of radiation heating the earth's atmosphere for global warming by that little bit. And the more widespread the technology becomes the worse the problem will be.
By contrast, nuclear doesn't add any heat that isn't already in the system, and Wind and Solar basically recycle energy that has already been added directly by the sun.
Running power plants from orbit? Why? Spongebob, Why? Put em on the ground and save the (environmental/financial) cost of lifting all that stuff into orbit.
lots of pissed birds, bats, pollen and insects too. Actually I think they'll be parboiled.
Speaking of which, if this is taking solar radiation that would otherwise miss earth and transmit it down through the atmosphere, isn't it actually _increasing_ global warming?
Combined with the cost of getting all the orbital and terrestrial pieces together and this sounds sub-optimal on so many levels. Even if they can pull it off technologically, I don't see how they can get regulatory approval.
That FTP IS stupid. They should switch to SFTP and require digital certificates to connect, so they can authenticate connections without compromising login credentials.
Masking passwords, logging off the user on non-use after ten minutes, and other such security methods do not actually decrease the chance of compromise significantly when the user has physical security. Websites should allow for this.
You mean you'd trust the average user to make a security decision about whether a website should show them their password in cleartext? The only users who could be trusted with that authority are the ones who are security-conscious enough to recognize the value of having the password masked or completely hidden, and therefore have no need to turn it off, even when they're in a situation where such masking isn't required.
Remember, these are the same users that fill their PCs up with so much crap and malware that the guys at Geek Squad are still in business.
Slashdot Mirror
Am I being overly paranoid and resistant to change? You're not being "overly" paranoid, but your paranoia is poorly focused. The remote access issue doesn't increase your exposure to unethical sysadmins. If the admins are going to steal your data, all they have to do is make a "bad" backup tape and walk out of the building with it. The remote access increases your exposure to hackers and other Slashdot readers due to the open port on the internet. If you already have a remote access feature for your own employees, letting the outsourcing company use that gateway isn't really adding to your risk.
Should we just trust our administrator because they have a reputation to uphold? No you should trust your system administrator because your contract specifies stringent penalties they will be required to pay if they violate your trust. You should trust them because they are contractually obligated to provide on demand network access logs for all of their personnel showing the systems, directories, files, databases and tables that were accessed. You trust them because you vet their remote employees accessing your systems with the same security scrutiny you would perform on their employees with physical access to your site. You trust them because your firewall rules can restrict access to your most critical systems to specific addresses on the contractor's space. You trust them because your contract manager has the technical chops or the technical staff to know when you're being bullshitted.
In other words, don't just trust them. Treat them like any other "arms length" business partner.
Or should we lock them out and make them administer the network in person so we can stand behind and watch them? If you go this way, your cost savings pretty much disappear. Cost will be comparable to leasing your computer HW and having your own IT staff. The lease option may be better for your peace of mind.
He's just torrenting porn...
Maybe it's the Love Shack?
Don't forget your jukebox money.
If the platform is incompatible with the GPL, you can't release GPL software on it. They aren't violating the spirit or the letter of the GPL by charging for the software, but I think the "installer" issue is more critical. Unless they start distributing the jailbreak software and its source code, along with installation scripts required to load their app on a jailbroken phone, the end user has no way to install a modified version of the program on the target platform by building from the source code they provide. Since providing the jailbreak software is a violation of Apple's TOS, it looks like they are caught between the App Store TOS and the GPL.
If they were distributing their app for another platform that didn't encrypt the installation process, they'd be in the clear.
I thought Apple had banned GPL licensed SW from the App store....
Items created/published by the U.S. government are in the public domain at least in the U.S. I'm not sure if the rights are granted abroad as well.
However, items created under a contract to the U.S. government may or may not be in the public domain. There's a section of US law that companies have to invoke in their contract or the software license regarding U.S. government "limited rights" to keep their code or other work private. On the other hand, NIST DATA shouldn't be copyrightable in any case, although companies still like to test the theory that their databases are copyrighted fairly frequently.
I am not a lawyer. Even if I were a lawyer, I'm not YOUR lawyer. The above discussion is mostly intended to point out that you're more likely to get a better deal for data out of the government than out of a private company. If you need pre-built software from a private firm, you're likely to be tied into a license agreement that affirms copyright over the data or its storage format (or both), which could be a source of disagreement with the software vendor if you decide to follow your plan of extracting the data for your own use.
Should have a few words to say on this issue. After all, they bought up Lotus.
Asking someone to sign a non-disclosure contract to vet an idea is only crass if you don't offer to pay them. If your idea is "interesting" enough to go to the effort of an NDA, it should be interesting enough to put a little cash down to support.
But maybe before going to a subject matter expert, you can do a little informal market and pricing research. Ask your friends how much they would pay for a product based on your idea, if they would buy it at all. See if that fits in the ballpark for how much it would take to manufacture and deliver it. If something will cost $20 to make, it probably won't fly even if your friends are willing to pay $20 for it, since you still have to cover overhead, advertising and so on. Your margins have to be high enough to cover those costs plus recover your startup costs within about a year to a year and a half depending on your sales volume. High margins are a double-edged sword, though. It makes it harder to justify the price in the consumer's mind, plus it provides an incentive for competitors to enter the market.
But the main thing is, if you want to vet your idea, there are several aspects to explore informally before you have to shell out for expert opinion.
There isn't any security tool in the world that adequately protects against interception by a keylogger or any other tool that can read the "cleartext", the way you describe here. So knocking it for risk due to interception the way you describe is a bit of a strawman argument.
There are several factors in this tool that give it bigger security than you describe:
1) If the entire transaction is handled in SSL, they have to crack a layer of encryption just to be able to see the challenge pattern and response code.
2) The number of combined challenges and responses is bigger than you describe, since it depends a) the challenge pattern, b) the alignment of the challenge pattern within the screen template and c) the decoding pattern on the card.
3) The lifetime of the "onetime pad" is limited to the CC expiration date when a new card would be issued. If you're a business user that does hundreds of online transactions a month, this won't help. But for the average consumer that maybe does 10 online transactions a month, you generate less than 500 CC transactions in 4 years (the life of a typical card). So as long as the number of available combinations is on the order of 1,000 they won't be repeated for most users and can replace the entire set of available CCVs on a single card. And what hacker is going to wait around 4 years to gather enough encrypted data to crack the card when all they need is a couple months worth of transactions from a card using a CCV?
On the flip side, the possible pattern combinations will probably not turn out to be completely random, so if there are only 1,000 combinations, the response to a pattern could probably be predicted after only 100 or 200 observations.
But looking at a sample pattern on the demo site, it looks like the number of patters is more on the order of 100,000 or higher. It looks like they overlay a 10-digit 7-segment pattern with another 9-digit one (i.e. the right hand side of the first digit of the 10-digit pattern lines up with the left segment of the 9-digit pattern). Since the return value is 6 digits, it's probably designed so that the entire 1 000 000 value space for 6 digit numbers is available for any given card. That would make the security of the system on the same order as battery-powered PIN cards, without relying on a timer (which required clock alignment) or a push-button (which can be thrown off if the button is pushed without using the code). Not to mention enviro-friendliness of not putting lithium batteries out there.
When considered relative to the CC Card CCV and PIN that is commonly in use, it's hundreds of times better, since those are constant, so any MITM automatically knows that every response with the same CC number has the same cleartext.
So: no, not a perfect security solution, but hundreds of times better than constant-valued CCV or PIN.
Unless they're on an old COBOL system or a derivative of such. In which case, they're probably storing as compact BCD (2 decimal digits per byte). Which could be how the spaces passed validation.
Must be her new gig now that she's resigned as Gov.
A senior technical person and a junior manager or project manager in the tech team basically have to deal with the same political, financial and people management issues anyway. If there's a problem with the schedule, or the skill set of one of the junior team members, both the tech lead and the manager have to come up with a plan and deal with it. The difference is in the perspective they need to bring to the table. The tech lead should be focused more (but not exclusively) on the "best possible" resolution to an issue, whether that is more training for the team or adjusting the schedule to ensure a quality product. The manager/PM will be more concerned with the costs and deadlines and getting the most out of the team possible within those constraints. The two need to have enough common ground to understand the constraints and requirements from both perspectives and recognize which ones take precedence in a given situation. So would you rather risk dealing with a lousy tech lead as a manager, or dealing with a lousy manager as a tech lead?
The promotion ladder is longer in management, but it's harder to get a job back if you get cut, because management skills tend to be more common. So apart from which job is more enjoyable, you might want to think about weighing your future promotion chances vs. the risk of job cuts. Also, if you're thinking long-term of starting your own company, a management (or accounting) skill set is more useful for keeping your partners honest.
The other problem with the role ascribed to flash memory in the article is the write-wearing of flash. If flash memory decays with fewer writes than disk memory, there's a trade-off between the overall lifetime of the disk subsystem and the use of flash memory for caching/buffering. If you do most of your active writes to flash as a buffer before doing sector-based writes to magnetic disk, sure your performance is better, but you shorten the lifetime of the disk subsystem.
A more likely scenario is to have an SRAM or DRAM cache buffering the Flash memory and use a combination of flash and magnetic disk for secondary storage. Magnetic disks would also serve as offline storage.
Another impact of the continuing miniaturization of CPU features is going to be some truly humongous on-board L2 and L3 caches. I figure 6-8 cores on a single die is probably the most that is practical for connecting to a 64-bit memory and I/O system so after that point you have to start integrating more motherboard features onto the CPU die, or go to a 128-bit data bus. Eventually we may do away with system RAM completely and just have multi-gig memory modules on CPU, using flash drives as secondary storage.
Agreed that 95% isn't enough to do the job on its own and that's a pain in the butt.
But on the other hand the war between the malware and the anti-virus tools is basically the same as the war between infectious diseases and our immune systems. Our bodies are still susceptible to things like MRSA and plague, and we don't have a cure for the common cold (or the flu) yet either.
So this isn't a software _quality_ issue, it's a software _adaptability_ issue. As long as you face a moving target that mutates its behavior as you change your own, you are never going to achieve 100% detection or eradication. Think of it as the world's longest software development project with unending requirement changes and scope creep.
Well technically the protocol only changes the data based on the ascii/binary toggle. It's the FTP client that correlates these with the file type/extension, and sets the protocol mode accordingly.
In the days when all text data was ASCII, or at least standard 8-bit code pages, the ascii/binary switch was a convenience that saved running a manual step for dos2unix or whatever. Nowadays, it can still be convenient in that particular siuation, but there are so many text formats other than ascii out there now that it really doesn't make sense. The usage is too limited in comparison with the risk of corruption. Try running in ascii mode for a UTF-16 file or some other such format.
Symantec has cleaned up their performance and bloat issues in internet security 2009. I have some machines running Norton, some running McAfee, using freeware stuff like Spybot, AVG and NoScript as additional lines of defense. Norton is definitely faster and smaller than McAfee this year and doesn't put perceptible overhead on any of the machines where I have it installed, including the old Athlon single core. McAfee chews up a full core of a CPU for a minute or so when it installs updates and the full scan can take days.
The detection rates for both are still mediocre, but those vary from month to month and vendor to vendor so much that I accept anything in the 95-99% detection range. There are too many new threats to rely on reported detection rates that are more than a couple of months old. The only major vendor that I've completely ruled out for a while is CA, and a few years ago they had the best detection rates in the (pay) industry. Compensate for mediocre detection by multi-layer defenses: NoScript to prevent website attacks, Spybot to provide a cross-check against spyware (especially "commercial" spyware that commercial vendors turn a blind eye to) and so on.
On the other hand, the Symantec exec IS spreading FUD saying that the free stuff can't do the job. I just ignore that kind of crap, it's endemic to the industry. The main reason I pay for commercial products is convenience (all other things being equal on the quality front). The free stuff is either nagware that wants you to upgrade to a pay version or it isn't an integrated suite, so I have to monitor separate installations for Antivirus, Anti-spyware, Intrusion Detection, Firewall and so on.
Except OP says he's going from Windows to Windows. So unless the FTP server is configured to respond with a system type as Unix, that doesn't really fly.
Send the $20 to the EFF.
I used to get dropped characters and groups of characters in text files using FTP back in the 1990s and early 21st century. It seemed to be a bug in the FTP client, because it only happened when we used the Windows Explorer interface for the product. When we did command line or used the native GUI there was no problem. If you're seeing this type of a pattern where you can see that characters are missing, switch to a different FTP client or try the Windows command line FTP.
Another possibility is that the target Windows system is mimicking a Unix system, so that an ASCII transfer is stripping the CR characters from CR/LF sequences.
On the other hand, if you really want a "guaranteed delivery" with formal acknowledgment and validation, try using a secured protocol like SSH or SFTP or a messaging system like JMS with a handshaking architecture around it. There are plenty of Open Source architectures you can build around (xBus for example), but I don't know of any ready-built executables. Commercially, vendors like IBM (MQ) and Tibco have products that deal with the messaging at a similar level.
And here we have the extremely sharp, contentious edge of the censorship debate. Is it justifiable to publish this kind of information if it will endanger someone's life? If someone decides to go ahead and publish, is it OK to erase their publication?
Slide down the razor blade of life, anyone? (Apologies to Tom Lehrer).
If the phase between the transmitters is random, which it will become if not positively locked to a reference beam, all interference disappears and the energy is dissipated in all directions.
Yeah, just what we need: direct warming of the atmosphere at a rate of 2000MW per orbital station.
It's called a phase-locked loop. The beam resonates at the desired wavelength to generate the required power levels. Without the reflection there is no resonance and hence no power.
Of course, I don't think any of these clowns really knows how well the phasing would work through 20 miles or so of turbulent atmosphere. I think maybe the technique that astronomers use to compensate for atmospheric distortion would work, but it would be complicated due to the surface area affected by the beam (more distortions to account for) plus the transmission delay between geosynchronous orbit and the ground. It's probably possible, but not a trivial issue.
I don't care about the frickin animals. I care about the fact that it's an overblown, overpriced technical solution to a problem that can be solved by less expensive means. I also disagree about the burden of proof mentioned by the GP. The burden of proof is on the developers of the new technology to show that it's (reasonably) safe, cost-effective and doesn't create more problems than it solves. Microwaving moisture-laden air just increases the level of radiation heating the earth's atmosphere for global warming by that little bit. And the more widespread the technology becomes the worse the problem will be.
By contrast, nuclear doesn't add any heat that isn't already in the system, and Wind and Solar basically recycle energy that has already been added directly by the sun.
Running power plants from orbit? Why? Spongebob, Why? Put em on the ground and save the (environmental/financial) cost of lifting all that stuff into orbit.
lots of pissed birds, bats, pollen and insects too.
Actually I think they'll be parboiled.
Speaking of which, if this is taking solar radiation that would otherwise miss earth and transmit it down through the atmosphere, isn't it actually _increasing_ global warming?
Combined with the cost of getting all the orbital and terrestrial pieces together and this sounds sub-optimal on so many levels. Even if they can pull it off technologically, I don't see how they can get regulatory approval.
That FTP IS stupid. They should switch to SFTP and require digital certificates to connect, so they can authenticate connections without compromising login credentials.
Masking passwords, logging off the user on non-use after ten minutes, and other such security methods do not actually decrease the chance of compromise significantly when the user has physical security. Websites should allow for this.
You mean you'd trust the average user to make a security decision about whether a website should show them their password in cleartext? The only users who could be trusted with that authority are the ones who are security-conscious enough to recognize the value of having the password masked or completely hidden, and therefore have no need to turn it off, even when they're in a situation where such masking isn't required.
Remember, these are the same users that fill their PCs up with so much crap and malware that the guys at Geek Squad are still in business.