On Tuesday 25 Jun 2013 16:26:37 Nitesh Bharadwaj wrote: > On Sunday 16 Jun 2013 18:53:26 Nitesh Bharadwaj wrote: > > > On Sun, Jun 9, 2013 at 12:51 AM, Matthew Toseland < > > [email protected] > > > > > > > > > > The github link for android port under development and related > > testing is > > > > > https://github.com/NiteshBharadwaj/Fred-Staging-Android > > > > > > > > IMHO it would be best if we could have a common source code, and just > > have > > > > different scripts to build Freenet on different platforms. Whereas the > > > > above is definitely not forked from the main fred repository. Also it > > > > includes binaries in the repo, which is usually a bad thing. > > > > > > > Yes. I have changed the code structure with fred-staging as submodule. I > > > have a question. By common source code do you mean - > > > a) We have abc.java and abc_android.java for the files that are needed to > > > be changed. And the ant script chooses the files depending on platform. > > > b) abc.java contains code of all platforms. This is turning to be > > difficult > > > as we don't have compile time conditionals in java. #ifdef #ifndef etc. > > > c) If you mean point a) then that is same as having different source > > codes > > > at different locations?? > > > > I'd probably go for (a), yes. How much of the code actually needs a > > different version for Android? I mean, Android includes 99% of the Java 6 > > API, apart from the GUI stuff. Only one or two files use GUI stuff, so it > > should be possible to exclude that (it's only used by web pushing anyway)? > > > If db4o were to be replaced by db4o embedded, some portion of code might > vary depending on the availability of functions. Apart from that most would > remain unchanged
Hmmm, native queries might be a problem yes. However, we are planning to get rid of db4o. > > > > > > With respect to QR, I have cloned Operheim's implementation of > > > > > NoderefQRCode which is a plugin to freenet and can convert node > > > > references > > > > > into QR code and decode them back. > > > > > https://github.com/Thynix/NoderefQRCode > > > > > > > > > > Since, this part is already implemented by Operheim, I have just run > > a > > > > few > > > > > tests. > > > > > I tried to scan the generated QR using popular applications > > available on > > > > > google app store. It could decode correctly 7 out of 10 times while 3 > > > > times > > > > > it decoded a random number! > > > > > Using the original decoder (in NoderefQR), it gave similar results > > except > > > > > that instead of random number it ran into check sum exception once or > > > > twice. > > > > > > > > > > The basic problem I noticed is bigger the size of the string to be > > > > decoded, > > > > > the longer it takes (quite irritating) and more the chances of a > > wrong > > > > > decode. > > > > > > > > > > During the planning stage, we thought about using QR codes only to > > > > > establish Wi-Fi Direct connection between two mobiles. The actual > > node > > > > > references are exchanged via Wi-Fi direct. This seems a better option > > > > > compared to encoding whole nodereference in QR (We could provide > > multiple > > > > > options anyway). The high band-width during such transfer can also be > > > > > utilized for sneakernet support later on. > > > > > > > > Yes, or you will have to do some work on shrinking noderefs first. Let > > me > > > > know if this is a serious option, we have lots of ideas about it, but > > > > really IMHO exchanging via wifi direct is probably best. That can use > > NFC > > > > or Bluetooth for short range key exchange, or you could use QR codes to > > > > exchange a password to be used for wifi encryption. > > > > > > > > > > Specific Questions: > > > > > > > > > > 1) (Related to darknet support) On the main freenet node, should I > > let > > > > this > > > > > be an optional plugin or directly add options to fred-staging to > > > > > synchronize peers with its mobile node. > > > > > > > > I'm not sure. Probably best to make it part of fred. Certainly it > > needs to > > > > be integrated closely, e.g. we may want something on the Add a Friend > > page. > > > > > > > Ok. > > > > > > > > > > > > > 2) (Related to android port) db4o offers a package Db4OEmbedded and > > had > > > > > several positive reviews online. So, is it still necessary to rip out > > > > db4o > > > > > from fred? > > > > > > > > db4o will be removed from fred soon. So don't worry about it one way or > > > > the other. > > > > > > > > > > Suggestions and Comments are most welcome. > > > > > > > > > > Thanks for reading through! > > > > > > > > > > For more details related to project, please visit > > > > > http://niteshgsoc2013.blogspot.in/ > > > > > > > > > Thanks! > > > > > > > I will be focusing on making the required changes to fred on Add a Friend > > > page and work on the connection between mobile node and fixed node this > > > week. > > > > > > I think providing multiple options would be beneficial so that users can > > > choose depending on hardware > > > > > > Option1: > > > > > > A Wi-Fi direct (softAP on mobile node - stays active only until the > > noderef > > > is transferred to save battery) to legacy Wi-Fi connection (on fixed > > node - > > > assuming fixed node doesn't support Wi-Fi Direct although Windows 8 > > devices > > > now support) > > > 1) A way to transfer the WPS pass key auto generated by mobile node to > > > fixed node. > > > a) Typing in the passkey on fixed node > > > b) QR (assuming fixed node has webcam) > > > > Do it the other way around. Generate a QR on the fixed node and take a > > picture with the phone. > > > Ok. The user types in the pass key only for the first time during > connection establishing.. Usually the phone will have a camera, no? In which case a QR is a perfectly acceptable way to send the passphrase. However, as we discussed on devl, it may not be realistic, or appropriate, to have the node reconfigure the computer's network connections. Mostly the home node will be connected to a router (either wired or wirelessly), and the phone should connect to the home wifi via the router. In which case we will need to know which node the mobile node is associated with - there could be more than one on the LAN. (And authentication might be useful too). > > > > 2) I observed that one mobile node always generates the same pass key for > > > its softAP (Wi-Fi Direct) > > > a) Advantage: Transfer the pass key only once per mobile node it is > > synced > > > up with and remember for all future noderef sync ups. > > > b) Disadvantage: Security?? Some handshake to make sure that we are > > > communicating with right node or some crypto?? > > > > Hmmm, is that intended? You should talk to nextgens. > > > > > > Option2: > > > > > > A bluetooth connection between mobile node and fixed node to sync up node > > > references > > > > Some home nodes won't have BT. > > User would select one of the option depending on the hardware available to > him Possibly. Maybe easier to set up than wifi? > > > > > > > Option3: > > > > > > Only QR - Using the plugin implemented by Operheim to generate QR on > > fixed > > > node > > > > In which case you're just downloading the noderef as a QR? You would still > > need to be able to verify it. Anyway you'll need to be able to transfer > > data back to the node to finish setting up connections. So IMHO you need a > > wifi or BT link, no? > > This option is for home nodes with zero RF hardware (Wi-Fi and BT) and also > not connected to router which also acts as AP. In which case it's very unlikely that they have a webcam. Webcams are less common than wifi. > > The initial noderef transfer would take place when phone scans the QR. The > later on sync ups would happen when the mobile is connected to home node > via a USB? Exactly. The options are: 1) Connect via USB directly to the home node. 2) Connect to the home wifi network (NOT directly to the home node). The phone needs to know which node to connect to (there may be more than one). We probably want the home node to periodically broadcast a handshake; the phone should pick this up and send the noderefs, but it needs to authenticate the home node first. A QR code, generated by the home node to be seen by the phone, is probably the easiest way to set up the initial connection to exchange public keys. ("Associate your phone with your home node" or whatever). We will still want to manually confirm addition of any new connections from the home node. IMHO connecting directly to the home node via wifi is unrealistic, because if it breaks it may break the user's internet connection, it may get us labelled as malware, it requires administrator permissions; and tearing down the user's wireless internet connection temporarily is pretty anti-social too. Also, it would require using the command line; there are no suitable libraries for this. > > A more organised description about the possibilities that may arise: > > 1) A node might be connected via Ethernet connection to a Wi-Fi router. > We directly connect the mobile also to the router. Here encryption is > necessary as other nodes might be connected to the same router. Exactly. > > 2) The above node itself has WiFi connectivity. > a) We still connect to the Wi-Fi router and reuse the code for #1 > b) (Probable) We establish P2p between mobile and home node by Wi-Fi > Direct (softAP) and Legacy Wi-Fi connection while the node still maintains > internet connectivity through Ethernet > > 3) A node is without Wi-Fi hardware and is directly connected to LAN via > ethernet > a) So here, initial transfer would occur through QR. Later on, sync ups > occur whenever the mobile is connected via a USB > i) USB and Ethernet bridge and reuse code of #1 > ii) Plain USB data transfer through java code > b) If it has bluetooth hardware, use bluetooth based transfers Yes, except that if it's connected via USB you don't need a QR code. But we may not be able to tell that easily from software, so it may be simplest to have a QR-based "connect my phone to my home node" operation, during which we would need to have some sort of connectivity (either wireless or USB). > > 4) A node connected to LAN (say company LAN/ college LAN) and "has" Wi-Fi > hardware which is not being used > We use p2p WPA2 Wi-Fi Direct to WiFi here between softAP on mobile and > home node As I explained above, I don't think this makes sense. > > 5) For users who want to use bluetooth for transfers , bluetooth option. Yes, bluetooth is a reasonable option. > > IN BAND: > #1, #2a,#3ai. These methods are in band and definitely need encryption from > our side > > OUT OF BAND: > #2b, #3aii, #3b, #4, #5. They may not need further encryption as we are > using p2p only > > In each of the case 1,2,3,4 I'll have to choose one method for data > transfer. > Advantage of IN BAND primarily is reusability of code and heavy encryption > Advantage of OUT OF BAND is that they are out of band methods! > > Note that one IN BAND(#1) and two OUT OF BAND(#4,#5) are compulsory for > satisfying all cases. So, I'll have a choice only in case of #2, #3? > > Disadvantage of WiFi-Direct to Wi-FI connections (p2p) (#4,#2b) is that > Wi-Fi connection on the home node cannot be assumed to be connected with > mobile node (softAP) and we will have to either > a) Request the user to establish connection either through desktop stock > application > b) Provide some way to establish connection through our application.The > problem being there is no JAVA library on home nodes which does this work. > We should either call runtime.exec() or use jni wrappers particular to each > OS(windows, linux, MAC) selected automatically based on System...//getOSname > > Note that AFAIK this is not the case with either bluetooth(#5,#3b) or > WiFI/WiFi-Direct in android which provide concrete java classes to achieve > connectivity. So later on during the project, two mobiles can be connected > using plain java without a hitch > > Thoughts in this aspect? > We want to keep it simple, robust, and authenticated. AFAICS the best option for this is: Initial association of phone with home node: - Add a Friend -> "Connect my phone to my home node" button. - Home node: "Please connect your phone and click the button". - Home node shows a QR code. - Phone node scans the QR code, uses it as a temporary password, sets up a secure connection. - Home node and phone node exchange public keys. - Public keys can then be used to authenticate both ways. Later on: - Phone node becomes connected: either it connects to the home LAN, or we plug it into the USB. - Home node periodically broadcasts an announcement on the LAN; the announcement identifies the home node's pubkey, so we can happily have more than one home node on the same LAN. - Phone and home node authenticate, and exchange the downloaded noderefs. - Home node asks the user to manually confirm adding the new connections. (Show names, click a button). (This stage is necessary because there is a good chance the phone could be stolen, compromised etc). This works well in the three major cases: - Phone connected via USB. - Phone connected via wifi to home LAN (even if there is a separate router). - Phone connected via bluetooth to home computer. Do we really need the complexity of any other cases? Especially given that they are likely to 1) involve the user making more choices and 2) be technically risky?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
