1176003 - Allow enabling full-devtools & developer mode on ROOTED devices without factory reset.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Developer Tools, enhancement)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

For rooted devices, we can't protect data from local attackers by restricting devtools & developer mode. So at the moment on a rooted device you can enable devtools/developer mode with WebIDE but on the device itself. 

What I propose is that we add code to detect if the phone is rooted. And if so, then for the "Factory Reset and Enable Full Devtools" button would just toggle the specific prefs, without a factory reset. Probably both settings app and gecko changes required here (settings app to remove the facory reset references and gecko to detect the root state, and i guess populate a setting or something so gaia knows what to show).

Comment 1

[Paul Theriault [:pauljt] (no longer reading bugmail)]

[Blocking Requested - why for this release]:

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

They "why" being: this will greatly improve usability for foxfood program.

Comment 3

[Mahendra Potharaju [:mahe]]

Not blocking 2.5 release. Marked as a feature.

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Developer mode controls more things than just access to extensions.  It also enables full DevTools access.

Bug 1196963 seems to only affect extensions, so I believe this bug is still valid.

Comment 6

[kang hee don]

How can I detect if the phone is rooted?
Is there any component or API?

If there is no way to detect status of root.
Could you advise me How to implement that?

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

J. Ryans, you can set enables full DevTools access in the Developer setting without having to factory reset.  I believe that we're considering removing the Full DevTools switch.

In regards to determining if the phone is rooted:
adb shell cat default.prop
* ro.debuggable =1  - means that you have at least su capablities ( ie userdebug variant )
* ro.secure=0 - means that the phone is rooted

Comment 8

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #7)
> J. Ryans, you can set enables full DevTools access in the Developer setting
> without having to factory reset.  I believe that we're considering removing
> the Full DevTools switch.

It's been a little while since I've checked a device, but the code seems mostly the same:

https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/panels/developer/developer.js#L126-L168

The "full DevTools" button in Settings calls `factoryReset`.

You are only able to set full DevTools without a factory reset if you (1) have a rooted device and (2) change it from WebIDE / edit a pref manually with ADB.

The purpose of the "full DevTools" button from Settings (that does factory reset) is to allow *un*rooted devices to have some way of getting to this mode, since it's not possible otherwise.  So, this bug still seems valid, since we could simplify the situation for devices that *are* rooted by possibly not requiring the factory reset.

Why do you want to remove the full DevTools switch?  Once again, it does more that just allow add-ons.  It enables debugging the Gaia apps that ship on the devices.  Without full DevTools mode, you can only see apps you have installed yourself, so most of the phone can't be inspected.

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

The main reason is because to remove the devmode is that it does the factory reset wiping out the content of the device.  Production devices shouldn't have this option and it's confusing to end users who aren't interested in web development.  ( see bug 1177002 ) It should be removed for the production=1 builds, IMO.  Why bother having the options if people don't bother to read what the warning states and then wipes their device?  Esp when you can go through manually on the phone and enable all those options without wiping your data and resetting the phone?  Wouldn't also setting those phones become a more security risk if it was out in production?  I would be surprised if any carrier would end up leaving this option in anyhow for a variant=user build.

There were additional patches that allow for the extensions and there have been additional options in the developer such as "Gaia Debug Traces" that allow for debugging.

Theoretically we have moved to a position where we could remove the option as it only short cuts a few items that we could have in an engineering build.

Only the Nexus 4/5 devices are currently running as VARIANT=user which can't gain root access.  The Aries and the flame devices that we provide pushes a userdebug which allows for root access by either adb root or adb shell then su.

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

BTW, see https://discourse.mozilla-community.org/t/backup-the-phone-with-adb-permission-denied-or-adb-root-is-unavailable/6137/2

Clare has a user build and using that switch doesn't allow her to see WebIDE.  For nonrooted phones, according to her, it doesn't work as advertised.

Comment 11

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #9)
> The main reason is because to remove the devmode is that it does the factory
> reset wiping out the content of the device.  Production devices shouldn't
> have this option and it's confusing to end users who aren't interested in
> web development.  ( see bug 1177002 ) It should be removed for the
> production=1 builds, IMO.

The entire purpose of "reset to full DevTools" was *for* it to be used on production, end user devices so they could become "fully DevTools unlocked" even if they can not be *rooted* because of carrier / OEM restrictions.

It sounds like a larger discussion is needed, maybe on the mailing list.  It makes little sense to disable it on production builds, because that is the target market of the feature.  Now, if people just think it's bad entirely, it could be removed, but that means you are heavily restricting debugging of the device.

When I read bug 1177002, it sounds like confusion goes away if the reset requires a PIN to be entered if it exists.  Bug 1188541 was filed to do this.  It should like it would help here.

> Why bother having the options if people don't
> bother to read what the warning states and then wipes their device?  

I believe most of the confusion in bug 1177002 comes from the Spark program directing everyone to enable full DevTools without making the risk clear.

We should find some way to make it more obvious.

> Esp when you can go through manually on the phone and enable all those options
> without wiping your data and resetting the phone?

That is not true.  It is not possible to enable full DevTools without setting a pref.  If you phone cannot be rooted, you have no way to set a pref.  That is the entire reason for the reset to full DevTools: it sets a pref for production users who have no other secure way to do so.

> Wouldn't also setting
> those phones become a more security risk if it was out in production?  I
> would be surprised if any carrier would end up leaving this option in anyhow
> for a variant=user build.

We spent a long time talking to Paul Theriault about the security risks before adding this.  The reason it wipes your device is so we can avoid exposing private data in case of some bystander taking your device, enabling full access, and pulling data.  Since the device is wiped by this feature, there is no security risk.

If carriers disable this feature, then that is unfortunate, and they are limiting our ability to offer a fully debuggable phone to all users.

> There were additional patches that allow for the extensions and there have
> been additional options in the developer such as "Gaia Debug Traces" that
> allow for debugging.

The original meaning of "reset to full DevTools" *only* enabled additional debugging of the apps not installed from WebIDE (so, all Gaia, Marketplace, etc.).  During the Spark effort, this switch was "abused" / extended to also set more things about add-ons.

I do not personally care about the add-ons part of it.  Maybe that should be reverted?  I am only trying to describe the purpose of the original full DevTools ability which has nothing to do with add-ons.

> Theoretically we have moved to a position where we could remove the option
> as it only short cuts a few items that we could have in an engineering build.

Aren't engineering builds rooted?  This feature makes sense only for end users with devices they cannot get root for.

It does not make sense for nearly any MoCo Gaia developer, as I would strongly suspect they have a rooted device.

> Only the Nexus 4/5 devices are currently running as VARIANT=user which can't
> gain root access.  The Aries and the flame devices that we provide pushes a
> userdebug which allows for root access by either adb root or adb shell then
> su.

As above, this feature is meant for end users with devices that can't gain root access to.  You seem to be thinking it is intended for MoCo Gaia developers, but that is incorrect, assuming their devices have root access.

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #10)
> BTW, see
> https://discourse.mozilla-community.org/t/backup-the-phone-with-adb-
> permission-denied-or-adb-root-is-unavailable/6137/2
> 
> Clare has a user build and using that switch doesn't allow her to see
> WebIDE.  For nonrooted phones, according to her, it doesn't work as
> advertised.

I disagree with your interpretation.  Claire says: "I see an option "Unlock privileges"> "Unrestrict dev tools" = false
But when I click on this option to enable it, a big warning ask me "erase all my data and to a reset" so I didn't"

So, they chose not to use the feature because of the warning.  Thus, I would assume it still works fine.  This person just chose not to use it.

Comment 12

[BMO Automation]

Firefox OS is not being worked on