-
Notifications
You must be signed in to change notification settings - Fork 0
20140831 Meeting Minutes
Plutôt non. A garder sous le coude, mais integration/réutilisation trop contraingnants
-
Différence technique: Pas distribué, basé sur le mobile, pas de vidéo
-
Techiniquement différent de ce qu'on veut, mais au niveau utilisateur lambda, feature très similaire.
-
Comme on est pas soumis à une pression du marché et dàinnovation par rapport aux concurrent donc on peut continuer Yaqar pour avoir ce que l'on veut vraiment
-
ZRTP pour WebRTC n'existe pas. Options: écrire une lib ou convertir une lib C en javascript (5 existante)
-
OTR peut être repris de TextSecure car il y est bien implémenter
-
Prochaine étape?
- Palava ========= Le système est découpé comme ceci:
Partie client
- palava-client logique client (CoffeeScript)
- palava-portal interface graphique (AngularJS)
Partie serveur
- palava-machine serveur signaling (Ruby)
C'a l'air plutôt bien fait leur truc mais il y a quelques aspects qui dérangent. Premièrement, ils ont fait leur propre protocole de signaling que le client et serveur implémentent (https://github.com/palavatv/palava-client/wiki/Protocol) mais ce protocole ne correspond pas à ce qu'on veut faire. Il est basé sur des "chat rooms" alors qu'on aimerait plutôt des contacts et trouver qui est connecté. Il faudrait y ajouter cela, mais du coup autant avoir notre propre protocole.
Deuxièmement, la partie client n'a aucun test unitaire. Cela ne correspond pas au but de test-driven development fixé pour ce projet. Si on modifie leur client CoffeeScript, il faudra commencer par écrire les test manquants. :/
-
TextSecure ============= Ensuite, il y a un autre projet: TextSecure/RedPhone/Signal. Il est dirigé par un expert en crypto (Moxie Marlinspike) donc cet aspect est solide dans leur implémentation. Ils ont sorti une version 2 cette année, on a réessayé et c'est bien plus utilisable. Ils ont récemment commencé à fusionner TextSecure et RedPhone en une seule application: Signal, déjà publiée pour iPhone (https://whispersystems.org/blog/signal/). Pour l'instant, ils ne font que du mobile (Android, IOS) mais ils se lancent aussi dans le desktop avec une extension Chrome (https://github.com/whispersystems/TextSecure-Browser). En comparaison avec Zaquar, ils n'ont apparemment pas de plan pour faire de la vidéo et leur système est centralisé (mais les serveurs peuvent être fédérés, sans plus de détails...).
-
DTLS-SRTP vs. ZRTP ===================== Ces deux protocoles sont conçus pour générer les clés d'une session RTP, avec des approches différentes. Le signaling et la vérification d'identité de WebRTC utilisent l'empreinte des clés générées par DTLS-SRTP. La sécurité de DTLS-SRTP dépend d'une PKI (certificats signés par une CA reconnue par les browsers). Donc c'est un système centralisé à sa racine, ça fonctionne mais cela implique de pouvoir faire confiance: au serveur de signaling et à l'Identity Provider (IdP). A l'opposé, ZRTP est conçu pour fonctionner sans certificats ni CA et protège contre des attaques MiTM. http://www.ietf.org/mail-archive/web/rtcweb/current/msg04007.html http://www.ietf.org/mail-archive/web/rtcweb/current/msg04032.html http://zfoneproject.com/faq.html#ZRTP-vs-DTLS
On peut rajouter ZRTP par dessus WebRTC pour vérifier les empreintes et garantir qu'il n'y a pas de MiTM (suggéré dans http://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-01). Cependant, il faudra implémenter (en partie) ZRTP en JavaScript.
- Zaquar M1 ============ le M1 est presque (reste le bouton disconnect, vraiment à faire?) donc j'ai pu explorer le gros de l'API WebRTC. :) Je propose qu'on attaque le protocole client-serveur pour voir qui est en ligne et s'y connecter.