On Sep 16, 2013, at 9:57 PM, Jim Blandy wrote:
> On 09/15/2013 04:41 AM, Paul Theriault wrote:
>> That's certainly a consideration although sometimes the access granted by
>> the debugger is greater. Someone using your phone could read your emails,
>> where as someone with debug access can read your email password - which, if
>> its your gmail password for example, give access to other services. There
>> are only a few cases like this currently that I can think of - email , wifi,
>> passcode (set but not enabled) - and could be worse depending on who you use
>> for your email/wifi etc.
>>
>> Also consider the 'evil maid' attack (short-term unauthorized access). You
>> leave your device unattended for a short amount of time, someone plugs your
>> phone in to a laptop and uses debugger to dump all your emails and sms
>> messages to peruse later at their leisure. They steal your passwords and
>> social network cookies. This could be done in less that a few minutes and
>> since you didn't lose your device, you would be none-the-wiser.
>>
>
> 1) This is possible.
>
> 2) If I am being targeted by a person with such exploit software on their
> laptop, and I haven't set a security code on my phone, someone somewhere has
> paid too much.
>
> 3) If I ever have the good fortune to visit Sydney, my first priority will be
> stealing JT's phone. :)
>
> More seriously: if a user's phone is stolen, their concern will be for their
> messages, their mail, their photos, and so on, which the thief has access to,
> protocol or not. The thief has access to their email account, and thus can
> probably use password recovery to change the victim's passwords to whatever
> they like. These are what the user fears, not the additional exposure via
> mechanized access. The differential emotional salience (?!?) of the latter
> seems quite limited, to me.
>
> The benefit of exposing the protocol, with a light activation burden, for all
> our users, is major. It is directly in line with our goals: helping the web
> be a vibrant, creative medium; providing an on-ramp and lowering barriers to
> entry for new creators in new markets; and making a device that answers to
> the user first.
>
> The best way to help users with stolen phones would be to provide a remote
> kill facility, not to make the phone harder to hack on for all our technical
> users who have not had their phones stolen.
>
I would have thought it was much easier to implement a mechanism which
sanitizes sensitive user the first time that you enable system debugging (in a
manner which has a minimal impact to developer workflow), than to implement a
remote kill/wipe facility.
But let me try to rephrase the dilemma here. Currently for 1.2, we have a
preference ('devtools.debugger.forbid-certified-app') which prevents remote
debugging _only_ for certified apps. And I assume that so long as developers
had the ability to flip this preference, there this is no issue here. In 1.2,
you need root access to change this preference and debug certified apps - root
access is non-trivial for regular developers to obtain, so this isn't a great
situation. In 1.3 we plan to have UI and mechanism to toggle this preference
this securely (through wiping sensitive user data, or some other solution that
doesn't impact developer workflow).
So I think the question is really just what to do for the 3 months in between
the release of 1.2 and 1.3. The argument that I think I am hearing in this
thread, is that we should switch this preference earlier (i.e. 1.2) because the
benefit to the ecosystem in terms of ease of development, is greater than the
risk to our regular users by enabling debugging of certified apps. I don't
agree with this argument for all the reasons stated above - both from a
protection of users and potential impact to our reputation. But ultimately this
needs to be a decision for project leadership, and we need to be loud and clear
to users about the implications of the decision.
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
