Sleeping with the enemy

Today I have been at the monthly meeting of the Python Madrid group where I did a keynote about HTML5 and what benefits can offer to the Python web developers, and also showed ShareIt! as a proof of the technology potential. Althought some technical problems with the projector, finally I was able to show it and was a sucess :-)

They liked so much the idea behind of ShareIt! and were very interested on the technology behind it, specially about how I'm using WebSockets for the DataChannel-polyfill and if the final native implementations will support high estress use like the one ShareIt will so or maybe bigger ones (I believe someone is thinking about highly masive videochats... :-D ) but also they asked me a very interesting question that I didn't thought about: the most important building blocks on ShareIt! are annonimity and confidentiality, being the users identified by a random UID at load and with encrypted communications (both WebSockets with TLS and DataChannels by the specification), but since I'm not a security expert, there is an important security hole regarding to annonimity, so it's critical: to be able to do the PeerConnection, you need to transfer your SDP to the other peer to be able to do the connection, but the fact is that it has your public IP on the origin field (just the ID used by DataChannel-polyfill, by the way...), so this way the other end can be able to connect to you... but also know where you are. And it's done both ways. If at one of the ends there is a men in black listening (here at Spain we have La Innombrable, that it's scarier) and send him your shared files list, you have a problem.

They suggested me to use some type of friends white list based on public key for authenticity of the other pair, but since you can connect to anyone to fetch the data in a distributed way and not end having a lot of limited, private networks, this in unfeasable. Anyway, I got the idea banging on my head and think found a solution: just ask for authentification when you query a files list. This way, since for tranfering chunks you look for the files by their hash, you don't know what is being requested except if you have already the file with that hash, so you'll need to ask for all the combinations of the hash (on Tiger TTH, 2^192 combinations, bigger than the ZFS address space), and something similar would happen if you do a fulltext search over the network, so it's impracticable. The only attack point would be ask directly to a specific peer for its files list, and since this is something that you'll not do too much frequently (you want to fetch a file, doesn't matter where he comes), this can be easily filtered only allowing to do it if you have exchange a public key with the other peer (something you should do only if you know who is at the other end...), so you know the request is legit and also you can send the files list data cyphered with that key. Easy and unobstrusive :-)

Another option would be just to remove entirelly the files list request mechanism and only allow searching for files. This would limit the functionality of the protocol, but would be fairly more simple and secure, so maybe it's a good option for a future version...

ShareIt! working over DataChannel-polyfill

I could be able to finish it two days ago (after an entire week -and weekend- going to sleep after 3:00 AM :-P) but I have been busy this two days with university. Anyway, I have finished to debug the code and now ShareIt! is using DataChannel-polyfill to do the communications between the peers. Also, I needed to develop an IndexedDB polyfill to by-pass the Chrome bug related to storing Blob objects, so there's no persistence but I could be able to continue with the experiments :-)

The only drawback I have seen is that communications were really slow (about 25-30 seconds just for a 500KB image) until I got on the fact i have a 10Mbps/1Mbps ADSL line, so I tested it using a DataChannel-polyfill backend server on localhost and it downloaded in just 2 seconds, so maybe it was a problem with my limited line upload. The good part is that for the tests i used Chrome SpeedTracer and didn't look any unusual (except comunication peaks were about each 5 seconds), so the app is very responsible :-) Also i have developed the code on a library way, so it could be exported to other projects (althought previously it needs some documentation and port the original, simple interface to it as a proof-of-concept).

Finally, you can test it (currently only on Chrome, DataChannel-polyfill is giving me problems on Firefox) at http://shareit.piranna.5apps.com, running against a handshake server and a datachannel backend server that I have hosted on two Nodejitsu testing sandboxes.

And obviously, you can get the code on GitHub :-D Things were I would need some help from now are related with the Kademlia implementation for searches (I was thinking about using KadOH), and file hashes where I would like to use Tiger TTH, but currently there's no JavaScript implementation. Another point I have been thinking about this days is just use the SDP IDs to do the handshake directly over the DataChannels, so there will be no need to use handshake or backend servers at all, but this need some investigation (a friend of mine told me that SDP IDs would expire in a few minutes so I can't be able to have a PeerConnection object ready to accept incoming connections just to do the handshake, any clue about this?).

And this is all for now. As usual, any comments or suggestions are welcome :-)

DataChannel polyfill

Han sido tres semanas de duro trabajo, pero finalmente he terminado una implementacion de DataChannel usando WebSockets :-D

Obviamente, no es P2P porque necesita un servidor funcionando como proxy entre los pares, pero puesto que lo he desarrollado a partir de la especificacion deberia ser compatible con su API cuando haya una implementacion nativa en Chrome o Firefox a final de año, o al menos deberia ser util para empezar a trabajar con una mentalidad distribuida en lugar de basada en servidor (esto es lo que mas me ha costado mientras desarrollaba la implementacion :-P ) y probar nuestras aplicaciones. Usarlos es tan simple como incluir datachannel.js en el codigo HTML (despues de cambiar la URL del servidor puesto que actualmente esta metida a pelo), arrancar el servidor proxy y listo, a partir de aqui es completamente autonomo :-D

El codigo se puede encontrar en https://github.com/piranna/DataChannel-polyfill. Tambien tengo una version modificada del codigo de la demo y del cliente de WebRTC.io que he usado para probarlo (sustituyendo el pequeño chat que tienen hecho basado en servidor a una arquitectura P2P enviando los mensajes a todos los pares conectados) que pueden encontrarse en https://github.com/piranna/webrtc.io-demo/tree/polyfill y https://github.com/piranna/webrtc.io-client/tree/polyfill y tambien he hecho un pull-request para que lo añadan en su rama maestra. Por favor mandadme cualquier comentario, consejo o mejora que le veais al codigo :-)

P.D.: por si alguien anda perdido, WebRTC es la especificacion que esta desarrollando para poder conectar los navegadores web directamente entre ellos sin necesidad de un servidor entre medias, y aunque en las ultimas version de Chrome y de Firefox ya hay soporte para realizar videoconferencia directamente desde el navegador y hay algunas aplicaciones que ya empiezan a usarlo (incluso Skype va a cambiar su protocolo para acogerse al estandar), lo cierto es que el soporte para el envio de datos todavia esta por definir y no hay ningun navegador que lo soporte hasta final de año, por lo que para ir preparandome para entonces y poder ir adaptando el codigo para estar listo he desarrollado esta libreria siguiendo la especificacion para que el codigo sea compatible de cara al futuro.