Debugging is how many people are going to learn how to write apps; think about the role of "view source" in introducing people to web technology. And it's consistent with our goal of putting the user in charge of their own device. I think we should treat all apps as debuggable, on any device.

As far as non-developer users are concerned: debugging is turned off by default. You need to go (rather deep) into the settings and explicitly turn debugging on, before the server begins listening. There is no reason a non-developer would ever need to enable debugging (and we should ensure this remains true). So I don't see the risk to non-developer users.

We should protect developers, too. If we require users to set a passcode on their phone in order to enable debugging, and turn off the debugging server automatically after (say) two hours of inactivity, then it seems to me the risk to developers is rather small.


I also don't think creating restrictions as to which apps the user can debug is very meaningful, at a technical level.

The debug server now listens on a Unix domain socket, which means its name is in the filesystem. The kernel enforces the usual filesystem permissions when something tries to connect to it. If we make the socket readable and writable only to the main B2G process's user, then any process capable of connecting to the debug server is equally capable of using the 'ptrace' system call (or others) to directly read and write the main B2G process's memory and registers.

So while it makes sense to pay close attention to which code runs as that user, we should remember that any code that *does* run as that user has full control over the phone. Trying to enforce finer-grained distinctions will not keep attackers out, but will make the phone more cumbersome to hack on. That seems like an "own goal".

_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to