The Dumber Android Is, the Better, Say Experts 165
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.'"
Yes...but... (Score:3, Funny)
Dumb terminals can never defeat idiots. That's why nothing is idiot proof.
Re: (Score:2, Funny)
What?! Somebody had to make the Radiohead reference.
Security : Paranoid
Gphone : Android
Re: (Score:2)
The most secure phone ever! (Score:5, Funny)
Re:The most secure phone ever! (Score:5, Interesting)
I know it's meant to be funny, but strangely it's one of the reasons I haven't ditched my land-line to go all wireless. Mobile phones, especially those that try to do everything, aren't particularly good at anything and the more things you cram onto them, the greater their vulnerability profile. My wife just traded her old broken-down phone for a T-Mobile Shadow, and it's not the world's greatest phone (it runs Windows Mobile, but that isn't the root of the problem). The sound quality is horrendous and I haven't tried the MP3 player in it, but I'm not holding out hope.
I don't think we're at the point where phones can handle multiple tasks well, and using one is leaving yourself open to all sorts of mischief.
Re:The most secure phone ever! (Score:5, Interesting)
My cell phone worked, however. It also was a very handy flashlight, as there was no power AT ALL anywhere near my apartment and boy, was it dark there at night! It's been years since I've had a landline.
-mcgrew
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
how did you keep the batteries charged?
Re: (Score:2)
What is the signal strength when you get this "awful sound quality" - T-Mobile has the smallest network (read: least coverage) of the four U.S. carriers. That's why they're so dirt cheap - you get what you pay for.
This article is just a pile of FUD. I laugh at the morons who buy antivirus software for Windows Mobile phones, when there is little to no risk of contracting a virus unless
Re:The most secure phone ever! (Score:5, Informative)
But the Western Electric 500s were hackable! Some of them had no dials; businesses used the dial-less phones for where they wanted a low level employee, like the teenaged me at the ticket booth at the drive in theater, to be able to answer them but not make outgoing calls.
You could, however, "dial" them by repeatedly hitting the hangup buttons. So I was hacking your "unhackable" phone when I was 16. Actually I was cracking not hacking; I was hacking when I made guitar fuzzboxes out of $10 transistor radios and selling them for $50 each to other teenaged guitar players.
-mcgrew
PS- I've almost forgotten this, but in the Metro East St Louis area you could dial Bridge 1300 and a spooky noise cane out of the phone. The other kids said it was a ghost, I never had the heart to educate them about the reality.
Re: (Score:2, Interesting)
Re: (Score:2, Interesting)
Re: (Score:2)
As for what 271300 was, I haven't the faintest idea.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The what the hell does that make PHONE NUMBERS?
Can you imagine anybody creating a communication system today where subscribers are addressed by a seven digit number plus a three digit prefix?
We use GotoAssist at work -- highly recommended by the way if you support Windows clients. GotoAssist issues seven digit tickets, which works great; people are so accustomed to seven digit phone numbers that they are ridiculously adept at keeping them in short term memory.
Re: (Score:2)
Huh? (Score:5, Interesting)
Re: (Score:2)
No wrong... (Score:5, Insightful)
Re:No wrong... (Score:5, Funny)
Re: (Score:2)
And many of the smart ones are less likely to pay for crap too, so you have to go to the trouble of actually making stuff that works well.
Still wrong: (Score:4, Funny)
Re: (Score:2)
perhaps completely unrelated (Score:1, Insightful)
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 nev
I think you've come to the wrong conclusion. (Score:5, Informative)
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.
Re: (Score:2)
"A foolish consistency is the hobgoblin of little minds" - Ralph Waldo Emerson
Re: (Score:2)
Notice that in your quote that Emerson is referring to "foolish consistency." It sounds like she is foolishly consistent. She lets some people in without their key card, so she is inconsistent.
Why would it be a good idea to buzz people in she doesn't know?
Re: (Score:2)
Re: (Score:2)
They should value her as an asset, as she is obviously very resitent to social engineering.
Re: (Score:2)
As far as I am aware, there has been 2 hacks of the Sun's Java security manager, both fixed quickly. Apart from that, Java applets have been living safely in people browsers without incident. Java has convinced me that virtual machines are
Re: (Score:2)
However, Java also offers one major advantage for me. Other than having multiple user accounts, which is a pain, I don't know of any good way of stopping a program getting access to files in my home directory. As I'm the only person on my computer, to be honest having a program 'go mad' as me is jus
Re: (Score:3, Insightful)
With that in mind, consider the possibility that you often misplace your security card as your failing. Instead of blaming someone else because they won't fix your life for you, take a little responsibility.
I know, it's a bit of a no
Re: (Score:2)
Re: (Score:2)
Did I miss something? (Score:5, Funny)
Re: (Score:2)
If I remember right, that closed source thing... hmmm it seems to be working out really well for Microsoft.
Yep, they're practicly eradicated by now. Along with every other closed source company. No? If you take the big three - price, functionality and quality, pick any two, then either they can't be far behind in security or their product are a lot better, since they sure don't win on price. And you can't accuse all of them of having the deskatop monopoly of our favorite hate object...
Re: (Score:3, Insightful)
The "many eyes" argument fails as well, though, simply because many eyes do not make for better security. Many hands, on the other... um... hand, make for better response time. Open source code tends to be more agile because it's o
Re:Did I miss something? (Score:4)
Re: (Score:2)
Robert
Closed source is even more hackable in this way (Score:2)
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
Re: (Score:2)
Yeah, and as I said.... (Score:2)
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
Re: (Score:2)
security experts? (Score:2)
Androids... Robots... (Score:2)
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 more "smart network, dumb device" logic. (Score:5, Interesting)
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.
Re:This is more "smart network, dumb device" logic (Score:2)
Re:This is more "smart network, dumb device" logic (Score:2)
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 "
proprietary security is like creationism (Score:5, Insightful)
Re:proprietary security is like creationism (Score:4, Interesting)
And, there are good arguments for security through obscurity -- a concept all too quickly shot down here at Slashdot. For example, leaving a house key inside a fake rock in your garden is arguably more secure than leaving the key under your welcome mat. Another example, in which I have personally experienced the behefits of security through obscurity, is network ports. I used to have ann SSH server running on the standard, port 22. Every day, my logs showed numerous login attempts by unknown individuals trying to gain access to my system. Once I moved the server to a different, more _obscure_ port, though, my logs rarely show any connection attemps. Now, is this new port more secure? No. But, because it's further hidden it does afford _more_ security.
And, as for your final, fanny-pat statement to the "consensus" of the "scientific" world: I'm a creationist, and I'm not out of touch. For me, the incalcuably small probability of spontaneous generation of a lifeform able to be nourished by it's environment and then able to reproduce is not a large-enough foundation on which to build a scientific consensus.
Re: (Score:2, Insightful)
Re: (Score:2)
This is not necessarily true with closed source, but is ALWAYS true with open source.
Re: (Score:2)
There's not much direct evidence in support of abiogenesis. It's more of a logical argument that life had to come from somewhere, at some point. Even if you accept that God created the Earth and all the life on it, God himself is a living being so the creation of Earth
Re: (Score:2)
As for your last sentence, if you include supernatural in your definition of "living being", then you are once again correct. If, however, you assert that creationists must believe the Creator to be a mortal creation Himself, then you're stuck back at the problem of God's spontaneous generation. In that case, nothing is gained and, as you st
Re: (Score:2)
But, abiogenesis IS a prerequisite to rejecting creationism, and therein lies my point.
No its not. Just like you don't have to accept a particular cause for the Big Bang to accept that the Big Bang happened and study the development of the universe, you don't have to accept a particular cause for abiogenesis to accept that abiogenesis happened and study evolution.
As the grandparent post said, its fully possible to believe that evolution occurred more or less undisturbed after God provided the initial s
Re: (Score:2)
But, abiogenesis IS a prerequisite to rejecting creationism, and therein lies my point.
No it's not. There are other theories. Maybe I don't accept creationism or abiogenesis. I might even say I have no idea how life started without accepting any explanation.
If, however, you assert that creationists must believe the Creator to be a mortal creation Himself
Just to nitpick, it's not necessary for God to be mortal. As long as you consider God to be a form of "life", by whatever definition of that term you choose, then creationism is not a satisfactory explanation for the origin of life. If you stipulate that God is not a form of life but is eternal without beginning or end, then God is in so
Re: (Score:2)
Well, ok. Tell me ONE theory for the origin of life that does not either require a supernatural creator, or spontaneous generation from "primordial soup." I'm not aware of any, and intuitively cannot even conceive of another possible explanation. God and abiogenesis are, exhaustively, the two possible theories.
Also, if
Re: (Score:2)
Also, if you take a moment to consider the demonstrably infinitessimal probability of abiogenesis, I argue that is IS impossible. It is proven improbable, and has yet to even be proven possible. I submit that it is, in fact, impossible.
First off, until something is proven impossible, it is necessarily possible, just by what it means to be "possible". Secondly, it's quite likely that there is some piece to the puzzle still missing from our understanding of how life formed. The current theories may be wrong, but the logical argument for abiogenesis (that life had to come from somewh
Re: (Score:2)
I like the portknocking idea. But, you are wrong -- it is obscure. In this case, either exhaustive, manual search or a tool (in this case a port scanner) is required to find the port. By definition, because it is more difficult to find, it is obscure. And, my server logs reflect the effect.
I find it a much much smaller pr
Re: (Score:2)
I whole-heartedly agree that port-knocking would afford an even higher level of security than simply moving the port. In fact, both methods are security through obscurity -- port knocking is just even more so. My original point was that security through obscurity is effectual. It looks like we both agree on that.
The probabilities fo
Re: (Score:2)
But it was actually just "people who believe in proprietary security are like creationists... because everyone else says they're wrong."
Disclosure gets you better security (Score:2)
Android (Score:4, Insightful)
Re: (Score:2)
http://linux.slashdot.org/article.pl?sid=07/11/06/0223211 [slashdot.org]
Open is better (Score:3, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Re:Open is better (Score:4, Informative)
The debate about the relative security merits of open-source as opposed to proprietary software development has been a very long-running one
Indeed. The principle of open security was first proposed by Auguste Kerckhoffs in 1883.
Any time security depends on the secrecy of some mechanism, that security is pepetually at risk. All these millions of instances of the same vulnerable mechanism, no way to tell in general whether their security has been broken, and -- as you point out -- a certainty that the vulnerable secret cannot be contained.
In what way exactly does this remain a matter of debate?
Re: (Score:2)
Can you say DLL Hell? (Score:5, Interesting)
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)?
Re: (Score:2)
As quaint as it sounds, I'm a big fan of static linking when it comes to APIs that are not a part of the base operating system. This is probably because I expect the user to lose each and every related dependency, configuration file, and other random file that my app needs to run. You don't know how nice
Re: (Score:2)
From the wha...? (Score:3, Interesting)
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..
Re:From the wha...? (Score:4, Informative)
Re: (Score:2)
Wonders of open source (Score:2, Insightful)
Re: (Score:2, Insightful)
The beauty of open source is that it lets people like me contribute little dribbles here and there. I've probably touched a couple of dozen projects; typically only contributing a single fix or small feature, even something as small as the ability to daemonize hot-babe.
Now by itself that's not much, and in the context of progress it's miniscule, but it adds a tiny feature. Certainly I'm not a cathedral builder, I'm more of the guy who comes in and sweeps up the dust by one door.... But with enoug
Reverse engineering not required (Score:5, Informative)
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
A big 'duh!' from this end (Score:2)
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?
Embedded systems - feature vs. bug (Score:3, Insightful)
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.
What kind of phones do you use? (Score:2)
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.
Re: (Score:2)
I also suspect they did not lose many phones at all, though, or we would have heard about it in the earnings... in other words the returns/repairs would have hit them (much like the XBox 360 repair/returns hit Microsoft).
Re: (Score:2)
The ROM is broken down into parts. Even if you screw up everything in the very large portion you can mess with, there's still enough smarts to respond to USB/ActiveSync from Windows XP and put a new ROM in there. Trust me - I've bricked it! And was very pleased to see very unbrickable it was.
It's really a very simple thing to do.
very promising (Score:2)
The dumber android the better... (Score:2)
Cmdr. Data would would debate this point! (Score:3, Funny)
And Lars, well he would just do something diabolical and painful to you for suggesting this...just because he could.
Dumb and Dumber (Score:2, Offtopic)
That's why we all drive Model A Fords.
"found through reverse engineering" (Score:2)
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].
Re: (Score:2)
Re:Slasddot Grammary Advisory (Score:4, Funny)
Re:Slasddot Grammary Advisory (Score:4, Funny)
Re: (Score:2)
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why, that is UNpossible!