On 10 Sep 2014, at 7:16 pm, Stephanie Ouillon <[email protected]> wrote:
>> >> Other options for user authentication I had been thinking about were: >> >> - pairing the phone with the computer it is going to be plugged into - maybe >> via adb (maybe by use of 842747) or wifi (with upcoming wifi debugging) >> - Ship phones with “developer NFC sticker” - basically an NFC tag which is >> proof of ownership (only works for NFC devices obviously) >> - Pair the phone with a computer via bluetooth during FTU. Access to >> developer options later requires you to pair to the computer again >> > > I don't see how 1) solves the case when a user has never paired his/her > device with > a computer and the attacker does it. Or do you mean doing that during FTU? Yeh I meant all during FTU as an alternative to pin code/password. > 3) solves this issue, but the drawback is that you don't necessarily have a > computer > nearby when you first start your phone. > > For 1) and 3), considering it solves the issue of an attacker being able > to pair first the stolen phone to his/her own computer, what happens if you > want to help somebody debug his/her phone, or use a device that you don't > necessarily own (I'm thinking about the context of a debugging session, > or workshop, or hackaton, or class...)? > Maybe an option you could set (while the phone is connected on the > legitimate paired computer) such as "enable pairing with one more device", > would solve that. > > > > _______________________________________________ > 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
