The Customizer is not very discoverable right now, so to make it more visible, we will build a launcher app for it. This will appear on the Homescreen as a “Customizer” app. The user will see a list of installed apps when this app is opened. The user then selects an app, and the app is opened, then the Customizer along with it.

Paul, Fabrice, we want to be able to enable developer mode from within this app when it's launched, or at the very least from within the Settings app. I recall a discussion that we can't enable developer mode on-device, probably for security reasons, so we instead opted to add the toggle to WebIDE. Is there no way we can put this setting somehow into the Settings app?

We decided to not have a setting (and thus no access from the settings app) to mitigate the risk of someone turning on dev mode quickly when borrowing a phone, and then installing a certified app etc. So I don't think we can provide that by simply launching an app either. I think the customizer app should just display some help content explaining how to turn on dev mode.

(In reply to Fabrice Desré [:fabrice] from comment #2) > We decided to not have a setting (and thus no access from the settings app) > to mitigate the risk of someone turning on dev mode quickly when borrowing a > phone, and then installing a certified app etc. So I don't think we can > provide that by simply launching an app either. > > I think the customizer app should just display some help content explaining > how to turn on dev mode. Note there is no additional risk to providing an app for enabling developer mode on a phone which is already root enabled. (Since obviously the necessary preference can be flipped anyways). Does that help your use case Doug? Maybe we can do something in the settings app based on the android ro.secure property? BTW is there a separate preference for developer mode? (I mean separate to devtools.debugger.forbid-certified-apps)

(In reply to Paul Theriault [:pauljt] from comment #3) > Note there is no additional risk to providing an app for enabling developer > mode on a phone which is already root enabled. (Since obviously the > necessary preference can be flipped anyways). Does that help your use case > Doug? Maybe we can do something in the settings app based on the android > ro.secure property? I'm a bit out of my depth here. I don't think that Gaia has any way of retrieving the "ro.secure" setting, so I'm not sure how we would make use of anything like this. Do you have any suggestions? > BTW is there a separate preference for developer mode? (I mean separate to > devtools.debugger.forbid-certified-apps) Yes. It's 'dom.apps.developer_mode'. When we toggle this, we also have to temporarily enable 'network.disable.ipc.security' until we have a better fix for bug 1150106.

(In reply to Doug Sherk (:drs) (use needinfo?) from comment #4) > (In reply to Paul Theriault [:pauljt] from comment #3) > > Note there is no additional risk to providing an app for enabling developer > > mode on a phone which is already root enabled. (Since obviously the > > necessary preference can be flipped anyways). Does that help your use case > > Doug? Maybe we can do something in the settings app based on the android > > ro.secure property? > > I'm a bit out of my depth here. I don't think that Gaia has any way of > retrieving the "ro.secure" setting, so I'm not sure how we would make use of > anything like this. Do you have any suggestions? My thought was that we would just do something in Gecko. I.E if the device is root enabled, then we can then choose to mirror the pref in a setting, which in turn can then be shown in the developer menu. In terms of how to do that, I assume maybe something in the file where we create the mirroring of gecko prefs to settings. Specifically see this line, which already does things based on android properties e.g: http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/settings.js#335 Basically we would implement similar logic, except based on the android property of ro.secure. (1 means rooted, e.g: shell@aries:/ $ getprop ro.secure 1 > > > BTW is there a separate preference for developer mode? (I mean separate to > > devtools.debugger.forbid-certified-apps) > > Yes. It's 'dom.apps.developer_mode'. When we toggle this, we also have to > temporarily enable 'network.disable.ipc.security' until we have a better fix > for bug 1150106. Does toggling dom.apps.developer_mode automatically flip the prefs for allowing the debugger to connect to all apps? I assume not? All I'm thinking is that when we dynamically add our toggle code to the settings app in the developer section based on the ro.secure, we probably want to enable flipping all prefs that developers might need (devtools.debugger.forbid-certified-apps & devtools.debugger.forbid-certified-apps.discard-source) Maybe devtools people can better advise here - I'm just thinking that if you have developer mode enabled, you probably want to be able to connect to things like the system app so you can debug interactions etc. Of course if the device is rooted, a developer can stop b2g, change the pref and restart, but just a thought to make life easier.

Needinfo myself for comment 5.

Paul: Fabrice, Justin, Freddy and I met to talk about this. Here's the plan that we came up with: * Mirror dom.developer-mode.enabled pref to a setting * Expose dev mode as a `navigator` feature * Customizer Launcher, Sharing, Hackerplace will check for the feature ** If feature doesn’t exist, dispatch activity to Settings app to enable dev mode ** Settings app will handle an activity to enable dev mode, by presenting a nice dialog explaining the risks to the user How does this sound to you?

(In reply to Doug Sherk (:drs) (use needinfo?) from comment #7) > Paul: Fabrice, Justin, Freddy and I met to talk about this. Here's the plan > that we came up with: > > * Mirror dom.developer-mode.enabled pref to a setting > * Expose dev mode as a `navigator` feature > * Customizer Launcher, Sharing, Hackerplace will check for the feature > ** If feature doesn’t exist, dispatch activity to Settings app to enable dev > mode > ** Settings app will handle an activity to enable dev mode, by presenting a > nice dialog explaining the risks to the user > > How does this sound to you? Not great, to be honest. I'm not sure how you got to this proposal since I wasn't in the discussion but this is significantly _less_ secure than just mirroring the dom.developer-mode.enabled preference to a setting, which I said above was unsafe, unless the device is already rooted. (web activities don't support authentication in either the initiating page or the handler. Any web page could initiate the web activity to encourage the user to disable the security on their phone). What I'm getting at, is that this "feature" is basically "turn-of-all-the-security". It would be quite unsafe to use any phone that had this mode enabled. It only really makes sense for a developer device for which the user is never going to put any sensitive information, (and even then the device presents a risk to the internal network if it is used to randomly browse the web). I'm finding it very hard to respond to this, since I really don't know what the ultimate goal for developer mode is? Are you expecting this to be a feature that is possible to enable on production devices? I assume not. I assume this is this a feature that will be available only on developer builds of Firefox OS. In which case, maybe you do something like two preferences: dom.developer-mode.allowed (default false, NOT mirrored in settings) dom.developer-mode.enabled (default false, mirror in settings, only if dom.developer-mode.allowed==true ) Then you do your web activity approach (assuming the settings ignores the activity if the setting is not present). But then we are basically back to square one in this bug. So I'll try to reach out via email to progress further.

Just a note that I saw in scrollback from Freddy that in your discussion the idea was that developer-mode was ONLY available after the full devtools mode was enabled (i.e. After "Reset and Enable Full DevTools" from the developer menu, and the device has gone through factory reset to flip the devtools.debugger.forbid-certified-apps preference). If that is in fact the proposal (you didnt mention this in comment 7) I would be fine with this. So basically to summarize what the security model would be: - developer mode is disabled an not available on production devices by default - production devices can get full devtools access using "Reset and Enable Full DevTools" from the developer menu - if full devtools access is enabled, developer mode is enable-able from the setting app (and its fine to have a web activity so that apps can link to the UI for enabling this feature). I still think you'll need a second preference here since there are 3 states for developer mode: - forbidden (and disabled of course) - allowed but not enabled - allowed and enabled BTW the has-feature thing seems redundant to me. Why wouldn't you just have Customizer Launcher, Sharing, Hackerplace check the setting? Im not very familiar with the "feature" api though...

(In reply to Paul Theriault [:pauljt] from comment #9) > Just a note that I saw in scrollback from Freddy that in your discussion the > idea was that developer-mode was ONLY available after the full devtools mode > was enabled (i.e. After "Reset and Enable Full DevTools" from the developer > menu, and the device has gone through factory reset to flip the > devtools.debugger.forbid-certified-apps preference). If that is in fact the > proposal (you didnt mention this in comment 7) I would be fine with this. That's correct, this is the way to turn on dev-mode on device (the other way being from webide when asking for "full dev mode powers"). > So basically to summarize what the security model would be: > > - developer mode is disabled an not available on production devices by > default > - production devices can get full devtools access using "Reset and Enable > Full DevTools" from the developer menu > - if full devtools access is enabled, developer mode is enable-able from the > setting app (and its fine to have a web activity so that apps can link to > the UI for enabling this feature). > > I still think you'll need a second preference here since there are 3 states > for developer mode: > - forbidden (and disabled of course) > - allowed but not enabled > - allowed and enabled > > BTW the has-feature thing seems redundant to me. Why wouldn't you just have > Customizer Launcher, Sharing, Hackerplace check the setting? Im not very > familiar with the "feature" api though... My proposal was to expose the dev mode state read-only through the navigator.hasFeature() api (which is privileged only) to let apps that need dev-mode have the opportunity to display something useful to the user and trigger the settings activity to the right panel. Mirroring the pref to a setting means that any app that has settings access can toggle dev mode which seemed more dangerous to me. We can implement the 3-state if you really wish.

So just to clarify be based on irc conversations with fabrice: We will: * Expose dev mode as a `navigator` feature * Customizer Launcher, Sharing, Hackerplace will check for the feature ** If feature doesn’t exist, dispatch activity to Settings app to enable "Enable full devtools mode" (which requires factory reset) ** Settings app will handle an activity to enable dev mode, by presenting a nice dialog explaining the risks to the user We will NOT: * mirror dom.developer-mode.enabled pref to a setting, since then any app with settings access could disable security That sounds fine to me. (lets ignore my 3-state approach)/

Firefox OS is not being worked on