It helps if the vulnerability isn't being actively exploited, and if it gives you time to fix up the critical root and TLD nameservers before the script kiddies even know about it.
None of this changes the behavior of ISC with respects to disseminating information regarding newly discovered (but not widely known or exploited) vulnerabilties. Not at all! Presently stuff like this is discovered, patches written, root- and TLD-nameservers are upgraded, and *then* the vulnerability is announced and upgraded provided to the general public. All they're wanting to do is make that process official by creating a membership that includes other critical infrastructure parties and vendors into that list of people that get early warnings.
If I had a RedHat system, I know it would be very nice to see an urgent advisory like this appear and have RPM's ready and waiting for me to install to secure my system. At the moment, everyone has to rely on source code. What if you're merely using a BIND-derived nameserver? You have to wait for your vendor to release their own version, which can be a pretty scary thing. This simply aims to eliminate that problem.
We're talking about root- and top-level-nameservers here, not second-level domains. Things like ".", "EDU.", "ORG.", "COM.", etc., are the ones we're worried about. The critical infrastructure needs to be addressed first. The second-level stuff can (in cases such as this) wait for the public announcement.
Quite the opposite. By creating a membership group that can be granted (in some cases) a bit of advance notice with respects to vulnerabilities not widely known or exploited, he ensures that vendors will have updated versions of Bind-based software readily available when the time comes to announce it. This effectively overcomes both of your points, at least to the point it can. Nobody can force an SA to upgrade his machine, but by providing vendors access to this information ahead of time, you can bet the vendor will be able to do all it can to be sure he knows about it, and can have the upgrade readily available to make the required fix. In the past (and, well, today really) this was/is very difficult to organize.
How many clueful admins do you think will run BIND in 2002?
I suspect quite a lot. Bind 8 will be relegated to the same places Bind 4 is now, and Bind 9 (again, a total re-write) will enter increasing use as a replacement for Bind 8. To date its power, stability and adherence to standards is unmatched.
Note that I'm all for heterogenity, especially in critical things like this, but don't bash Bind as a whole based upon a codebase that will be finding its way into obsolescence soon.
In this case, where a vulnerability is found by someone with less-than-good intentions, you're absoultely right: a membership like this won't do a bit of good, and I can't imagine that they would even try to delay any announcement in a situation like this, opting instead to place a priority on getting a patch written and applied to the critical infrastructure as quickly as possible.
ISC has always been up-front with security issues with bind. They have delayed announcement of some quieter yet severe vulnerabilities in the past, to ensure that things like the root nameservers are all patched up first, but they've always done what they could to make that interrim as short as possible, because if they found the vulnerability, others can too. They're not even talking about extending that interrim, only expanding the circle of people that get to use it.
Except in this case, the "lead time" we're talking about can't be more than a week or so. The membership I also imagine will be rather tightly controlled, and if it becomes a problem, I'm sure it'll just be disbanded and we'll be back to an informal "patch the root servers first, then worry about everyone else" policy. No net loss here.
A "pre-release" group like this obviously won't do much good in the case where a vulnerability is discovered and is being actively exploited in the wild. That's not what it's there for. It's for those vulnerabilities that are discovered quietly, where the script kiddies haven't figured it out yet or exploits are otherwise not being used. In cases like that, the only sane thing to do is be sure the critical infrastructure is patched first, *then* move on to releasing the information to the general public. All they're doing is defining "critical infrastructure" and including vendors in that list, so that when the vulnerability *is* announced, people don't have to go compiling source code to secure their systems; their vendors will have an upgrade path all ready for them.
And we're not talking about a significant amount of time here. All they want to do is give a sufficient lead time to the systems that matter the most, and have everything ready for a quick and painless upgrade for the rest of us that need it.
If we don't give the vendors any lead time before these vulnerabilities (which are not necessarily being actively exploited) are announced, how can upgrades like this be possible?
Membership to this ISC group will be very tightly controlled and limited to those organizations that provide critical DNS infrastructure or are vendors that need lead-time to build and prepare updates to their clients. I suspect you are neither, and will have to wait for the public announcement of a security fix like the rest of us.
Note that they're not "hiding" this information. Stuff that isn't being actively exploited can stand to wait a few more days before being released, so that our critical infrastructure can be fixed up first. All they're doing is formalizing that process with an official membership roster.
This doesn't make any sense. You would rather risk the root- and TLD servers because you have some personal issues with one of the operators?
This is why people like you do not run our Internet infrastructure, and run things like EFnet IRC servers instead. Such attitudes are apparently a pre-requisite for that, but have no place for things of critical importance like our top-level DNS infrastructure. Personal issues aside, has Paul Vixie ever acted in a dangerous/untrustworthy way with respects to security issues of critical importance?
Yet nobody talked this time. Your logic is flawed. Not all vulnerabilities make their way to IRC skr1pt k1dd33Z first. Occasionally the Good Guys hear about it first, and they do the only sane and logical thing: Get some patches written, get the patches applied to the critical infrastructure, and then start disseminating the information, starting with the operational/infrastructure crowd. In this case the root servers were patched about a week before anyone else ever heard there was a bug, and there's no indication that this was ever actively exploited prior to that announcement. I'd say the system worked beautifully this time.
All they're recommending with the creation of this membership is "officializing" the "root servers first" policy, and including certain vendors and high-priority organizations in that list. I think it's a perfectly sane and needed extension of their existing policies. When news broke, not an updated RPM was to be found with the fixed version of bind. That shouldn't be.
The very fact that these vulnerabilities were discovered in the first place is a testament to Open Source. It's just that in cases like this, the discoverer would choose to contact the vendor/author about the problem rather than going to all his l33t IRC friends. A patch was written, the critical infrastructure was fixed, and then the information was released to the general public.
This sounds like the perfect way to solve a vulnerability, and is indeed a positive thing for Open Source. I don't think a membership like this even qualifies as anti-Full Disclosure.
We're not talking about a closed list, or hiding vulnerabilities. This is just a membership to allow certain "high-priority" sites the ability to receive critical infrastructure updates before these are known to the general public (thus the script kiddies). It's about delaying the announcement in an organized and official way, instead of an ad-hoc "let's get the root servers patched up first, then release the advisory" way. They're just making this policy official and expanding the circle of people that know about these updates to include certain vendors.
Something tells me that any actively exploited vulnerabilities won't be subject to the same waiting periods they're proposing for this members list than vulnerabilities which have been discovered in a lab or in private that are not yet known/actively exploited.
It's just common sense. It doesn't serve anybody at all any good to sit on information for a few days if it's being actively exploited.
And remember, we're not talking about anything new here. ISC typically shores up root name servers immediately with patches/updates when vulnerabilities are discovered. Only *then* do they worry about disseminating vulnerability information to the general public. Get the infrastructure fixed first, then worry about everyone else. All he was proposing here is a way to make this official, and figure out a way of getting other "high-priority" people involved in it as well.
Or you can drop Bind 8 in favor of Bind 9. It's a total re-write (as all major version number changes should be), and never had an issue with this bug. The Bind 8 codebase is already over 4 years old, and the availability of exploits, the methodology used in building and distributing these exploits, and the ability of those willing to share these exploits with script kiddies has changed quite a lot in 4 years. Like these alternative name server implementations, Bind 9 was written with these issues firmly in mind.
Not that I'm trying to turn anyone away from an alternative implementation. Heterogenity is a good thing. It's just that with respects to Bind 8, Bind 9 is essentially a completely different product.
What does this have to do with security through obscurity? We're not talking about hiding the existince of these bugs. Root name server operators are already given about a week advance notice on critical yet unreported bugs of this magnitude for precisely the same reason this member's list is suggested. While stuff that's actively "blown up" and being exploited doesn't benefit from this, there's still lots of stuff that isn't widely known (or known at all) that can stand to wait another week before it's announced, to give our infrastructure time to shore up before it's made public. There's nothing about "obscurity" here.
Something tells me a) ISC is going to do a little bit better job of administering this members list than your random Slashdot kiddie will, so odds are, these script kiddies you speak of will not find their way on the list; b) Even if they could con their way in, I'm thinking the membership fees might be a little pricey for them; and c) when they are discovered, it's all revoked, and they're not likely to get back in.
But I think the membership requirements are going to stop them long before anything else.
I guess it depends on your line of work more than anything.. I maintain the infrastructure for the external web sites for a major communications company, and I work in a group with over a dozen "web techies" like myself, and while we do have a few occasional telecommuters among us, the concensus is that it would be far too difficult for us to do our jobs from home.
Many (like myself) even go so far as to indicate that they'd lack the self-discipline to get as much done working from home as they would in the office. The work atmosphere is great there.
On the development side of the house (numbering in the hundreds of developers building web content), only a miniscule portion of them telecommute, and this is mainly out of necessity (office space is at a premium!).
I mean don't get me wrong, I imagine some of us would like to telecommute if given the opportunity, but my own practical experiences in corporate IT differ from these results.
And again, it might just be the type of work, and the type of company I work for.. I just can't help but wonder where the bias in this poll is.
I doubt this post will get much attention since the article is already at least a day old, but how much of this is in public record? The search warrant itself must have a judge's name on it, and the guy had to sign the warrant and get his own copy of it. Can he contact the judge's office and get additional information on why the warrant was granted?
Even if this type of request has to wait until the investigation is over, I would still be very interested in the information law enforcement provided to the judge to make him/her agree that the search warrant was necessary. I think, with that information, we will either know some true/additional reasons behind this, or we will know that something in our legal/judicial system needs to be addressed.
like, dude!!!! cash is, like, totally still legal tender and stuff!@!#% I can get along without a credit card fine!!! If I don't have a driver's license (which isn't MANDATORY), I just can't DRIVE. that doesn't, like, affect my purchasing abilities. I can still get a JOB. I can still sustain my survival. I don't think there is a single "privacy-invading" piece of technology that is a requirement in my life.
Your articles seem to focus around what could be done with this technology, not around what will be done. How many times in the last 50 years have we seen a new piece of technology that could be misused to destroy the lives and privacy of everyone in the country? How many times has that actually happened? Thanks, but if I read another article about how we should reject this technology because they will start carrying serial numbers with '666' in them, I'm going to vomit.
Stop judging things based on what COULD happen. If you're worried that your evil government is going to mandate that these things be implanted, perhaps it's time you moved to a new country or replaced the one you have.
Rad the effing article yourself, you pompous poot.
For the record, you're the one that started the personal attacks, not me.
What percentage of the voting public (now down to what? 30%?) has any say in what politicians do anyway, these days?
How many letters have you written to your congressmen? This attitude quite frankly sucks. The people you elected to those positions are there to be your voice in the government. If you're really buying into that whole "politicians are working for big companies against their constituents", perhaps you need to vote somebody better into office or write a letter or two.
Personally, I don't buy it. Every letter I've written to my congressmen has been replied to personally, with his own thoughts and information. Work WITH them, not AGAINST them.
Sheesh.. from the actual web page:
Stop nit-picking. If you disagree with something I've said, by all means present an argument. The size difference between a grain of rice and a dime makes no difference as far as my argument is concerned. From their press release:
Those attending the event in New York City will see a working, multimedia demonstration of Digital Angel's technological building blocks. A miniature sensor device -- smaller than a grain of rice and equipped with a tiny antenna -- will capture and wirelessly transmit a person's vital body-function data, such as body temperature or pulse, to an Internet-integrated ground station.
I'm sure different feature packages will result in a device that's a different size.
A side effect? If you consider being able to be tracked, real-time, via a radio-based network a "side effect" you're 'way more trusting than I am, or than the majority of posters here..
I can't tell if you really don't understand what I was saying or are deliberately trying to misunderstand.
All I was saying is that their research has been focused on providing biometric data to nearby base stations. The fact that they now have a small device capable of transmitting data now means that they can use it as a location device. They did not approach this research with a lets-track-the-public mind-set. That's what I meant by "side-effect". It was not the focus of their research, but it's certainly a marketable feature.
Well, I seriously believe you'd buy into anything anyone wanted to put over on you...
Again, if you want to refute my statement, by all means let's hear your argument. Remember that cell phones put out a rather large amount of RF energy and get very hot and use up a lot of electricity doing so. Scale that down to something the size of a dime or a grain of rice, and the number of required cell-phone-type towers goes up by at least 1 or 2 orders of magnitude. The costs involved would be prohibitive.
I really am shocked at the tremendously poor quality of posts on this thread. It's clear that very few people actually read the information on the site or even tried to think logically about any of this.
1. This will eventually be mandatory and The Man will track us wherever we go! This seems to be the chief conspiracy theory. Let's think about this for a moment. What percentage of the voting public would desire or permit the government to mandate implanted tracking devices? If somehow the evil government broke away from the people and started trying to force this upon its people, how many would take up arms against it? I WOULD. I may be trying to speak in defense of this project here (only because there's an overwhelmingly uninformed body against it at the moment), but I would certainly fight any attempt at mandating tracking devices in our bodies. This is just stupid to even consider.
2. The devices can communicate with satellites and track us all with GPS! Another poster mentioned this, but he was quickly rebuffed by another uninformed poster, but do you really think we have the technology to shrink down a fully functional GPS receiver into a device the size of a grain of rice? The smallest GPS receiver I've ever seen was built into a wristwatch, and it was the bulkiest watch I've ever seen in my life. The best we can do is something the size of about 3 AA batteries, and you've still gotta have a good antenna and a clear view of the sky for it to work. What they're saying by linking the devices up to GPS technology is the same sort of "GPS tracking" they're planning on building into your phones: conventional base-station triangulation linked against known GPS information.
3. All of the RF radiation from these things will kill us, like our cell phones are! Do you really think a rice-sized device is going to put out as much RF energy as your cell phone? This thing is powered off of what little energy it can get from muscle movement. Have you also noticed how HOT your cell phone gets pumping out all that energy? Putting out 750mw of power from a grain of rice will cook your flesh quite effectively. I'll talk more about this topic below.
4. Why do these tracking devices need to be implanted, anyway? READ THE PAGE! The primary use for these things is for BIOMETRIC SENSING. Location is simply a side-effect and a nifty other purpose. They specifically say on their site that the biometric sensing devices are meant to be implanted or bonded close to the body SO THAT IT CAN COLLECT BIOMETRIC DATA. These things aren't about tracking the human population, they're about things that are legitimately useful. Do you really think a company is going to be very successful marketing an implanted people tracking device?
I seriously doubt there is going to be a significant "global network" capable of receiving transmissions from these devices such as what you're seeing with cell phones. The devices are small and extremely low-power, so they can't transmit far, and they were built for biometrics sensing. I don't have any more information from you, but calling on my meager yet sufficient store of COMMON SENSE, I can figure out that they are planning on using these things inside buildings, hospitals perhaps, or when out of doors, "base stations" would be located on mobile vehicles, which would drive around, listening for signals it's looking for and collecting the data/location.
This makes these devices quite useful for things like hospital patient monitoring, lost children, pets and endangered animals, since the base station is either positioned near the devices, or can be relocated in small area to search.
This does not make these devices useful for these stupid human implant tracking device conspiracy theories.
Can we please use a little more common sense and think through some of this stuff before we go frothing at the mouth about all of the phantom evils this new technology spawns?
It helps if the vulnerability isn't being actively exploited, and if it gives you time to fix up the critical root and TLD nameservers before the script kiddies even know about it.
None of this changes the behavior of ISC with respects to disseminating information regarding newly discovered (but not widely known or exploited) vulnerabilties. Not at all! Presently stuff like this is discovered, patches written, root- and TLD-nameservers are upgraded, and *then* the vulnerability is announced and upgraded provided to the general public. All they're wanting to do is make that process official by creating a membership that includes other critical infrastructure parties and vendors into that list of people that get early warnings.
If I had a RedHat system, I know it would be very nice to see an urgent advisory like this appear and have RPM's ready and waiting for me to install to secure my system. At the moment, everyone has to rely on source code. What if you're merely using a BIND-derived nameserver? You have to wait for your vendor to release their own version, which can be a pretty scary thing. This simply aims to eliminate that problem.
We're talking about root- and top-level-nameservers here, not second-level domains. Things like ".", "EDU.", "ORG.", "COM.", etc., are the ones we're worried about. The critical infrastructure needs to be addressed first. The second-level stuff can (in cases such as this) wait for the public announcement.
Quite the opposite. By creating a membership group that can be granted (in some cases) a bit of advance notice with respects to vulnerabilities not widely known or exploited, he ensures that vendors will have updated versions of Bind-based software readily available when the time comes to announce it. This effectively overcomes both of your points, at least to the point it can. Nobody can force an SA to upgrade his machine, but by providing vendors access to this information ahead of time, you can bet the vendor will be able to do all it can to be sure he knows about it, and can have the upgrade readily available to make the required fix. In the past (and, well, today really) this was/is very difficult to organize.
How many clueful admins do you think will run BIND in 2002?
I suspect quite a lot. Bind 8 will be relegated to the same places Bind 4 is now, and Bind 9 (again, a total re-write) will enter increasing use as a replacement for Bind 8. To date its power, stability and adherence to standards is unmatched.
Note that I'm all for heterogenity, especially in critical things like this, but don't bash Bind as a whole based upon a codebase that will be finding its way into obsolescence soon.
In this case, where a vulnerability is found by someone with less-than-good intentions, you're absoultely right: a membership like this won't do a bit of good, and I can't imagine that they would even try to delay any announcement in a situation like this, opting instead to place a priority on getting a patch written and applied to the critical infrastructure as quickly as possible.
ISC has always been up-front with security issues with bind. They have delayed announcement of some quieter yet severe vulnerabilities in the past, to ensure that things like the root nameservers are all patched up first, but they've always done what they could to make that interrim as short as possible, because if they found the vulnerability, others can too. They're not even talking about extending that interrim, only expanding the circle of people that get to use it.
Except in this case, the "lead time" we're talking about can't be more than a week or so. The membership I also imagine will be rather tightly controlled, and if it becomes a problem, I'm sure it'll just be disbanded and we'll be back to an informal "patch the root servers first, then worry about everyone else" policy. No net loss here.
A "pre-release" group like this obviously won't do much good in the case where a vulnerability is discovered and is being actively exploited in the wild. That's not what it's there for. It's for those vulnerabilities that are discovered quietly, where the script kiddies haven't figured it out yet or exploits are otherwise not being used. In cases like that, the only sane thing to do is be sure the critical infrastructure is patched first, *then* move on to releasing the information to the general public. All they're doing is defining "critical infrastructure" and including vendors in that list, so that when the vulnerability *is* announced, people don't have to go compiling source code to secure their systems; their vendors will have an upgrade path all ready for them.
And we're not talking about a significant amount of time here. All they want to do is give a sufficient lead time to the systems that matter the most, and have everything ready for a quick and painless upgrade for the rest of us that need it.
That's the idea:
rpm --upgrade bind*
If we don't give the vendors any lead time before these vulnerabilities (which are not necessarily being actively exploited) are announced, how can upgrades like this be possible?
Membership to this ISC group will be very tightly controlled and limited to those organizations that provide critical DNS infrastructure or are vendors that need lead-time to build and prepare updates to their clients. I suspect you are neither, and will have to wait for the public announcement of a security fix like the rest of us.
Note that they're not "hiding" this information. Stuff that isn't being actively exploited can stand to wait a few more days before being released, so that our critical infrastructure can be fixed up first. All they're doing is formalizing that process with an official membership roster.
It didn't leak this time. The root nameservers were patched a week before word was released. I think that speaks for itself.
This doesn't make any sense. You would rather risk the root- and TLD servers because you have some personal issues with one of the operators?
This is why people like you do not run our Internet infrastructure, and run things like EFnet IRC servers instead. Such attitudes are apparently a pre-requisite for that, but have no place for things of critical importance like our top-level DNS infrastructure. Personal issues aside, has Paul Vixie ever acted in a dangerous/untrustworthy way with respects to security issues of critical importance?
Yet nobody talked this time. Your logic is flawed. Not all vulnerabilities make their way to IRC skr1pt k1dd33Z first. Occasionally the Good Guys hear about it first, and they do the only sane and logical thing: Get some patches written, get the patches applied to the critical infrastructure, and then start disseminating the information, starting with the operational/infrastructure crowd. In this case the root servers were patched about a week before anyone else ever heard there was a bug, and there's no indication that this was ever actively exploited prior to that announcement. I'd say the system worked beautifully this time.
All they're recommending with the creation of this membership is "officializing" the "root servers first" policy, and including certain vendors and high-priority organizations in that list. I think it's a perfectly sane and needed extension of their existing policies. When news broke, not an updated RPM was to be found with the fixed version of bind. That shouldn't be.
The very fact that these vulnerabilities were discovered in the first place is a testament to Open Source. It's just that in cases like this, the discoverer would choose to contact the vendor/author about the problem rather than going to all his l33t IRC friends. A patch was written, the critical infrastructure was fixed, and then the information was released to the general public.
This sounds like the perfect way to solve a vulnerability, and is indeed a positive thing for Open Source. I don't think a membership like this even qualifies as anti-Full Disclosure.
We're not talking about a closed list, or hiding vulnerabilities. This is just a membership to allow certain "high-priority" sites the ability to receive critical infrastructure updates before these are known to the general public (thus the script kiddies). It's about delaying the announcement in an organized and official way, instead of an ad-hoc "let's get the root servers patched up first, then release the advisory" way. They're just making this policy official and expanding the circle of people that know about these updates to include certain vendors.
Something tells me that any actively exploited vulnerabilities won't be subject to the same waiting periods they're proposing for this members list than vulnerabilities which have been discovered in a lab or in private that are not yet known/actively exploited.
It's just common sense. It doesn't serve anybody at all any good to sit on information for a few days if it's being actively exploited.
And remember, we're not talking about anything new here. ISC typically shores up root name servers immediately with patches/updates when vulnerabilities are discovered. Only *then* do they worry about disseminating vulnerability information to the general public. Get the infrastructure fixed first, then worry about everyone else. All he was proposing here is a way to make this official, and figure out a way of getting other "high-priority" people involved in it as well.
Or you can drop Bind 8 in favor of Bind 9. It's a total re-write (as all major version number changes should be), and never had an issue with this bug. The Bind 8 codebase is already over 4 years old, and the availability of exploits, the methodology used in building and distributing these exploits, and the ability of those willing to share these exploits with script kiddies has changed quite a lot in 4 years. Like these alternative name server implementations, Bind 9 was written with these issues firmly in mind.
Not that I'm trying to turn anyone away from an alternative implementation. Heterogenity is a good thing. It's just that with respects to Bind 8, Bind 9 is essentially a completely different product.
What does this have to do with security through obscurity? We're not talking about hiding the existince of these bugs. Root name server operators are already given about a week advance notice on critical yet unreported bugs of this magnitude for precisely the same reason this member's list is suggested. While stuff that's actively "blown up" and being exploited doesn't benefit from this, there's still lots of stuff that isn't widely known (or known at all) that can stand to wait another week before it's announced, to give our infrastructure time to shore up before it's made public. There's nothing about "obscurity" here.
But I think the membership requirements are going to stop them long before anything else.
I guess it depends on your line of work more than anything.. I maintain the infrastructure for the external web sites for a major communications company, and I work in a group with over a dozen "web techies" like myself, and while we do have a few occasional telecommuters among us, the concensus is that it would be far too difficult for us to do our jobs from home.
Many (like myself) even go so far as to indicate that they'd lack the self-discipline to get as much done working from home as they would in the office. The work atmosphere is great there.
On the development side of the house (numbering in the hundreds of developers building web content), only a miniscule portion of them telecommute, and this is mainly out of necessity (office space is at a premium!).
I mean don't get me wrong, I imagine some of us would like to telecommute if given the opportunity, but my own practical experiences in corporate IT differ from these results.
And again, it might just be the type of work, and the type of company I work for.. I just can't help but wonder where the bias in this poll is.
I doubt this post will get much attention since the article is already at least a day old, but how much of this is in public record? The search warrant itself must have a judge's name on it, and the guy had to sign the warrant and get his own copy of it. Can he contact the judge's office and get additional information on why the warrant was granted?
Even if this type of request has to wait until the investigation is over, I would still be very interested in the information law enforcement provided to the judge to make him/her agree that the search warrant was necessary. I think, with that information, we will either know some true/additional reasons behind this, or we will know that something in our legal/judicial system needs to be addressed.
As does most every other major operating system.
like, dude!!!! cash is, like, totally still legal tender and stuff!@!#% I can get along without a credit card fine!!! If I don't have a driver's license (which isn't MANDATORY), I just can't DRIVE. that doesn't, like, affect my purchasing abilities. I can still get a JOB. I can still sustain my survival. I don't think there is a single "privacy-invading" piece of technology that is a requirement in my life.
Your articles seem to focus around what could be done with this technology, not around what will be done. How many times in the last 50 years have we seen a new piece of technology that could be misused to destroy the lives and privacy of everyone in the country? How many times has that actually happened? Thanks, but if I read another article about how we should reject this technology because they will start carrying serial numbers with '666' in them, I'm going to vomit.
Stop judging things based on what COULD happen. If you're worried that your evil government is going to mandate that these things be implanted, perhaps it's time you moved to a new country or replaced the one you have.
For the record, you're the one that started the personal attacks, not me.
What percentage of the voting public (now down to what? 30%?) has any say in what politicians do anyway, these days?
How many letters have you written to your congressmen? This attitude quite frankly sucks. The people you elected to those positions are there to be your voice in the government. If you're really buying into that whole "politicians are working for big companies against their constituents", perhaps you need to vote somebody better into office or write a letter or two.
Personally, I don't buy it. Every letter I've written to my congressmen has been replied to personally, with his own thoughts and information. Work WITH them, not AGAINST them.
Sheesh.. from the actual web page:
Stop nit-picking. If you disagree with something I've said, by all means present an argument. The size difference between a grain of rice and a dime makes no difference as far as my argument is concerned. From their press release:
I'm sure different feature packages will result in a device that's a different size.
A side effect? If you consider being able to be tracked, real-time, via a radio-based network a "side effect" you're 'way more trusting than I am, or than the majority of posters here..
I can't tell if you really don't understand what I was saying or are deliberately trying to misunderstand.
All I was saying is that their research has been focused on providing biometric data to nearby base stations. The fact that they now have a small device capable of transmitting data now means that they can use it as a location device. They did not approach this research with a lets-track-the-public mind-set. That's what I meant by "side-effect". It was not the focus of their research, but it's certainly a marketable feature.
Well, I seriously believe you'd buy into anything anyone wanted to put over on you...
Again, if you want to refute my statement, by all means let's hear your argument. Remember that cell phones put out a rather large amount of RF energy and get very hot and use up a lot of electricity doing so. Scale that down to something the size of a dime or a grain of rice, and the number of required cell-phone-type towers goes up by at least 1 or 2 orders of magnitude. The costs involved would be prohibitive.
I really am shocked at the tremendously poor quality of posts on this thread. It's clear that very few people actually read the information on the site or even tried to think logically about any of this.
1. This will eventually be mandatory and The Man will track us wherever we go!
This seems to be the chief conspiracy theory. Let's think about this for a moment. What percentage of the voting public would desire or permit the government to mandate implanted tracking devices? If somehow the evil government broke away from the people and started trying to force this upon its people, how many would take up arms against it? I WOULD. I may be trying to speak in defense of this project here (only because there's an overwhelmingly uninformed body against it at the moment), but I would certainly fight any attempt at mandating tracking devices in our bodies. This is just stupid to even consider.
2. The devices can communicate with satellites and track us all with GPS!
Another poster mentioned this, but he was quickly rebuffed by another uninformed poster, but do you really think we have the technology to shrink down a fully functional GPS receiver into a device the size of a grain of rice? The smallest GPS receiver I've ever seen was built into a wristwatch, and it was the bulkiest watch I've ever seen in my life. The best we can do is something the size of about 3 AA batteries, and you've still gotta have a good antenna and a clear view of the sky for it to work. What they're saying by linking the devices up to GPS technology is the same sort of "GPS tracking" they're planning on building into your phones: conventional base-station triangulation linked against known GPS information.
3. All of the RF radiation from these things will kill us, like our cell phones are!
Do you really think a rice-sized device is going to put out as much RF energy as your cell phone? This thing is powered off of what little energy it can get from muscle movement. Have you also noticed how HOT your cell phone gets pumping out all that energy? Putting out 750mw of power from a grain of rice will cook your flesh quite effectively. I'll talk more about this topic below.
4. Why do these tracking devices need to be implanted, anyway?
READ THE PAGE! The primary use for these things is for BIOMETRIC SENSING. Location is simply a side-effect and a nifty other purpose. They specifically say on their site that the biometric sensing devices are meant to be implanted or bonded close to the body SO THAT IT CAN COLLECT BIOMETRIC DATA. These things aren't about tracking the human population, they're about things that are legitimately useful. Do you really think a company is going to be very successful marketing an implanted people tracking device?
I seriously doubt there is going to be a significant "global network" capable of receiving transmissions from these devices such as what you're seeing with cell phones. The devices are small and extremely low-power, so they can't transmit far, and they were built for biometrics sensing. I don't have any more information from you, but calling on my meager yet sufficient store of COMMON SENSE, I can figure out that they are planning on using these things inside buildings, hospitals perhaps, or when out of doors, "base stations" would be located on mobile vehicles, which would drive around, listening for signals it's looking for and collecting the data/location.
This makes these devices quite useful for things like hospital patient monitoring, lost children, pets and endangered animals, since the base station is either positioned near the devices, or can be relocated in small area to search.
This does not make these devices useful for these stupid human implant tracking device conspiracy theories.
Can we please use a little more common sense and think through some of this stuff before we go frothing at the mouth about all of the phantom evils this new technology spawns?