On 10 Sep 2014, at 12:25 am, Dale Harvey <[email protected]> wrote:
> I am likely ignorant about the reasoning behind some of the security > decisions made for our device, however I have been fustrated by them, in > previous lives doing android and ios development I have found fxos fairly > similiarly fustrating as ios between different areas, and android > comparatively a huge amount easier. > > Its possible I am entirely off base and there are reasons we cant make life > this easy, but at least having them explained would maybe help ease the > fustration. > > With android development, I get my device (user build), enable the developer > menu (it used to be tap a button 7 times, now its shake it I think), turn on > debugging, when my phone connects to my computer I accept a prompt that says > that computer is allowed to access my device, at that point I have unfetered > access and adb continues to work no matter if my screen is switched off or > restarted or is in various other states in which we lose adb access. This is useful feedback but i think adb access is separate to the discussion here. The only reason to prevent new ADB connections from a security perspective is when the device is locked with a passcode, so anything else we should consider a bug and fix. Which I think would alleviate most of your pain points above. But that is a little separate to what I was proposing. What I am talking about here is access to debug Firefox OS itself, with requiring the phone to be rooted, but whilst also protecting user data. To debug the main process or certified apps, you currently you need root access, which means you have to have access to, and flash a build with root enabled. Im trying to improve this situation, by providing a way to get this access, but while also protecting the user data which is only protected by virtue of root access not being available. > > If my phone has a pin then the only way to get adb access is to get access to > my device unlocked, at that point all bets are off which I think is entirely > reasonable. > > Even in development builds but particularly with user builds adb access to > the device is extremely flakey and I routinely have to go into fastboot mode > to reflash my entire device, like if I push a syntax error in the system app > in a user build then adb will never be reenabled. > > Having to do a factory reset, or as was mentioned in the google doc sign up > to some firefox online account seems straight up developer hostile to me. I don’t see why? Enabling this level of debugging is equivalent to rooting. Im struggling to see how providing a way for developers to have effectively root access production phones MORE hostile than a situation where its currently not possible. AFAIK Android does exactly the same thing btw, with "fastboot oem unlock” when rooting. > > On 9 September 2014 15:53, Stéphanie Ouillon <[email protected]> wrote: > Hi, > On 09/09/2014 15:00, Kartikaya Gupta wrote: > > On 8/9/2014, 5:20, 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. > > > > Thanks for pointing this out, as it is an important distinction that is > > the heart of the problem. > > > >> Cons: > >> - A user must set passcode at FTU (and remember it!), else they wont > >> be able to use this mode without a factory reset > > > > When they do a factory reset, is there a mechanism available for them to > > backup and restore their data? (I admit I'm unfamiliar with what the > > average user would use for this - a quick search online seems to > > indicate you have to use adb to do this). If there is a mechanism, what > > prevents the "malicious person who just found your phone" from doing > > this data backup and stealing your data? Is this somehow a less-bad > > scenario than the malicious person being able to enable os-developer mode? > > Definitely not, since what we want to achieve ultimately is protecting > the user's data. But I don't know the details of the possible solutions > for the backup and restore mechanism, so I'll let better informed people > answer this. > > > > > I just worry that forcing a factory reset in this scenario is going to > > place a big barrier to allowing our users to organically grow from > > "users" to "webmaker". That is, they will find it much harder to learn > > and hack their phones in ways that we should be should be actively > > encouraging. > > > > This 'os-developer' mode is meant for people who want to write and debug > certified apps. This factory reset scenario won't impact web app > developers (privileged, web). Are would-be Gaia developers the target > you're concerned about? > > > > Seeing as the heart of the problem is distinguishing the device owner > > and Mr. Malicious, perhaps we could ask for some piece of information > > the device owner is much more likely to have. The SIM PIN might be such > > a thing, or maybe some other unique identifier that comes with the phone > > but isn't physically present or accessible on the handset itself. > > Since the SIM can be removed and replaced by the attacker's SIM, it > doesn't look like a right candidate. That's why we consider the device > PIN code instead. > The issue we're hitting is always the same: how to make sure it's the > actual owner of the device who is initializing _first_ the > authentication service (setting a PIN code, synchronizing to a backup > service, etc) while protecting the data. Hence the reset factory solution... > > > Stéphanie > _______________________________________________ > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
