RTCIceCandidate no longer returning IP

Just noticed that on Chrome only, RTCIceCandidate no longer returns an IP, but rather an obfuscated address.

RTCIceCandidate 
address: "a5b3ef18-2e66-4e24-91d2-893b93bbc1c1.local"
candidate: "candidate:169888242 1 udp 2113937151 a5b3ef18-2e66-4e24-91d2-893b93bbc1c1.local 47871 typ host generation 0 ufrag 7dHv network-cost 999"
component: "rtp"
foundation: "169888242"
port: 47871
priority: 2113937151
protocol: "udp"
relatedAddress: null
relatedPort: null
sdpMLineIndex: 0
sdpMid: "0"
tcpType: ""
type: "host"
usernameFragment: "7dHv"

Notice the first property of RTCIceCanadate is "address", and "ip" is no longer part of this object.

The following code determines the local IP address of a browser. Still works on MOZ.

function discover()
{
    try{
        //Get Local IP
        window.RTCPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection;   //compatibility for firefox and chrome

        if (pc)
            pc.close();

        pc = new RTCPeerConnection({iceServers:[]});   
        pc.onicecandidate = onIceCandidate;   
        pc.createDataChannel("");   
        pc.createOffer(pc.setLocalDescription.bind(pc), noop);   

    } catch (e)
    { console.log(e.message);}
}

function noop()
{
}

function onIceCandidate(ice)
{   
    console.log(ice.candidate);

    if(!ice || !ice.candidate || !ice.candidate.candidate)  return;

    var my_ip = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/.exec(ice.candidate.candidate)[1];

    this.onicecandidate = noop;

    ip = my_ip.split(".")[0]+'.'+my_ip.split(".")[1]+'.'+my_ip.split(".")[2];
}

Is WebRTC officially now a fractured standard? MOZ still lists "ip" as a member of RTCIceCandidate, with no mention of the "address" member that Chrome returns.

Is there a way to de-obfusucate the "address" to an "ip"?

回答1:

The ip field got renamed to address in the W3C webrtc specification at some point since these days the field can contain either an IP address or a mdns hostname. What you are seeing is part of the rollout of the WebRTC host candidate obfuscation which is described ħere which is happening in Chrome 75. You can not decode this mdns hostname in the browser.

If you have a legitimate use-case you might want to ask for it to be considered in that mailing list thread.

回答2:

Chrome is not broken, the WebRTC standard is evolving to prevent sites from collecting local addresses by diverting the WebRTC API. If your use case rely on this WebRTC hack to obtain local addresses, you might want to reevaluate it and find another approach.

Here are the corresponding bugs for Chromium and Firefox, and the current IETF draft for WebRTC mDNS candidates.