On Thu, Sep 05, 2013 at 06:34:44PM +0530, Nitesh Bharadwaj wrote: > Key feature updates: > > 1) Bundled Zxing QR scanner app with the our app: > The original code hosted by zxing had to be modified slightly in order to > bundle it. Some changes to not to allow our app from being the default > barcode scanner and some changes to the deprecated methods used there. End > result - a repository resembling the original repository has to be > maintained in order to allow building from source code. Don't know anything > about copyrights etc.
Fork first, ask questions later? Please check the license. If it's GPL or ASL (or something more liberal e.g. 3 clause BSD), we're fine. > > 2) QR to bootstrap Wi-Fi direct and bluetooth: > I've followed similar methods in both Wi-Fi direct and bluetooth with the > ascending hierarchical order > - A button (to start exchange process) > - Start a server on each of the individual mobiles > - Generate QRcode of MAC+IP+port+WPA password in case of wifi-direct and > only MAC in case of bluetooth > - One of the device-user clicks on 'scan QR' button and scans QR from other > mobile > - Close server on one mobile (on which user has clicked 'scan-QR') > - Initiate connection to the other mobile > - Once connected, exchange noderefs > > In case of Wi-Fi direct, the user interaction is complete as soon as he/she > scans the QR Cool. > In case of 'previously unpaired' bluetooth devices, qr scan results in > popping of pairing notifications on both mobiles. Each of the user have to > accept the pair requests from their notification bars. Only then a > connection is established Ugh. > > I can try to avoid the above process by using reflections and messing with > android but can't guarantee if it is possible. If this is done we can also > generate a random key when starting bluetooth server and include it in QR. > > - After noderef exchange is complete, a text box containing complete > noderef pops up. User needs to manually accept the received reference here The user is not going to check a full noderef. You need to think about what actually needs checking. IMHO the main thing is the node name. Possibly in the long run we could include a photo and check that too. > > 3) Nfc to bootstrap: > Same as above except that the message containing MAC etc. is also encoded > as an NDEF message if the mobile has nfc adapter. > Instead of scanning, the two mobiles need to be brought back to back. The > default android nfc animation starts asking user to click to beam content. Nice. > > The wikipedia page suggests that nfc exchange can be eavesdropped. > So, theoretically, someone can listen to the broadcast and connect to our > mobile before our peer mobile connects to us and pulls our noderef. Though > the two mobiles need to be close to each other for nfc message exchange, it > can be eavesdropped from a distance of 5-10m with dedicated hardware as > mentioned in the following link: > http://en.wikipedia.org/wiki/Near_field_communication > > In this respect, bluetooth is more secure as it requires us to click on > pair button after nfc beaming Why is that more secure? Can we detect when there are two responses? > > Boils down to #easytouseislesssecure Why does the user clicking a button make any difference? Even a QR can be spied upon. > > Work to be done: > - Testing and fixing bugs especially related to closing the connections > properly > - Displaying messages to the user on a message text box regarding the > status of our app (connecting, connected, transferring, success, failure > ...) > - Adding android application record to the ndef message. This allows the > other mobile to redirect to our playstore page (when we have one) if app > isn't previously installed > - Exchange over internet(?) > > App: > https://github.com/NiteshBharadwaj/Freenet/tree/master/src Sounds good. Don't have time to review.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
