NVidia can still come off okay too, if they start now. They don't have to risk their IP either. If they contribute money and/or access to older video cards, then they have fostered the development of Nouveau. If they give the team the resources to succeed without giving them access to the source code to the proprietary drivers, then they have fostered the reverse engineering without committing their own staff or risking lawsuit from revealing potentially infringing/stolen intellectual property.
At the very least, they should review the Nouveau contributors and declare them to be free of NVidia influence (a condition of fending off an IP lawsuit). This may not do anything to foster the development directly, but it certainly gives the open source advocates all kinds of warm fuzzies that the company is genuinely interested in making quality open source drivers.
Quickly, before Cringely ruins it with bad math, I need to point out some very obvious weaknesses in making this work correctly:
SHA-1 has been (somewhat) broken. Not highly repeatable yet, but they're getting there.
Encryption does not hide a message forever. Most of us picked up on that in one form or another. It just hides it long enough to make the information useless. If I can only break a single machine 6 years after it was written, the video isn't going to be very useful to me.
Good encryption methods assume two things. One is the attacker does not have the key. Smart card attacks have shown (PDF) that even though an attacker has to guess the key, a poor implementation may provide useful hints during the guessing phase.
The second assumption is that the message is not highly predicatable. Disk drives are known for having highly-predicable components on them which makes finding the plaintext all that easier.
These folks are so cocky about SHA-1's entropy space, they claim "there is no need to abort the authentication process from a specific host. For example, there is no need to abort the authentication process if a specific host generates three wrong passwords. " Zeroization is the only way to do this right. You can also vary this so that after three failures, an automatic delay is introduced to slow down the guessing.
Reading the patent text indicates that new "commands" will be added. No mention of a bus protocol (ATA or SCSI) is mentioned. Presumably, they won't make the drives themselves, so it will need standardized. The hard drive community is open to using patents, but only if the terms are reasonable or a cross-licensing deal is in the works. If this is a forced attempt, it will fail miserably or cost so much that the drives will be considered custom, low-volume, high-cost components.
The likelihood of them screwing the implementation up are so high, they should pursue FIPS 140-1 certification for every hard drive made. Then, the patent can apply outside the domain of Tivo.
This scheme works better as a general hard drive protection measure than for a Tivo. People who own a Tivo might probe the memory chips for the crypographic module to sweep for the drive or system keys. AACS recent events ought to make it obvious that people are motivated to do this. The general case may prevent a lost hard drive from being very useful.
It would appear that the cryptographic module does NOT actually encrypt data on the platters. It seems to only cover communication between the host and the disk controller. If an attacker were to replace the circuit board with one whose path was trusted, they could read the platters without issue. They do this all the time in the hard drive repair business; no clean room required.
Okay, you all can go back to your regularly scheduled cheap shots.
I understand your question, but Microsoft has made it obvious that they perceive vendor-supplied drivers as a serious threat to stability. When Linux is working without proprietary drivers, kernel coders have a chance to thrown useful debugging information in because they aren't trying to hide anything. Throw an independent, proprietary driver in there and your system's stability is at stake. Windows NT/2003/XP and Linux are both monolithic kernels; that is drivers run in kernel space. Vista has tried pretty hard to move closer to a microkernel architecture, but I haven't seen a whole lot on this so I don't remember if they've succeeded or not.
Case in point, Microsoft has seriously threatened that any driver that isn't WHQL-certified won't be allowed to run under Vista. Some could view this as an effort to push their cash-cow in trademark usage approvals, but I'm sure it's plenty profitable. Besides, all that testing takes time, which vendors hate. If vendors had time, they wouldn't be rushing the product to market in the first place. So market demands push poor coding practices on the driver, but Microsoft wants a reputation as having a stable OS.
Having open specification makes this problem go away completely. If Microsoft can keep the driver in their kernel, then they, like the Linux kernel hackers, can understand the ripple effects to internal API changes completely. No ambiguity. Microsoft, like the kernel hackers, can only speculate how their necessary changes will affect the binary-only drivers.
This is the world that NVidia and ATI are playing in. Only time will tell if they succeed to Microsoft's stability needs. There are lots of roads that can be taken, but nothing beats having drivers in plain view of every Vista kernel developer. NVidia or ATI (AMD) could court both parties by offering to throw away their proprietary and possibly IP violating code through an effort to fund a complete rewrite by a third party who has no access to the original codes.
Has anyone considered that the reason ATI/NVidia won't open source their drivers/firmware is because there are blatant copyright and patent violations in their code? I'm not saying there are violations, but if there are, then I would expect each to violently defend against anyone seeing their source code. To date, the best argument heard is that access to the code would provide their competitors an unfair advantage into their optimization techniques, which most of us recognize to be hog wash. At worst, they wrap it up in "we have licensed proprietary algorithms" declarations and refuse to give the community a chance to work around those algorithms.
There is only one way forward. NVidia should fund the effort to rewrite their firmware/drivers, providing only the hardware register descriptions and nuances. I'm quite sure others have asked NVidia to do this already, but Intel moving forward with this plan should force the other's hand. I'm surprised that Microsoft hasn't chimed in here because for every open specification we get in the OSS world, they also get. That's where all those Microsoft drivers come from. And only on occasion is a vendor-supplied driver better that the Microsoft one. Open sourcing any drivers also helps Microsoft support more hardware out of the box, without a multitude of licensing agreements and royalty schemes.
And of course, NVidia (and now ATI) have been adding more treasure to their war chests with the PCIe motherboards. I just bought a new motherboard and it's extremely hard to find a new board with PCI-Express that doesn't have an nForce or ATI chipset.
It's going to be a tough game for Intel because it's not just graphics drivers. AMD could play into this game if they took a decisive maneuver with their GPU integration into the CPU. Remember that AMD now owns ATI.
LISTEN to this chap! E-mailing the list is bad because that communication is in-band. It took the phone companies much frustration to move it's signaling out of bands. When payphones and the switches did all their communication in-band, then phreakers could manipulate the line via blue boxes or red boxes. If someone is running malware on one of your client's workstations, they could see the e-mail come across and later copy it for their own uses.
Out-of-band communication works because an attacker needs access to both communication channels. Usually, the cost of doing so is extremely high and is a very good countermeasure. In enos' descriptions, the mentioned out-of-band communications are a pad of numbers mailed through the postal system, which is slow and usually not preferred by marketing folks, but still quite effective.
The second case was the SMS message, like Google uses for G-Mail. The disadvantage here is that a) it costs money in the states, and b) not everyone has an SMS capable device.
A similar, but third alternative would require the customer to call the toll-free number on the back of their card, type the last four digits of their card, and three digits given in-band. The cost associated with war dialing an ANI-backed, bank phone number is EXTREMELY high, as the police have great motivation to go after people trying to steal from a bank.
In any case, if the customer has to hold onto something, make getting a replacement card as simple as 5 minutes in a branch office. Just let the tellers associate their new scratch-and-sniff card with their account and you're off. If you own your own ATMs, you can even dispense replacements from there for US$1.00 each, just like the deposit envelopes on some machines. Otherwise, they are just mailed for free when the pad of numbers starts to run low.
Encrypted file systems have a similar problem. They need to decrypt the filesystem for authorized boots or mounts, but need to stay encrypted otherwise. One common trick here is to only make the decryption key available once, at start up, after which it is put into memory, preferable with a small amount of obfuscation to slow down memory walkers. You could then use something like FUSE to mount the encrypted filesystem with your plaintext password.
As other folks have wisely pointed out though, the best posture is to use mandatory access control and restrict access to the configuration file. If you have the privileges, another good practices involves removing all compilers from the machine, firewalling all FTP traffic in or out, firewalling egress (outbound) HTTP traffic (pull in files to process), restrict SSH traffic to pre-defined nodes and enforcing that with a firewall ruleset. Preferably, you'd make all the firewall stuff occur on a separate box. What this does is restrict what tools will be available to an attacker. You can also remove fun programs like strings, ldd, od, *hexedit, and so on. "But I need to modify these tools!" you say. Leave SVN or CVS clients on the node, check your changes into SVN/CVS on your test bed machine, and then just check out the latest stable branch on your exposed machine. Then you get good protection and good configuration management all in one swoop.
Other tricks involve establishing a proxy process or strict limiting what can be done with the compromised username/password. A proxy process might be a setuid C program that only does one thing and accepts no user input. If you must accept user input, be extremely strict (use sscanf on all inputs and limit the size of the buffer accepted) and then have an experienced C developer review your code for improper bounds handling. This proxy process might do things like move files to a read-only directory structure (static web pages in a DMZ), or it might be a CGI script that updates rows in a database. We've actually used the CGI script idea because it a) it a cross-platform way of talking to the database, b) is a good decoupler of otherwise complex code, and c) strongly limits what can be done as an attack. Be careful of the venerable SQL injection attack there though.
A good use of a proxy process might be the transparent mounting/unmounting of an external USB drive, perhaps against a hidden partition on the stick. The drive would have your key. Sure it's obfuscation, but it's complicated enough to decode that it will slow somebody down for a while.
The last trick is to limit what can be accomplished with the username/password that is obtained. We have some processes whose job is to inject data into the database for the backend to all of our tools. That database user is limited to select, insert, and update operations. With Oracle, I could even restrict which specific tables get which privileges.
The best thing to do is to write a document that some folks call the Security Design Document to define your security posture, what you are known to protect against, and where you are vulnerable. Assign a risk mitigation matrix (vulnerability, threat, countermeasure, residual risk) row to each vulnerability. Be honest and then let your manager understand the position you've left them in and try to assign a cost to each countermeasure/mitigation so they can make a decision on what to close or leave open.
You are always going to have vulnerabilities. Everyone does, even the best systems. What makes the difference is those who analyze, understand, and counter that risk in a way that is appropriate to the situation. Direct exposure to the Internet is a situation that should warrant better risk analysis, but rarely does.
Let's start by linking to a Washington Post Article written by Dave Barry. I don't have the syndication rights to Mr. Barry's intellectual contributions, yet I just distributed a way for people to read that. I understand that the material in question is different, and I also know that the Washington Post has a policy explicitly allowing linking. But even if they didn't, I still don't have the right to advertise for Dave Barry without his agent or distributor's permission.
Senior Engineers that are worth their weight in gold provide the role of mediator. I provide such a role in my little microcosm, and in turn answer to others when the problem steps outside my microcosm. In my organization, I have these groups all involved in changes to production: developers, system administrators, testing/QA, purchasing, security officers, storage administrators, network administrators, database administrators, and core infrastructure (electric, HVAC, floor loads). As a senior engineer, I have a BS is CS, have studied the OSes we use extensively and perhaps may obtain certification. I stay aware of security practices and rules that may hinder our permission to use it (think untrusted firewall vendors). Then there's the stuff that is the bread and butter of everyone else: Storage Area Networks, backup and recover, database performance/demands, and upgrades to the building blocks of the datacenter (electric, HVAC). And we haven't even talked about the user to developer interface, but that's usually a read-only operation for the Senior Engineer - know what the applications are and how they generally communicate so that issues from the application can be separated from issues with the infrastructure.
"No one person can do all that!" True, no one person can be expert in all of that, but that one person should dip their tendrils into all of it. Be all things to all people. Some situations where this has been relevant:
DBAs want developers to use a test instance for near-production testing. They think an extra machine with gobs of memory, plenty of disk, network connectivity (and addresses), and application configuration are all just waiting for the DBA to ask for them. But the DBAs approach the senior engineer while the thought is still a small thought, and the senior engineer understands their needs in the DBA language because he's been to classes, even if he wouldn't dare do it himself. Then, when the idea comes to fruit, the senior engineer has communicated the need to everyone else in a professional manner that makes the disparate groups a team, and the test instance can go up. Maybe not as quickly as originally hoped, but certainly a lot smoother than if the DBA had whined for a few months.
Java developer works out a very nice mathematical algorithm for processing interesting data sets. They even use Java 5.0 so it's actually fast. What it's not is memory efficient. The senior engineer will see that the enormous memory requirement are unrealistic, not because it's fun to beat up Java developers for memory consumption, but because he knows the users will have at least six other major applications at the same time and the workstation will become unusable. The senior engineer may also have a better understanding of the network/disk load the application will place once a few dozen analysts fire the application up simultaneously.
Management gets this great idea to mix several systems together into a single-vendor solution because a white paper and website's ROI calculator tells them it will save money over the next 10 years. The senior engineer will either a) scoff at the idea or b) know which parties in the major listing above need coordination and input to understand the full impact of the change to the configuration, so that management can see the real ripple effect besides simpler purchasing and a single support contract. Any senior engineer who chooses a) will not be a senior engineer for long.
So if you haven't caught on by now, the phrase that pays here is "be all things to all people," which the Apostle Paul used to tell Christians on how to win unbelievers. Having the heart of someone who wants to genuinely help everyone means that the senior engineer will NEVER have to justify his job, because everyone will know that this disparate group of people, skill, and processes are brought together because of this individual's communication, understanding, and a willingness to help. If they get caught up in terf battles, then they ar
The most painful way, but only sure way to accomplish this is to disassemble the drive and melt the platters. If they are really old drives, then waving the disassembled platters under a wand-based degausser usually works. This stuff is all measured in oersteds. The recording head has to overcome the coercivity of the magnetic media in order to record a reliable signal. Coercivity is the strength of magnetic field (measured in, you guessed it, oersteds) required to alter the alignment of the particles on the platter. The heads can write at this strength and so must you if you wish to properly erase the data. That's why the big bulk erasers cost so much. The big one, the TD-1 can do up to about 8000 oersteds, which will do anything up to, but not including the perpendicular recording stuff in the 500+GB drives.
If you're a cheap skate, you and a T-8 wrench are going to be friends (get a bit for about every 20 drives cause they wear out fast if you're in a hurry) and pull the drives completely apart, down to getting the platters off the spindle motor. Some drives take a T-10 or T-6. Then send the platters to be burned. If you don't courier them to the incinerator, then at least play 52 card pickup with them and make it difficult for any but the most determined.
Rather than strip them of their patents, remove the right to decide who can or cannot license the patents, and take away all royalties. If you make it so that all parties using their patents simply notify them in writing, then they still retain their works and derive future patents off of them. However, they will be constantly reminded of yet another product that they will never get royalties from because of their past behavior. Stretch it back to when the comittee first started meeting at which point Rambus started their deceptive practices and end it at the time that the lawsuit was filed on the anti-competitive behavior. Anything before and anything after are unrelated and could be tied to a change in management attitude, be it for the better or worse.
This has to be done because not everyone is a scientist with an experimental, discovery mindset. Everyone is also not a C++ programmer (or Java, Perl, C, C#, etc.) and thus proficient at error checking and dealing with a variety of system interaction. Face it, people hire scientists to develop things no one else is doing, but who learned programming as a necessary evil. People hire professional developers to glue or reform that prototype effort into something a customer wants. I found that my college training taught me to understand what a scientist says, but I never really developed the mindset to be a scientist. Neither could do the other's job to everyone's satisfaction. I serve in roles similar to that in my job where I bridge everyone's needs and goals.
We have faced this decision recently with a Matlab-like program called IDL, by RSI Inc (now called ITT). Our future work is getting so big and monstrous that IDL cannot deal with the datasets we need to process. Fundamentally, our scientists love the language - mostly. The CS people think it sucks as a language. But the language developers wisely provided ways to bridge their work with your code, and vice versa. They even developed an IDL-JAVA bridge a couple of years back. They have rudimentary support for XML (one of our coders rebridged that to Xerces a bit better) and he also bridged in HDF5 better than they did.
Still, our original concept of build it in IDL and optimize the hard parts in C just simple isn't going to cut it now. So now we will build the framework in C++ and let them add plugins that use IDL. C++ provides access to importing/exporting all the nasty data types, user interface, and handles the bulk of memory management. C++ also provides an easy bridge to a multitude of other languages.
It's tough, but the scientists are going to get the flexibility to poke and prod with new ideas, while the C++ folks keep the production users happy.
Bring on the High-Fructose Corn Syrup. Drink more Dew. Drink more Sprite. Obey your thirst. Feed your kids drinks with less than 100% fruit juice.
Tongue in cheak of course.
Almost reminds you of the idea people have with introducing insects into non-native environments and the bug turns out to be hostile so they introduce a second bug to kill the first, but which turns out to be worse than the first.
Farmer thirsty in corn field.
Farmer tired of water and lemonade. Sees future in vending machines.
Develops early soft drink laced with party enhancers.
People like the buzz, but sugar is about all they can stand.
Full out sugar drinks get people hyper. Farmer gets bizarre idea to melt corn into corn syrup.
I've heard whining that digg.com is faster on the review/post time, but I saw this on the TODAY show nearly 13 hours earlier, and they'd actually interviewed Ferarri and played the tape. Youch.
Perhaps they'll help get Audible out into the open with their proprietary codec. Doubt it though Audible everyone shuts down everyone who posts tranfer methods from their proprietary format to MP3. Sorry, no links since those get taken down too (i.e. GoldWave)
The U.S. Federal Government has pursued such an endeavor for places where multiple machines on a desktop are the norm. In those cases the thin client is replacing multiple network drops, one computer for each network, and sometimes a monitor for each (though usually a single-headed, VGA, PS/2 keyboard mouse). This may seem crazy to you and I, but imagine your internal accounting network which will never, never, never be exposed to the internet, not even remotely.
Their solution has been the DoDIIS Trusted Workstation, or DTW, (Google search) which has had mixed reviews to poor. Most resistance comes before anyone ever sees the thing work, never mind the O&M savings to IT. It turns out that users are hooked on having their own, dedicated CPU time, even if they kick it every day. Mix that with the parent's comment about terrible Microsoft licensing and you have a recipe for failure.
User's reasons include: insufficient bandwidth to display the graphics I use, insufficient dedicated CPU time for the programs I need to run, and "one network glitch and the whole enterprise stops working." I think these are all valid complaints. IT complains because the cost savings in hardware isn't really there. Good luck buying a thin-client for under $400. You always have that $200 monitor, plus the box is really just a micro-ATX box with flash memory to boot off of (the fancy ones) or DHCP/BOOTP remote boot (the cheap ones).
Face it, I don't really think you are saving much in terms of central administration because you are going to have select users that need custom tools. When was the last time you successfully had one program installed on an Windows box that wasn't instantly visible to other users on the same machine. Think in terms of that specially licensed accounting app for which your company can only afford four seats. You'll give accounting their own machines just to keep from avoiding the potential of illegal multiple installs. I could be wrong on this, but even if it is possible, the administration of such a system is non-trivial.
So how does DTW stack up anyways? Not so well in the places I've heard them trying to force it into place. In theory, it does what everyone wants to really do, but that darned software attributed of usability keeps creeping it's ugly little head up.
HardCat made by an Australian company, is a top of the line product. They offer a core+modules system that meets your budget. Covers purchasing, acquisition, warehousing, inventory, auditing, stock, depracation, equipment check in/out, handheld inventories, and more. Slightly pricey, but truly worth it. You've already got your organization for inventory worked out so the hardest part is done.
A big seller for me was the hierarchical locations, which makes it easy to write reports for what is in a room, floor, building, region, etc without having to redo everything. You choose the RDBMS (I know of Oracle, Postgres, or built-in Sybase). Offers assigning specific privileges to users to limit their domain of use. Nice touch is attaching whatever you want to an asset (picture of the asset) or to the class it belongs in (warrantees, manuals, etc) avoiding duplications. Plus it tracks your suppliers and keeps your purchase orders. End-to-end solution if you want. Worth the cost when it can completely replace your existing solution.
Ask a reseller near you for a demo CD with a sample or blank database. They cripple it by limiting the number of times you can connect to the database (hundreds of times) so you can freely evaluate the product.
If you have a lot of data, then you can choose a scalable system like IBRIX and then use stateful load balancers between each of the POP3/IMAP servers. When you get to multiple nodes on the same filesystem, you have two problems: synchronization between nodes and locking.
Note that the Oracle Clustered Filesystem v2 has now been merged with the mainline kernel.
Google Books seems like an ideal solution to this problem. Of course, I'd talk to Google about it first. Your source code repository would be transformed into book form with the source code as large excerpts and the revision control system being your chapter introductions. This would force the repository to be something organized and not just a mish-mash of inserted code. Their About page says that they'll show you a couple of pages. I would ask them to restrict the search to only showing the section introduction and a 15 lines surrounding the code in question. Google could then wrap an API around it to make it easy to programatically search.
Then, there's the issue of licensing. This would be, I think, the first legitimate use of the GPL (not the LGPL) for a published document. Google promises to protect the work as a dark search until valid copyrights expire. If you put a hypertext link into each section where the code can be properly licensed (i.e. downloaded), then it works as a prior art repository and as a code reuse archive.
Have we all forgotten what companies charge for $2 wall warts? I've even seen a Brother label maker wall adapter that has an odd voltage (7.3v), odd amperage, a non-uniform center pin, and inverse polarity. They go overboard with the accessory business. This particular wall wart costs $24 at OfficeMax. Then another $18 for the label cartriges. Then there are the power-hungry devices like cameras that don't come with a wall wart at all (computer controlled, time interval shots). Us mere mortals have to guess when we go down to the store what size connector to use. Face it, the money is in the connectors. If they can find a cheap way to make you use a new connector and charge outrageous amounts of money for adapters, they will. Cheer up. Atleast your iPod doesn't have any custom connector on it. Oh, wait. Never mind.
So maybe a better solution would be a single brick with different connectors for different voltages - this would conform to ISO standards. Then they could just pull the old printer "this box contains no cables" trick, and it would reduce the number of unused transformers out there eating away at copper supplies.
As the cloning discussions reveal, this one-factor authentication is too weak. Two Factor Authenticaion is the solution to this. It's the constant trade-off between security and convenience. This company neglects the convenience factor without improving the security factor. Obviously, the public outcry will change their mind, if their employee's opinions haven't already. Besides, all they are storing are video camera footage tapes. Obviously, they want to be able to prove whether or not there has been tampering. So work on methods to detect tampering and just make it reasonably difficult to get physical access to the vault. Someone really needs to read some Bruce Schneier books.
This multi-core race is already over. Sony wins by default with the PS3 coming in with 7 cores (#8 is a ghost to cover over manufacturing flaws and defect counts). And everyone is whining about how to code for 7 cores. Having four cores won't change this single-threaded world. When the libraries of the world are suddenly multi-threaded, the PS3 will be light years ahead. Plus, IBM is going to be putting their Cell processors on blades. IBM and AMD are two years too late to the game.
If a big-time politician came wandering through my cube, (and a couple have) you have two obligations: clean up your desk, and greet the distinguished visitor with a smile. If your boss asked you to work during the tour, let's not be an idiot about it - find some work, or at least repeat some work you've already done. The VIP doesn't know the difference. "Sir, I'm working on an analysis of the workload levels of the T&M contractors the city hires to see if we're getting a good return on our contracts." Never mind it was something you did 3 months ago.
Oh, and don't act like you aren't the BOFH that opens up old network statistics charts or network snoops, pouring over them when the big boss comes in. "Sir, I'm tracking through some anomalous network activity our SOA layer got during last night's advertising during the Olympics opening ceremony."
Anybody caught doing something stupid when a VIP is in the room deserves what they get. It's like seeing a cop in the median a mile ahead and then getting the bright idea to shift four lanes of traffic and pass on the right. You're begging for it. "My cell phone rang and I was just trying to honor good road safety rules, officer." Yeesh.
Slashdot Mirror
NVidia can still come off okay too, if they start now. They don't have to risk their IP either. If they contribute money and/or access to older video cards, then they have fostered the development of Nouveau. If they give the team the resources to succeed without giving them access to the source code to the proprietary drivers, then they have fostered the reverse engineering without committing their own staff or risking lawsuit from revealing potentially infringing/stolen intellectual property.
At the very least, they should review the Nouveau contributors and declare them to be free of NVidia influence (a condition of fending off an IP lawsuit). This may not do anything to foster the development directly, but it certainly gives the open source advocates all kinds of warm fuzzies that the company is genuinely interested in making quality open source drivers.
Quickly, before Cringely ruins it with bad math, I need to point out some very obvious weaknesses in making this work correctly:
Okay, you all can go back to your regularly scheduled cheap shots.
Funny, yes, but when I RTFA, those agencies weren't even listed.... And the real report doesn't list them either.
I understand your question, but Microsoft has made it obvious that they perceive vendor-supplied drivers as a serious threat to stability. When Linux is working without proprietary drivers, kernel coders have a chance to thrown useful debugging information in because they aren't trying to hide anything. Throw an independent, proprietary driver in there and your system's stability is at stake. Windows NT/2003/XP and Linux are both monolithic kernels; that is drivers run in kernel space. Vista has tried pretty hard to move closer to a microkernel architecture, but I haven't seen a whole lot on this so I don't remember if they've succeeded or not.
Case in point, Microsoft has seriously threatened that any driver that isn't WHQL-certified won't be allowed to run under Vista. Some could view this as an effort to push their cash-cow in trademark usage approvals, but I'm sure it's plenty profitable. Besides, all that testing takes time, which vendors hate. If vendors had time, they wouldn't be rushing the product to market in the first place. So market demands push poor coding practices on the driver, but Microsoft wants a reputation as having a stable OS.
Having open specification makes this problem go away completely. If Microsoft can keep the driver in their kernel, then they, like the Linux kernel hackers, can understand the ripple effects to internal API changes completely. No ambiguity. Microsoft, like the kernel hackers, can only speculate how their necessary changes will affect the binary-only drivers.
This is the world that NVidia and ATI are playing in. Only time will tell if they succeed to Microsoft's stability needs. There are lots of roads that can be taken, but nothing beats having drivers in plain view of every Vista kernel developer. NVidia or ATI (AMD) could court both parties by offering to throw away their proprietary and possibly IP violating code through an effort to fund a complete rewrite by a third party who has no access to the original codes.
Has anyone considered that the reason ATI/NVidia won't open source their drivers/firmware is because there are blatant copyright and patent violations in their code? I'm not saying there are violations, but if there are, then I would expect each to violently defend against anyone seeing their source code. To date, the best argument heard is that access to the code would provide their competitors an unfair advantage into their optimization techniques, which most of us recognize to be hog wash. At worst, they wrap it up in "we have licensed proprietary algorithms" declarations and refuse to give the community a chance to work around those algorithms.
There is only one way forward. NVidia should fund the effort to rewrite their firmware/drivers, providing only the hardware register descriptions and nuances. I'm quite sure others have asked NVidia to do this already, but Intel moving forward with this plan should force the other's hand. I'm surprised that Microsoft hasn't chimed in here because for every open specification we get in the OSS world, they also get. That's where all those Microsoft drivers come from. And only on occasion is a vendor-supplied driver better that the Microsoft one. Open sourcing any drivers also helps Microsoft support more hardware out of the box, without a multitude of licensing agreements and royalty schemes.
And of course, NVidia (and now ATI) have been adding more treasure to their war chests with the PCIe motherboards. I just bought a new motherboard and it's extremely hard to find a new board with PCI-Express that doesn't have an nForce or ATI chipset.
It's going to be a tough game for Intel because it's not just graphics drivers. AMD could play into this game if they took a decisive maneuver with their GPU integration into the CPU. Remember that AMD now owns ATI.
LISTEN to this chap! E-mailing the list is bad because that communication is in-band. It took the phone companies much frustration to move it's signaling out of bands. When payphones and the switches did all their communication in-band, then phreakers could manipulate the line via blue boxes or red boxes. If someone is running malware on one of your client's workstations, they could see the e-mail come across and later copy it for their own uses.
Out-of-band communication works because an attacker needs access to both communication channels. Usually, the cost of doing so is extremely high and is a very good countermeasure. In enos' descriptions, the mentioned out-of-band communications are a pad of numbers mailed through the postal system, which is slow and usually not preferred by marketing folks, but still quite effective.
The second case was the SMS message, like Google uses for G-Mail. The disadvantage here is that a) it costs money in the states, and b) not everyone has an SMS capable device.
A similar, but third alternative would require the customer to call the toll-free number on the back of their card, type the last four digits of their card, and three digits given in-band. The cost associated with war dialing an ANI-backed, bank phone number is EXTREMELY high, as the police have great motivation to go after people trying to steal from a bank.
In any case, if the customer has to hold onto something, make getting a replacement card as simple as 5 minutes in a branch office. Just let the tellers associate their new scratch-and-sniff card with their account and you're off. If you own your own ATMs, you can even dispense replacements from there for US$1.00 each, just like the deposit envelopes on some machines. Otherwise, they are just mailed for free when the pad of numbers starts to run low.
Encrypted file systems have a similar problem. They need to decrypt the filesystem for authorized boots or mounts, but need to stay encrypted otherwise. One common trick here is to only make the decryption key available once, at start up, after which it is put into memory, preferable with a small amount of obfuscation to slow down memory walkers. You could then use something like FUSE to mount the encrypted filesystem with your plaintext password.
As other folks have wisely pointed out though, the best posture is to use mandatory access control and restrict access to the configuration file. If you have the privileges, another good practices involves removing all compilers from the machine, firewalling all FTP traffic in or out, firewalling egress (outbound) HTTP traffic (pull in files to process), restrict SSH traffic to pre-defined nodes and enforcing that with a firewall ruleset. Preferably, you'd make all the firewall stuff occur on a separate box. What this does is restrict what tools will be available to an attacker. You can also remove fun programs like strings, ldd, od, *hexedit, and so on. "But I need to modify these tools!" you say. Leave SVN or CVS clients on the node, check your changes into SVN/CVS on your test bed machine, and then just check out the latest stable branch on your exposed machine. Then you get good protection and good configuration management all in one swoop.
Other tricks involve establishing a proxy process or strict limiting what can be done with the compromised username/password. A proxy process might be a setuid C program that only does one thing and accepts no user input. If you must accept user input, be extremely strict (use sscanf on all inputs and limit the size of the buffer accepted) and then have an experienced C developer review your code for improper bounds handling. This proxy process might do things like move files to a read-only directory structure (static web pages in a DMZ), or it might be a CGI script that updates rows in a database. We've actually used the CGI script idea because it a) it a cross-platform way of talking to the database, b) is a good decoupler of otherwise complex code, and c) strongly limits what can be done as an attack. Be careful of the venerable SQL injection attack there though.
A good use of a proxy process might be the transparent mounting/unmounting of an external USB drive, perhaps against a hidden partition on the stick. The drive would have your key. Sure it's obfuscation, but it's complicated enough to decode that it will slow somebody down for a while.
The last trick is to limit what can be accomplished with the username/password that is obtained. We have some processes whose job is to inject data into the database for the backend to all of our tools. That database user is limited to select, insert, and update operations. With Oracle, I could even restrict which specific tables get which privileges.
The best thing to do is to write a document that some folks call the Security Design Document to define your security posture, what you are known to protect against, and where you are vulnerable. Assign a risk mitigation matrix (vulnerability, threat, countermeasure, residual risk) row to each vulnerability. Be honest and then let your manager understand the position you've left them in and try to assign a cost to each countermeasure/mitigation so they can make a decision on what to close or leave open.
You are always going to have vulnerabilities. Everyone does, even the best systems. What makes the difference is those who analyze, understand, and counter that risk in a way that is appropriate to the situation. Direct exposure to the Internet is a situation that should warrant better risk analysis, but rarely does.
Let's start by linking to a Washington Post Article written by Dave Barry. I don't have the syndication rights to Mr. Barry's intellectual contributions, yet I just distributed a way for people to read that. I understand that the material in question is different, and I also know that the Washington Post has a policy explicitly allowing linking. But even if they didn't, I still don't have the right to advertise for Dave Barry without his agent or distributor's permission.
I agree. Truly bizarre.
Senior Engineers that are worth their weight in gold provide the role of mediator. I provide such a role in my little microcosm, and in turn answer to others when the problem steps outside my microcosm. In my organization, I have these groups all involved in changes to production: developers, system administrators, testing/QA, purchasing, security officers, storage administrators, network administrators, database administrators, and core infrastructure (electric, HVAC, floor loads). As a senior engineer, I have a BS is CS, have studied the OSes we use extensively and perhaps may obtain certification. I stay aware of security practices and rules that may hinder our permission to use it (think untrusted firewall vendors). Then there's the stuff that is the bread and butter of everyone else: Storage Area Networks, backup and recover, database performance/demands, and upgrades to the building blocks of the datacenter (electric, HVAC). And we haven't even talked about the user to developer interface, but that's usually a read-only operation for the Senior Engineer - know what the applications are and how they generally communicate so that issues from the application can be separated from issues with the infrastructure.
"No one person can do all that!" True, no one person can be expert in all of that, but that one person should dip their tendrils into all of it. Be all things to all people. Some situations where this has been relevant:
So if you haven't caught on by now, the phrase that pays here is "be all things to all people," which the Apostle Paul used to tell Christians on how to win unbelievers. Having the heart of someone who wants to genuinely help everyone means that the senior engineer will NEVER have to justify his job, because everyone will know that this disparate group of people, skill, and processes are brought together because of this individual's communication, understanding, and a willingness to help. If they get caught up in terf battles, then they ar
But specifically, Sed & Awk, and the latest Perl Nutshell book (3rd edition). A healthy subscription to alt.binaries.ebook.technical is also a must.
The most painful way, but only sure way to accomplish this is to disassemble the drive and melt the platters. If they are really old drives, then waving the disassembled platters under a wand-based degausser usually works. This stuff is all measured in oersteds. The recording head has to overcome the coercivity of the magnetic media in order to record a reliable signal. Coercivity is the strength of magnetic field (measured in, you guessed it, oersteds) required to alter the alignment of the particles on the platter. The heads can write at this strength and so must you if you wish to properly erase the data. That's why the big bulk erasers cost so much. The big one, the TD-1 can do up to about 8000 oersteds, which will do anything up to, but not including the perpendicular recording stuff in the 500+GB drives.
If you're a cheap skate, you and a T-8 wrench are going to be friends (get a bit for about every 20 drives cause they wear out fast if you're in a hurry) and pull the drives completely apart, down to getting the platters off the spindle motor. Some drives take a T-10 or T-6. Then send the platters to be burned. If you don't courier them to the incinerator, then at least play 52 card pickup with them and make it difficult for any but the most determined.
Rather than strip them of their patents, remove the right to decide who can or cannot license the patents, and take away all royalties. If you make it so that all parties using their patents simply notify them in writing, then they still retain their works and derive future patents off of them. However, they will be constantly reminded of yet another product that they will never get royalties from because of their past behavior. Stretch it back to when the comittee first started meeting at which point Rambus started their deceptive practices and end it at the time that the lawsuit was filed on the anti-competitive behavior. Anything before and anything after are unrelated and could be tied to a change in management attitude, be it for the better or worse.
This has to be done because not everyone is a scientist with an experimental, discovery mindset. Everyone is also not a C++ programmer (or Java, Perl, C, C#, etc.) and thus proficient at error checking and dealing with a variety of system interaction. Face it, people hire scientists to develop things no one else is doing, but who learned programming as a necessary evil. People hire professional developers to glue or reform that prototype effort into something a customer wants. I found that my college training taught me to understand what a scientist says, but I never really developed the mindset to be a scientist. Neither could do the other's job to everyone's satisfaction. I serve in roles similar to that in my job where I bridge everyone's needs and goals.
We have faced this decision recently with a Matlab-like program called IDL, by RSI Inc (now called ITT). Our future work is getting so big and monstrous that IDL cannot deal with the datasets we need to process. Fundamentally, our scientists love the language - mostly. The CS people think it sucks as a language. But the language developers wisely provided ways to bridge their work with your code, and vice versa. They even developed an IDL-JAVA bridge a couple of years back. They have rudimentary support for XML (one of our coders rebridged that to Xerces a bit better) and he also bridged in HDF5 better than they did.
Still, our original concept of build it in IDL and optimize the hard parts in C just simple isn't going to cut it now. So now we will build the framework in C++ and let them add plugins that use IDL. C++ provides access to importing/exporting all the nasty data types, user interface, and handles the bulk of memory management. C++ also provides an easy bridge to a multitude of other languages.
It's tough, but the scientists are going to get the flexibility to poke and prod with new ideas, while the C++ folks keep the production users happy.
Bring on the High-Fructose Corn Syrup. Drink more Dew. Drink more Sprite. Obey your thirst. Feed your kids drinks with less than 100% fruit juice.
Tongue in cheak of course.
Almost reminds you of the idea people have with introducing insects into non-native environments and the bug turns out to be hostile so they introduce a second bug to kill the first, but which turns out to be worse than the first.
I've heard whining that digg.com is faster on the review/post time, but I saw this on the TODAY show nearly 13 hours earlier, and they'd actually interviewed Ferarri and played the tape. Youch.
Perhaps they'll help get Audible out into the open with their proprietary codec. Doubt it though Audible everyone shuts down everyone who posts tranfer methods from their proprietary format to MP3. Sorry, no links since those get taken down too (i.e. GoldWave)
The U.S. Federal Government has pursued such an endeavor for places where multiple machines on a desktop are the norm. In those cases the thin client is replacing multiple network drops, one computer for each network, and sometimes a monitor for each (though usually a single-headed, VGA, PS/2 keyboard mouse). This may seem crazy to you and I, but imagine your internal accounting network which will never, never, never be exposed to the internet, not even remotely.
Their solution has been the DoDIIS Trusted Workstation, or DTW, (Google search) which has had mixed reviews to poor. Most resistance comes before anyone ever sees the thing work, never mind the O&M savings to IT. It turns out that users are hooked on having their own, dedicated CPU time, even if they kick it every day. Mix that with the parent's comment about terrible Microsoft licensing and you have a recipe for failure.
User's reasons include: insufficient bandwidth to display the graphics I use, insufficient dedicated CPU time for the programs I need to run, and "one network glitch and the whole enterprise stops working." I think these are all valid complaints. IT complains because the cost savings in hardware isn't really there. Good luck buying a thin-client for under $400. You always have that $200 monitor, plus the box is really just a micro-ATX box with flash memory to boot off of (the fancy ones) or DHCP/BOOTP remote boot (the cheap ones).
Face it, I don't really think you are saving much in terms of central administration because you are going to have select users that need custom tools. When was the last time you successfully had one program installed on an Windows box that wasn't instantly visible to other users on the same machine. Think in terms of that specially licensed accounting app for which your company can only afford four seats. You'll give accounting their own machines just to keep from avoiding the potential of illegal multiple installs. I could be wrong on this, but even if it is possible, the administration of such a system is non-trivial.
So how does DTW stack up anyways? Not so well in the places I've heard them trying to force it into place. In theory, it does what everyone wants to really do, but that darned software attributed of usability keeps creeping it's ugly little head up.
Ask a reseller near you for a demo CD with a sample or blank database. They cripple it by limiting the number of times you can connect to the database (hundreds of times) so you can freely evaluate the product.
If you have a lot of data, then you can choose a scalable system like IBRIX and then use stateful load balancers between each of the POP3/IMAP servers. When you get to multiple nodes on the same filesystem, you have two problems: synchronization between nodes and locking.
Note that the Oracle Clustered Filesystem v2 has now been merged with the mainline kernel.
Google Books seems like an ideal solution to this problem. Of course, I'd talk to Google about it first. Your source code repository would be transformed into book form with the source code as large excerpts and the revision control system being your chapter introductions. This would force the repository to be something organized and not just a mish-mash of inserted code. Their About page says that they'll show you a couple of pages. I would ask them to restrict the search to only showing the section introduction and a 15 lines surrounding the code in question. Google could then wrap an API around it to make it easy to programatically search.
Then, there's the issue of licensing. This would be, I think, the first legitimate use of the GPL (not the LGPL) for a published document. Google promises to protect the work as a dark search until valid copyrights expire. If you put a hypertext link into each section where the code can be properly licensed (i.e. downloaded), then it works as a prior art repository and as a code reuse archive.
Have we all forgotten what companies charge for $2 wall warts? I've even seen a Brother label maker wall adapter that has an odd voltage (7.3v), odd amperage, a non-uniform center pin, and inverse polarity. They go overboard with the accessory business. This particular wall wart costs $24 at OfficeMax. Then another $18 for the label cartriges. Then there are the power-hungry devices like cameras that don't come with a wall wart at all (computer controlled, time interval shots). Us mere mortals have to guess when we go down to the store what size connector to use. Face it, the money is in the connectors. If they can find a cheap way to make you use a new connector and charge outrageous amounts of money for adapters, they will. Cheer up. Atleast your iPod doesn't have any custom connector on it. Oh, wait. Never mind.
So maybe a better solution would be a single brick with different connectors for different voltages - this would conform to ISO standards. Then they could just pull the old printer "this box contains no cables" trick, and it would reduce the number of unused transformers out there eating away at copper supplies.
As the cloning discussions reveal, this one-factor authentication is too weak. Two Factor Authenticaion is the solution to this. It's the constant trade-off between security and convenience. This company neglects the convenience factor without improving the security factor. Obviously, the public outcry will change their mind, if their employee's opinions haven't already. Besides, all they are storing are video camera footage tapes. Obviously, they want to be able to prove whether or not there has been tampering. So work on methods to detect tampering and just make it reasonably difficult to get physical access to the vault. Someone really needs to read some Bruce Schneier books.
This multi-core race is already over. Sony wins by default with the PS3 coming in with 7 cores (#8 is a ghost to cover over manufacturing flaws and defect counts). And everyone is whining about how to code for 7 cores. Having four cores won't change this single-threaded world. When the libraries of the world are suddenly multi-threaded, the PS3 will be light years ahead. Plus, IBM is going to be putting their Cell processors on blades. IBM and AMD are two years too late to the game.
If a big-time politician came wandering through my cube, (and a couple have) you have two obligations: clean up your desk, and greet the distinguished visitor with a smile. If your boss asked you to work during the tour, let's not be an idiot about it - find some work, or at least repeat some work you've already done. The VIP doesn't know the difference. "Sir, I'm working on an analysis of the workload levels of the T&M contractors the city hires to see if we're getting a good return on our contracts." Never mind it was something you did 3 months ago.
Oh, and don't act like you aren't the BOFH that opens up old network statistics charts or network snoops, pouring over them when the big boss comes in. "Sir, I'm tracking through some anomalous network activity our SOA layer got during last night's advertising during the Olympics opening ceremony."
Anybody caught doing something stupid when a VIP is in the room deserves what they get. It's like seeing a cop in the median a mile ahead and then getting the bright idea to shift four lanes of traffic and pass on the right. You're begging for it. "My cell phone rang and I was just trying to honor good road safety rules, officer." Yeesh.
For those seeking to follow the actual PIV program for federal employees/contractors, check out their home page.