Linked by David Adams on Thu 24th Jun 2010 16:22 UTC, submitted by Governa
Thread beginning with comment 431444
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
RE: Why the App Store is not a revolution
by nt_jerkface on Fri 25th Jun 2010 08:55
in reply to "Why the App Store is not a revolution"
Of course the Apple system is more secure. It's no contest.
Android apps can phone home and change themselves without user permission
http://blogs.forbes.com/firewall/2010/06/21/researcher-builds-mock-...
Thanks for posting your manuscript though.
RE[2]: Why the App Store is not a revolution
by Neolander on Fri 25th Jun 2010 09:03
in reply to "RE: Why the App Store is not a revolution"
Android apps can phone home and change themselves without user permission
http://blogs.forbes.com/firewall/2010/06/21/researcher-builds-mock-...
http://blogs.forbes.com/firewall/2010/06/21/researcher-builds-mock-...
Those are security defects, which indeed require patching, in the Android operating system, not in the market model. The previous posts were about the App Store model, not about iOS' specific implementation.
(I won't be advocating Android facing iOS, since in my opinion both operating systems are canned crap. In fact, I think that the whole touchscreen smartphone idea has only spawned canned crap in all of its current implementations, though Windows Phone 7 Series looks somewhat promising if they sell it on phones with a physical keyboard)
Thanks for posting your manuscript though.
You're welcome, sir =p
Edited 2010-06-25 09:07 UTC
RE: Why the App Store is not a revolution
by Stratoukos on Fri 25th Jun 2010 12:32
in reply to "Why the App Store is not a revolution"
1/Keeping user informed
One might argue that it requires the user to have some previous knowledge of malware. However, everybody has such knowledge, to some extent, in the form of common sense. If an unknown guy comes at home and ask if he can borrow your TV set, you'll probably say "no", because you're almost sure that he will never come back. What the system manufacturer has to do is to describe, in an understandable yet precise fashion, what the application wants to do. Precision is important : an application should not ask for "access to system files", but rather for "ability to change active wi-fi connection". This requires a fine-grained underlying security permission system.
A second thing the system manufacturer can do is to make the system analyze the permission being asked, and specifically warn the user about dangerous ones. As an example "Make a phone call with prior acknowledgement from the user" is relatively safe, while "Make a phone call without prior acknowledgement" or "Access all system files" are dangerous options, which the security system should warn the user about.
A security system built around those ideas can both help an expert who wants to know if the application is safe and a non-technical user who can check, at his knowledge level, if the software is asking for reasonable things.
One might argue that it requires the user to have some previous knowledge of malware. However, everybody has such knowledge, to some extent, in the form of common sense. If an unknown guy comes at home and ask if he can borrow your TV set, you'll probably say "no", because you're almost sure that he will never come back. What the system manufacturer has to do is to describe, in an understandable yet precise fashion, what the application wants to do. Precision is important : an application should not ask for "access to system files", but rather for "ability to change active wi-fi connection". This requires a fine-grained underlying security permission system.
A second thing the system manufacturer can do is to make the system analyze the permission being asked, and specifically warn the user about dangerous ones. As an example "Make a phone call with prior acknowledgement from the user" is relatively safe, while "Make a phone call without prior acknowledgement" or "Access all system files" are dangerous options, which the security system should warn the user about.
A security system built around those ideas can both help an expert who wants to know if the application is safe and a non-technical user who can check, at his knowledge level, if the software is asking for reasonable things.
I think this is a little more complex. A user with limited computer experience already places a lot of trust to his computer. If he can't understand what is going behind the scenes, and of course it's not reasonable to expect everyone to do so, he simply must trust his computer. This ranges from the simplest of things (the app will launch when I double click the icon) to the most complex (click here to restore the pc after it has broken). Since the user is trained to trust what the computer says, he will most likely do so when what the computer says is from an untrusted source. This is why the most successful attacks are the fake antiviruses.
When a legit alert from a user's antivirus pops up, he doesn't really understand what is happening behind the scenes, so he just clicks the "Keep me safe" button. When a malicious pop up says the exact same thing he will do the exact same thing.
In your analogy, the user would most likely lend his TV set if the person that asked was his brother. If the user doesn't have at least some rudimentary training about computer security, there is no difference between the OS and an untrusted third party. It's the same entity, "the computer".
RE[2]: Why the App Store is not a revolution
by Neolander on Fri 25th Jun 2010 14:04
in reply to "RE: Why the App Store is not a revolution"
I think this is a little more complex. A user with limited computer experience already places a lot of trust to his computer. If he can't understand what is going behind the scenes, and of course it's not reasonable to expect everyone to do so, he simply must trust his computer. This ranges from the simplest of things (the app will launch when I double click the icon) to the most complex (click here to restore the pc after it has broken). Since the user is trained to trust what the computer says, he will most likely do so when what the computer says is from an untrusted source. This is why the most successful attacks are the fake antiviruses.
When a legit alert from a user's antivirus pops up, he doesn't really understand what is happening behind the scenes, so he just clicks the "Keep me safe" button. When a malicious pop up says the exact same thing he will do the exact same thing.
In your analogy, the user would most likely lend his TV set if the person that asked was his brother. If the user doesn't have at least some rudimentary training about computer security, there is no difference between the OS and an untrusted third party. It's the same entity, "the computer".
When a legit alert from a user's antivirus pops up, he doesn't really understand what is happening behind the scenes, so he just clicks the "Keep me safe" button. When a malicious pop up says the exact same thing he will do the exact same thing.
In your analogy, the user would most likely lend his TV set if the person that asked was his brother. If the user doesn't have at least some rudimentary training about computer security, there is no difference between the OS and an untrusted third party. It's the same entity, "the computer".
That's something I've been thinking about for some times. My answer is that system warnings have to look and behave in a way that no other app looks like, with imitation being forbidden in some way (or privileged in a way that the OS issues a "only install if you know what you're doing" window during installation).
As an example, let's suppose applications can't draw borderless windows and arbitrary-sized UI widgets, nor register double right clicks from the mouse. If the system uses some, this result can be achieved. This is akin to Windows 2000's use of Ctl+Alt+Del to prevent login window spoofing.
The user then only have to know that he can trust borderless windows, but must be careful about strange behaviors from the rest of the applications. That doesn't sound very complicated.
Edited 2010-06-25 14:13 UTC





Member since:
2010-03-08
Here, I'll explain in details why I think that the App store is not a revolution in security, and how things can really be improved, based on simple computer security notions.
Let's take as a basic assumption that absolute security does not exist. It's effectively true, because it would require the user to make any kind of hardware and software he uses all by itself. The best we can do is to reduce the amount of trust that the user has to put in third parties. As far as I know, these are the strategies which exist as of today :
1-Keeping the user well-informed and in control.
2-Make knowingly malicious software disappear.
3-Have experts analyzing the software and say if it can be relied upon.
4-Be cautious about what kind of software is installed, do not let anything make its way.
5-Put limitations on what software is able to do.
Now let's analyze those strategies. First from a philosophical point of view.
1, 4, and 5 are at the same time the most safe and liberal (as opposed to authoritarian) solutions. They don't require to trust an additional third-party about what is safe, the user is independent instead of being treated like a child.
2 and 3, on the other hand, are more dangerous, because you have to rely about an unknown bunch of people who pretend to know what is safe (and can be themselves authors of malicious software). For that reason, those options should not be used independently, but rather as a complement of other options that one can bypass.
Now, let's get more technical.
1/Keeping user informed
One might argue that it requires the user to have some previous knowledge of malware. However, everybody has such knowledge, to some extent, in the form of common sense. If an unknown guy comes at home and ask if he can borrow your TV set, you'll probably say "no", because you're almost sure that he will never come back. What the system manufacturer has to do is to describe, in an understandable yet precise fashion, what the application wants to do. Precision is important : an application should not ask for "access to system files", but rather for "ability to change active wi-fi connection". This requires a fine-grained underlying security permission system.
A second thing the system manufacturer can do is to make the system analyze the permission being asked, and specifically warn the user about dangerous ones. As an example "Make a phone call with prior acknowledgement from the user" is relatively safe, while "Make a phone call without prior acknowledgement" or "Access all system files" are dangerous options, which the security system should warn the user about.
A security system built around those ideas can both help an expert who wants to know if the application is safe and a non-technical user who can check, at his knowledge level, if the software is asking for reasonable things.
2/Remove known malware from user sight
This is the most obvious benefit of a central repository system. All properly maintained central repositories (from Debian's APT repos to the Android market) provide this kind of security, and it cannot work properly outside of such a system, as anyone who experienced antivirus software on Windows can acknowledge. This system has, however, a major flaw that make it insufficient alone except in technical environments : in order to work, it requires a large and representative part of the user base to keep the repository maintainers informed about what malware they have found.
3/Expert check
This one is quite interesting, because it is were being open-source can actually result in increased software security. That's because a source code can generally be fully checked for malicious behaviors in a reasonable amount of time. In a binary-based system, however, such a full check cannot be performed, and the sole advantage that an expert has over an average user is his experience (which is not necessarily worth much in a rapidly-evolving and polymorphic area like malware).
All the expert can do, when being given a binary file, is to try to run it in every single possible way and check for unwanted behaviors. However, this is insufficient. Suppose that an attacker makes malware which looks like a plane reservation application. The application checks plane availability from a distant server (which is controlled by the attacker), and allows the user to book a seat. However, if a specific available plane is registered on the server, the application suddenly goes evil. This is commonly called a backdoor.
The attacker first submits his application to the expert, with usual content on the server. The expert stress-tests the app, and notices no strange behavior, so he approves it, and people start to download and use the app. Once the app is widespread, all the attacker has to do is to put the fatal entry on the server, and BOOOM ! Millions of phones are suddenly tainted by malware.
4/Thinking before installing
This one can be very effective again phishing-like attacks ("Your phone is slow because it is tainted with malware ! Download this absolutely free software to remove it !"), but it requires prior education of the user.
Does one really require to replace a phone book ? A core component of the system like the control panel or the filesystem manager ? One shouldn't give very high permissions to an application without thinking not twice, but rather three times. If a core component of the system doesn't work, you should consider moving to another system, warning the manufacturer about its defects, or patching it yourself if you're a technical user and it's free software. Relying on several third-parties for core components of an OS is generally a bad thing, as some Linux user may acknowledge.
5/Limiting apps capabilities
This one is *extremely dangerous*. People who wrote the security system just don't know what the users will do with their computer. Moreover, computer usage varies wildly as time passes. Who are we to decide what is good for the user ?
However, this idea can find its place in a less extreme form, that is carefully choosing what an application can do without a security permission being given. As an example, consider a situation where applications have a private folder, sort of like in OSX. They can do whatever they want in said folder, but they can't do anything outside of that folder without prior acknowledgement (as an example through use of an "open file" dialog, or by getting the appropriate security permission). This way, the amount of warnings about security permissions can be reduced, and hence once one does appear, there are higher chances that the user will read it instead of just clicking "next"/"ok"/"ack"/whatever right away.
Now where does the App store fits in this model ? Most smartphone OSs use a combination of repositories and limited abilities. Android adds up an informed user. The App store chooses to add up an expert check, which, as we've seen before, certainly isn't the most effective way of managing security, except if the users are dumb or uninformed (I prefer to think that the latter option is the good one). It's not intrinsically superior, given that the security systems are properly designed and patched, it's still three security principles out of five available.
One must them ask himself if relying on experts who can do little because they have to check binary apps is worth being forced to download from this repository, which has no security benefit and is a purely jerkish move from Apple aiming at maximum incomes...
Edited 2010-06-25 08:31 UTC