Slashdot Mirror
The Dumber Android Is, the Better, Say Experts
ZDOne writes "ZDNet UK is reporting that it will not be known until the Android software development kit comes out on Monday whether the Gphone will be strictly Java-based, but security experts claim that the less smart a phone is, the less vulnerable it is. Android developers should stick to a semi-smartphone platform because the Java sandbox can protect against the normal kinds of attacks, experts claim. The article also discusses some of the pros and cons of open vs. closed source security. 'The debate about the relative security merits of open-source as opposed to proprietary software development has been a very long-running one. Open-source software development has the advantage of many pairs of eyes scrutinizing the code, meaning irregularities can be spotted and ironed out, while updates to plug vulnerabilities can be written and pushed out very quickly. However, one of the disadvantages of open-source development is that anyone can scrutinize the source code to find vulnerabilities and write exploits. The source code in proprietary software, on the other hand, can't be directly viewed, meaning vulnerabilities need to be found through reverse engineering.'"
Dumb terminals can never defeat idiots. That's why nothing is idiot proof.
"The dumber android is, the better say experts." IS NOT
a sentence. Now return to your seance with the world's most dangerous criminal,
Cheers.
Experts suggest security-conscious consumers consider the Western Electric 500 for their next smartphone. Lacking Java, JavaScript, ActiveX, and any other type of software, its spartan phone interface makes it virtually immune to any security vulnerabilities, and its innovative "rotary dial" system circumvents attacks possible on touch-tone phones. The casing is constructed of nearly indestructible Bakelite plastic, making it far more durable than the average smartphone. It does however require a service agreement with AT&T.
"FDA staff reviewers expressed concern about the number of patients who were left out of the study because they died."
The dumber the smart phone is the better? Sounds like someone doesn't want to take their programming job seriously.
The smarter the user is the more secure the phone is.
Other brilliant revolations offered by the experts:
More parts == more places things can go wrong == more vulnerable.
Your ad here. Ask me how!
social scientists have long inferred that dumber people are less likely to fall for hustles/social engineering/hacking/etc., because they lack the imagination to consider alternate realities.
i've been consulting for a new york firm for about 9 months now. i do a lot of traveling, but i'm in the new york home base office at least 4 times a week. i often misplace my card-key - and the receptionist refuses to buzz me in, EVERY TIME. She's always like, "I'm sorry, I don't know who you are." her policy is to never buzz anyone in. She angered the chairman once over it, who was talked out of firing her precisely because he's in the office like 3 times a year. She won't buzz people in and she's unrepentently steadfast about it. She's dumb as dirt.
Simple systems are more likely to be secure than more complex systems in general as they are less prone to component failure.
un burrito me trampeó.
looks like we have a junk science blog (Client Audit) leading the best science blog in the best Science blog award. Polls close in an hour, so Making a firehose entry won't do a bit of good because it simply won't be visible enough and I know Mods are going to knock this off topic, but durn it, vote for bad astronomy (which is in second place), heck vote for anyone, we're slashdot, we should be able to sway the vote.
http://2007.weblogawards.org/polls/best-science-blog-1.php
Support NYCountryLawyer RIAA vs People
Yes, security through obfuscation always It seems that perhaps people would learn by now that simply isn't true. Maybe the obfuscation slows down the attacks, but the real issue is how fast the fix can be had. No matter whether the software is open or closed sourced, there will be bugs, and therefore potential attacks on it. At least with open-sourced software anyone can potentially fix the problem, instead of waiting for a company to take potentially very long times to patch it (which is fairly frequent, as documented by /.).
Also, something to consider is that both the HW and OS play a larger role overall in security. It is possible to design a system with automatic sandboxing, such that one program cannot touch the memory of any other program including the OS. You don't need Java for this. If the HW and OS are done correctly, all Java really buys you (in terms of security) are programs that won't segfault (though often exceptions aren't fully handled, which usually gives the same end result).
At first I thought this was a repeat of the previous robot article. I guess I really should brush up on the difference between androids and robots.
Anyway, More complex is effectivly as safe as less complex as long as the default options do not immediatly provide vulnerabilities. The more complex a device is the less features ID10T users will be able to misconfigure as it will be to complex for them to move much past the basics such as voice/text messaging.
This is the old telecom industry chant. "Let's put the smarts in the network, they say, where they're out of touch and nobody can even get in to attack them, and have dumb devices out on the edge. Blue boxes are just a rumor."
By all means it should be possible to make dumb phones with Java sandboxes around third party software using Android. Yes, every layer of security is good. But it's not perfect... if you put everything you want to protect inside the sandbox, who cares whether someone breaks out of it or not?
Don't forget, the OS they're basing it on was designed for timesharing use, where it was common for people who had very different security requirements running code together on the same computer. Linux is a relatively young implementation of UNIX, but it's still using the same design that was able to keep some of the world's smartest CS undergrads from getting at the test papers and scores stored on the very same computers as their class accounts in the early '80s.
And some of the biggest vulnerabilities available to attackers on any platform are in application layers, in code doing what it was designed to do, with no individual component violating any constraint that a sandbox would prevent. The biggest problems are not implementation flaws, they're design flaws.
That's why, despite years of warnings from antivirus company experts, we don't have a flood of smartphone viruses... because PalmOS and Pocket PC and the rest don't have multiple internal firewalls like UNIX or Windows NT, but they're also not designed around a model of accepting code from untrusted sources and running it, like Windows is.
Get the application design right, and you're solid. Get it wrong, and you lose... no matter whether the kernel is inviolate or not.
$SUBJ. If so (they gonna "tivoize" it as RMS would say) I'm sure backlash will be huge. If not - it's pretty clear that "Java-only" will not hold for more than a day or two.
There is an overwhelming consensus amongst real security professionals that security is achieved through openness, not obscurity and closed source. Just look at the systems that hyper secure organizations like the NSA advocate. Those who continue to rail against open source systems as being insecure because "hackers can look at the source" (yeah but they can't look at my key) seem as out of touch as creationists.
Disclosure gets you better security. Yes, it means two steps forward and one step backwards. If you only look at the step backwards then you'll miss that you've gotten better security overall.
Don't piss off The Angry Economist
"A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams.
You're welcome.
Shiny. Let's be bad guys...
This is the second article about Google Android today already and we never even discussed the original announcement, just what Ballmer and now ZDNet have to say. But I suppose there will be a long line of articles in the future so maybe it won't matter, just seems odd.
Reviewing just the first hour of video games.
Thats foolishness. Open source is far and away a more secure platform than "closed" source. One problem with closed source is that no software is truly closed. So you still have a handful of perhaps underpaid folks that get to see the holes just for themselves. Not to mention same folks can add their own holes. And still when holes are found the closed source companies tend to act like they don't exist. And try to write for themselves contracts that prevent them getting in trouble for said holes. There are just too many problems with security in "closed" source software.
Open source does not have any of these problems. Only problem with open source is if you have one person who is significantly smarter than everyone else looking at the code and can come up with an exploit before anyone else notices. This is a more comfortable position to be in as far as I am concerned.
First: She's always like, "I'm sorry, I don't know who you are." her policy is to never buzz anyone in. She angered the chairman once over it, who was talked out of firing her precisely because he's in the office like 3 times a year. She won't buzz people in and she's unrepentently steadfast about it. She's dumb as dirt.
She's not dumb, she's smart.
Second: Simple systems are more likely to be secure than more complex systems in general as they are less prone to component failure.
The Java sandbox is an extremely complex system, with trusted and untrusted code running in the same address space calling the same libraries, with the security managed by code that's also using the same libraries and running in the same address space. I am honestly amazed that it's worked as well as it has.
The multiuser protection in UNIX is an extremely simple system, with untrusted code running in separate address spaces and, traditionally, with the ability to run security applications using no shared libraries at all. It's also proven extremely effective, and it has the advantage that even if flawed code is run those flaws do not automatically provide an escape route from the whole sandbox the way flaws in libraries called from Java do.
This is not to say that the Java sandbox isn't a useful tool, but rather to say that when analyzing the security of the system as a whole the fact that an application is written in Java should not be given the kind of importance that it seems to be getting here.
Actually... I think it should be: the smarter the user thinks they are, the less secure the phone is. Reminds me of my PC Tech Support days long ago... "My neighbor came over, and he knows a lot about computers, so he started fixing my computer, now it won't start..."
People will want to make their phones do special and complex things. To facilitate this, they will write API libraries that other parties will also use because the phone's basic API will not support much.
The results of a non-robust API will be large amounts of object code libraries being built and installed, varying dependencies and conflicts and on and on. As much as possible, it would be best to maintain the API from a single point. This will also enable a much smoother user experience since people won't be forced to create their own GUI libraries and the like.
It needs to be complex and it needs to support everything... at least potentially. Ideally, everything except the data and the object code should be provided through the OS and OS supplied libraries. This would best guarantee compatibility and stability. But we know it won't happen that way. We can't even get KDE and GNOME unified. Some "smarter-than-you-and-me" guy will write something that will be rejected by the masters of the API but will be used by a variety of other developers and then it all begins.
And what happens when the OSS community rebels? Recall how XFree86 became stagnant and people rebelled to create X.org? That wasn't a disaster, but what happens when it happens on users' phones? And will there be multiple phone distros? And will AT&T and T-Mobile try to lock them up? And if they "can't" then will they block those phones from being used on their network (in spite of laws to the contrary)?
Perhaps this is a really dumb idea, but I can't get it out of my head. Please someone tell me I'm wrong and why. I can't stop myself from considering the possibility that there could be Microsoft lackeys that would purposely release malware for things like the Android so that people don't buy it. I feel like Microsoft has more than enough money to cover up their tracks too, so really - what's stopping them?
Whoa...wait...is that...no...it couldn't be...
Is that a Red Dwarf reference right there at the top?!?!??!
I woulda thought a place like teh slash would have had more references to that show, honestly...and for the record, Kryton was WAY smarter than Rimmer or Lister...
Unless...this is a reference to something else, and I'm being my usual dumb self..
Living With a Nerd
I like open source projects (mysql and subversion are tops in my book), but I have to take exeption with the notion that open source software is great because thousands of people from around the world are looking at and trying to fix the code. I think this is bull$h!t. Open source code is coded by a small fraction of it's userbase. And each project still has one, or myme two people at the top that approve and integrate each real change. It's not this automated machine. When developing any kind of software, you still need a someone in charge. Any software project needs a way to align the needs of the market with the efforts of the developers. In closed-source software, this is provided by the market. Money. And coordinated by non-coders, who try to find the greatest need in the market and fill it, because there's cash to be made. In open source, there's no such mechanism. Coders with features because they need them for their particular purpose, or because they are cool. As a result, some important features always seem to get overlooked.
XUL is the widget set of Mozilla. Because it is XML based, it is more secure because there is less parsing and less chance of programming errors. It will also allow digitally signed remote XUL applications to run. Mozilla is working on a phone version browser.
shaun
If I remember correctly from the brief days of my programming, isn't it possibly to copy an entire program into a text copy of the executable simply by mirroring the source output from an exe into a separate text file, which can even be done in things such as pascal? Doesn't this trump the whole "you can't seeeeee that" false sense of security?
So why is it that people think that not being able to look would be more secure when you really can't lock it out? Isn't it also a fact that when a vulnerability is abused in open source that it can be fixed just as fast?
A comma would help ("The Dumber Android Is, The Better, Say Experts"), but you're just being an ass.
This is so wrong it isn't funny. I need know NOTHING about the internals of a program to exploit it - I only need to find a set of inputs that make it crash in interesting ways. Buffer overflows can be trivially used to redirect a running program to jump to a stack frame supplied as part of the crafted inputs. There are other ways to play the game against binaries without reverse engineering.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Next they'll be telling us that "smart" functionality is a buzzword-compliant euphemism for complex code, that complex code is harder to debug than simple code, and that code which is hard to debug often has a lot of, surprise, vulnerabilities. How is this news?
The thing that a lot of people do not understand is that for the most part cell phones are one-time-programmable consumer electronic devices. Once the code is released to manufacturing, that is it. There are no more bugs - just unexpected features.
It matters not who is looking at the code in terms of fixing it. It is not updatable. I suppose it is possible that someone might come up with an updatable phone that was 100% impossible to "brick" but so far I've not see it. The risks do not outweigh the rewards with that and the current "experiment" with the iPhone is not proving to be very satisfying. Yes, they have a distribution technique for software updates through iTunes, but how many phones did they lose with the first update?
Treo has a slightly better record, except they do not have a distribution method. You have to download stuff and jump through all kinds of hoops. Perhaps 1 in 10 people update their Treo. I suspect Blackberry isn't much different from that. Also, it is far, far too easy to utterly destroy a Treo with a bad update.
No, I would not count on updates. Too risky and too little penetration. The end result is bugs that get released are features. And they are there to stay.
"The more they overthink the plumbing, the easier it is to stop up the drain."
-- Chief Engineer Montgomery Scott
Saying your "phone ran out of batteries" is like saying your "car ran out of gas tanks".
Look, it's a rough paraphrase of a Simpson's quote...
But my real beef with the mods is how can this be moderated "Overrated" when it hadn't been modded up by anyone?!?!? Who overrated it?
Phones have been updatable for a long time, simply by selecting an option somewhere in the settings will it check and download the latest software for that phone.
You would really have to travel back in time to get phones that don't have this.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
because here we have a situation were the various software have to communicate together. They have to speak a common language.
And that standard used to communicate between the device, HAS to be documented well.
from the
False.
You don't need to actually reverse engineer it.
Just get the documentation for the used standard. Then try every possible corner situation :
data packets bigger than normal, empty packets, parameters set to undocumented value, etc...
Chance are at least some of them will crash the code (giving a nice tool for DOS attacks) or even buffer overruns (giving a nice lead to explore to develop remote execution exploits).
And most companies producing proprietary code are small and have limited resource (small number of programmers and/or available eyes to do quality checking).
Thus they concentrate their efforts on the most critical features and important bugs (read: to be able to ship at least something - by ironing out bugs that prevent the code from even starting up) and read secondary bugs for later or never (read: every other possible bug).
Whereas in big open-source community you'll always find some psychopath whose hobby on friday nights is to run every single piece of code through Valgrind and similar tools. Or anal-retentive maniacs who won't stop before eliminating all compiler "warnings".
In a corporate world, those people would be kindly asked to concentrate on the main features before the deadline arrives. In open-source environment everyone is free to do what he wants with the code (the freedoms that license like GPL try to protect) and those people can even be useful if they provide patches and not alienate the rest of the developers when communicating with them.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Symbian say it's no good, Microsoft says it's no good, the Java lobby says it's no good. It looks to me like Android must be a winner if all these people declare their undying hate for it.
Ya, a dumb Android 18 would be fun.
If you could reason with religious people, there would be no religious people
Wouldn't it be great if /. editors learned how to use a frickin' comma?
It doesn't matter if your android is not so bright, as long as she is hot!
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
Yes, I totally agree! But try to make any corporate management to understand that, no way (yet?) OS can not protect when application makes stupid things. And for me, if you build a stack, it is an applications, if you build a driver, it is an application, if you build the authorization server, .. you get the picture. Unfortunately security is not (yet?) very high on list, even lower than performance in most cases I have seen. As you say, it is the design! There may be code problems but if the design is good they usually are very easy to test and find or the application just doesn't work. Now, especially lately, I have seen bad or no design at all, the word for developers is use this/that vendor/OS/IDE whatever and don't worry, it will work, you don't have to know/think such things like security/performance/manageability/testability/etc. Sad!
But he would not be offended unless he had his Emotion Chip installed.
And Lars, well he would just do something diabolical and painful to you for suggesting this...just because he could.
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
Quotes wouldn't help the actual grammar. Have you studied linguistics for 4-5 years? Maybe you should stick to what you know.
And the more extra complexity a car has, the more there is to go wrong.
That's why we all drive Model A Fords.
--
make install -not war
found through reverse engineering
I think we all know that hasn't stopped anyone before. So I still don't think this is a valid argument [pro closed source, that is].
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
I was starting to get excited until somebody mentionned its likely to be an all-Java environment, great - more slow apps coded by crappy outsourcers!
Can we have Python and Bash please - both provide a nice console as well as a decent programming language.
Is this really Linux-based like OpenMoko/Greenphone, or is it just another J2EE thing you can do nothing with and might as well stick with WinCE?
#include <sig.h>
The simpler/dumber the system, the better.
Computers are vastly too flexible/powerful for the average user. It's not that users are dumb/ignorant, it's just that most people would rather just do what they want to do and then do something else. Most people don't want to learn about subnetting, or how to edit the registry or set the virtual memory. They want to watch a pr0n clip, shoot at monsters, chat with hotties and find a recipe for turkey.
HOW TO - Make a Brazillion Dollars:
Create an atari 2600 like machine with cartridges containing programs that do email, surf teh webs, word processing, media playback and video games. Make it so that the user can perform only one function at a time, like a console or C64. Have the switching occur so fast the user doesn't think of it as: load, unload, load, unload reload. When the user switches from Email to word processing, the RAM is set to 0 instantly, aside from something like the clip board. Then load in the new program. Have the most essential programs hardwired into the system. Sell ROMs of other games and apps. These products must be static, so get them right the first time.
Is such a thing harder than it sounds? i think it would serve the needs of the average Joe and Jane far better than any PC on the market.
Utilizing the synergization of benchmark e-solutions to pre-workaround action items!
Anyway, except for the things' paths (there were two of them), power was only out for a few hours, so I charged it at work.
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
The desire of the telecom industry to "put the smarts in the network" has nothing to do with security and everything to do with economics. If the "smarts" are in my network, then you have to use my network to use those "smarts". If the "smarts" are in the phone then you can use those "smarts" on anyone's network. (Or, at least, on anyone's network that provides some basic level of infrastructure, such as Internet access.)
Don't underestimate the power of The Source
"Fuzzing" : Yeah, and you got "Gremlins" for testing PDA application, various memory debuggers (Valgrind, DUMA, dmalloc).
I know tools exist.
And as I said, where are you more likely to find people mucking around with such tools ?
- In a proprietary settings where you have a very small team that is short on time to have at least some running code before the deadline ?
- Or on some open source project where everyone is free to play around with the code (because of the definition of the GPL) and where you almost have an unlimited pool of contributors once your project crosses a certain amount of popularity ?
And given some recent history at Microsoft, I'm starting to doubt that even bigger companies that technically have the man power to divert some effort into quality checking, don't actually have a policy to systematically apply all available tools to secure their products.
They probably devote the additional man power at producing additional features to tout their products - i.e. more useless eyecandy.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]