...and your management shouldn't try to change that. Good management understands that they have to ensure that personnel expected to perform tasks have the experience and/or training to do those tasks. Your off time isn't theirs.
If they really think you're responsible for getting training in your off time, even if you're doing self-study, then it's time to get a new job. The market is good now, and you don't have to put up with idiots like this -- especially if the PHBs expect you to develop some instant affinity to Active Directory management. Yuck.
I've noted before that this was the really important missing piece for open-source systems, the other being Commmon Criteria accreditation. In U.S. federal government (and especially DoD) programs, not only do you need to be EAL3 or better, but interoperate with FIPS 140-2 crypto systems in a FIPS 140-2 compliant manner when encryption is used, which is almost all the time. We have open-source systems certified under common criteria, but we couldn't use them with DOD PKI, so the utility of these systems was severely limited.
As a side note, it never seemed as if Microsoft's failure to get CC validations promptly ever slowed down IIS or XP deployments, but it's been a major roadblock for any other systems to get through DITSCAP if there was any possible reason to deny the request.
FIPS accreditation removes the final roadblock for open source in the federal government. Now there is not a single valid policy or security requirement that can block deployments of open source systems.
Also of note is that since anyone can use OpenSSL, small development shops are no longer held hostage to Certicom's expensive licensing schemes if they want to deploy FIPS compliant solutions. It used to be financially daunting to sell software to the government that included crypto, and this created a nice, safe sandbox for the small set of approved vendors to charge outrageous prices for FIPS compliant solutions. Now they have to compete with open source, which will likely bring costs down considerably for anyone required to deploy only FIPS compliant solitions.
Another poster mentioned that this restricted the choice of encryption algorithms to 3DES. That is incorrect. FIPS 140-2 is an AES implementation, specifically because of concerns over 3DES' long-term viability. There are no approved 3DES implementations under FIPS 140-2.
I would have liked it if instead of saying "here's how you do it" you said "here's how I did it."
I worked with a guy a few years ago that got wrapped up in this, um, er, philosophy. He actually got the HR department for a fortune-500 company to stop witholding social security from his paycheck on the basis of a poor reproduction of a letter on congressional letterhead from a Congressman with these unique ideas. About 9 months later, he gets word from HR that not only are they resuming witholding, but complying with a garnishment order to recoup not only the witholdings in default, but penalties and interest as well. If HR hadn't ended up looking like complete idiots in this case, I'm pretty sure they would have let him go, but I'm sure the embarrasment on their part tied their hands.
Lo and behold, he's dismissed about a year later. Last I heard he was serving time for trying to meet with a supposedly 14 year old he met on the internet who had in fact been an undercover police officer in a chatroom. Wish I could get you to talk to him, but I'm sure he can't take phone calls these days...
Yeah, you need that overkill since you've got four Seagate drives in a RAID 0 configuration. Makes for speedy access, but that cuts MTBF by 75% for the array over what you'd get with a single 1TB disk. Maybe they think they can mirror the more interresting stuff to the other array which should have at least 300GB available?
I think someone using MythTV would have made radically different choices.
In industry we try to overcome these very obstacles on a regular basis because there's a huge profit incentive to do so. Increasing power doesn't usually help the signal reflected back from the tag to be more powerful very much, and at some point you drown out the return signal with this approach. Intermec tried to do this with their mobile readers, and they still perform poorly. Multiple antenna/readers help improve coverage, but they don't make a poor signal into a better one. Now tags have remarkably improved over the past few years, and I do see quality improvements making a difference, but they'll probably not overcome debilitating interference and environmental problems.
But let's say they finally arrive at passive tag nirvana, of a $0.05 900MHx passive tag that trumps reasonable interference, doesn't fail regularly, and can be read with a $15 antenna/reader combo from 20 feet. What are they going to obtain with a read?
Example: SGTIN-96 encoding format
* Header = 0011 0000 (8 bits)
* Filter Value (3 bits) = 001 is retail item
* Partition (3 bits)
* EAN.UCC Company Prefix (20-40 bits)
* Item Reference (24-4 bits)
* Serial Number (36 bits)
I don't see any field for SSN, Phone number, or customer name. It will only interoperate with other systems if the company is an EPCglobal member (HUGE membership costs) and uses a registered company prefix. The Item Reference is assigned locally, so you have to have access to the EPCglobal network to figure out what the heck the item is, and the serial number is a dumb number with no embedded intelligence.
Now if you go off on your own and encode a tag in "Joe's Peculiar Format" or whatever, nobody else will be able to understand what it is, or worse yet, they might interpret it as something it is not. UPC barcodes provide more easily deriveable intelliegence within them than a typical RFID encoding format.
It gets worse. These are EPC encodings, which are ISO. There's also weigand encoding (in active and active-passive), used in asset tracking. That is typically a 24 bit value with no construct or consistency at all. You get a number that could mean anything, and that number is likely duplicated by someone else using weigand tags, so each tag is only uniqie within the enterprise that encoded it (as long as they're being careful, which isn't always the case). Then there's DoD encodings, which frequently change and have no meaning outside of the Department of Defense.
I walked across the hall, took an Avery-Denison squiggle tag and taped it to the bottom of my shoe for you. We couldn't read it at all with a Symbol MC9000 handheld, and that's a GREAT reader. The tag orientation was all wrong. I walked around the office and then peeled it off, set it up so the orientation was correct, and it was dead. Walking on the chip destroyed it. So in my little test for you (I'm billing you $0.23 for materials expenses;) ) it seems like this would be a completely ineffective means of attaching an RFID tag to a person.
Reader technology is limited by pretty ordinary physics issues, so don't expect inexpensive, uniquitous 900MHz passive readers that are immune to interference to start showing up any time soon. Readers operate on public use frequencies, and baby monitors, cordless phones, microwave ovens, and a host of other equipment easily wreaks havoc with reads. The return signal from a passive tag to a reader is on the order of -50 dbm, far, far less power than your cell phone emits. The readers are power limited under FCC rules Part 15, so you can't crank up the power in the hopes of getting a better return signal -- not that that works too well anyways.
Nokia makes a cell phone with an integrated 13.56MHz RFID reader. They work pretty well, but the read range for 13.56 is a couple of inches at best. Limited use cases for this, but an interesting idea.
The fire safety system has been piloted within the US Government, but there are implementation issues that haven't been cleared so it's still in pilot.
A lot of you out there have been using 13.56MHz systems for building access badges for years, and I haven't seen much complaining about those. It's doubtful anyone will be interested in using 900MHz for this with longer ranges, since access control works better when you're guaranteed one read at a time from close range. Reading multiple tags at 10ft and opening a lock because one of them is authorized isn't a good use case.
Where this stuff is really useful is in a warehouse/distrubution center. Thousands of boxes an hour running past a reader on a conveyor system and being read automagically in order to be correctly routed to the right loading bay, instead of requiring a human to perform mind-numbing task of sorting is a HUGE winner. Lower costs, fewer mistakes, and you can speed up the conveyor system allowing more units per hour and avoiding the need to expand the facility. This technology, as most others, will follow the money. Deploying ubiquitous readers and managing the crushing volume of data they will generate is hugely expensive and will generate no revenue.
BTW, software that turns this flood of duplicative, often erroneous data and can do something useful with it is "where it's at." SamSys, who makes some great readers is just about bankrupt and laying off hundreds of employees this week or next -- who I'm hoping to snap up to help us on the software/integration/implementation side. It's HARD finding enough people who can do more than just spell "RFID".
A passive tag typically is 96 bits in length these days, and those are the only tags anywhere near economically feasible for large-scale deployment. Of those 96 bits, you need between 30-50 bits to identify the encoding construct and the marking entity. That leaves you usually with on average 32-48 bits available for you to put your nefarious track-the-human-and-spy-on-him payload. There are lots of barcodes that can contain far more information than EPC Class 1 Gen 2 passive RFID tags.
If you can completely control me with 32 bits of data, well, you're such an awesome engineer that I probably should reward you by letting you do it. That's as close to engineering nirvana as I've ever heard.
Those 32 to 48 bits are nothing but a unique identifier within a marking entities address space, and all the potential for tracking and controlling is back in the enterprise where that unique identifier gets translated into meaningful and useful information. If "they" have all the data about me that would be required in order to understand who I am and what I'm doing, I'm royally screwed regardless of whether my toothpaste tube is in a package that has an RFID tag on it. That tag is entirely irrelevant.
Here's a sample data stream from your privacy-invading fixed passive RFID reader that has about $5k of middleware attached that will identify tag constructs and filter redundant data:
TAG READ: CONSTRUCT: SBSS EPC MGR CODE:11045 ID: 10F4 C061 0117 found
TAG READ: CONSTRUCT: GIAI ENT ID:4CY76 PROD: 56A23 TAG ID: 5671 B1C7 found
TAG READ: CONSTRUCT: SBSS EPC MGR CODE:11045 TAG ID: E254 887F 0045 found
TAG READ: CONSTRUCT: DOD96 TYPE: CASE CAGE: 0GTY88 ID: 9867 7F 7645 found
My, I saw 10F4 C061 0117 today! Holy bitbucket, batman! Whatever that is, I OWN it now!
...under threat of their machines loosing network access...
Since you can get a replacement RJ45 modular plug for about $0.05, you can easily repair loose connections so you don't lose network access. It's not really that big of a problem.
It appears that many design decisions are influenced by a need to maintain compatibility with software designed to operate under previous versions of Windows. Breaking too many "legacy" applications is risky from a business standpoint, but it does tend to perpetuate architecure choices that may not meet current realities and may impose more significant longer-term business risks. Is Microsoft considering an architecure refresh in the future, or do you see continuing architectural components such as the registry and kernel-space user code indefinitely?
An interesting post, considering your previous high regard for vnc, gimp, bash and telnet. To wit:
But, "progress" rolls on and the company that made this product got bought out by a competitor with a lesser product. The new company didn't understand anything about how the original product made life easier for its users. Instead they felt that the character based interface is too old to really be useful and must be hard to use since it's not a GUI. So they pushed their monstrous product onto the customer. It's a GUI based product that does many of the functions the old system did 10 times slower even nearly a year after it's debut. There are just some tasks that require a keyboard and a character interface and no GUI is EVER going to improve on that. However, not only is this GUI incredibly pooly laid out and awkward, it is also hampered by bandwidth requirements. The telnet client was replaced by a pretty heavy proprietary client. The new client requires about 14k per user with the majority of users being on the other side of T1s or, at worst, cell phone modems. This company actually expects it's customer to take a good deal of downtime just for the proprietary client to update by sucking bandwidth while downloading the client from the main middle tier server. Ridiculous!
In the end, I guess I'm just thankful I don't work for you.
Depends on the frequency of the tag, and a LOT on the physical environment. A 13.56 MHz tag can only be read at a range of an inch or two, but a 900 MHz tag can be read from up to 20 feet away in perfect conditions. Any liquid or metal in proximity to the tag will severely degrade the results. Put that tag next to metal and you can't read it at all.
There is a whole discipline in RFID that deals with tag placement, orientation and environmental impacts to help get tag read rates somewhere near where 90% of them will be reliably read. It's not uncommon to see read rates in the 60% range without a detailed engineering effort. If you're looking at a completely uncontrolled physical environment inside a metal trash container, the read rates would probably be so low that it wouldn't be worthwhile even trying to attempt this. It would be far more efficient to simply paw through the garbage.
This technology is extremely hard to get reliably working in a controlled environment. These fears attribute a level of maturity and capability in RFID technology that does not exist, and may not ever exist with passive RFID.
This article entirely misses the point of a SOA. If the purpose of SOA is to enable the creation of multiple instances of the same object in different applications, then worrying about code reusability would be warranted. But that's not what SOA is all about. You want to reuse the services that are created in a SOA, consolidating common functionalities into services that are shared by different "applications". Once you "get" what SOA is, the next logical step is net-centric where we stop duplicating applications and start creating reusable architectures. We create enterprise services (such as authentication, data discovery, business processes, etc.), and those are re-used, not the code that created them. And then if you're really good, you start moving towards Enterprise Architecture. I thought IBM was this good.
I can't imagine what sort of nitwit is going to try to use the same language and coding construct across all the systems in an enterprise, which is what code reuse will require. Maybe the best way to code your web app is in python, but the RFID system needs to be written in C, and the business process monitoring is a Mercator or Unwired Orchestrator dashboard. You can either put developers into bondage and mandate.Net for everything, which will yield universally mediocre results but excellent code re-use, or you can use the best tool for the job at hand and worry about service architectures rather than development minutae. Guess where the best business value lies? Guess where you end up creating a dynamic, interesting and challenging development shop that doesn't swap out key staff every 18 months?
IBM usually has their head on straight with SOA, so I'm rather surprised with this article. Seems like some of their people have wandered off the reservation and fallen into a deep ravine.
I get my information from working in the federal/DoD arena for a software vendor and butting heads with this stuff on a fairly regular basis. We do a lot of work with SPAWAR and NAVSUP. Most of my work is in the Mobile arena, but I have a strong personal preference for Linux and try to push that as the OS for our products because it works better.
NMCI has been a major pain in the butt for us. NAVSUP wants to do more handheld work, and all that is available on CLIN 23 is ancient, non-Wifi crud or Blackberry, which has it's own issues. Can't get new stuff on the list because PalmOS, PocketPC and Linux aren't CC certified. NAVSUP feels like they're screwed. Maybe when the new wireless policy comes out things will get better, but no one is that optimistic.
Intel agencies want to do more handheld work for their logistics, and again CC and FIPS are putting these initiatives dead in the water. I hear stories of end-arounds, butcan't figure out how those might happen and wonder if they're just stories.
In the enterprise field, things are a little easier, as there tends to be more money thrown around, but usually only by the major players who are already entrenched. If you like Oracle, life is easy. If you need something else, it's still pretty painful. With us, FIPS is an issue because those few vendors for FIPS 140-2 certified code is sold at an astronomical premium and the engineers and product managers can't stomach the expense when the DoD revenue is a fraction of what the commercial revenue is. They can't justify the expense to their bottom line, and that locks us out of a lot of the federal sector. We can't get the sales without FIPS and CC, but we can't beg for the expense of FIPS certified code because there's no current pipeline. It's a chicken/egg tailspin that really hurts us federal folks.
I'd love to know how you're getting RedHat in DON when Linux isn't kosher under NMCI. I thought the loophole for this closed April 04.
This really only makes a difference in the federal sector here in the U.S., as commercial firms might be interested in CC, they understand that CC really doesn't mean a whole lot. For the federal sector, this is only one half of the whole ball of wax.
Just about every DoD or other federal government RFP these days requires that every part of the solution be CC EAL 3 or greater because of DoDD 8200.1 and other mandates. Without CC, you can't be considered, no matter how much better your solution is than the relatively limited menu of certified options.
The other half is FIPS 140-2, which covers data encryption. If you don't have FIPS 140-2 you can't play ball, and even then in some places like the U.S. Navy, there's another layer of certifications for NMCI and such. So however we might celebrate SLES EAL4 cert, it STILL doesn't get them in the game without adding on a (typically) expensive FIPS 140-2 certified SSL component. My understanding is that RedHat understood this and bundled a certified solution with RHEL.
So will this announcement cause more enterprises to use SLES? Nope. They don't really care. Companies? Same boat. Governments? Only in those cases where SLES will exist entirely within a secure intranet or will piggyback on a generally closed-source 3rd party FIPS certified encryption system. SLES hasn't scored yet.
The other barrier is that for most potential government installs, there has to be CC certified software to run on it, unless it's just a network appliance. MySQL, Apache and all the rest would have to be CC certified to actually get a pure open source solution in the door.
The net effect is that this plays directly into the hands of the big software/hardware vendors and creates a barrier to entry for smaller players who would like to play in the federal space. Sure, SLES is certified, but with what? Oracle and IBM? Who's going to pay to get Apache2 certified for both Common Criteria and FIPS 140-2?? Or MySQL? Or PHP4? Look for more domination in the federal software market by the likes of Microsoft and Oracle, who will have even less incentive to create really good software because this somewhat meaningless certification process reduces competition and increases profitability for those who can invest in certifications.
Look at NMCI if you are doubtful. It hasn't helped the Navy improve it's IT infrastructure one bit, and made EDS nearly the sole vendor for all IT for the Navy. It's the gatekeeper of the NTISSP certification process, and everything it decides to approve has to be purchased through and managed by EDS. Certifications like this are simple money grabs by major Systems Integrators and muscular software companies.
I think the range of choices here should be expanded a bit. My understanding is that the best service right now is being provided by non-governmental associations that don't have to deal with the business pressures of a telco nor the bureaucratic hurdles of a municipality. This doesn't have to be a binary equation.
If municipalities can encourage actual grass-roots organizations, or provide them with some low level of support (e.g: can site antennas on public buildings), the best answer may be groups of citizens who build their own networks and contract with corporations for their connection to the backbone. Companies will be relieved of the burden of local build-out and the risk of developing infrastructure than may not be profitable, and municipalities won't have to come up with the technical resources and funds to manage it.
If we can manage to keep local politicians and companies out of the way, there's a possibility we could implement this without as many of the downsides legitimately mentioned by others here.
If this were a real obligation, it would be listed as part of the national debt. T-bills and other treasury instruments are, this is not. Now if the government doesn't consider this a debt, I don't understand why I should think it is.
See this site for a table of the current national debt broken down by category. Any corporation facing a future obligation that it must pay is required by law to state unfunded future liabilities in it's financial statements. None of these appear in the treasury reports.
Every penny of payroll taxes collected is spent. Not a single penny in excess of what is paid to beneficiaries is saved, BY LAW. If the social security "trust fund" is truly an asset, where are the assets? They're gone, and all that remains is a vague promise of the government to somehow raise the funds to repay these IOU's, subject to appropriations and future political will.
And if the government "defaults" on these IOU's, how likely do you think it will be to sue the government for the benefits it has promised but not delivered?
Don't confuse these with Treasury bills. If the government defaults on those, every source of funding for the government will evaporate, and that would be a disaster. If the government defaults on these social security IOU's (written to the government, by the government) the only party directly injured is the government.
I wish it weren't so, really. This is my future being screwed, and I'm not happy about it at all.
The word justice is all over the Constitution and the Federalist Papers; Social Security fits the Founding Father's idea of justice, hence it's in the Constitution.
This is an awfully big stretch. You could use this to argue that it would be Constitutional to regularly depose officials through force of arms, or seceed from the Union. Both of these topics were actually discussed, rather than Social Security which was unimaginable in the 18th century.
Only a half-hearted attempt to understand this nation's founding and history could lead you to the conclusions you've vomited all over this page.
State pension plans invest deductions from payroll or state contributions in marketable securities. These securities receive interest income or capital appreciation and grow over time. Retirees then draw from this fund in the form of pension payments.
Social security invests NOTHING. Current contributions are immediately paid out to beneficiaries. The only deviation from this is when collections are greater than payouts, in which case the money is forwarded to the "general fund" and spent for government programs. The social security system receives an IOU from the government in the amount of the surplus that is filed somewhere, and is sometimes referred to as a "treasury security". Unlike a treasury security, however, it cannot be traded. It is not marketable in any way. No funds are set aside to meet these pseudo-obligations. As a security, these instruments have zero value and are only a political instrument used to cover the fact that payroll taxes are in excess of what is currently needed, and is used for non-social security purposes.
The social security system really is a lot like a ponzi scheme, but one supposedly supported by the ability of the U.S. Government to raise money (through taxation). As long as the government is willing to support social security when payroll taxes don't cover benefit payouts, we're fine. It's been the other way around for years now. But I sorta doubt that the feds will be able to do that when I retire.
...when we're talking about predicted wave heights on the Western Saharan shore of Brazil??? I'm no geography whiz, but I'm pretty sure the Sahara is located on a different continent.
Just in case, I'll be sure to keep clear of that portion of Brazil, should I ever get a chance to go there.
This guy was the head honcho for a couple of things called NIPRNET, SIPRNET and JWICS. These are defense networks for nonclassified, secret and top secret information. Additionally, there are a few others above JWICS that are even more trusted and restricted.
Now if Mr. "It's a Slam Dunk!" can't figure out that he could run all his sensitve stuff through SIPRNET or JWICS, where access is restricted to those with security clearances, he should refund the salary he collected over the past seven years for being an incorrigible fsck-up. He OWNED the 'internet for the responsible' for seven friggin years, and he thinks it's necessary to create somethibg else???
Perhaps he should have asked his co-speaker at the conference, Jamie Gorelick, who probably could have given him a clue. She had access to at least SIPRNET while she was on the 9-11 comission busily trying to blame others for the policies she personally instituted at USDOJ.
That conference was a suck-up to the discredited and failed. I can't understand why anyone is inclined to take anything coming from that non-event seriously.
I hate to see Vietnam used as an example a lot of the time because it was a laboratory for making every stupid decision possible in regards to the soldier's well-being and seeing what happened as a result. Thankfully, the lessons seem to have pretty much been learned and corrective action has been applied. You make an excellent point about some of the effects, and I think you get how unique an environment it was and how hard it is to use experiences there as a guidepost for potential future experiences.
The year-long tour of duty is one well known example. Relevant to this discussion is the "body count" statistics collection pioneered by MacNamara's boys. If anything would serve to dehumanize a soldier, it would be evaluating his performance almost entirely based upon unverified self-reporting of how many casualties a soldier (or his unit) inflicted.
As far as what helped or harmed the soldier, the solder replacement system (outgrowth of the "tour of duty") failed to create unit cohesion and effective unit training. 90-day OCS graduates were not sufficiently prepared to take on combat platoon leadership, and were not provided an opportunity to learn about their men before assuming command of front-line units. The failure to widely deploy native or trained linguists to help units understand the Vietnamese caused huge "us vs. them" issues. Little or no training for junior or mid-level NCO's. The list is pretty long.
Those would be pretty damaging to that support structure you mention.
You'd be awfully impressed with what U.S. soldiers are like today, and that support structure is there in spades. In particular the NCO Corps is absolutely top-rate and I think nothing else can be such a force for good or ill with the private soldier. They're smarter, better trained, and better educated than ever before, and you can see by the high morale and excellent unit effectiveness in Iraq and Afganistan that they're doing their job well.
They remind me of what I've heard from WWII vets, when they talked about their leaders. Those men were well taken care of.
I am a former infantry soldier. I never saw combat, but did work with a fair number of combat veterans during my 12 years of service. Now this military psychiatrist surely knows a whole lot more about mental health than I do, but my experience has been that it doesn't particularly bother most professional soldiers when they successfully accomplish their assigned tasks of killing people and breaking things. What weighs on them is the death and injuries of their fellow soldiers. It's hard losing comrades. Killing the enemy to protect yourself and your comrades isn't particularly hard for the soldiers I've seen to do.
I've never seen this great angst that apparently happens when you remember the enemy you've killed. I'm sure it happens to some, but it's not a really common thing. You might choose to think it's bacause these soldiers have been dehumanized by a morally bankrupt military system, but that says more about you than it says about them. If you ask the soldier, he'll most likely tell you it wasn't something that they enjoyed or feel particularly proud of, it was just simply the job they were expected to do.
If this were a really significant problem, I'd bet it would show up in places like Rwanda really big, where nonprofessionals hacked each other to pieces with machetes on an unimaginable scale. Despite that being the worst case scenario as far as I can imagine, I haven't heard anything about a mental health crisis there, although the obvious humanitarian crisis might well drown anything else out.
There were a lot of WWII vets who were up close and personal, and they don't seem to suffer from this. None of the Airborne who landed in Normandy seemed scarred by their actions, nor the vets in the Pacific who were often in hand-to-hand. Again, I haven't done a study, but the vets I've talked to didn't seem to be bothered by this. So I just can't buy the notion that professional soldiers are so mentally fragile that they can't withstand performing their primary function if they can in fact see their enemy.
Does it strike anyone as somewhat funny that firearms ownership in all of the jurisdictions mentioned is severely restricted? If there are all of these laws against posession of a firearm, why is there the need to identify and report on such a large number of unlawful discharges?
If the result of strict gun control laws is that there's a need to electronically monitor citizens who are firing guns, maybe it's time to consider whether these laws produce the effect they were intended to cause, or make conditions worse.
Slashdot Mirror
How about Microsoft Bob first?
If they really think you're responsible for getting training in your off time, even if you're doing self-study, then it's time to get a new job. The market is good now, and you don't have to put up with idiots like this -- especially if the PHBs expect you to develop some instant affinity to Active Directory management. Yuck.
Hey honey, guess what? Our Mac is now vulnerable to the Kama Sutra worm! Aintcha proud of me?
As a side note, it never seemed as if Microsoft's failure to get CC validations promptly ever slowed down IIS or XP deployments, but it's been a major roadblock for any other systems to get through DITSCAP if there was any possible reason to deny the request.
FIPS accreditation removes the final roadblock for open source in the federal government. Now there is not a single valid policy or security requirement that can block deployments of open source systems.
Also of note is that since anyone can use OpenSSL, small development shops are no longer held hostage to Certicom's expensive licensing schemes if they want to deploy FIPS compliant solutions. It used to be financially daunting to sell software to the government that included crypto, and this created a nice, safe sandbox for the small set of approved vendors to charge outrageous prices for FIPS compliant solutions. Now they have to compete with open source, which will likely bring costs down considerably for anyone required to deploy only FIPS compliant solitions.
Another poster mentioned that this restricted the choice of encryption algorithms to 3DES. That is incorrect. FIPS 140-2 is an AES implementation, specifically because of concerns over 3DES' long-term viability. There are no approved 3DES implementations under FIPS 140-2.
I worked with a guy a few years ago that got wrapped up in this, um, er, philosophy. He actually got the HR department for a fortune-500 company to stop witholding social security from his paycheck on the basis of a poor reproduction of a letter on congressional letterhead from a Congressman with these unique ideas. About 9 months later, he gets word from HR that not only are they resuming witholding, but complying with a garnishment order to recoup not only the witholdings in default, but penalties and interest as well. If HR hadn't ended up looking like complete idiots in this case, I'm pretty sure they would have let him go, but I'm sure the embarrasment on their part tied their hands.
Lo and behold, he's dismissed about a year later. Last I heard he was serving time for trying to meet with a supposedly 14 year old he met on the internet who had in fact been an undercover police officer in a chatroom. Wish I could get you to talk to him, but I'm sure he can't take phone calls these days...
I think someone using MythTV would have made radically different choices.
But let's say they finally arrive at passive tag nirvana, of a $0.05 900MHx passive tag that trumps reasonable interference, doesn't fail regularly, and can be read with a $15 antenna/reader combo from 20 feet. What are they going to obtain with a read?
Example: SGTIN-96 encoding format
* Header = 0011 0000 (8 bits)
* Filter Value (3 bits) = 001 is retail item
* Partition (3 bits)
* EAN.UCC Company Prefix (20-40 bits)
* Item Reference (24-4 bits)
* Serial Number (36 bits)
I don't see any field for SSN, Phone number, or customer name. It will only interoperate with other systems if the company is an EPCglobal member (HUGE membership costs) and uses a registered company prefix. The Item Reference is assigned locally, so you have to have access to the EPCglobal network to figure out what the heck the item is, and the serial number is a dumb number with no embedded intelligence.
Now if you go off on your own and encode a tag in "Joe's Peculiar Format" or whatever, nobody else will be able to understand what it is, or worse yet, they might interpret it as something it is not. UPC barcodes provide more easily deriveable intelliegence within them than a typical RFID encoding format.
It gets worse. These are EPC encodings, which are ISO. There's also weigand encoding (in active and active-passive), used in asset tracking. That is typically a 24 bit value with no construct or consistency at all. You get a number that could mean anything, and that number is likely duplicated by someone else using weigand tags, so each tag is only uniqie within the enterprise that encoded it (as long as they're being careful, which isn't always the case). Then there's DoD encodings, which frequently change and have no meaning outside of the Department of Defense.
I walked across the hall, took an Avery-Denison squiggle tag and taped it to the bottom of my shoe for you. We couldn't read it at all with a Symbol MC9000 handheld, and that's a GREAT reader. The tag orientation was all wrong. I walked around the office and then peeled it off, set it up so the orientation was correct, and it was dead. Walking on the chip destroyed it. So in my little test for you (I'm billing you $0.23 for materials expenses ;) ) it seems like this would be a completely ineffective means of attaching an RFID tag to a person.
I think you're safe.
Nokia makes a cell phone with an integrated 13.56MHz RFID reader. They work pretty well, but the read range for 13.56 is a couple of inches at best. Limited use cases for this, but an interesting idea.
The fire safety system has been piloted within the US Government, but there are implementation issues that haven't been cleared so it's still in pilot.
A lot of you out there have been using 13.56MHz systems for building access badges for years, and I haven't seen much complaining about those. It's doubtful anyone will be interested in using 900MHz for this with longer ranges, since access control works better when you're guaranteed one read at a time from close range. Reading multiple tags at 10ft and opening a lock because one of them is authorized isn't a good use case.
Where this stuff is really useful is in a warehouse/distrubution center. Thousands of boxes an hour running past a reader on a conveyor system and being read automagically in order to be correctly routed to the right loading bay, instead of requiring a human to perform mind-numbing task of sorting is a HUGE winner. Lower costs, fewer mistakes, and you can speed up the conveyor system allowing more units per hour and avoiding the need to expand the facility. This technology, as most others, will follow the money. Deploying ubiquitous readers and managing the crushing volume of data they will generate is hugely expensive and will generate no revenue.
BTW, software that turns this flood of duplicative, often erroneous data and can do something useful with it is "where it's at." SamSys, who makes some great readers is just about bankrupt and laying off hundreds of employees this week or next -- who I'm hoping to snap up to help us on the software/integration/implementation side. It's HARD finding enough people who can do more than just spell "RFID".
A passive tag typically is 96 bits in length these days, and those are the only tags anywhere near economically feasible for large-scale deployment. Of those 96 bits, you need between 30-50 bits to identify the encoding construct and the marking entity. That leaves you usually with on average 32-48 bits available for you to put your nefarious track-the-human-and-spy-on-him payload. There are lots of barcodes that can contain far more information than EPC Class 1 Gen 2 passive RFID tags.
If you can completely control me with 32 bits of data, well, you're such an awesome engineer that I probably should reward you by letting you do it. That's as close to engineering nirvana as I've ever heard.
Those 32 to 48 bits are nothing but a unique identifier within a marking entities address space, and all the potential for tracking and controlling is back in the enterprise where that unique identifier gets translated into meaningful and useful information. If "they" have all the data about me that would be required in order to understand who I am and what I'm doing, I'm royally screwed regardless of whether my toothpaste tube is in a package that has an RFID tag on it. That tag is entirely irrelevant.
Here's a sample data stream from your privacy-invading fixed passive RFID reader that has about $5k of middleware attached that will identify tag constructs and filter redundant data:
TAG READ: CONSTRUCT: SBSS EPC MGR CODE:11045 ID: 10F4 C061 0117 found
TAG READ: CONSTRUCT: GIAI ENT ID:4CY76 PROD: 56A23 TAG ID: 5671 B1C7 found
TAG READ: CONSTRUCT: SBSS EPC MGR CODE:11045 TAG ID: E254 887F 0045 found
TAG READ: CONSTRUCT: DOD96 TYPE: CASE CAGE: 0GTY88 ID: 9867 7F 7645 found
My, I saw 10F4 C061 0117 today! Holy bitbucket, batman! Whatever that is, I OWN it now!
Since you can get a replacement RJ45 modular plug for about $0.05, you can easily repair loose connections so you don't lose network access. It's not really that big of a problem.
It appears that many design decisions are influenced by a need to maintain compatibility with software designed to operate under previous versions of Windows. Breaking too many "legacy" applications is risky from a business standpoint, but it does tend to perpetuate architecure choices that may not meet current realities and may impose more significant longer-term business risks. Is Microsoft considering an architecure refresh in the future, or do you see continuing architectural components such as the registry and kernel-space user code indefinitely?
In the end, I guess I'm just thankful I don't work for you.
Depends on the frequency of the tag, and a LOT on the physical environment. A 13.56 MHz tag can only be read at a range of an inch or two, but a 900 MHz tag can be read from up to 20 feet away in perfect conditions. Any liquid or metal in proximity to the tag will severely degrade the results. Put that tag next to metal and you can't read it at all.
There is a whole discipline in RFID that deals with tag placement, orientation and environmental impacts to help get tag read rates somewhere near where 90% of them will be reliably read. It's not uncommon to see read rates in the 60% range without a detailed engineering effort. If you're looking at a completely uncontrolled physical environment inside a metal trash container, the read rates would probably be so low that it wouldn't be worthwhile even trying to attempt this. It would be far more efficient to simply paw through the garbage.
This technology is extremely hard to get reliably working in a controlled environment. These fears attribute a level of maturity and capability in RFID technology that does not exist, and may not ever exist with passive RFID.
I can't imagine what sort of nitwit is going to try to use the same language and coding construct across all the systems in an enterprise, which is what code reuse will require. Maybe the best way to code your web app is in python, but the RFID system needs to be written in C, and the business process monitoring is a Mercator or Unwired Orchestrator dashboard. You can either put developers into bondage and mandate .Net for everything, which will yield universally mediocre results but excellent code re-use, or you can use the best tool for the job at hand and worry about service architectures rather than development minutae. Guess where the best business value lies? Guess where you end up creating a dynamic, interesting and challenging development shop that doesn't swap out key staff every 18 months?
IBM usually has their head on straight with SOA, so I'm rather surprised with this article. Seems like some of their people have wandered off the reservation and fallen into a deep ravine.
I get my information from working in the federal/DoD arena for a software vendor and butting heads with this stuff on a fairly regular basis. We do a lot of work with SPAWAR and NAVSUP. Most of my work is in the Mobile arena, but I have a strong personal preference for Linux and try to push that as the OS for our products because it works better.
NMCI has been a major pain in the butt for us. NAVSUP wants to do more handheld work, and all that is available on CLIN 23 is ancient, non-Wifi crud or Blackberry, which has it's own issues. Can't get new stuff on the list because PalmOS, PocketPC and Linux aren't CC certified. NAVSUP feels like they're screwed. Maybe when the new wireless policy comes out things will get better, but no one is that optimistic.
Intel agencies want to do more handheld work for their logistics, and again CC and FIPS are putting these initiatives dead in the water. I hear stories of end-arounds, butcan't figure out how those might happen and wonder if they're just stories.
In the enterprise field, things are a little easier, as there tends to be more money thrown around, but usually only by the major players who are already entrenched. If you like Oracle, life is easy. If you need something else, it's still pretty painful. With us, FIPS is an issue because those few vendors for FIPS 140-2 certified code is sold at an astronomical premium and the engineers and product managers can't stomach the expense when the DoD revenue is a fraction of what the commercial revenue is. They can't justify the expense to their bottom line, and that locks us out of a lot of the federal sector. We can't get the sales without FIPS and CC, but we can't beg for the expense of FIPS certified code because there's no current pipeline. It's a chicken/egg tailspin that really hurts us federal folks.
I'd love to know how you're getting RedHat in DON when Linux isn't kosher under NMCI. I thought the loophole for this closed April 04.
This really only makes a difference in the federal sector here in the U.S., as commercial firms might be interested in CC, they understand that CC really doesn't mean a whole lot. For the federal sector, this is only one half of the whole ball of wax.
Just about every DoD or other federal government RFP these days requires that every part of the solution be CC EAL 3 or greater because of DoDD 8200.1 and other mandates. Without CC, you can't be considered, no matter how much better your solution is than the relatively limited menu of certified options.
The other half is FIPS 140-2, which covers data encryption. If you don't have FIPS 140-2 you can't play ball, and even then in some places like the U.S. Navy, there's another layer of certifications for NMCI and such. So however we might celebrate SLES EAL4 cert, it STILL doesn't get them in the game without adding on a (typically) expensive FIPS 140-2 certified SSL component. My understanding is that RedHat understood this and bundled a certified solution with RHEL.
So will this announcement cause more enterprises to use SLES? Nope. They don't really care. Companies? Same boat. Governments? Only in those cases where SLES will exist entirely within a secure intranet or will piggyback on a generally closed-source 3rd party FIPS certified encryption system. SLES hasn't scored yet.
The other barrier is that for most potential government installs, there has to be CC certified software to run on it, unless it's just a network appliance. MySQL, Apache and all the rest would have to be CC certified to actually get a pure open source solution in the door.
The net effect is that this plays directly into the hands of the big software/hardware vendors and creates a barrier to entry for smaller players who would like to play in the federal space. Sure, SLES is certified, but with what? Oracle and IBM? Who's going to pay to get Apache2 certified for both Common Criteria and FIPS 140-2?? Or MySQL? Or PHP4? Look for more domination in the federal software market by the likes of Microsoft and Oracle, who will have even less incentive to create really good software because this somewhat meaningless certification process reduces competition and increases profitability for those who can invest in certifications.
Look at NMCI if you are doubtful. It hasn't helped the Navy improve it's IT infrastructure one bit, and made EDS nearly the sole vendor for all IT for the Navy. It's the gatekeeper of the NTISSP certification process, and everything it decides to approve has to be purchased through and managed by EDS. Certifications like this are simple money grabs by major Systems Integrators and muscular software companies.
Nothing to see here. Keep moving.
I think the range of choices here should be expanded a bit. My understanding is that the best service right now is being provided by non-governmental associations that don't have to deal with the business pressures of a telco nor the bureaucratic hurdles of a municipality. This doesn't have to be a binary equation.
If municipalities can encourage actual grass-roots organizations, or provide them with some low level of support (e.g: can site antennas on public buildings), the best answer may be groups of citizens who build their own networks and contract with corporations for their connection to the backbone. Companies will be relieved of the burden of local build-out and the risk of developing infrastructure than may not be profitable, and municipalities won't have to come up with the technical resources and funds to manage it.
If we can manage to keep local politicians and companies out of the way, there's a possibility we could implement this without as many of the downsides legitimately mentioned by others here.
See this site for a table of the current national debt broken down by category. Any corporation facing a future obligation that it must pay is required by law to state unfunded future liabilities in it's financial statements. None of these appear in the treasury reports.
Every penny of payroll taxes collected is spent. Not a single penny in excess of what is paid to beneficiaries is saved, BY LAW. If the social security "trust fund" is truly an asset, where are the assets? They're gone, and all that remains is a vague promise of the government to somehow raise the funds to repay these IOU's, subject to appropriations and future political will.
And if the government "defaults" on these IOU's, how likely do you think it will be to sue the government for the benefits it has promised but not delivered?
Don't confuse these with Treasury bills. If the government defaults on those, every source of funding for the government will evaporate, and that would be a disaster. If the government defaults on these social security IOU's (written to the government, by the government) the only party directly injured is the government.
I wish it weren't so, really. This is my future being screwed, and I'm not happy about it at all.
This is an awfully big stretch. You could use this to argue that it would be Constitutional to regularly depose officials through force of arms, or seceed from the Union. Both of these topics were actually discussed, rather than Social Security which was unimaginable in the 18th century.
Only a half-hearted attempt to understand this nation's founding and history could lead you to the conclusions you've vomited all over this page.
Hmmm.
State pension plans invest deductions from payroll or state contributions in marketable securities. These securities receive interest income or capital appreciation and grow over time. Retirees then draw from this fund in the form of pension payments.
Social security invests NOTHING. Current contributions are immediately paid out to beneficiaries. The only deviation from this is when collections are greater than payouts, in which case the money is forwarded to the "general fund" and spent for government programs. The social security system receives an IOU from the government in the amount of the surplus that is filed somewhere, and is sometimes referred to as a "treasury security". Unlike a treasury security, however, it cannot be traded. It is not marketable in any way. No funds are set aside to meet these pseudo-obligations. As a security, these instruments have zero value and are only a political instrument used to cover the fact that payroll taxes are in excess of what is currently needed, and is used for non-social security purposes.
The social security system really is a lot like a ponzi scheme, but one supposedly supported by the ability of the U.S. Government to raise money (through taxation). As long as the government is willing to support social security when payroll taxes don't cover benefit payouts, we're fine. It's been the other way around for years now. But I sorta doubt that the feds will be able to do that when I retire.
...when we're talking about predicted wave heights on the Western Saharan shore of Brazil??? I'm no geography whiz, but I'm pretty sure the Sahara is located on a different continent.
Just in case, I'll be sure to keep clear of that portion of Brazil, should I ever get a chance to go there.
This guy was the head honcho for a couple of things called NIPRNET, SIPRNET and JWICS. These are defense networks for nonclassified, secret and top secret information. Additionally, there are a few others above JWICS that are even more trusted and restricted.
Now if Mr. "It's a Slam Dunk!" can't figure out that he could run all his sensitve stuff through SIPRNET or JWICS, where access is restricted to those with security clearances, he should refund the salary he collected over the past seven years for being an incorrigible fsck-up. He OWNED the 'internet for the responsible' for seven friggin years, and he thinks it's necessary to create somethibg else???
Perhaps he should have asked his co-speaker at the conference, Jamie Gorelick, who probably could have given him a clue. She had access to at least SIPRNET while she was on the 9-11 comission busily trying to blame others for the policies she personally instituted at USDOJ.
That conference was a suck-up to the discredited and failed. I can't understand why anyone is inclined to take anything coming from that non-event seriously.
I hate to see Vietnam used as an example a lot of the time because it was a laboratory for making every stupid decision possible in regards to the soldier's well-being and seeing what happened as a result. Thankfully, the lessons seem to have pretty much been learned and corrective action has been applied. You make an excellent point about some of the effects, and I think you get how unique an environment it was and how hard it is to use experiences there as a guidepost for potential future experiences. The year-long tour of duty is one well known example. Relevant to this discussion is the "body count" statistics collection pioneered by MacNamara's boys. If anything would serve to dehumanize a soldier, it would be evaluating his performance almost entirely based upon unverified self-reporting of how many casualties a soldier (or his unit) inflicted. As far as what helped or harmed the soldier, the solder replacement system (outgrowth of the "tour of duty") failed to create unit cohesion and effective unit training. 90-day OCS graduates were not sufficiently prepared to take on combat platoon leadership, and were not provided an opportunity to learn about their men before assuming command of front-line units. The failure to widely deploy native or trained linguists to help units understand the Vietnamese caused huge "us vs. them" issues. Little or no training for junior or mid-level NCO's. The list is pretty long. Those would be pretty damaging to that support structure you mention. You'd be awfully impressed with what U.S. soldiers are like today, and that support structure is there in spades. In particular the NCO Corps is absolutely top-rate and I think nothing else can be such a force for good or ill with the private soldier. They're smarter, better trained, and better educated than ever before, and you can see by the high morale and excellent unit effectiveness in Iraq and Afganistan that they're doing their job well. They remind me of what I've heard from WWII vets, when they talked about their leaders. Those men were well taken care of.
I am a former infantry soldier. I never saw combat, but did work with a fair number of combat veterans during my 12 years of service. Now this military psychiatrist surely knows a whole lot more about mental health than I do, but my experience has been that it doesn't particularly bother most professional soldiers when they successfully accomplish their assigned tasks of killing people and breaking things. What weighs on them is the death and injuries of their fellow soldiers. It's hard losing comrades. Killing the enemy to protect yourself and your comrades isn't particularly hard for the soldiers I've seen to do.
I've never seen this great angst that apparently happens when you remember the enemy you've killed. I'm sure it happens to some, but it's not a really common thing. You might choose to think it's bacause these soldiers have been dehumanized by a morally bankrupt military system, but that says more about you than it says about them. If you ask the soldier, he'll most likely tell you it wasn't something that they enjoyed or feel particularly proud of, it was just simply the job they were expected to do.
If this were a really significant problem, I'd bet it would show up in places like Rwanda really big, where nonprofessionals hacked each other to pieces with machetes on an unimaginable scale. Despite that being the worst case scenario as far as I can imagine, I haven't heard anything about a mental health crisis there, although the obvious humanitarian crisis might well drown anything else out.
There were a lot of WWII vets who were up close and personal, and they don't seem to suffer from this. None of the Airborne who landed in Normandy seemed scarred by their actions, nor the vets in the Pacific who were often in hand-to-hand. Again, I haven't done a study, but the vets I've talked to didn't seem to be bothered by this. So I just can't buy the notion that professional soldiers are so mentally fragile that they can't withstand performing their primary function if they can in fact see their enemy.
Does it strike anyone as somewhat funny that firearms ownership in all of the jurisdictions mentioned is severely restricted? If there are all of these laws against posession of a firearm, why is there the need to identify and report on such a large number of unlawful discharges?
If the result of strict gun control laws is that there's a need to electronically monitor citizens who are firing guns, maybe it's time to consider whether these laws produce the effect they were intended to cause, or make conditions worse.