Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Security implications of remote debugging on devices
137 views
Skip to first unread message
Paul Theriault
Sep 10, 2013, 11:29:59 AM9/10/13
to dev-b2g list, apo...@mozilla.com, pa...@mozilla.com
(bcc dev-gaia)
I have been discussing the security implications of remote debugging with a number of people and I wanted to through the question out to a wider audience. Remote debugging allows access to read any data in app and as such has implications for the scenario of when a user loses their phone.
Do we want to allow the remote debugger to connect to any app?
My proposal is that, for production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).
For developer builds, the remote debugger would connect to any app.
Thoughts on this proposal?
- Paul
I have been discussing the security implications of remote debugging with a number of people and I wanted to through the question out to a wider audience. Remote debugging allows access to read any data in app and as such has implications for the scenario of when a user loses their phone.
Do we want to allow the remote debugger to connect to any app?
My proposal is that, for production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).
For developer builds, the remote debugger would connect to any app.
Thoughts on this proposal?
- Paul
Jim Blandy
Sep 10, 2013, 12:17:25 PM9/10/13
to Paul Theriault, dev...@lists.mozilla.org
Debugging is how many people are going to learn how to write apps; think
about the role of "view source" in introducing people to web technology.
And it's consistent with our goal of putting the user in charge of their
own device. I think we should treat all apps as debuggable, on any device.
As far as non-developer users are concerned: debugging is turned off by
default. You need to go (rather deep) into the settings and explicitly
turn debugging on, before the server begins listening. There is no
reason a non-developer would ever need to enable debugging (and we
should ensure this remains true). So I don't see the risk to
non-developer users.
We should protect developers, too. If we require users to set a passcode
on their phone in order to enable debugging, and turn off the debugging
server automatically after (say) two hours of inactivity, then it seems
to me the risk to developers is rather small.
I also don't think creating restrictions as to which apps the user can
debug is very meaningful, at a technical level.
The debug server now listens on a Unix domain socket, which means its
name is in the filesystem. The kernel enforces the usual filesystem
permissions when something tries to connect to it. If we make the socket
readable and writable only to the main B2G process's user, then any
process capable of connecting to the debug server is equally capable of
using the 'ptrace' system call (or others) to directly read and write
the main B2G process's memory and registers.
So while it makes sense to pay close attention to which code runs as
that user, we should remember that any code that *does* run as that user
has full control over the phone. Trying to enforce finer-grained
distinctions will not keep attackers out, but will make the phone more
cumbersome to hack on. That seems like an "own goal".
about the role of "view source" in introducing people to web technology.
And it's consistent with our goal of putting the user in charge of their
own device. I think we should treat all apps as debuggable, on any device.
As far as non-developer users are concerned: debugging is turned off by
default. You need to go (rather deep) into the settings and explicitly
turn debugging on, before the server begins listening. There is no
reason a non-developer would ever need to enable debugging (and we
should ensure this remains true). So I don't see the risk to
non-developer users.
We should protect developers, too. If we require users to set a passcode
on their phone in order to enable debugging, and turn off the debugging
server automatically after (say) two hours of inactivity, then it seems
to me the risk to developers is rather small.
I also don't think creating restrictions as to which apps the user can
debug is very meaningful, at a technical level.
The debug server now listens on a Unix domain socket, which means its
name is in the filesystem. The kernel enforces the usual filesystem
permissions when something tries to connect to it. If we make the socket
readable and writable only to the main B2G process's user, then any
process capable of connecting to the debug server is equally capable of
using the 'ptrace' system call (or others) to directly read and write
the main B2G process's memory and registers.
So while it makes sense to pay close attention to which code runs as
that user, we should remember that any code that *does* run as that user
has full control over the phone. Trying to enforce finer-grained
distinctions will not keep attackers out, but will make the phone more
cumbersome to hack on. That seems like an "own goal".
Paul Rouget
Sep 10, 2013, 12:39:15 PM9/10/13
to Paul Theriault, apo...@mozilla.com, dev-b2g list, dev-...@mozilla.com
Paul Theriault wrote:
> (bcc dev-gaia)
>
> I have been discussing the security implications of remote debugging with a number of people and I wanted to through the question out to a wider audience. Remote debugging allows access to read any data in app and as such has implications for the scenario of when a user loses their phone.
>
> Do we want to allow the remote debugger to connect to any app?
>
> My proposal is that, for production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).
That would make me sad. We want to make the phone as hackable as possible, and
> (bcc dev-gaia)
>
> I have been discussing the security implications of remote debugging with a number of people and I wanted to through the question out to a wider audience. Remote debugging allows access to read any data in app and as such has implications for the scenario of when a user loses their phone.
>
> Do we want to allow the remote debugger to connect to any app?
>
> My proposal is that, for production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).
that would make the life of the certified and signed privileged apps developers
harder (they might not have a developer phone, just a regular phone), and
regular developer won't have access to the code of other apps (to learn).
Is the following the scenario you're trying to address here?
Phone get stollen. The user didn't set a password. The thief can turn on remote
debugging and then have access to the data of the user.
But:
1) the user didn't protect his phone
2) he already has access to many things (emails, contacts, etc).
3) he has access to the physical device, so to the sdcard (if any)
4) because the user has access to the email, he can already do many things (password recovery for example)
So your proposal would prevent people to steal password only if:
the phone doesn't have a code, the phone is not rooted, the
phone doesn't have an accessible sdcard, passwords are not recoverable
via email.
Is that right?
-- Paul
Dave Camp
Sep 10, 2013, 12:43:05 PM9/10/13
to Paul Theriault, dev-b2g list, Alexandre Poirot, dev-...@mozilla.com
On Tue, Sep 10, 2013 at 9:39 AM, Paul Rouget <pa...@mozilla.com> wrote:
>
> So your proposal would prevent people to steal password only if:
> the phone doesn't have a code, the phone is not rooted, the
> phone doesn't have an accessible sdcard, passwords are not recoverable
> via email.
And in that case they could just grab the data with adb, right?
>
> So your proposal would prevent people to steal password only if:
> the phone doesn't have a code, the phone is not rooted, the
> phone doesn't have an accessible sdcard, passwords are not recoverable
> via email.
-dave
Dave Hylands
Sep 10, 2013, 1:35:28 PM9/10/13
to Dave Camp, Paul Theriault, Alexandre Poirot, dev-b2g list, dev-...@mozilla.com
So on a production phone, the adb shell gives you a "shell" user shell. And the shell user has no permissions to read anything under /data (except for /data/local/tmp)
You can use 'adb shell id' to determine which user your adb shell runs under.
If you ave a root shell, then you can access anything under /data.
Dave Hylands
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>
You can use 'adb shell id' to determine which user your adb shell runs under.
If you ave a root shell, then you can access anything under /data.
Dave Hylands
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>
Paul Theriault
Sep 10, 2013, 1:58:31 PM9/10/13
to Paul Rouget, apo...@mozilla.com, dev-b2g list
(removing gaia to avoid cross-posting)
On Sep 10, 2013, at 6:39 PM, Paul Rouget wrote:
> Paul Theriault wrote:
>> (bcc dev-gaia)
>>
>> I have been discussing the security implications of remote debugging with a number of people and I wanted to through the question out to a wider audience. Remote debugging allows access to read any data in app and as such has implications for the scenario of when a user loses their phone.
>>
>> Do we want to allow the remote debugger to connect to any app?
>>
>> My proposal is that, for production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).
>
> That would make me sad. We want to make the phone as hackable as possible, and
> that would make the life of the certified and signed privileged apps developers
> harder (they might not have a developer phone, just a regular phone), and
> regular developer won't have access to the code of other apps (to learn).
I would like to see us at least implement this feature as a preference, so we (mozilla/partners) can make a call on a device by device basis, depending on whether or not the device is targeted at developers or end-users.
>
> Is the following the scenario you're trying to address here?
>
> Phone get stollen. The user didn't set a password. The thief can turn on remote
> debugging and then have access to the data of the user.
Yes - from a data security perspective, being able to debug all apps, is equivalent to having root access on the phone.
> But:
> 1) the user didn't protect his phone
> 2) he already has access to many things (emails, contacts, etc).
> 3) he has access to the physical device, so to the sdcard (if any)
> 4) because the user has access to the email, he can already do many things (password recovery for example)
>
This weakening of security controls would apply to all users who do not set a passcode (most?), on devices which are not rooted (all except developer phones).
The sdcard isn't protected regardless of this issue - the only way to protect the sdcard is to encrypt it.
Email passwords not being recoverable by email (?) is missing the point that it is ALL data (cookies, indexeddb etc)
On Sep 10, 2013, at 6:39 PM, Paul Rouget wrote:
> Paul Theriault wrote:
>> (bcc dev-gaia)
>>
>> I have been discussing the security implications of remote debugging with a number of people and I wanted to through the question out to a wider audience. Remote debugging allows access to read any data in app and as such has implications for the scenario of when a user loses their phone.
>>
>> Do we want to allow the remote debugger to connect to any app?
>>
>> My proposal is that, for production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).
>
> That would make me sad. We want to make the phone as hackable as possible, and
> that would make the life of the certified and signed privileged apps developers
> harder (they might not have a developer phone, just a regular phone), and
> regular developer won't have access to the code of other apps (to learn).
>
> Is the following the scenario you're trying to address here?
>
> Phone get stollen. The user didn't set a password. The thief can turn on remote
> debugging and then have access to the data of the user.
> But:
> 1) the user didn't protect his phone
> 2) he already has access to many things (emails, contacts, etc).
> 3) he has access to the physical device, so to the sdcard (if any)
> 4) because the user has access to the email, he can already do many things (password recovery for example)
>
> So your proposal would prevent people to steal password only if:
> the phone doesn't have a code, the phone is not rooted, the
> phone doesn't have an accessible sdcard, passwords are not recoverable
> via email.
My proposal makes its more difficult for someone with physical access to a phone without a passcode to steal sensitive app data. If we limit which apps you can debug as I described above, in order to get access to app data, you still need root access to the phone. If we allow access to debug all apps, this bar is lowered, so that you can access the app data by enabling debugging.
> the phone doesn't have a code, the phone is not rooted, the
> phone doesn't have an accessible sdcard, passwords are not recoverable
> via email.
This weakening of security controls would apply to all users who do not set a passcode (most?), on devices which are not rooted (all except developer phones).
The sdcard isn't protected regardless of this issue - the only way to protect the sdcard is to encrypt it.
Email passwords not being recoverable by email (?) is missing the point that it is ALL data (cookies, indexeddb etc)
Paul Theriault
Sep 10, 2013, 1:59:09 PM9/10/13
to Dave Camp, Alexandre Poirot, dev-b2g list, dev-...@mozilla.com
On Sep 10, 2013, at 6:43 PM, Dave Camp wrote:
> On Tue, Sep 10, 2013 at 9:39 AM, Paul Rouget <pa...@mozilla.com> wrote:
>
> So your proposal would prevent people to steal password only if:
> the phone doesn't have a code, the phone is not rooted, the
> phone doesn't have an accessible sdcard, passwords are not recoverable
> via email.
>
>
> the phone doesn't have a code, the phone is not rooted, the
> phone doesn't have an accessible sdcard, passwords are not recoverable
> via email.
>
>
> And in that case they could just grab the data with adb, right?
>
> -dave
No, production phones do not have root access, so you can't access /data (including the profile, ie cookies indexeddb etc)>
> -dave
Paul Rouget
Sep 10, 2013, 2:30:59 PM9/10/13
to Paul Theriault, apo...@mozilla.com, dev-b2g list
Here is another option:
2 "remote debugging" checkboxes.
- remote debug (give access to the apps you're working on)
- system remote debug (give access to everything)
'System remote debug' would wipe your /data/ partition first (only the
first time it's enabled).
-- Paul
2 "remote debugging" checkboxes.
- remote debug (give access to the apps you're working on)
- system remote debug (give access to everything)
'System remote debug' would wipe your /data/ partition first (only the
first time it's enabled).
-- Paul
David Burns
Sep 10, 2013, 2:38:12 PM9/10/13
to Paul Theriault, apo...@mozilla.com, dev-b2g list, pa...@mozilla.com
How would this security model work with Marionette since Marionette
needs to access different apps according to what the user wants to do.
We go in through a similar route to the remote debugger into the
device(we are just a different actor)
David
On 10/09/2013 16:29, Paul Theriault wrote:
> (bcc dev-gaia)
>
> I have been discussing the security implications of remote debugging with a number of people and I wanted to through the question out to a wider audience. Remote debugging allows access to read any data in app and as such has implications for the scenario of when a user loses their phone.
>
> Do we want to allow the remote debugger to connect to any app?
>
> My proposal is that, for production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).
>
needs to access different apps according to what the user wants to do.
We go in through a similar route to the remote debugger into the
device(we are just a different actor)
David
On 10/09/2013 16:29, Paul Theriault wrote:
> (bcc dev-gaia)
>
> I have been discussing the security implications of remote debugging with a number of people and I wanted to through the question out to a wider audience. Remote debugging allows access to read any data in app and as such has implications for the scenario of when a user loses their phone.
>
> Do we want to allow the remote debugger to connect to any app?
>
> My proposal is that, for production devices, you should only be allowed to debug the apps you are developing. That is, the remote debugger will only connect to web apps and privileged apps pushed to the device via the simulator. It will _not_ connect to certified apps, or signed privileged apps installed from the store. The only exception to this i can think of is we probably support remote debugging of tabs within the browser app (and possibly bookmarked web pages opened by the system app).
>
> For developer builds, the remote debugger would connect to any app.
>
> Thoughts on this proposal?
>
> - Paul
>
>
>
>
>
> Thoughts on this proposal?
>
> - Paul
>
>
>
>
Paul Rouget
Sep 10, 2013, 2:54:52 PM9/10/13
to Paul Rouget, Paul Theriault, Alexandre Poirot, dev-b2g list
We could even just empty the IndexedDB database and remove the cookies.
Paul Theriault
Sep 10, 2013, 2:57:20 PM9/10/13
to David Burns, apo...@mozilla.com, dev-b2g list, pa...@mozilla.com
Marionette isn't provided on production builds (unless that is what you are proposing). Developer builds have root access enabled so not an issue I think.
Marionette is actually equivalent to root, not just similar to root (since it can execute chrome code, not just code in the system app). So I don't think we would ship marionette on any phone that we prevent root access on.
Marionette is actually equivalent to root, not just similar to root (since it can execute chrome code, not just code in the system app). So I don't think we would ship marionette on any phone that we prevent root access on.
Paul Theriault
Sep 10, 2013, 3:04:40 PM9/10/13
to Paul Rouget, apo...@mozilla.com, dev-b2g list
On Sep 10, 2013, at 8:30 PM, Paul Rouget wrote:
> Here is another option:
>
> 2 "remote debugging" checkboxes.
>
> - remote debug (give access to the apps you're working on)
> - system remote debug (give access to everything)
>
> 'System remote debug' would wipe your /data/ partition first (only the
> first time it's enabled).
>
> -- Paul
Stefan Arentz
Sep 10, 2013, 3:10:18 PM9/10/13
to Jim Blandy, Paul Theriault, dev-b2g
On Sep 10, 2013, at 12:17 PM, Jim Blandy <jbl...@mozilla.com> wrote:
> We should protect developers, too. If we require users to set a passcode on their phone in order to enable debugging, and turn off the debugging server automatically after (say) two hours of inactivity, then it seems to me the risk to developers is rather small.
S.
David Burns
Sep 10, 2013, 3:56:18 PM9/10/13
to Paul Theriault, apo...@mozilla.com, dev-b2g list, pa...@mozilla.com
Its not in production builds yet but we should eventually get there
since how would an App developer be able to test their app? I appreciate
there are a number of HUGE security and privacy issues that need to be
overcome but I think it should still be on the table even if for a later
date.
David
since how would an App developer be able to test their app? I appreciate
there are a number of HUGE security and privacy issues that need to be
overcome but I think it should still be on the table even if for a later
date.
David
Krzysztof Adamski
Sep 10, 2013, 6:31:44 PM9/10/13
to Paul Rouget, Paul Theriault, apo...@mozilla.com, dev-b2g list
Dnia 2013-09-10, o godz. 20:30:59
Paul Rouget <pa...@mozilla.com> napisał(a):
> Here is another option:
>
> 2 "remote debugging" checkboxes.
>
> - remote debug (give access to the apps you're working on)
> - system remote debug (give access to everything)
>
> 'System remote debug' would wipe your /data/ partition first (only the
> first time it's enabled).
This is something I wanted to propose and it implements similar idea of
what HTC does with it's S-OFF mode (but a little simpler). You can ask
HTC to give you the code that will unlock your phone but this will
force factory reset of the phone to prevent someone from stealing data.
I believe that it would be ideal not to cagegorize phones as
"production" and "developement" versions. Instead I think they should
be "production" and "development" *modes* of the same phone. It should
be possible to switch between modes (possibly with data erase). This
way any "customer" can become "developer" at no additional hardware
cost.
That being said, it would be the best to allow doing as much
development as possible (from security/stability perspective) even in
"production" mode. And I believe this proposal meets those criteria
well enough.
Paul Rouget <pa...@mozilla.com> napisał(a):
> Here is another option:
>
> 2 "remote debugging" checkboxes.
>
> - remote debug (give access to the apps you're working on)
> - system remote debug (give access to everything)
>
> 'System remote debug' would wipe your /data/ partition first (only the
> first time it's enabled).
what HTC does with it's S-OFF mode (but a little simpler). You can ask
HTC to give you the code that will unlock your phone but this will
force factory reset of the phone to prevent someone from stealing data.
I believe that it would be ideal not to cagegorize phones as
"production" and "developement" versions. Instead I think they should
be "production" and "development" *modes* of the same phone. It should
be possible to switch between modes (possibly with data erase). This
way any "customer" can become "developer" at no additional hardware
cost.
That being said, it would be the best to allow doing as much
development as possible (from security/stability perspective) even in
"production" mode. And I believe this proposal meets those criteria
well enough.
Ben Francis
Sep 11, 2013, 5:20:42 AM9/11/13
to Stefan Arentz, Paul Theriault, dev-b2g, Jim Blandy
On Tue, Sep 10, 2013 at 9:10 PM, Stefan Arentz <sar...@mozilla.com> wrote:
> +1 Yes, we were discussion this earlier today. I think it makes a lot of
> sense. One thing to add, it would be good to have a ‘do not auto-lock the
> screen while i am debugging my app’ option. I think Android has something
> like that and it prevents a lot of frustration as it is super annoying to
> have the screen auto lock on you while you are working on something.
This has changed recently and it's a huge pain during development? Does
> +1 Yes, we were discussion this earlier today. I think it makes a lot of
> sense. One thing to add, it would be good to have a ‘do not auto-lock the
> screen while i am debugging my app’ option. I think Android has something
> like that and it prevents a lot of frustration as it is super annoying to
> have the screen auto lock on you while you are working on something.
anyone know what changed and why?
Dave Hylands
Sep 11, 2013, 5:39:03 AM9/11/13
to Ben Francis, Paul Theriault, dev-b2g, Jim Blandy, Stefan Arentz
So, the original changes (adb disabled when the screen was locked) and remote debugging disabled after 12 hours were done due to Bug 810092 and Bug 874484.
I sent a post to Dev-B2G and Dev-Gaia about this on Aug 17.
https://groups.google.com/forum/#!msg/mozilla.dev.b2g/vl2bczVZb2Y/Y_1U4x7d3pwJ
Fabrice also recently landed bug 912898 which prevents adb from being disconnected while a debug session is active.
Dave Hylands
----- Original Message -----
> From: "Ben Francis" <bfra...@mozilla.com>
> To: "Stefan Arentz" <sar...@mozilla.com>
> Cc: "Paul Theriault" <pther...@mozilla.com>, "dev-b2g" <dev...@lists.mozilla.org>, "Jim Blandy"
> <jbl...@mozilla.com>
> Sent: Wednesday, September 11, 2013 11:20:42 AM
> Subject: Re: [b2g] Security implications of remote debugging on devices
>
I sent a post to Dev-B2G and Dev-Gaia about this on Aug 17.
https://groups.google.com/forum/#!msg/mozilla.dev.b2g/vl2bczVZb2Y/Y_1U4x7d3pwJ
Fabrice also recently landed bug 912898 which prevents adb from being disconnected while a debug session is active.
Dave Hylands
----- Original Message -----
> From: "Ben Francis" <bfra...@mozilla.com>
> To: "Stefan Arentz" <sar...@mozilla.com>
> Cc: "Paul Theriault" <pther...@mozilla.com>, "dev-b2g" <dev...@lists.mozilla.org>, "Jim Blandy"
> <jbl...@mozilla.com>
> Sent: Wednesday, September 11, 2013 11:20:42 AM
> Subject: Re: [b2g] Security implications of remote debugging on devices
>
Ben Francis
Sep 11, 2013, 5:43:04 AM9/11/13
to Dave Hylands, Paul Theriault, dev-b2g, Jim Blandy, Stefan Arentz
On Wed, Sep 11, 2013 at 11:39 AM, Dave Hylands <dhyl...@mozilla.com> wrote:
> So, the original changes (adb disabled when the screen was locked) and
> remote debugging disabled after 12 hours were done due to Bug 810092 and
> Bug 874484.
>
> I sent a post to Dev-B2G and Dev-Gaia about this on Aug 17.
>
> https://groups.google.com/forum/#!msg/mozilla.dev.b2g/vl2bczVZb2Y/Y_1U4x7d3pwJ
>
> Fabrice also recently landed bug 912898 which prevents adb from being
> disconnected while a debug session is active.
>
Thanks Dave, and Fabrice. And sorry I missed your email to dev-gaia/dev-b2g.
> So, the original changes (adb disabled when the screen was locked) and
> remote debugging disabled after 12 hours were done due to Bug 810092 and
> Bug 874484.
>
> I sent a post to Dev-B2G and Dev-Gaia about this on Aug 17.
>
> https://groups.google.com/forum/#!msg/mozilla.dev.b2g/vl2bczVZb2Y/Y_1U4x7d3pwJ
>
> Fabrice also recently landed bug 912898 which prevents adb from being
> disconnected while a debug session is active.
>
I have filed bug
915061<https://bugzilla.mozilla.org/show_bug.cgi?id=915061>to disable
these security features with a Gaia build flag.
Ben
Julien Wajsberg
Sep 11, 2013, 6:05:48 AM9/11/13
to Ben Francis, Dave Hylands, Paul Theriault, dev-b2g, Jim Blandy, Stefan Arentz
It sometimes needs some conflict merging when Fabrice or Dave messes up
with this ;)
Dave Hylands
Sep 11, 2013, 6:25:28 AM9/11/13
to Julien Wajsberg, Jim Blandy, Ben Francis, dev-b2g, Paul Theriault, Stefan Arentz
My solution is that I put the following in my .userconfig
GAIA_PATH=${GAIA_PATH:-$(cd gaia; pwd)}
CUSTOM_SETTINGS="${GAIA_PATH}/build/custom-settings.json"
cat > "${CUSTOM_SETTINGS}.new" <<EOF
{"devtools.debugger.remote-enabled": true,
"keyboard.ftu.enabled": false,
"lockscreen.enabled": false,
"phone.ring.keypad": false,
"bootshutdown.sound.enabled": false}
EOF
if [ -f ${CUSTOM_SETTINGS} ] && cmp "${CUSTOM_SETTINGS}" "${CUSTOM_SETTINGS}.new" >& /dev/null; then
rm "${CUSTOM_SETTINGS}.new"
else
mv "${CUSTOM_SETTINGS}.new" "${CUSTOM_SETTINGS}"
fi
and this tweaks a bunch of stuff for all of my builds without having to modify any source code.
Dave Hylands
----- Original Message -----
> From: "Julien Wajsberg" <jwaj...@mozilla.com>
> To: "Ben Francis" <bfra...@mozilla.com>
> Cc: "Dave Hylands" <dhyl...@mozilla.com>, "Paul Theriault" <pther...@mozilla.com>, "dev-b2g"
> <dev...@lists.mozilla.org>, "Jim Blandy" <jbl...@mozilla.com>, "Stefan Arentz" <sar...@mozilla.com>
> Sent: Wednesday, September 11, 2013 12:05:48 PM
> Subject: Re: [b2g] Security implications of remote debugging on devices
>
GAIA_PATH=${GAIA_PATH:-$(cd gaia; pwd)}
CUSTOM_SETTINGS="${GAIA_PATH}/build/custom-settings.json"
cat > "${CUSTOM_SETTINGS}.new" <<EOF
{"devtools.debugger.remote-enabled": true,
"keyboard.ftu.enabled": false,
"lockscreen.enabled": false,
"phone.ring.keypad": false,
"bootshutdown.sound.enabled": false}
EOF
if [ -f ${CUSTOM_SETTINGS} ] && cmp "${CUSTOM_SETTINGS}" "${CUSTOM_SETTINGS}.new" >& /dev/null; then
rm "${CUSTOM_SETTINGS}.new"
else
mv "${CUSTOM_SETTINGS}.new" "${CUSTOM_SETTINGS}"
fi
and this tweaks a bunch of stuff for all of my builds without having to modify any source code.
Dave Hylands
----- Original Message -----
> From: "Julien Wajsberg" <jwaj...@mozilla.com>
> To: "Ben Francis" <bfra...@mozilla.com>
> Cc: "Dave Hylands" <dhyl...@mozilla.com>, "Paul Theriault" <pther...@mozilla.com>, "dev-b2g"
> <dev...@lists.mozilla.org>, "Jim Blandy" <jbl...@mozilla.com>, "Stefan Arentz" <sar...@mozilla.com>
> Sent: Wednesday, September 11, 2013 12:05:48 PM
> Subject: Re: [b2g] Security implications of remote debugging on devices
>
Julien Wajsberg
Sep 11, 2013, 9:15:51 AM9/11/13
to Dave Hylands, Jim Blandy, Ben Francis, dev-b2g, Paul Theriault, Stefan Arentz
Le 11/09/2013 12:25, Dave Hylands a écrit :
> My solution is that I put the following in my .userconfig
>
> GAIA_PATH=${GAIA_PATH:-$(cd gaia; pwd)}
> CUSTOM_SETTINGS="${GAIA_PATH}/build/custom-settings.json"
> cat > "${CUSTOM_SETTINGS}.new" <<EOF
> {"devtools.debugger.remote-enabled": true,
> "keyboard.ftu.enabled": false,
> "lockscreen.enabled": false,
> "phone.ring.keypad": false,
> "bootshutdown.sound.enabled": false}
> EOF
> if [ -f ${CUSTOM_SETTINGS} ] && cmp "${CUSTOM_SETTINGS}" "${CUSTOM_SETTINGS}.new" >& /dev/null; then
> rm "${CUSTOM_SETTINGS}.new"
> else
> mv "${CUSTOM_SETTINGS}.new" "${CUSTOM_SETTINGS}"
> fi
>
> and this tweaks a bunch of stuff for all of my builds without having to modify any source code.
>
But I don't think this disables the adb timer for example.
> My solution is that I put the following in my .userconfig
>
> GAIA_PATH=${GAIA_PATH:-$(cd gaia; pwd)}
> CUSTOM_SETTINGS="${GAIA_PATH}/build/custom-settings.json"
> cat > "${CUSTOM_SETTINGS}.new" <<EOF
> {"devtools.debugger.remote-enabled": true,
> "keyboard.ftu.enabled": false,
> "lockscreen.enabled": false,
> "phone.ring.keypad": false,
> "bootshutdown.sound.enabled": false}
> EOF
> if [ -f ${CUSTOM_SETTINGS} ] && cmp "${CUSTOM_SETTINGS}" "${CUSTOM_SETTINGS}.new" >& /dev/null; then
> rm "${CUSTOM_SETTINGS}.new"
> else
> mv "${CUSTOM_SETTINGS}.new" "${CUSTOM_SETTINGS}"
> fi
>
> and this tweaks a bunch of stuff for all of my builds without having to modify any source code.
>
I would be happy if we'd have a pref to do the same as my hacky patch,
so that we would just put this in our build/custom-prefs.js :)
--
Julien
Paul Theriault
Sep 11, 2013, 9:38:55 AM9/11/13
to David Burns, apo...@mozilla.com, dev-b2g list, pa...@mozilla.com
I agree - I don't know the marionette protocol all that well but it may not be that hard. The main difference as I understand between debugger and marionette is that marionette has Marionette.switch_context('chrome'). Might need some initial mitigations for that feature (since it is literally root access), but maybe we can probably take a similar approach to what we are doing with debugger ( i.e. clear all sensitive app data before enabling feature).
Kyle Huey
Sep 11, 2013, 2:03:18 PM9/11/13
to Paul Theriault, apo...@mozilla.com, dev-b2g list, pa...@mozilla.com
What determines whether a device is a "production" device or a "developer"
device?
- Kyle
On Tue, Sep 10, 2013 at 8:29 AM, Paul Theriault <pther...@mozilla.com>wrote:
> (bcc dev-gaia)
>
> I have been discussing the security implications of remote debugging with
> a number of people and I wanted to through the question out to a wider
> audience. Remote debugging allows access to read any data in app and as
> such has implications for the scenario of when a user loses their phone.
>
> Do we want to allow the remote debugger to connect to any app?
>
> My proposal is that, for production devices, you should only be allowed to
> debug the apps you are developing. That is, the remote debugger will only
> connect to web apps and privileged apps pushed to the device via the
> simulator. It will _not_ connect to certified apps, or signed privileged
> apps installed from the store. The only exception to this i can think of is
> we probably support remote debugging of tabs within the browser app (and
> possibly bookmarked web pages opened by the system app).
>
> For developer builds, the remote debugger would connect to any app.
>
> Thoughts on this proposal?
>
> - Paul
>
>
>
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
>
device?
- Kyle
On Tue, Sep 10, 2013 at 8:29 AM, Paul Theriault <pther...@mozilla.com>wrote:
> (bcc dev-gaia)
>
> I have been discussing the security implications of remote debugging with
> a number of people and I wanted to through the question out to a wider
> audience. Remote debugging allows access to read any data in app and as
> such has implications for the scenario of when a user loses their phone.
>
> Do we want to allow the remote debugger to connect to any app?
>
> My proposal is that, for production devices, you should only be allowed to
> debug the apps you are developing. That is, the remote debugger will only
> connect to web apps and privileged apps pushed to the device via the
> simulator. It will _not_ connect to certified apps, or signed privileged
> apps installed from the store. The only exception to this i can think of is
> we probably support remote debugging of tabs within the browser app (and
> possibly bookmarked web pages opened by the system app).
>
> For developer builds, the remote debugger would connect to any app.
>
> Thoughts on this proposal?
>
> - Paul
>
>
>
> _______________________________________________
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
>
Matt Claypotch
Sep 11, 2013, 2:19:17 PM9/11/13
to Paul Theriault, apo...@mozilla.com, dev-b2g list, pa...@mozilla.com
I think of remote debugging as the ability to run devtools on certain site.
I'd be uncomfortable with the notion that on some secure sites, I would be
disallowed to open the Developer Tools. Like desktop Firefox, I reject the
notion that "users" and "developers" should receive a different project. I
want the stability of a production build because this is my day-to-day
phone, and it should work properly.
I'd be uncomfortable with the notion that on some secure sites, I would be
disallowed to open the Developer Tools. Like desktop Firefox, I reject the
notion that "users" and "developers" should receive a different project. I
want the stability of a production build because this is my day-to-day
phone, and it should work properly.
Caio Lima
Sep 12, 2013, 12:40:37 AM9/12/13
to Julien Wajsberg, Paul Theriault, Jim Blandy, Ben Francis, Dave Hylands, dev-b2g, Stefan Arentz
Julien, I'm interested in your hack to enable the remote debugging. Could
you share? ;)
I want to enable it in my emulator!
2013/9/11 Julien Wajsberg <jwaj...@mozilla.com>
Caio Lima
you share? ;)
I want to enable it in my emulator!
2013/9/11 Julien Wajsberg <jwaj...@mozilla.com>
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>
>
--
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>
>
Caio Lima
Julien Wajsberg
Sep 12, 2013, 5:00:43 AM9/12/13
to Caio Lima, Paul Theriault, Jim Blandy, Ben Francis, Dave Hylands, dev-b2g, Stefan Arentz
Hey Caio,
it's attached to my previous mail ;)
Le 12/09/2013 06:40, Caio Lima a écrit :
> Julien, I'm interested in your hack to enable the remote debugging.
> Could you share? ;)
>
> I want to enable it in my emulator!
>
>
> 2013/9/11 Julien Wajsberg <jwaj...@mozilla.com
> <mailto:jwaj...@mozilla.com>>
> dev...@lists.mozilla.org <mailto:dev...@lists.mozilla.org>
it's attached to my previous mail ;)
Le 12/09/2013 06:40, Caio Lima a écrit :
> Julien, I'm interested in your hack to enable the remote debugging.
> Could you share? ;)
>
> I want to enable it in my emulator!
>
>
> 2013/9/11 Julien Wajsberg <jwaj...@mozilla.com
Caio Lima
Sep 12, 2013, 10:45:38 AM9/12/13
to Julien Wajsberg, Paul Theriault, Jim Blandy, Ben Francis, Dave Hylands, dev-b2g, Stefan Arentz
Sorry, I didn't see it. Thank you!
2013/9/12 Julien Wajsberg <jwaj...@mozilla.com>
> Hey Caio,
>
> it's attached to my previous mail ;)
>
> Le 12/09/2013 06:40, Caio Lima a écrit :
>
> Julien, I'm interested in your hack to enable the remote debugging.
> Could you share? ;)
>
> I want to enable it in my emulator!
>
>
> 2013/9/11 Julien Wajsberg <jwaj...@mozilla.com>
>
--
Caio Lima
2013/9/12 Julien Wajsberg <jwaj...@mozilla.com>
> Hey Caio,
>
> it's attached to my previous mail ;)
>
> Le 12/09/2013 06:40, Caio Lima a écrit :
>
> Julien, I'm interested in your hack to enable the remote debugging.
> Could you share? ;)
>
> I want to enable it in my emulator!
>
>
> 2013/9/11 Julien Wajsberg <jwaj...@mozilla.com>
>
Caio Lima
Jim Blandy
Sep 15, 2013, 2:52:23 AM9/15/13
to dev...@lists.mozilla.org
On 09/10/2013 10:58 AM, Paul Theriault wrote:
> My proposal makes its more difficult for someone with physical access to a phone without a passcode to steal sensitive app data. If we limit which apps you can debug as I described above, in order to get access to app data, you still need root access to the phone. If we allow access to debug all apps, this bar is lowered, so that you can access the app data by enabling debugging.
If the phone is stolen and no passcode is set, then I can access app
> My proposal makes its more difficult for someone with physical access to a phone without a passcode to steal sensitive app data. If we limit which apps you can debug as I described above, in order to get access to app data, you still need root access to the phone. If we allow access to debug all apps, this bar is lowered, so that you can access the app data by enabling debugging.
data by starting the apps, too. I have access to any web accounts those
apps might be tied to, and so on. Aren't the dev tools just a rather
painful method of doing what our UI people are trying to make as easy
and as pleasant as possible via other means?
Paul Theriault
Sep 15, 2013, 7:41:28 AM9/15/13
to Jim Blandy, dev...@lists.mozilla.org
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.
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.
A. Crespo
Sep 15, 2013, 7:57:12 AM9/15/13
to Paul Theriault, Dev B2G List, Jim Blandy
Paul,
I know what are you trying to explain but I can't figure out who would
leave his phone unattended. I mean, If you leave your phone alone you can
bet that you won't find it nevermore, at least in Spain. After that, with
or without remote debugger enabled, I'm sure I will steal your passwords.
Despite sometimes the access granted by the debugger could be greater, I
would like to suggest to put a reasonable limit on those cases.
2013/9/15 Paul Theriault <pther...@mozilla.com>
I know what are you trying to explain but I can't figure out who would
leave his phone unattended. I mean, If you leave your phone alone you can
bet that you won't find it nevermore, at least in Spain. After that, with
or without remote debugger enabled, I'm sure I will steal your passwords.
Despite sometimes the access granted by the debugger could be greater, I
would like to suggest to put a reasonable limit on those cases.
2013/9/15 Paul Theriault <pther...@mozilla.com>
Jim Blandy
Sep 16, 2013, 3:57:06 PM9/16/13
to Paul Theriault, dev...@lists.mozilla.org
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.
> 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.
>
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.
Clint Talbert
Sep 17, 2013, 2:39:22 PM9/17/13
to dev...@lists.mozilla.org
phone stolen, I didn't care whether I had a passcode on the phone or
whether I had USB Debugging enabled (I had both) I cared that I had a
remote kill switch to erase the phone. It's faster, it's easier, and
it's fool proof. While still at the bar where it happened, I borrowed a
buddy's phone, logged in, and killed my stolen phone.
If we allow ourselves to go down this rabbit hole too far we will have
a very secure phone at the cost of handcuffing would-be developers for
the web platform. I don't think that's the direction we should take
with Firefox OS.
Clint
Paul Theriault
Sep 18, 2013, 3:09:41 AM9/18/13
to Jim Blandy, dev...@lists.mozilla.org
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.
>
>>
>> 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.
>
> 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.
>
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.
Jonas Sicking
Sep 21, 2013, 8:49:01 AM9/21/13
to Jim Blandy, Paul Theriault, dev...@lists.mozilla.org
On Tue, Sep 10, 2013 at 9:17 AM, Jim Blandy <jbl...@mozilla.com> wrote:
> Debugging is how many people are going to learn how to write apps; think
> about the role of "view source" in introducing people to web technology. And
> it's consistent with our goal of putting the user in charge of their own
> device. I think we should treat all apps as debuggable, on any device.
>
> As far as non-developer users are concerned: debugging is turned off by
> default. You need to go (rather deep) into the settings and explicitly turn
> debugging on, before the server begins listening. There is no reason a
> non-developer would ever need to enable debugging (and we should ensure this
> remains true). So I don't see the risk to non-developer users.
The attack here is if the user gets the device stolen, then the thief
could go into the settings and explicitly turn debugging on. He/she
could then use the debugger to suck out all sorts of data from various
apps. Things like login tokens to your email or even raw passwords
from applications that store those client-side.
There's also the "evil maid" attack, where a maid which gets access to
your phone for 5 minutes, can do the same and quickly suck out all
data from your phone.
In neither scenario the user is particularly protected by hiding the
debugging-enabling checkbox deeper in the settings app.
Ideal would be if the user had to enter some code in order to turn on
debugging, but what code would we use? It would be pointless to enable
setting the code the first time debugging is turned on, since most
people will never turn on debugging. And so the thief/maid would just
be able to select the code themselves.
The code solution could be used to protect developers like you point out though.
The user would be protected if the phone is locked with a passcode,
but a lot of people don't enable those.
One idea that was floated was that we're in a good state if turning on
debugging only enables debugging of apps installed after debugging was
enabled. That would let the user turn on debugging, then install an
app that they want to know how it works, and start debugging away.
Unfortunately that doesn't help with users that want to debug the apps
that are preinstalled on the device. We didn't have any particularly
good solution there.
One bad-but-maybe-ok solution is to require that the phone goes
through a special factory reset codepath which boots up the device in
a mode where debugging is enabled from the start.
Requiring factory reset is obviously crappy and not an option for a
lot of developers. But it would only be required for developers that
want to attach a debugger to the preinstalled apps.
/ Jonas
> Debugging is how many people are going to learn how to write apps; think
> about the role of "view source" in introducing people to web technology. And
> it's consistent with our goal of putting the user in charge of their own
> device. I think we should treat all apps as debuggable, on any device.
>
> As far as non-developer users are concerned: debugging is turned off by
> default. You need to go (rather deep) into the settings and explicitly turn
> debugging on, before the server begins listening. There is no reason a
> non-developer would ever need to enable debugging (and we should ensure this
> remains true). So I don't see the risk to non-developer users.
The attack here is if the user gets the device stolen, then the thief
could go into the settings and explicitly turn debugging on. He/she
could then use the debugger to suck out all sorts of data from various
apps. Things like login tokens to your email or even raw passwords
from applications that store those client-side.
There's also the "evil maid" attack, where a maid which gets access to
your phone for 5 minutes, can do the same and quickly suck out all
data from your phone.
In neither scenario the user is particularly protected by hiding the
debugging-enabling checkbox deeper in the settings app.
Ideal would be if the user had to enter some code in order to turn on
debugging, but what code would we use? It would be pointless to enable
setting the code the first time debugging is turned on, since most
people will never turn on debugging. And so the thief/maid would just
be able to select the code themselves.
The code solution could be used to protect developers like you point out though.
The user would be protected if the phone is locked with a passcode,
but a lot of people don't enable those.
One idea that was floated was that we're in a good state if turning on
debugging only enables debugging of apps installed after debugging was
enabled. That would let the user turn on debugging, then install an
app that they want to know how it works, and start debugging away.
Unfortunately that doesn't help with users that want to debug the apps
that are preinstalled on the device. We didn't have any particularly
good solution there.
One bad-but-maybe-ok solution is to require that the phone goes
through a special factory reset codepath which boots up the device in
a mode where debugging is enabled from the start.
Requiring factory reset is obviously crappy and not an option for a
lot of developers. But it would only be required for developers that
want to attach a debugger to the preinstalled apps.
/ Jonas
Krzysztof Adamski
Sep 21, 2013, 1:12:47 PM9/21/13
to dev...@lists.mozilla.org
Dnia 2013-09-21, o godz. 05:49:01
Jonas Sicking <jo...@sicking.cc> napisał(a):
> Ideal would be if the user had to enter some code in order to turn on
> debugging, but what code would we use? It would be pointless to enable
> setting the code the first time debugging is turned on, since most
> people will never turn on debugging. And so the thief/maid would just
> be able to select the code themselves.
>
> The code solution could be used to protect developers like you point
> out though.
>
> The user would be protected if the phone is locked with a passcode,
> but a lot of people don't enable those.
>
> [...]
first time you have to make factory reset AND set the password. Then
you can easily disable debugging if you want to (like when finished
developing) but each time you want to re-enable it, you have to enter
the password. It could also be auto disabled after reboot or some
time after it was last used or something.. The only way to reset this
password would be to do factory reset again.
Jonas Sicking <jo...@sicking.cc> napisał(a):
> Ideal would be if the user had to enter some code in order to turn on
> debugging, but what code would we use? It would be pointless to enable
> setting the code the first time debugging is turned on, since most
> people will never turn on debugging. And so the thief/maid would just
> be able to select the code themselves.
>
> The code solution could be used to protect developers like you point
> out though.
>
> The user would be protected if the phone is locked with a passcode,
> but a lot of people don't enable those.
>
>
> One bad-but-maybe-ok solution is to require that the phone goes
> through a special factory reset codepath which boots up the device in
> a mode where debugging is enabled from the start.
>
> Requiring factory reset is obviously crappy and not an option for a
> lot of developers. But it would only be required for developers that
> want to attach a debugger to the preinstalled apps.
How about combining the two? If you are enabling debugging for the
> One bad-but-maybe-ok solution is to require that the phone goes
> through a special factory reset codepath which boots up the device in
> a mode where debugging is enabled from the start.
>
> Requiring factory reset is obviously crappy and not an option for a
> lot of developers. But it would only be required for developers that
> want to attach a debugger to the preinstalled apps.
first time you have to make factory reset AND set the password. Then
you can easily disable debugging if you want to (like when finished
developing) but each time you want to re-enable it, you have to enter
the password. It could also be auto disabled after reboot or some
time after it was last used or something.. The only way to reset this
password would be to do factory reset again.
Dale Harvey
Sep 21, 2013, 1:28:28 PM9/21/13
to Krzysztof Adamski, dev-b2g
But users can only turn in debugging if they have pin code access to the
phone?
If a developer has purposefully enabled remote debugging they can
understand the security implications of such, as said in the original email
adding more obscure protection methods that hamper the ability for people
to debug on devices seems counter productive. (especially factory resets or
wiping users data, for builtin apps or otherwise)
Requiring devs to have a pin code to enable debugging seems like more than
enough protection and for further measures it seems remote wipe is far more
useful than things that require us to wipe data (possible the data we are
trying to debug) before being able to debug it
phone?
If a developer has purposefully enabled remote debugging they can
understand the security implications of such, as said in the original email
adding more obscure protection methods that hamper the ability for people
to debug on devices seems counter productive. (especially factory resets or
wiping users data, for builtin apps or otherwise)
Requiring devs to have a pin code to enable debugging seems like more than
enough protection and for further measures it seems remote wipe is far more
useful than things that require us to wipe data (possible the data we are
trying to debug) before being able to debug it
Krzysztof Adamski
Sep 22, 2013, 6:24:49 AM9/22/13
to dev-b2g
Dnia 2013-09-21, o godz. 18:28:28
Dale Harvey <da...@arandomurl.com> napisał(a):
> Requiring devs to have a pin code to enable debugging seems like more
> than enough protection and for further measures it seems remote wipe
> is far more useful than things that require us to wipe data (possible
> the data we are trying to debug) before being able to debug it
If by "pin code" you mean PIN on SIM card then it's not enough since
all attacker has to do in order go steal your data is to use his own SIM
card.
I agree that wiping data first time we turn debugging on is not ideal
since this makes it hard to "start being developer" after we used the
phone for some time but remote wipe has it's downsides too. It does not
protect from "evil maid" attacks and many people seems to be concerned
about them. What is more important to me is that it may be too late
when you realize that your phone was stolen (couple minutes are enough
to copy all the data by attacker).
Also, how should that remote wipe work? Over the Internet or there is
some other way I'm not aware off? If it's the first one, then the first
thing that attacker will do is to disconnect the phone from the
Internet. And even if he doesn't, it's likely that stolen phone just
won't have continues Internet connectivity enabled. I personally often
turn Internet connection off to safe battery and I usually turn it off
completely when going abroad because it's too expensive in roaming.
Dale Harvey <da...@arandomurl.com> napisał(a):
> Requiring devs to have a pin code to enable debugging seems like more
> than enough protection and for further measures it seems remote wipe
> is far more useful than things that require us to wipe data (possible
> the data we are trying to debug) before being able to debug it
all attacker has to do in order go steal your data is to use his own SIM
card.
I agree that wiping data first time we turn debugging on is not ideal
since this makes it hard to "start being developer" after we used the
phone for some time but remote wipe has it's downsides too. It does not
protect from "evil maid" attacks and many people seems to be concerned
about them. What is more important to me is that it may be too late
when you realize that your phone was stolen (couple minutes are enough
to copy all the data by attacker).
Also, how should that remote wipe work? Over the Internet or there is
some other way I'm not aware off? If it's the first one, then the first
thing that attacker will do is to disconnect the phone from the
Internet. And even if he doesn't, it's likely that stolen phone just
won't have continues Internet connectivity enabled. I personally often
turn Internet connection off to safe battery and I usually turn it off
completely when going abroad because it's too expensive in roaming.
Salvador de la Puente González
Sep 23, 2013, 7:27:47 AM9/23/13
to Krzysztof Adamski, dev-b2g
Hello guys.
I want to contribute here with my little grain of sand: what about
asking in the FTU if the user is a developer and then ask for
configuring the device in such a special way including these passwords
and so on?
I think it could be a very cool feature to ask the user "do you think
you will create apps for Firefox OS?" with a yes / no answer. If you say
no, I remember you can always launch the FTU whenever you want.
Anyway, I will try to not be paranoid about security. If an attacker
gets your phone is only matter of time to get root access, the no
solution is effective.
Cheers!
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>
________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Jim Blandy
Sep 23, 2013, 7:28:13 PM9/23/13
to Paul Theriault, dev...@lists.mozilla.org
On 09/18/2013 12:09 AM, Paul Theriault wrote:
> 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.
Here are the parts I think we agree on:
> 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.
Given that access to sensitive data (messages, pictures, and, via email,
password resetting) is possible either way on a phone with no passcode
set, making the pref false adds only mechanized access to the picture.
Then, features like USB photo sync provide such mechanized access for
some sensitive data already. (We don't insist on wiping photos before
enabling sync, right?) This further reduces the *additional* (that is,
available only by flipping the pref) exposure from allowing debugging.
Is this characterization fair and complete?
Then, I'm not yet persuaded that a user whose phone has been stolen, and
who is already worried about in-app access, will further be upset that
the debugging protocol offers an additional channel to the thief. I'm
not a typical user, but even keeping my limited perspective in mind,
that's hard for me to imagine.
I don't even think we should *require* users to wipe sensitive data to
enable debugging. We should *offer* to do so, but forcing it seems like
building in the assumption that users who are choosing to develop can't
consider the consequences of that choice. Is that the way we want to
treat people?
Jonas Sicking
Sep 23, 2013, 7:54:58 PM9/23/13
to Jim Blandy, Paul Theriault, dev...@lists.mozilla.org
On Mon, Sep 23, 2013 at 4:28 PM, Jim Blandy <jbl...@mozilla.com> wrote:
> I don't even think we should *require* users to wipe sensitive data to
> enable debugging. We should *offer* to do so, but forcing it seems like
> building in the assumption that users who are choosing to develop can't
> consider the consequences of that choice. Is that the way we want to treat
> people?
I'm not sure what you mean here. If we assume that most users won't
> I don't even think we should *require* users to wipe sensitive data to
> enable debugging. We should *offer* to do so, but forcing it seems like
> building in the assumption that users who are choosing to develop can't
> consider the consequences of that choice. Is that the way we want to treat
> people?
ever turn on debugging, and we assume that the attacker might turn on
debugging. Then what is the purpose of asking about wiping the phone
at the time of turning on debugging?
The only thing in that direction I could see doing would be to ask at
the initial phone boot if the user wants to enable security features
like "wipe on debug turn-on". But I doubt that we'll be ok with adding
UI during the first-time-run specifically about developer features.
/ Jonas
Dale Harvey
Sep 24, 2013, 7:10:57 AM9/24/13
to Jonas Sicking, Paul Theriault, dev...@lists.mozilla.org, Jim Blandy
The passcode we use is not a sim card lock and not overridable by switching
sim cards
With that in place I still dont understand why we are talking about wiping
peoples phones to debug them
sim cards
With that in place I still dont understand why we are talking about wiping
peoples phones to debug them
Jonas Sicking
Sep 24, 2013, 11:52:17 AM9/24/13
to Dale Harvey, Paul Theriault, dev...@lists.mozilla.org, Jim Blandy
On Sep 24, 2013 4:10 AM, "Dale Harvey" <da...@arandomurl.com> wrote:
>
> The passcode we use is not a sim card lock and not overridable by
switching sim cards
>
> With that in place I still dont understand why we are talking about
wiping peoples phones to debug them
Like I said, most people don't enable a passcode. I guess we could simply
>
> The passcode we use is not a sim card lock and not overridable by
switching sim cards
>
> With that in place I still dont understand why we are talking about
wiping peoples phones to debug them
point the finger of blame at those people, but I'd rather try to do
something better than that. Especially since we know that stolen phones is
not a rare occurrence in some of our target markets.
But potentially we could enable debugging system apps without wiping in
phones that do have a passcode. But of course we don't want the person who
stole your phone to be able to turn on the passcode and then steal all your
data.
/ Jonas
Jim Blandy
Sep 24, 2013, 1:42:21 PM9/24/13
to Jonas Sicking, Paul Theriault, dev...@lists.mozilla.org
On 09/23/2013 04:54 PM, Jonas Sicking wrote:
> On Mon, Sep 23, 2013 at 4:28 PM, Jim Blandy <jbl...@mozilla.com> wrote:
>> I don't even think we should *require* users to wipe sensitive data to
>> enable debugging. We should *offer* to do so, but forcing it seems like
>> building in the assumption that users who are choosing to develop can't
>> consider the consequences of that choice. Is that the way we want to treat
>> people?
> I'm not sure what you mean here. If we assume that most users won't
> ever turn on debugging, and we assume that the attacker might turn on
> debugging. Then what is the purpose of asking about wiping the phone
> at the time of turning on debugging?
There are two separate situations under discussion where wipes might be
> On Mon, Sep 23, 2013 at 4:28 PM, Jim Blandy <jbl...@mozilla.com> wrote:
>> I don't even think we should *require* users to wipe sensitive data to
>> enable debugging. We should *offer* to do so, but forcing it seems like
>> building in the assumption that users who are choosing to develop can't
>> consider the consequences of that choice. Is that the way we want to treat
>> people?
> I'm not sure what you mean here. If we assume that most users won't
> ever turn on debugging, and we assume that the attacker might turn on
> debugging. Then what is the purpose of asking about wiping the phone
> at the time of turning on debugging?
valuable:
a) Folks have suggested requiring a wipe when turning on debugging. A
thief interested in personal data would simply leave debugging off, and
use the apps as the owner would. For this deterrent to work, the wipe
must be an inescapable consequence of turning on debugging.
b) If I were going to try some wild experiment on my phone, then I might
well want to depersonalize it first. For this use case, a voluntary wipe
is fine, and needn't be tied to debugging at all.
> The only thing in that direction I could see doing would be to ask at
> the initial phone boot if the user wants to enable security features
> like "wipe on debug turn-on". But I doubt that we'll be ok with adding
> UI during the first-time-run specifically about developer features.
need to stay out of peoples' way.
Jim Blandy
Sep 26, 2013, 10:27:29 PM9/26/13
to Jonas Sicking, Paul Theriault, dev...@lists.mozilla.org
On 09/21/2013 05:49 AM, Jonas Sicking wrote:
> On Tue, Sep 10, 2013 at 9:17 AM, Jim Blandy <jbl...@mozilla.com> wrote:
>> Debugging is how many people are going to learn how to write apps; think
>> about the role of "view source" in introducing people to web technology. And
>> it's consistent with our goal of putting the user in charge of their own
>> device. I think we should treat all apps as debuggable, on any device.
>>
>> As far as non-developer users are concerned: debugging is turned off by
>> default. You need to go (rather deep) into the settings and explicitly turn
>> debugging on, before the server begins listening. There is no reason a
>> non-developer would ever need to enable debugging (and we should ensure this
>> remains true). So I don't see the risk to non-developer users.
> The attack here is if the user gets the device stolen, then the thief
> could go into the settings and explicitly turn debugging on. He/she
> could then use the debugger to suck out all sorts of data from various
> apps. Things like login tokens to your email or even raw passwords
> from applications that store those client-side.
Right - the debugging protocol allows users, thieves or otherwise,
> On Tue, Sep 10, 2013 at 9:17 AM, Jim Blandy <jbl...@mozilla.com> wrote:
>> Debugging is how many people are going to learn how to write apps; think
>> about the role of "view source" in introducing people to web technology. And
>> it's consistent with our goal of putting the user in charge of their own
>> device. I think we should treat all apps as debuggable, on any device.
>>
>> As far as non-developer users are concerned: debugging is turned off by
>> default. You need to go (rather deep) into the settings and explicitly turn
>> debugging on, before the server begins listening. There is no reason a
>> non-developer would ever need to enable debugging (and we should ensure this
>> remains true). So I don't see the risk to non-developer users.
> The attack here is if the user gets the device stolen, then the thief
> could go into the settings and explicitly turn debugging on. He/she
> could then use the debugger to suck out all sorts of data from various
> apps. Things like login tokens to your email or even raw passwords
> from applications that store those client-side.
access to data apps don't offer via their UIs. But most data the user
cares about protecting *is* available via the UIs. And access to the
user's email account will allow the attacker to change the user's
passwords (in the guise of "password recovery", so auth tokens are
effectively available to the thief, debugger or not. So the additional
exposure here is minor; am I missing something?
> There's also the "evil maid" attack, where a maid which gets access to
> your phone for 5 minutes, can do the same and quickly suck out all
> data from your phone.
protected phones, and is only valuable when the attacker is uninterested
in simply stealing the phone outright, seems a bit artificial to me,
like what Scheier calls a "movie plot attack": one that sounds dramatic,
but is not worth designing security policy around.
Is there more background here that would help me apprehend this better?
How can we responsibly assess the significance of this attack against
non-passcode-protected phones, and compare it to the value of having the
phone enable development-oriented users to actually learn how apps work?
(By the way - can we call it the 'office spy' attack, or something? The
'evil maid' monicker - and I know it was coined in full innocence - is
just a little icky, since hotel and custodial staff are, I'm told, often
blamed for thefts they didn't commit.)
> In neither scenario the user is particularly protected by hiding the
> debugging-enabling checkbox deeper in the settings app.
> Ideal would be if the user had to enter some code in order to turn on
> debugging, but what code would we use? It would be pointless to enable
> setting the code the first time debugging is turned on, since most
> people will never turn on debugging. And so the thief/maid would just
> be able to select the code themselves.
between legimate and illegitimate users. Whatever level of access we
offer goes to both sides, thus the question.
> One idea that was floated was that we're in a good state if turning on
> debugging only enables debugging of apps installed after debugging was
> enabled. That would let the user turn on debugging, then install an
> app that they want to know how it works, and start debugging away.
approach. If we conclude that the additional exposure via the debugging
protocol is salient, then this might be a good solution, presuming users
can re-install pre-installed apps. But as I say above, I don't really
agree with the premise.
Jim Blandy
Sep 26, 2013, 10:32:57 PM9/26/13
to dev...@lists.mozilla.org
On 09/23/2013 04:27 AM, Salvador de la Puente González wrote:
>
> I think it could be a very cool feature to ask the user "do you think
> you will create apps for Firefox OS?" with a yes / no answer. If you say
> no, I remember you can always launch the FTU whenever you want.
>
Wonderful! I'd said earlier that we shouldn't mess with the FTU at all
>
> I think it could be a very cool feature to ask the user "do you think
> you will create apps for Firefox OS?" with a yes / no answer. If you say
> no, I remember you can always launch the FTU whenever you want.
>
--- but this could be a way to point out to users that their FxOS phone
is theirs to control! I love it!
But I think this is where the UX people come in and say, "Look, folks,
it's a sweet idea, but that's just going to waste the time of 99.99% of
users. Leave it alone." :)
Jim Blandy
Sep 26, 2013, 11:01:41 PM9/26/13
to dev...@lists.mozilla.org
On 09/26/2013 07:27 PM, Jim Blandy wrote:
> On 09/21/2013 05:49 AM, Jonas Sicking wrote:
>> The attack here is if the user gets the device stolen, then the thief
>> could go into the settings and explicitly turn debugging on. He/she
>> could then use the debugger to suck out all sorts of data from various
>> apps. Things like login tokens to your email or even raw passwords
>> from applications that store those client-side.
> Right - the debugging protocol allows users, thieves or otherwise,
> access to data apps don't offer via their UIs. But most data the user
> cares about protecting *is* available via the UIs. And access to the
> user's email account will allow the attacker to change the user's
> passwords (in the guise of "password recovery", so auth tokens are
> effectively available to the thief, debugger or not. So the additional
> exposure here is minor; am I missing something?
More succinctly: when a developer's phone is stolen, is their reaction
> On 09/21/2013 05:49 AM, Jonas Sicking wrote:
>> The attack here is if the user gets the device stolen, then the thief
>> could go into the settings and explicitly turn debugging on. He/she
>> could then use the debugger to suck out all sorts of data from various
>> apps. Things like login tokens to your email or even raw passwords
>> from applications that store those client-side.
> Right - the debugging protocol allows users, thieves or otherwise,
> access to data apps don't offer via their UIs. But most data the user
> cares about protecting *is* available via the UIs. And access to the
> user's email account will allow the attacker to change the user's
> passwords (in the guise of "password recovery", so auth tokens are
> effectively available to the thief, debugger or not. So the additional
> exposure here is minor; am I missing something?
going to be "Oh dear, someone might hook up a debugger!"?
I'm saying that's going to be pretty far down on their list of concerns.
And if developers don't care about that, non-developer users won't either.
Jonas Sicking
Sep 27, 2013, 8:58:20 PM9/27/13
to Jim Blandy, dev...@lists.mozilla.org
"oh crap, now they can get at all the data on my phone, I wish I had
had a passcode enabled, now I gotta change all my passwords!".
I indeed didn't specifically think about debuggers, but I don't think
that's really relevant here. The question is if the data can be stolen
or not. And how much damage can be done between the time when the
device is stolen and the user is able to do something about it.
>> One idea that was floated was that we're in a good state if turning on
>> debugging only enables debugging of apps installed after debugging was
>> enabled. That would let the user turn on debugging, then install an
>> app that they want to know how it works, and start debugging away.
>
> This sounds similar to the "wipe sensitive data when enabling debugging"
> approach. If we conclude that the additional exposure via the debugging
> protocol is salient, then this might be a good solution, presuming users can
> re-install pre-installed apps. But as I say above, I don't really agree with
> the premise.
actually have a plan for how it could be implemented (we still have no
idea how to "wipe sensitive data" without wiping all data).
I still think that enabling debugging for all apps installed after the
debugger was enabled brings us 90% of the value (developers can debug
their own apps as they are developing as well as inspect other 3rd
party apps that they install) at almost 0% of the cost (no additional
risk of data leakage, relatively easy to implement).
If we on top of that enable debugging any app after a system wipe,
that gives us an additional few percent of value as we would enable
people to learn from our apps, but only if they use a device which
isn't their day-to-day phone. The cost here is definitely higher
though as implementing this is more complicated (it's hard to get any
information to survive a system wipe, including the information of
"start the device in debug-enabled mode).
So the question is how much cost we are willing to take for getting
the last few percent of value. I.e. how much additional user data
leakage risk are we willing to take to enable developers to debug
system apps without also wiping their contents?
/ Jonas
Jim Blandy
Oct 1, 2013, 6:08:17 PM10/1/13
to Jonas Sicking, dev...@lists.mozilla.org
On 09/27/2013 05:58 PM, Jonas Sicking wrote:
> On Thu, Sep 26, 2013 at 8:01 PM, Jim Blandy <jbl...@mozilla.com> wrote:
>> More succinctly: when a developer's phone is stolen, is their reaction going
>> to be "Oh dear, someone might hook up a debugger!"?
>>
>> I'm saying that's going to be pretty far down on their list of concerns. And
>> if developers don't care about that, non-developer users won't either.
> Really? As someone who has had my phone stolen, my first reaction was
> "oh crap, now they can get at all the data on my phone, I wish I had
> had a passcode enabled, now I gotta change all my passwords!".
>
> I indeed didn't specifically think about debuggers, but I don't think
> that's really relevant here. The question is if the data can be stolen
> or not. And how much damage can be done between the time when the
> device is stolen and the user is able to do something about it.
It's exactly what's relevant here: if users who understand the
> On Thu, Sep 26, 2013 at 8:01 PM, Jim Blandy <jbl...@mozilla.com> wrote:
>> More succinctly: when a developer's phone is stolen, is their reaction going
>> to be "Oh dear, someone might hook up a debugger!"?
>>
>> I'm saying that's going to be pretty far down on their list of concerns. And
>> if developers don't care about that, non-developer users won't either.
> Really? As someone who has had my phone stolen, my first reaction was
> "oh crap, now they can get at all the data on my phone, I wish I had
> had a passcode enabled, now I gotta change all my passwords!".
>
> I indeed didn't specifically think about debuggers, but I don't think
> that's really relevant here. The question is if the data can be stolen
> or not. And how much damage can be done between the time when the
> device is stolen and the user is able to do something about it.
significance of debugging consider the possibility of someone connecting
to their stolen phone with a debugger to be a second-tier concern, given
all the other ways of getting personal data off the phone, then there's
little advantage to restricting debugging.
The known disadvantage is that restricting debugging makes the phone
less cooperative with developers. The idea that the phone should be
responsive to you, and that the web is something anyone can create, are
central to our mission.
----
More broadly: when the phone is in the hands of its legitimate owner, we
want it to be super-responsive and inviting. The more we can lower the
thresholds to making cool stuff happen, including sharing data with
off-phone, non-Mozilla services, the better. We want frictionless access.
But once an unlocked phone is stolen, all effort in that direction works
against us. The easier it was for the owner to do stuff, the easier it
is for the thief.
It does *not* follow that we should therefore hinder these interactions,
just in case the phone gets stolen; that's crazy.
Debugging is just another kind of access that users might want. It's not
a special case.
Jim Blandy
Oct 1, 2013, 6:21:56 PM10/1/13
to Jonas Sicking, dev...@lists.mozilla.org
On 09/27/2013 05:58 PM, Jonas Sicking wrote:
>>> One idea that was floated was that we're in a good state if turning on
>>> debugging only enables debugging of apps installed after debugging was
>>> enabled. That would let the user turn on debugging, then install an
>>> app that they want to know how it works, and start debugging away.
>> This sounds similar to the "wipe sensitive data when enabling debugging"
>> approach. If we conclude that the additional exposure via the debugging
>> protocol is salient, then this might be a good solution, presuming users can
>> re-install pre-installed apps. But as I say above, I don't really agree with
>> the premise.
> I don't see how it's similar given that no wiping occurs? And that we
> actually have a plan for how it could be implemented (we still have no
> idea how to "wipe sensitive data" without wiping all data).
My thought was, if a user can debug pre-installed apps by deleting them
>>> debugging only enables debugging of apps installed after debugging was
>>> enabled. That would let the user turn on debugging, then install an
>>> app that they want to know how it works, and start debugging away.
>> This sounds similar to the "wipe sensitive data when enabling debugging"
>> approach. If we conclude that the additional exposure via the debugging
>> protocol is salient, then this might be a good solution, presuming users can
>> re-install pre-installed apps. But as I say above, I don't really agree with
>> the premise.
> I don't see how it's similar given that no wiping occurs? And that we
> actually have a plan for how it could be implemented (we still have no
> idea how to "wipe sensitive data" without wiping all data).
(and thus losing their local data) and then re-installing them, then the
implemented behavior is still "wipe-before-debug"; it's just that the
user "wipes" by "uninstalling". But if it's not possible to delete
pre-installed apps (that's disappointing), then it's moot.
> I still think that enabling debugging for all apps installed after the
> debugger was enabled brings us 90% of the value (developers can debug
> their own apps as they are developing as well as inspect other 3rd
> party apps that they install) at almost 0% of the cost (no additional
> risk of data leakage, relatively easy to implement).
better the pre-installed stuff is, the more true this gets --- that I
can't debug. That seems like a shame, given that (as I believe) the
additional exposure allowed by simply permitting anything to be debugged
is minimal.
Jim Blandy
Oct 1, 2013, 6:31:17 PM10/1/13
to dev...@lists.mozilla.org
One source of difficulty is that this conversation should be explicitly
enumerating what sorts of data one can get with the debugger that one
can't get anyway with the app's UI, using email for password recovery,
USB photo sync, and so on.
I am feeling like this unspecified data is serving the role of a MacGuffin:
In fiction <http://en.wikipedia.org/wiki/Fiction>, a *MacGuffin...*
is a plot device <http://en.wikipedia.org/wiki/Plot_device> in the
form of some goal, desired object, or other motivator that the
protagonist <http://en.wikipedia.org/wiki/Protagonist> pursues,
often with little or no narrative
<http://en.wikipedia.org/wiki/Narrative> explanation as to why it is
considered so important. The specific nature of a MacGuffin is
typically unimportant to the overall plot.
but it's probably 2:3 that I'm just unimaginative or ill-informed.
So, what are they? Not photos. Not passwords. Presumably not text
messages, if we've got a back-up-my-text-messages app we can install.
etc. Let's get them down, so we can think in concrete terms.
enumerating what sorts of data one can get with the debugger that one
can't get anyway with the app's UI, using email for password recovery,
USB photo sync, and so on.
I am feeling like this unspecified data is serving the role of a MacGuffin:
In fiction <http://en.wikipedia.org/wiki/Fiction>, a *MacGuffin...*
is a plot device <http://en.wikipedia.org/wiki/Plot_device> in the
form of some goal, desired object, or other motivator that the
protagonist <http://en.wikipedia.org/wiki/Protagonist> pursues,
often with little or no narrative
<http://en.wikipedia.org/wiki/Narrative> explanation as to why it is
considered so important. The specific nature of a MacGuffin is
typically unimportant to the overall plot.
but it's probably 2:3 that I'm just unimaginative or ill-informed.
So, what are they? Not photos. Not passwords. Presumably not text
messages, if we've got a back-up-my-text-messages app we can install.
etc. Let's get them down, so we can think in concrete terms.
0 new messages