I was shocked to see that RWindowGroup::CaptureKey is bound to the SwEvent
capability. Why is it dangerous if a program gives the opportunity to the
user to activate it by a keypress? Why restrict such basic and useful and
completely user-conscious functionality?
hotkey protection??
Kitty wrote:
> I was shocked to see that RWindowGroup::CaptureKey is bound to the SwEvent
> capability. Why is it dangerous if a program gives the opportunity to the
> user to activate it by a keypress? Why restrict such basic and useful and
> completely user-conscious functionality?
Most likely preventing constuction of a key-logger without
certification.. 😊
:: Heikki Pora
> Most likely preventing constuction of a key-logger without
> certification.. 😊
Well... I guess one can always work out a worst-case scenario to justify
authoritarian restrictions. And where does this end? Newborn childs could
certainly be killed to prevent their unlawful actions later...
Okay, now you say I'm pathetic. No, I just want to make you think. I got the
impression the Symbian Signed decisionmakers are rather uncontrolled by the
developer community and quite unaware of practical considerations.
If the bad-bad wolf makes a key-logger out of CaptureKey, what can he do
with it without having OTHER harmful and surely capability-bound functions?
I think he can do nothing, but tell me if I'm wrong.
Don't you think this is pure paranoia that does nothing but makes developers
and end-users suffer? I really wonder about opinions, including non-biased
ones!
Cheers all, Kitty
On Wed, 18 Jan 2006 11:46:03 -0000, Kitty <[email protected]> wrote:
[color=green]
>> Most likely preventing constuction of a key-logger without
>> certification.. 😊
>
> Well... I guess one can always work out a worst-case scenario to justify
> authoritarian restrictions. And where does this end? Newborn childs could
> certainly be killed to prevent their unlawful actions later...
>[/color]
Security is only usefull when the benefits outweigh the costs.
Most apps don't need to access keys in this way so the cost is small, but
the benefit is significant.
> Okay, now you say I'm pathetic. No, I just want to make you think. I got
> the
> impression the Symbian Signed decisionmakers are rather uncontrolled by
> the
> developer community and quite unaware of practical considerations.
>
> If the bad-bad wolf makes a key-logger out of CaptureKey, what can he do
> with it without having OTHER harmful and surely capability-bound
> functions?
> I think he can do nothing, but tell me if I'm wrong.
>
How about hiding it in data, such as a jpeg, that is likely to be passed
on to where bad-bad wolf can get hold of it.
So you think it is acceptable that any application that can send data via
GPRS can send all the user's keystrokes - including say the password they
used to access their bank account.
The problem with doing it your way is that all security control ends up
being control of being able to communicate, with the end result that any
app that uses communication needs to be extensivly audited to be "safe".
> Don't you think this is pure paranoia that does nothing but makes
> developers
> and end-users suffer? I really wonder about opinions, including
> non-biased
> ones!
>
> Cheers all, Kitty
>
>
--
Alan Montgomery
/"\
\ / ASCII ribbon campaign
X against HTML mail
/ \ and postings - est. June 1998
"Alan Montgomery" <[email protected]> wrote
> Security is only usefull when the benefits outweigh the costs.
That's what I'm talking about: keyword is ONLY...
> Most apps don't need to access keys in this way so the cost is small, but
> the benefit is significant.
At this point our opinions differ a lot. IMHO any harmless app may need a
hotkey to let the user invoke it from background (let's say a screen capture
utility, and also any other). The benefit of preventing this is zero (I will
try to explain why below).
> So you think it is acceptable that any application that can send data via
> GPRS can send all the user's keystrokes - including say the password they
> used to access their bank account.
On one hand, this is what I call paranoia. On the other (more important)
hand, as far as I know an application can not send out anything via GPRS
without getting signed. If bad wolf decides to sign his program for having a
chance to send data by GPRS, then he can include the SwEvent capability
without extra cost, so he can capture the keys and log and send the
password. If his app is accepted then he is the winner and this dis not
depend on CaptureKey, but on the GPRS access.
So, why restrict CaptureKey in itself when all harmful use of it is already
forbidden? Why disable innocent use cases?
> Security is only usefull when the benefits outweigh the costs.
I wonder if the above sentence could be better adapted for the case of
CaptureKey.
On Wed, 18 Jan 2006 12:39:41 -0000, Kitty <[email protected]> wrote:
> "Alan Montgomery" <[email protected]> wrote
>[color=green]
>> Security is only usefull when the benefits outweigh the costs.
>
> That's what I'm talking about: keyword is ONLY...
>
>> Most apps don't need to access keys in this way so the cost is small,
>> but
>> the benefit is significant.
>
> At this point our opinions differ a lot. IMHO any harmless app may need a
> hotkey to let the user invoke it from background (let's say a screen
> capture
> utility, and also any other). The benefit of preventing this is zero (I
> will
> try to explain why below).
>[/color]
Only a very small number of apps actually NEED this facility, it is only
required when the application MUST respond to the user when not in the
foreground - many apps as a convenience have quick asccess keys.
[color=green]
>> So you think it is acceptable that any application that can send data
>> via
>> GPRS can send all the user's keystrokes - including say the password
>> they
>> used to access their bank account.
>
> On one hand, this is what I call paranoia. On the other (more important)
> hand, as far as I know an application can not send out anything via GPRS
> without getting signed. If bad wolf decides to sign his program for
> having a
> chance to send data by GPRS, then he can include the SwEvent capability
> without extra cost, so he can capture the keys and log and send the
> password. If his app is accepted then he is the winner and this dis not
> depend on CaptureKey, but on the GPRS access.
>
> So, why restrict CaptureKey in itself when all harmful use of it is
> already
> forbidden? Why disable innocent use cases?
>[/color]
What about a app that captures all key events and thus prevents any other
app getting them - making the phone unusable, and requiring a factory
reset?
Many apps NEED the ability to communicate. If you make this the sole point
of security control for information it becomes hard to check which apps
are "safe"
The risk from keylogging isn't dependant only on communication, it also
requires key access.
Furthermore it may be possible to find a way around the communication
restriction, so that then all security would be negated.
There is also the issue of information - if you know an app doesn't have
key access but does have communication, then you know it can't pass on
your key information.
[color=green]
>> Security is only usefull when the benefits outweigh the costs.
>
> I wonder if the above sentence could be better adapted for the case of
> CaptureKey.
>
>[/color]
--
Alan Montgomery
/"\
\ / ASCII ribbon campaign
X against HTML mail
/ \ and postings - est. June 1998
The two obvious threats are PIN or other user data capture and someone who
simply wants to make the UI un-useable - e.g. by simply capturing and
discarding all events to the "1" key.
I'd say rendering the phone un-useable is a fairly serious attack.
Getting access to the capability via symbian signed is easy if you have a
legitimate reason - through declarative statement.
"Alan Montgomery" <[email protected]> wrote in message
news😮[email protected]...
> On Wed, 18 Jan 2006 12:39:41 -0000, Kitty <[email protected]> wrote:
>[color=green]
>> "Alan Montgomery" <[email protected]> wrote
>>[color=darkred]
>>> Security is only usefull when the benefits outweigh the costs.
>>
>> That's what I'm talking about: keyword is ONLY...
>>
>>> Most apps don't need to access keys in this way so the cost is small,
>>> but
>>> the benefit is significant.
>>
>> At this point our opinions differ a lot. IMHO any harmless app may need a
>> hotkey to let the user invoke it from background (let's say a screen
>> capture
>> utility, and also any other). The benefit of preventing this is zero (I
>> will
>> try to explain why below).
>>[/color]
>
> Only a very small number of apps actually NEED this facility, it is only
> required when the application MUST respond to the user when not in the
> foreground - many apps as a convenience have quick asccess keys.
>[color=darkred]
>>> So you think it is acceptable that any application that can send data
>>> via
>>> GPRS can send all the user's keystrokes - including say the password
>>> they
>>> used to access their bank account.
>>
>> On one hand, this is what I call paranoia. On the other (more important)
>> hand, as far as I know an application can not send out anything via GPRS
>> without getting signed. If bad wolf decides to sign his program for
>> having a
>> chance to send data by GPRS, then he can include the SwEvent capability
>> without extra cost, so he can capture the keys and log and send the
>> password. If his app is accepted then he is the winner and this dis not
>> depend on CaptureKey, but on the GPRS access.
>>
>> So, why restrict CaptureKey in itself when all harmful use of it is
>> already
>> forbidden? Why disable innocent use cases?
>>[/color]
>
> What about a app that captures all key events and thus prevents any other
> app getting them - making the phone unusable, and requiring a factory
> reset?
>
> Many apps NEED the ability to communicate. If you make this the sole point
> of security control for information it becomes hard to check which apps
> are "safe"
>
>
> The risk from keylogging isn't dependant only on communication, it also
> requires key access.
> Furthermore it may be possible to find a way around the communication
> restriction, so that then all security would be negated.
>
> There is also the issue of information - if you know an app doesn't have
> key access but does have communication, then you know it can't pass on
> your key information.
>[color=darkred]
>>> Security is only usefull when the benefits outweigh the costs.
>>
>> I wonder if the above sentence could be better adapted for the case of
>> CaptureKey.
>>
>>[/color]
>
>
>
> --
> Alan Montgomery
>
> /"\
> \ / ASCII ribbon campaign
> X against HTML mail
> / \ and postings - est. June 1998[/color]
"Alan Montgomery" <[email protected]> wrote
> many apps as a convenience have quick asccess keys.
You mean some other way than using CaptureKey? If yes then what is it? That
could solve my problem.
> What about a app that captures all key events and thus prevents any other
> app getting them - making the phone unusable, and requiring a factory
> reset?
Why would it require a factory reset? I think in the worst case it just
requires a reboot, after which the app does not run anymore and can be
uninstalled. Autostart requires another capability!
"Hamish Willee" <[email protected]> wrote
> I'd say rendering the phone un-useable is a fairly serious attack.
Certainly. However, as pointed out above, solely by capturing keys and
without having other capabilities an application can bring the system down
only temporarily, until the next reboot. Furthermore, if a "hacker" is that
eager to kill the phone, he can have a similar effect using code like
this...
TInt * pCrash = NULL;
*pCrash = 0;
Using TInt pointers is not (yet) bound to capabilites, so the bad guy's
unsigned app can still crash the phone of the "average" user who installs
just about anything found on the net. But do you guys think the hackers out
there are really spending their time working in such directions? I don't
think so. I rather still think CaptureKey is the victim of a thoughtless
paranoia.
A more generic question: if the miracle happened and everybody would
suddenly become convinced that CaptureKey is indeed not that dangerous (in
itself!!), then would there be a chance to change its capability requirement
status to none, before the release of Symbian 10.0? Or the system is not
that flexible?
"Kitty" <[email protected]> wrote in message
news:cBmsgJNHGHA.372@extapps30...
> "Alan Montgomery" <[email protected]> wrote
>[color=green]
>> many apps as a convenience have quick asccess keys.
>
> You mean some other way than using CaptureKey? If yes then what is it?
> That
> could solve my problem.
>
>> What about a app that captures all key events and thus prevents any other
>> app getting them - making the phone unusable, and requiring a factory
>> reset?
>
> Why would it require a factory reset? I think in the worst case it just
> requires a reboot, after which the app does not run anymore and can be
> uninstalled. Autostart requires another capability!
>
> "Hamish Willee" <[email protected]> wrote
>
>> I'd say rendering the phone un-useable is a fairly serious attack.
>
> Certainly. However, as pointed out above, solely by capturing keys and
> without having other capabilities an application can bring the system down
> only temporarily, until the next reboot. Furthermore, if a "hacker" is
> that
> eager to kill the phone, he can have a similar effect using code like
> this...
>
> TInt * pCrash = NULL;
> *pCrash = 0;[/color]
This will crash the app but not the phone.
> Using TInt pointers is not (yet) bound to capabilites, so the bad guy's
> unsigned app can still crash the phone of the "average" user who installs
> just about anything found on the net. But do you guys think the hackers
> out
> there are really spending their time working in such directions? I don't
> think so. I rather still think CaptureKey is the victim of a thoughtless
> paranoia.
I would expect that these hackers will do similar stuff as hackers on PC's
nowadays, which is trying to obtain as much mony as possible using as
lilltle effort as possible. Just like any other business, but by using
criminal activities. Making the hacking process harder will result in less
people trying because it isn't ecomical for them.
A reason for having as much capabilites as possible.
Also, there are all this supposed uses for mobile phones: it will replace
your wallet, your keys and whatnot. Nobody in his right mind will do
something like that at the remotest change of having his phone hacked. And
such a device will be the prime target for criminals.
--
Sander van der Wal
www.mBrainSoftware.com
> A more generic question: if the miracle happened and everybody would
> suddenly become convinced that CaptureKey is indeed not that dangerous (in
> itself!!), then would there be a chance to change its capability
> requirement
> status to none, before the release of Symbian 10.0? Or the system is not
> that flexible?
>> A more generic question: if the miracle happened and everybody would[color=green]
>> suddenly become convinced that
>> CaptureKey is indeed not that dangerous (in itself!!),
>> then would there be a chance to change its capability requirement status
>> to none, before the release of Symbian 10.0? Or the system is not that
>> flexible?[/color]
This is software - anything can be changed. Its not going to happen though
because clearly this API is a legitimate security threat.
"Kitty" <[email protected]> wrote in message
news:cBmsgJNHGHA.372@extapps30...
> "Alan Montgomery" <[email protected]> wrote
>[color=green]
>> many apps as a convenience have quick asccess keys.
>
> You mean some other way than using CaptureKey? If yes then what is it?
> That
> could solve my problem.
>
>> What about a app that captures all key events and thus prevents any other
>> app getting them - making the phone unusable, and requiring a factory
>> reset?
>
> Why would it require a factory reset? I think in the worst case it just
> requires a reboot, after which the app does not run anymore and can be
> uninstalled. Autostart requires another capability!
>
> "Hamish Willee" <[email protected]> wrote
>
>> I'd say rendering the phone un-useable is a fairly serious attack.
>
> Certainly. However, as pointed out above, solely by capturing keys and
> without having other capabilities an application can bring the system down
> only temporarily, until the next reboot. Furthermore, if a "hacker" is
> that
> eager to kill the phone, he can have a similar effect using code like
> this...
>
> TInt * pCrash = NULL;
> *pCrash = 0;
>
> Using TInt pointers is not (yet) bound to capabilites, so the bad guy's
> unsigned app can still crash the phone of the "average" user who installs
> just about anything found on the net. But do you guys think the hackers
> out
> there are really spending their time working in such directions? I don't
> think so. I rather still think CaptureKey is the victim of a thoughtless
> paranoia.
>
> A more generic question: if the miracle happened and everybody would
> suddenly become convinced that CaptureKey is indeed not that dangerous (in
> itself!!), then would there be a chance to change its capability
> requirement
> status to none, before the release of Symbian 10.0? Or the system is not
> that flexible?
>
>[/color]
> clearly this API is a legitimate security threat.
Well, okay, let's say I'm convinced. Key capture is possible to be used for
harming the end-user. By chance a hacker in the future would have used it -
but with the SS security he can't.
The end-users are defended well in advance, before they could realize any
threat. I wonder if they will be happy about it, for the price of having a
lot less applications.
"Kitty" <[email protected]> wrote in message
news:xcePAoaHGHA.2156@extapps30...[color=green]
>> clearly this API is a legitimate security threat.
>
> Well, okay, let's say I'm convinced. Key capture is possible to be used
> for
> harming the end-user. By chance a hacker in the future would have used
> it -
> but with the SS security he can't.[/color]
Rest assured this would be by design, not by change.
> The end-users are defended well in advance, before they could realize any
> threat. I wonder if they will be happy about it, for the price of having a
> lot less applications.
Get your app signed with the right capability and see your sales soar 😉
--
Sander van der Wal
www.mBrainSoftware.com
Prior to Symbian signed the quality of many "commercial" programs was poor.
Symbian Signed gives a limited guarantee of some level of "good phone
citizenship".
So I take your point, but I think most users will be happier with a smaller
number of robust and "safe" applications than a large number of arbitary
applications.
"Kitty" <[email protected]> wrote in message
news:xcePAoaHGHA.2156@extapps30...[color=green]
>> clearly this API is a legitimate security threat.
>
> Well, okay, let's say I'm convinced. Key capture is possible to be used
> for
> harming the end-user. By chance a hacker in the future would have used
> it -
> but with the SS security he can't.
>
> The end-users are defended well in advance, before they could realize any
> threat. I wonder if they will be happy about it, for the price of having a
> lot less applications.
>
>[/color]
"Hamish Willee" <[email protected]> wrote...
> So I take your point, but I think most users will be happier with a
smaller
> number of robust and "safe" applications than a large number of arbitary
> applications.
I rather predict that (at least the better educated) phone users will not be
so happy by not being able to decide what they install on their phone - but
we will see from their reactions once the first Symbian 9 phones are
released.
Furthermore, your views above seem to imply that small-scale (shareware)
developers (those who are likely to be killed by the costs and hassles of
signing) are by definition unable to write proper applications, so they are
better eliminated. I'm not sure if you are right in this. Again, end-users
will presumably give feedback if they miss something from the pre-Symbian 9
era.
Interesting logical jump from "users want safe applications" to "shareware
developers can't write good applications".
Symbian wants to support an open environment, promote development (of all
kinds) and at the same time protect users. So far industry feedback is fully
behind this approach. Costs of signing are decreasing, and we're also
working on mechanisms to get freeware signed.
If you have a suggestion of how these goals can be better met or balanced
then this is a good forum to raise them.
"Kitty" <[email protected]> wrote in message
news:Zwr%23HCNIGHA.2776@extapps30...
> "Hamish Willee" <[email protected]> wrote...[color=green]
>> So I take your point, but I think most users will be happier with a
> smaller
>> number of robust and "safe" applications than a large number of arbitary
>> applications.
>
> I rather predict that (at least the better educated) phone users will not
> be
> so happy by not being able to decide what they install on their phone -
> but
> we will see from their reactions once the first Symbian 9 phones are
> released.
>
> Furthermore, your views above seem to imply that small-scale (shareware)
> developers (those who are likely to be killed by the costs and hassles of
> signing) are by definition unable to write proper applications, so they
> are
> better eliminated. I'm not sure if you are right in this. Again, end-users
> will presumably give feedback if they miss something from the pre-Symbian
> 9
> era.
>
>[/color]