- et aussi, du coup on voit ta véritable IP de ton serveur, c'est vraiment ce que tu veux ?
Nope, la 1ère étape de l'échange WebRTC c'est de taper sur un serveur STUN (STUN est un protocole sur UDP qui permet d'obtenir des informations sur les options de contournement de NAT possibles) public, en général celui de Mozilla ou de Google (il suffit d'en spécifier un lors de la création de l'objet RTCPeerConnection pour avoir l'IPv4 publique derrière un NAT).
La véritable adresse IP du serveur qui sert le Javascript, et qui reçoit les informations SDP en retour, n'a pas à être révélée.
- effctivement le WebRTC demande la permission d'échanger de la data, audio ou vidéo. Quand je me balade sur un forum, et que soudainemetn mon navigateur me demande ça... soit je me casse, soit je refuse.
Je viens de tester avec les dernières versions de Chrome ou de Firefox, il n'y a pas d'autorisation de demandée lors de l'appel à createOffer() ou setLocalDescription(). Seul l'usage du microphone ou de la webcam, quand il est demandé explicitement, requiert une autorisation explicite.
WebRTC peut être bloqué correctement en modifiant les paramètres avancés du navigateur, et l'obtention de la description SDP locale demandera une autorisation lors de l'utilisation de certains clients comme Tor Browser, mais à ma connaissance c'est une fonctionnalité spécifique à Tor Browser (et si ton utilisateur utilise Tor Browser, son numéro de port n'est probablement déjà plus d'une grande utilité à l'OCLCTIC).
Dans tous les cas le site est hébergé en France et les données whois sont toutes legit, la PJ (donc au dessus de l'OCLCTIC) m'ont carrèment dit que ce forum leur est utile car il leur fait office "d'honeypot", on nous a plus ou moins expliqué que c'est pour ça qu'il n'est pas fermé.
C'est intéressant, j'avais déjà entendu ce discours venant de l'OCLCTIC (pas pour un truc à moi).
Sinon intéressant pour ta seconde option Marin, j'avais jamais trop touché au webrtc et il s'avère qu'effectivement c'est une belle mine d'or en terme d'infos côté client. Reste juste le problème qu'un mec peut bloquer/modifier l'appel à l'endpoint qui log les données.
Il suffit de s'assurer que l'adresse IP matche avec celle observée concernant le client pour ne pas polluer la base (quoique tu perds des cas intéressants où WebRTC contourne le proxy/VPN en place), ensuite il n'y pas grand chose à polluer s'il s'agit d'envoyer un entier entre 0 et 65535, ou alors le mec a déjà les connaissances techniques pour se protéger un peu plus que ça.