Researchers Find Big Leaks In Pre-installed Android Apps 136
An anonymous reader sends this quote from an article at Ars Technica:
"Researchers at North Carolina State University have uncovered a variety of vulnerabilities in the standard configurations of popular Android smartphones from Motorola, HTC, and Samsung, finding that they don't properly protect privileged permissions from untrusted applications (PDF). In a paper just published by researchers Michael Grace, Yajin Zhou, Zhi Wang, and Xuxian Jiang, the four outlined how the vulnerabilities could be used by an untrusted application to send SMS messages, record conversations, or even wipe all user data from the handset without needing the user's permission. The researchers evaluated the security of eight phones: the HTC Legend, EVO 4G, and Wildfire S; the Motorola Droid and Droid X; the Samsung Epic 4G; and the Google Nexus One and Nexus S. While the reference implementations of Android used on Google's handsets had relatively minor security issues, the researchers were 'surprised to find out these stock phone images [on the devices tested] do not properly enforce [Android's] permission-based security model.' The team shared the results with Google and handset vendors, and have received confirmation of the vulnerabilities from Google and Motorola. However, the researchers have 'experienced major difficulties' in trying to report issues to HTC and Samsung."
Ars Technica? (Score:1)
How about a link to the quoted article?
Re: (Score:2)
Or not linking to a PDF named Woodpecker?
Cyanogenmod (Score:5, Insightful)
What does it say when I trust a bunch of random coders on the internet to give me a better performing, more secure, and overall more pleasing experience with my smartphone than the company that created it.
Re:Cyanogenmod (Score:5, Funny)
That they stood on the shoulders of giants, and combed their hair?
Re:Cyanogenmod (Score:5, Interesting)
People who own and use phones have a greater incentive to make a good phone OS than people who sell and provide service to phones.
Re:Cyanogenmod (Score:5, Insightful)
Re:Cyanogenmod (Score:4, Insightful)
Look, the people who develop the phones use them too. The reality is that there just aren't that many smart, motivated, capable engineers out there. Even when you have a few alpha-engineers on a team, their time is usually spent trying to squash those hard-to-fix bugs instead of doing a thorough security analysis. They're rushing to get the damn thing to production so they can move on to the next big thing.
I've spent my career developing embedded applications and not once has anyone paid me to address security. Bugs - user experience issues, stability problems, content security, standards compliance - those get the money. No one in management values security or privacy and they won't unless security researchers and hackers make the consumer aware of it.
Re:Cyanogenmod (Score:4, Interesting)
Actually - I wonder if there is a certification agency for security/privacy? I've never heard of it, but if someone like the EFF got together with a testing lab and established a logo-certification program for various classes of devices(phones, operating systems, set-top boxes, networking equipment, etc.) you'd have a way for the consumer to evaluate security and make decisions accordingly.
Re: (Score:2)
What does it say when I trust a bunch of random coders on the internet to give me a better performing, more secure, and overall more pleasing experience with my smartphone than the company that created it.
We refer to that as the "Open Source" development model
Re: (Score:1)
Re: (Score:2)
That was my first thought - are privacy and commercial success mutually exclusive for mobile devices? It seems that once a mobile OS is adopted by a large market the sleazebags move in to load it up with shovelware that siphons off your personal data (in the case of Android, that includes the carriers and even the manufacturers). Meanwhile the geek-oriented OSes (custom Android builds, Maemo/MeeGo, Ubuntu Mobile, etc) running open-source apps with funny names exist happily with no problems.
Re: (Score:2)
It means they can root your phone so you can install their, um, rootkit, essentially....
Re: (Score:2)
What does it say when I trust a bunch of random coders on the internet to give me a better performing, more secure, and overall more pleasing experience with my smartphone than the company that created it.
Except that the phones from the company that created the OS, Google, didn't have any security issues. CM is cool, but it's less secure than a standard Google build, not more. Although it probably is more secure than Android as delivered by the carriers.
Re: (Score:2)
Would using this software have protected a person against Carrier IQ's rootkit? I don't know anything about smart phone tech. I was actually thinking of getting one until this story broke. If I can gut the software and use something like a cyanogenmod to protect myself against privacy abuse that would be golden.
Re: (Score:2)
That you realize random coders on the internet are more likely to care about the end results of their product than a monolith like Samsung?
Where are the free source code scrubbers? (Score:1)
We need automated tools to catch obvious security errors in software much like grammer and spelling checks in Word processors.
The use of automated source code review tools should become more popular, especially as a well-linked resource from inside SourceForge and other sites that promote software development. Based on the number of security vulnerabilities so frequently found in software, there's got to be some signature-based checking that could catch the common mistakes, which could be made available by
Re: (Score:1)
> grammer
Spill cheque woks grate!
Re: (Score:3)
They exist (though they're extremely immature at the Android end of the spectrum), but they're breathtakingly expensive. I'm not allowed to cite specific products or prices, but we're talking "annual licensing fees comparable to the salary of a full-time human employee for 3-6 months" expensive.
Re: (Score:3)
Re: (Score:2)
Unless something has massively changed in the very recent past, Clang doesn't analyze Java (directly). EVEN IF you somehow managed to coax gcc into outputting something Clang can analyze, it's questionable whether the output would even be relevant. At best, you'd be scanning for vulnerabilities due to bugs in Android itself (which obviously exist, but are unlikely to be easily found as low-hanging fruit). At worst, you'd be completely wasting your time looking for vulnerabilities that might hypothetically e
Re: (Score:2)
Carriers (Score:3, Insightful)
The lack of control the carriers have over iOS is just one of the reasons I prefer it over Android. They wanted to pre-install a bunch of junk on the iPhone, and Apple wouldn't have it. The difficulty reporting these vulnerabilities to HTC and Samsung is not surprising.
Re: (Score:3)
Not again the iOS vs Android mantra about carrier installed crap, do you want a new clean phone? buy it unlocked without carrier intervention. Expensive? need financing? Use your credit card financing services, problem solved. And this worked since the old smatphones generations, I used Nokia and Sony Ericsson phones before the Nexus One
Re: (Score:2)
Where does one buy such a phone that is not locked down at the onset WITH warranty?
Re: (Score:2)
You must be living in USA, the country of locked phones, but just check the Nexus line [google.com], Sony Ericcson [amazon.com] and even Nokia [amazon.com]
Re: (Score:2)
I live in it little brother up north, the OTHER country of locked phones. (Our regulator is a revolving door to vendors)
I was hoping for Motorola droid razr.
Re: (Score:2)
Sure, but what about when some sort of vulnerability is found in iOS? It's not like Apple is somehow magically invulnerable to software security issues. At least with a lot of Android phones you can do something about it without getting too much shit (if any) from your carrier.
Re: (Score:3)
Re: (Score:2)
I would agree that they have more incentive to make sure things work, and they have more liberty to make the necessary changes, but these don't always translate into better outcomes. They have so far, though.
Re: (Score:2)
Every iOS device introduced after June 2010 is supported with OS updates and security fixes from Apple. Can Android users say the same?
Let's see....
Android
1. A security vulnerability is found
2. Google patches the vulnerability
3. And
Re: (Score:2)
Sure it does. When a vulnerability is found in WebKit and Apple patches it, it get's checked into source control and eventually used by Google.....
Re: (Score:2)
IIRC Apple *installed* Carrier IQ, but it wasn't activated unless you enabled "send debugging information". Something like that. I don't have an IPhone, and I can't quite remember the precise activation mechanism.
Now of course this doesn't mean that they might not activate it in the future via some "security upgrade". That kind of behavior is what turned me off to Apple. But *currently* they appear to be using it in a reasonable manner.
Re: (Score:2)
Re: (Score:2)
It's only operational on the iPhone 4 if you opt into it. It's already been disabled on all other phones and will be removed in a later version of iOS6.
Re: (Score:2)
Crap. In a later version of iOS5.
Re: (Score:3)
The IPhone comes with a pile of junk on it too, which you can't remove. Furthermore, Apple have admitted they've been using Carrier IQ, which was obfuscated from detection.
Finally, the iPhones are the only phones you can root by merely going to a website. Now that is utterly pathetic!
I'm not sure why I'm bothering, but what junk are you referring to? You may not want a magnetic compass or a calculator but I wouldn't classify it as junk. Put it in a folder off your home screen and I doubt it uses more disk any song that's not innagadadavida.
The iPhone's diagnostic data is not obfuscated. It's plain text and available/viewable from the menu. It never recorded keystrokes.
True about the website and many people see that as a benefit. Downloading and running an app to root is so 1990.
Re: (Score:2)
True about the website and many people see that as a benefit. Downloading and running an app to root is so 1990.
I thought Apple patched the exploits used by jailbreakme.com ages ago.
But Let's Vote Using Smartphones (Score:5, Insightful)
I hope all of the people thinking it would be very cool and convenient to vote via smart phones (or the internet, or the telephone, or the mail system) will notice that smart phones might not yet be perfect.
Voting is a classic example of a situation where the requirements cry out for appropriate technology.
The requirements are unique: you must not be able to prove how you voted, you must not be able to sell your vote or be coerced by anyone, you should be able to have complete confidence that your vote was counted properly along with everyone else's.
The technology that is required is completely straightforward -- people have to go to protected locations, create physically countable and non-traceable artifacts that represent their uncoerced opinions, deposit these artifacts into a locked box at the location, and know that the contents of the locked box are properly reflected in the results.
The best way to accomplish the last step is to count the contents in public before the contents are moved, and to generate and digitally sign images of the artifacts so that anyone who wants to confirm your count is an accurate representation of the contents is able to do that.
All attempts to modernize voting for convenience's sake are misguided. All opinions that making a simple approach more complex to speed up the distribution of results are misguided. Something that is convenient but cannot be checked is not appropriate for voting. And any time a computer scientist tells you how secure something is, introduce them to real people and the way they protect their passwords.
Re:But Let's Vote Using Smartphones (Score:4, Insightful)
The appropriate technology for voting is a pencil.
Anything mechanized or computerized might be splendid, efficient, and offer a whole host of other benefits. But they all lack the absolutely vital feature; the average man on the street must be able to audit it. And verily, should be required to do so.
Making a voting system where only a limited set of technocrats can audit it's veracity is madness.
Re: (Score:3)
Even if the voting machine is a pencil, as long as the counting machine is a computer, we run into the same issue. Sure, it can be audited, but that's not going to happen the majority of the time.
Re: (Score:3)
And that's why, in addition to hand counting of the ballots at the precinct, there ought to be (at least) a digital image backup enabling complete redundant counting off the images.
The best approach would be to generate the image collection, on unchangeable media, at the precinct at the close of polls. This should probably be generated from an independent scanning station, so that the ballots can be shuffled prior to scanning. This copy should be created at the precinct, because that is where workers can
Re: (Score:2)
If you computer count all ballots and randomly hand-count some segments of ballots, you catch errors in the counting.
Re: (Score:2)
The only appropriate technology for voting is raising your hand. Any device such as a ballot that can be locked in a box and carted into a locked room to be counted by strangers is eminently hackable.
The secret ballot is the single greatest threat to verity in elections since we stopped allowing the outright buying of votes.
Re: (Score:2)
Wait. You think you're going to be shot if you vote in public, so you don't mind a system where you can't protect your vote from simply being ignored?
Get out of my America.
Re:But Let's Vote Using Smartphones (Score:5, Interesting)
Let's be honest: the average man can't audit anything. In the end, it's more about trust than technology.
Can I trust that no one will fold the ballot in a certain, unique way that would allow someone to tell it apart? Can I trust that no one will add a doodle that will equally provide a "signature"? If I can't, then I must admit there are ways to prove how someone voted.
Can I trust that no one will use the signatures describe above to identify a voter and pay/coerce? Can I trust that everyone will uphold the secrecy? If I can't, then I must admit that votes may be up for sale or manipulation.
Can I trust that no one will miscount? Can I trust that the people counting are impartial and not subject to coercion? Can I trust that, even if I'll never be present at the counting and audit the system myself, it will be carried out perfectly? If I can't, then I must admit that the whole counting thing will eventually be rigged.
There's only one reason an average man on the street trusts the system (if he does): it's familiar. Just like his trust on https, credit cards, or the expiration date of his food. Regulations for voting give trust to Average Joes and Janes because they are familiar with those measures and can somewhat understand how are they supposed to prevent rigging, not because they are effective (this is true for a lot of situations, TSA comes to mind). If people trust electronic voting systems, then they'll become the appropriate technology.
I'm sick and tired of hearing "You can't be 100% sure of X with electronic voting systems! The whole system is crap!" or "Aha! The 7th step in your chain of validations can be manipulated! The whole system is crap!". Well, it isn't. Look at elections worldwide: they are done in P&P, yet everyone says they are rigged, regardless of international (and supposedly impartial) auditing. Regardless of analysis. Just because people don't have trust in it.
We can't, therefore, judge a voting system just on how inexpugnable they are: the only thing we can do is put enough checks and barriers to make it really hard to break the main requirements, we do enough information campaigns to explain in layman terms what's going on, and we friggin' trust on the outcome. We are losing some great stuff (i.e. precision and accuracy) just because we demand things we never had and never will.
Now, let the /. crowd proceed to mod me down. But before that, my ad hominem. Your comment is group-think at its finest. Only a few people bring nice arguments to the /. table nowadays; the rest just repeats whatever the consensus is and are happy to maintain the status quo. Use your friggin' brain and don't follow the herd.
Re: (Score:2)
I think you're right that auditing is a non-solution. But that only means that the counts must be easily verifiable by average persons, when motivated. The trick is to provide a solution where the average motivated person has access to enough information -- correct information -- to confirm things for themselves. The glories of redundancy will then take over, because there will often be people who are inclined to check.
As long as the signed ballot images can be confirmed to match the ballots -- and that
Re: (Score:2)
Well, after reading your response, my mind is at ease (I also took a nap and reached my WHO-recommended 6 hours of sleep :P ).
On the question of how easy it is to verify, I really don't know. Not because I can't come up with ideas, but because I don't know what the Average Joes and Janes would find acceptable. Maybe distributing a photo of all the motherboards involved, and using acrylic cases to display them on election day, is enough to earn their trusts. Of course, it won't do for us, tech-savvy people,
Re: (Score:3)
You should look into Scantegrity, developed by security researchers David Chaum and Ron Rivest (the latter is the 'R' in RSA).
It is an automated, scanner-based voting system which is more secure than pencil and paper systems, precisely because it's more auditable. It actually enables each voter to verify that his or her ballot was counted correctly in the final tally -- but without giving the voter the ability to prove who they voted for to anyone else, to eliminate issues of vote coercion. The system a
Re: (Score:2)
All voting systems have holes.
Ballot boxes can be stuffed. The counting room can be infiltrated by partisans. The entire process can be a sham run by the state's Secretary of State.
And the issues on which you base your votes can be complete bullshit designed to distract you from the true issues on which you should be making your decisions.
Nobody said plural voting wasn't a logical fallacy in the first place. It's just better than letting a guy make the decisions because he killed the last guy who made th
Re: (Score:2)
Voting should not be another phone app. It should take a deliberate effort on the voter instead of something you can do while sitting on the crapper.
It's absolutely scary how people vote now. They blindly vote along party lines and have no clue who the candidates are, their history or even their position on key issues (not the fluff crap the media tells you is important). You'd see a radical difference if the ballots just listed names and did away with the little (D) and (R) labels. Don't even put a descri
I love drop-through logic... (Score:2, Insightful)
if (x < 0) {do_sfuff(); exit;} ...
if (x == 0) { do_other_stuff(); exit;}
if (x > 1) {
... establish restrictions
perform_secure_operation();
}
.
.
.
So... what happens when x == 1
Re:I love drop-through logic... (Score:4, Funny)
} else {
... user equals root.
}
Re: (Score:2)
HTC and Samsung (Score:5, Funny)
No problem. Just repeat your findings into one of their phones: they'll literally get the message via CarrierIQ.
Re: (Score:2)
Or put it out in the wild where slashdot can get at it.
Android = Windows 98 (Score:1)
A year ago I was excited about Android. Today I would not touch it.
Re:Android = Windows 98 (Score:4, Informative)
The real problem with android, is that handset makers release closed source binary drivers.
This creates a powerful barrier to entry against rom hackers like the cyanogen team.
Personally, I would like to see google smack some bitches by demanding either open source drivers only, or supplying feature complete whitepapers for all devices released with closed drivers intended for the android platform.
This would create a permanent hole in the current software lockdowns carriers and handset makers use.
My own phone, a samsung sidekick 4g, is basically a galaxy series device inside, but is not supported by cyanogen because of binary drivers issues, and a not fully documented cpu variant. I would very much like to ditch the stock rom, and not have to rely on cooked roms based on it, and finally get something newer than froyo with a facelift.
Requiring open drivers or feature complete white papers would fix that.
Re: (Score:2)
Won't work. If Google imposes it as part of "With Google", the only chips available would be ones with open-source drivers. And there's very few of those, even fewer with 3D accelleratio
Re: (Score:2)
I didn't say the license needed to be gpl, just open.
As for "we don't want another xda-dev sprouting up", that strikes me as the rhetoric of a dinosaur. If they said "we don't want to be put in the position where we might be forced to support 3rd party modifications" I would be sympatheric, but when they essentially epoxy the hood shut on my sportscar, because they "don't want another community-mechanics site popping up" I don't see them as anything but officious asshats.
Re: (Score:2)
The real problem with android, is that handset makers release closed source binary drivers.
While that may be a real problem, it's got nothing to do with the problem discussed in this paper.
Re: (Score:2)
On the contrary.
A fully open system is more easily audited. A more easily audited system is harder to hide garbage code in.
The carriers and handset makers are putting quick and dirty kludges in effect, because they want to race to market, and they feel they can get away with it.
If you make it harder for them to feel more secure (emotionally) by hiding dirt under the rug, they will make themselves feel more secure by actually sweeping up, even though that is work they apparently don't want to do.
Further, pro
Re: (Score:2)
On the contrary.
A fully open system is more easily audited. A more easily audited system is harder to hide garbage code in.
Read the paper. All the code that was examined to find these issues was Dalvik bytecode, which is very easy to analyze and audit. In this case it was probably easier to audit at that level than to audit the source.
Re:Software = Windows 98 (Score:2)
There. Fixed that for you.
I never agreed to the permissions for the pre-apps (Score:2)
So, if I never agreed to the permissions.. how can I disable their use?
And don't answer with 'root'. Rooting is not an option.
How legitimate, or legal, is it for these built in applications to access my data when I have never accepted the permissions?
Re: (Score:2)
Security wise - yes, most Android installations are pretty terrible. Especially if you are stuck with Froyo or some other outdated version.
There are only two real options: Nexus and Cyanogenmod. Everything else is pretty much unacceptable (especially Samsung, as nice as the hardware may be).
Re: (Score:2)
Security wise - yes, most Android installations are pretty terrible. Especially if you are stuck with Froyo or some other outdated version.
There are only two real options: Nexus and Cyanogenmod. Everything else is pretty much unacceptable .
You forgot iOS. So, that's three options.
Re: (Score:3, Funny)
Re:Android sucks (Score:5, Funny)
he tried using "Frosty piss" with Siri, but it gave him directions to closest outdoor bathroom
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Grow up, retard; the goatse shit is old - much older than you'll ever be.
(oblig.) He got you good you fucker!
Re: (Score:2)
Re: (Score:2)
Yeah, but the classics never go out of style.
Re:facepalm (Score:5, Insightful)
Re: (Score:3)
so true! at least put security at the method call level, not in the code-body! A user of an API should NOT be capable of even running if the user does not have permission!
Re:facepalm (Score:4, Insightful)
How then do you prevent the user from circumventing the application and using their db permissions to misbehave directly if the user should only be able to do certain things in certain situations? To say blanketly that the only correct approach to security is to implement it at the db level is naive as there are many situations where it is not desirable that the user have any permission to the DB other than through the application. It would be nice if it was possible to have a combined security that would only allow the user to have permission while going through the application, but that is also notoriously difficult (if not impossible) to implement in many situations or on certain platforms.
Re:facepalm (Score:4, Interesting)
You say this, like something complex is doomed to be incomprehensible to do correctly. Simple fact of the matter is, these silly folks are still using strlen(...) and ridiculously bad coding practices, known for decades, all to come in under deadlines.
I see WAY too often a multi-tier database application, where security is implemented by constantly querying what rights the user has from a "Users" table. They implement security with a bunch of 'if/switch' statements and claim "it's the nature of complex software!" when a security vulnerability is found, rather than putting security on the database.
Uh, what other way is there to implement a rights check?
Whether you get your data once or a hundred times, or whether you do a specific check or rely on the OS do it, it doesn't matter - it's still a table of users + rights, and a bunch of conditional statements the cpu plows through. You may argue that it's more error prone if you're writing a query and an if statement every time a check is needed, rather than using an API or relying on the OS to automatically call its own APIs. But you can't say it's less secure until you actually have an incident where there was an error that would have been prevented by calling the API instead of doing an ad-hoc query + if.
More likely to be insecure != insecure != less secure.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Uh-huh. So for instance, on a web-app, your recommendation would be that every time a user signs up, the app creates another database-level user with specific permissions. So your app now has to have permissions to grant permissions on a database, and you could well end up with a couple of hundred thousand database users. Man am I glad you don't work with me.
Also, in the implementation of most databases, user rights are still just queried from a table. The only difference is the tables are managed, and the
Re: (Score:2)
You say this, like something complex is doomed to be incomprehensible to do correctly.
A claim which is particularly interesting in light of the fact that the Google phones had no significant flaws (at least under this analysis). Does it really surprise anyone that all of the crapware loaded by the carriers causes problems?
Re:facepalm (Score:5, Insightful)
Re:facepalm (Score:5, Insightful)
Nope. This complex software (Android) has a surprisingly good security model. Carriers are installing software which ignores permissions, is not removable by the user, and creates new, serious security issues. The carriers are being evil and/or incompetent.
Re: (Score:3, Insightful)
If you read the paper you would find that *Google* phones also suffered from the problem, albeit to the least degree. Both the Nexus One and Nexus S did not effectively protect the DELETE_PACKAGES permission. That isn't exactly insignificant. Now, the likelihood of a google fixing it is rather higher than Samsung or HTC who ignored the researchers reports prior to release of the paper, but it isn't *just* a carrier issue.
Re: (Score:2, Informative)
Well maybe you need to read more closely too -- Those two phones allowed DELETE_PACKAGES to be called on a hard-coded string related to the pico TTS component. Basically if you used this method, you would uninstall part of a text to speech engine. This is not exactly critical. The carrier leaks potentially considerably worse though.
Re: (Score:3, Insightful)
Re: (Score:2, Insightful)
Re: (Score:2)
Wait, what now? So when it's about Android vulnerabilities it's "Faceplam. This just in: complex software has security vulnerabilities." and when it's about Windows vulnerabilities, Gates should get a death sentence and we should bomb half the planet to kill every human being has ever even touched Windows?
Welcome to slashdot.
Re:facepalm (Score:4, Insightful)
Re: (Score:2)
I think the key difference is the number of us who've had to clean up after Gates and suffer the outcomes of his security.
Every time some windows botnet completely outside of my ability to control hammers on my public facing boxes and I have to divert time into dealing with or mitigating the impacts of that traffic, I look to the sky, shake my fist and scream GAAAATESSSS! All of the time I spend doing that is time that I don't spend adding real value to my customers.
How many of us that run secured equipment
Re:Just try to remove them... (Score:4, Insightful)
But you CAN root your phone, which means that these massive security flaws are actually a FEATURE of Android phones, because it will inspire everyone to root their android phone too!
Duh!
Re: (Score:1)
As long as somebody can root my phone I'm happy.
Re: (Score:2)
Goatse alert (Score:2)
For those of you who live under a rock, that's goatse. *Yawn*
Come on dude try something new. You're boring us.
Re:Not Exactly Shocking... (Score:4, Insightful)
Open source, assuming you have enough (competent) people working on it, is MORE secure than closed source.
In short, it appears you have some rather backwards pre-conceived notions about open source, and apparently you also have a reading comprehension problem.
Re: (Score:3)
You are presuming that they are blunders rather than something more sinister. This may be a correct presumption, but should not be presumed so. The actual fact is, we don't know why they are doing this. If it's a mistake, someone else will take advantage of it, if it's intentional, they will, perhaps by selling the information, perhaps more directly.
So the reason is less important than the fact. But it's not unimportant, so it shouldn't be presumed. While there's insufficient information it should rema
Re: (Score:2)
That said, yes, there are reasons why FOSS is generally more secure. One of them is the expectation of errors being revealed. We all want to avoid embarrassment. Closed source software doesn't usually need to worry about that.
I'd have to say its more along the lines of:
a) They are more likely to be revealed (because anyone can see the code)
and
b) They are more likely to be fixed (because anyone can work on the code)
To steal from ESR's "The Cathedral and the Bazaar", Many Eyeballs Tame Complexity. [catb.org]
Re: (Score:1)
Goatse again (Score:2)
If user = dev### or href=boredgeek.evenweb.com then page=goatse
Add that to your brain's page filter script everyone.