On Fri, Dec 21, 2012 at 10:51 AM, John McLear <johnym...@gmail.com> wrote: > Kristopher I think a separate thread should be created if you want to > address that issue specifically. > > Łukasz Sanek the phone has to be turned on "IE powered on" with the power > button before NFC is enabled, so the exploit you mentioned is not actually > possible, but your point is still valid however like with Kristopher's > concern I think that is an issue for another thread. Devil's advocate: under what use case does a user carry around a phone that is powered off (if the battery is not dead)?
> Ducz thanks for your input and thoughts. Perhaps your organization might > also be interested in sponsoring some of the development. > > So as there has been no major objection I will go ahead putting together a > draft proposal. I think its a bad idea prima fascia. I think its they are data ingress and data egress points, and that non-essential transfer/traffic could occur without the user's knowledge. But I'd need to see the details to be certain of my position. Put another way, don't worry about the 'good' use cases. Think about the 'bad' use cases, and what folks like Zdziarski, Miller, Zovi are going to do. > I will also reach out to the NFC Forum and Google to see if they would > consider sponsoring the development. > > Would it be possible to look through previous commits to the master branch > to see who wrote the bulk of the unlock functionality? I think grabbing a > few email addresses from there and bumping them to see if they would be > interested would be the best practice from a security perspective as they > should already be familiar with the code. Thoughts/opinions on this? If > anyone can do my homework and grab some email addresses for me that would be > fantastic :) Yes, the previous commits are available on the web. See, for example, https://android-review.googlesource.com/. As you probably know/realize, its hit or miss whether someone will write you back after you contact them. Don't confuse Functionality with Best Practices. A lot of functionality violates best practices. For example, writing unencrypted data to an SD Card. But if you did not do it (or make the choice available), folks would want to hang you from a yard arm. As another example, some would consider using Android Beam to send unencrypted data to an non-authenticated handset a violation of best practices. Also see http://source.android.com/source/submit-patches.html. > Final call for objections / input please people, I don't want to go down > this road only to be roadblocked by someone in the Android team. You don't need AOSP/Google permission for this endeavor. As Kris stated, a mod (e.g., Cyanogen or Clockwork) may be interested in the work if mainline is not. Jeff -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to android-security-discuss@googlegroups.com. To unsubscribe from this group, send email to android-security-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
