Reply

srowen wrote:

It doesn't solve the problem of writing contacts though. If you farm that out to a separate app, then it has to able to accept contact information from another app, to write. That other app didn't ask for write permission though. This is a sort of problem with per-app permissions but the ability for apps to cooperate via Intents.

An application that receives an Intent and blindly writes a contact is absolutely a bad idea. The solution to this would be not to use Intents to send the data back.

Specifically, you'd need to use android.os.Binder, probably but not necessarily by using AIDL to generate the (synchronous, IPC) interface. (It actually seems like it'd be easier to implement the interface directly, but since there is a standard mechanism...) I think, but am not certain, that this means the ZXing-library-app would need to extend Android.os.Service.

My original reply had a sketch of a secure request-reply protocol using Intents and the fact that

IBinder/Binder objects [can] be used as a unique identity (to serve as a token or for other purposes) that can be managed across processes[,]

but as it turns out this is probably not a good idea, for at least two reasons:

• Both scanning and displaying are inherently synchronous operations, and a calling application is going to sit around twiddling its thumbs in any case; one might as well use synchronous IPC.
• Unexpected failure of the scan/display app will result in the calling application twiddling its thumbs forever.

(Of course, it's probably safe enough to use Intents for display alone: one wouldn't be expecting any data back, so failure is uninteresting, no? Admittedly I haven't thought that one through.)

I think the idea of separating the apps is interesting. You're asking users to separately download another app, or else forgo this functionality. That's a cost. But it does have the benefit you suggest.

Hmm. I suspect (but can only conjecture) that this cost would be mitigated slightly if you were to package "Barcode Scanner" as a library, like Radar, instead of as an app in and of itself. Then just say 'this application requires the Barcode Scanner library, listed under Software Libraries' -- which, I note, everyone else is already going to have to say. Like that one Barcode Battlers game (or whatever it's called) already does.

This would also help users who have more than one ZXing-using application: only one copy of the library would be taking up valuable disk space. It might also encourage application writers by making them aware of the existence of a barcode scanner library qua library: at present there are only two software libraries at all, so there would be significantly fewer faces in the crowd against whom to stand out.

Zebra Crossing

... usually, in this context, spelled ZXing.

ZXing is, at its heart, a barcode scanner for mobile phones implemented in software. This is very useful to application writers: I believe ShopSavvy (mentioned previously) includes a copy of ZXing internally in order to scan barcodes. ZXing is also capable of creating barcodes that other devices can then read off of the phone's screen. It's a nifty library, with a lot of potential uses.

However, ZXing (named simply Barcode Scanner in the official standalone version on the Android Market) seems also to have aspirations of direct use as a social application. In at least the Android version of the app, code exists that will, at the request of another application, read one's contacts list and display a barcode on the phone's screen representing a contact's information.

This is not really a good thing, for several reasons.

It's not that the act of sharing contact information is inherently bad. Barcodes are probably a more secure method than most to do so, at that: they're relatively difficult to intercept from across the room, which isn't necessarily true of even encrypted Bluetooth. It even implicitly contains the promise of eventually being able to do so in a cross-platform way, so that iPhones and Android devices can share contact information with relative equanimity.

But letting a common library — which Barcode Scanner is — have access to contact information isn't really safe. It's possible that it could be tricked into returning contact information, or some other variant of a confused deputy situation. It doesn't appear to verify that the calling application has any sort of access to the contacts list, either.

Furthermore, seeing "read contacts, write contacts, full Internet access" in the permissions-request list — with no explanation given in the application description — should be setting off warning signals in the user's head, as it did mine: "wait, you want to do what?" I'm aware that the vast majority of users invariably ignore message boxes, but I'd really prefer they not have reason to do so.

This would all be easily resolvable simply by separating out the contacts-access code into a separate application from the barcode-reading/displaying library: the former would request and declare reading and writing of contacts, and the latter would have and need no permissions beyond camera access.

(In point of fact, as ZXing is open-source, I was able to browse the code and confirm that the potential security issues remain potential rather than actual. But I really shouldn't have had to.)