+1 On Wed, Sep 10, 2014 at 5:17 AM, Paul Theriault <[email protected]> wrote:
> > On 10 Sep 2014, at 6:49 am, Jared Hirsch <[email protected]> wrote: > > > On Sep 9, 2014, at 1:31 PM, Jan Jongboom <[email protected]> wrote: > > > >> Well you need to enforce PIN because otherwise everyone who finds your > phone can grab all the data, or you should wipe it out whenever someone > enables that menu but you don't want that either I'd say. > > > > Actually, I think we're fine here - I don't see how this differs from > the threat mentioned already. > > > > If an attacker finds your phone, then presumably you have lost it. In > that case, you can use FMD to lock or wipe it remotely. > > If you actually set up FMD. If it has battery. If it has network > connectivity etc. > > > > I'm specifically suggesting that we don't need the "developer PIN", but > maybe you're referring to the lockscreen PIN? I definitely do think the > users should have their lockscreen PIN enabled ^_^ > > Yeh I agree that is confusing in the doc - we talk about a developer pin > code which is kept in sync with the lockscreen passcode. Overly complex i > think. It should just BE the lockscreen passcode. > > > > >> > >> On Tue, Sep 9, 2014 at 10:05 PM, Jared Hirsch <[email protected]> wrote: > >> Hi Paul, > >> > >> Nice work on the proposal! I would love to see us lower the barrier to > hacking on Gaia, I have some feedback below. > >> > >> BTW, I work on Gaia stuff for Cloud Services; this includes Firefox > Accounts, Find My Device, and prototyping work for backup/restore (though > it seems other people are working on this independently, too). I'm very > happy to discuss user/device security and user identity any time. I'm > usually in #gaia during Pacific business hours. > >> > >> On Sep 9, 2014, at 5:16 AM, Jan Jongboom <[email protected]> wrote: > >> > >>> On Monday, September 8, 2014 11:20:02 AM UTC+2, Paul Theriault wrote: > >>>> > >>>> The challenge we had when talking through this situation previously > was that its difficult to distinguish between the device's owner & someone > who has just found your phone, and wants to take advantage of developer > mode to compromise your phone and/or data. > >> > >> Find My Device allows users to remotely lock or wipe a lost device. It > shipped in 2.0. > >> > >> It seems to me that FMD takes care of this particular threat (malicious > person compromises lost device). > >> > >> So, maybe the user doesn't need to prove device ownership before > enabling certified debugging? > >> > >>>> > >>>> > >>>> > >>>> My team has been working on a proposal to remedy this situation: > >>>> > >>>> - Introduce an "os-developer" mode > >>>> > >>>> - Provide a way in FTU to have the user choose a lockscreen pass code > (not necessarily enabled, just chosen) > >>>> > >>>> - Add UI into developer settings to enable os-developer mode, which > requires the user to enter their passcode > >>>> > >>>> - When enabled, this mode allows installing and debugging certified > apps. When disabled, certified app installation & debugging is forbidden. > >>>> > >>>> - The user MUST set a lockscreen code during FTU for os-developer to > be available. If they do not, os-developer mode is disabled, and can only > be re-enabled through the process of a factory-reset then redoing FTU. > >>>> > >>>> - Note that the user do not have to ENABLE the lockscreen during FTU, > they just have to at least choose a passcode. But encouraging users to set > a passcode comes with its own benefits. > >> > >> The "developer PIN" concept and UX seem quite complex. > >> > >> What if we just add an "enable certified app debugging" checkbox to the > developer menu? > >> > >> The two goals in the linked google doc are (1) manage security risk > from lost devices, see my FMD comments above; and (2) give users full > access if they want to hack on Gaia. I think my counterproposal here > enables (2) with a lot less work, and reduced barrier to user > experimentation (no passcode, no need to factory reset if you didn't set a > flag during FTU). > >> > >> Cheers, > >> > >> Jared > >> > >> > >>>> > >>>> > >>>> > >>>> Pros: > >>>> > >>>> - Allows a way to enable developing of certified apps & Gaia hacking > on production, unrooted phones while protecting the user's data > >>>> > >>>> > >>>> > >>>> Cons: > >>>> > >>>> - A user must set passcode at FTU (and remember it!), else they wont > be able to use this mode without a factory reset > >>>> > >>>> - In the past there has been pushback on having passcode selection in > FTU > >>>> > >>>> > >>>> > >>>> There are a lot of other details and considerations, but I'll keep it > short(er) for now to start discussion. Does anything think this is a useful > change or is there a better way to enable certified app debugging, whilst > protecting user data? If you are interested, there is a more detailed > proposal here: [1] > >>>> > >>>> > >>>> > >>>> Thoughts & suggestions welcome. > >>>> > >>>> > >>>> > >>>> - Paul > >>>> > >>>> > >>>> > >>>> [1] > https://docs.google.com/a/mozilla.com/document/d/11Q1_fj2nKciVyG2PdGH_LuiH09BhZJKzFjBuIcaHKqs/edit# > >>> > >>> Wow, interesting catch. I alwasy assumed that it was not possible to > install certified apps on a non-rooted phone. So yeah, any way we can make > this possible on non-rooted phones will get applause. > >>> > >>> Pin code sounds like a proper way of enabling this on consumer phones. > >>> _______________________________________________ > >>> dev-b2g mailing list > >>> [email protected] > >>> https://lists.mozilla.org/listinfo/dev-b2g > >> > >> > > > > _______________________________________________ > > dev-b2g mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-b2g > >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
