This is a tracking bug for items related to control of what ICE candidates are gathered and user authorization of PeerConnection createOffer/Answer, in particular tools for users to monitor and/or authorize connection attempts.
Whatever is done here should probably aim to solve the threats described in bug 959893.
Depends on: 959893
(In reply to Zack Weinberg (:zwol) from comment #1) > Whatever is done here should probably aim to solve the threats described in > bug 959893. It should probably block that bug instead of depend on it.
As a generic scope overview for this issue, Roman Shpount from the IETF mailing list puts it very nicely on why overriding default routes should be disabled by default: ------------------- One thing that I do not agree with is that PeerConnection introduced a significant new behavior -- routing data over the non-default network interface. This is something that was not possible before. There is no way to overwrite default routing with HTTP request or anything similar generated by the browser. Overwriting default routing would allow creation of a whole new class of exploits, from determining user other IP addresses to forcing traffic over unexpected networks and generating expenses for the user. My suggestion is that until system wide preferences are exposed via some other mechanism defined by MIF, web browser should follow the local policy and do not overwrite local routing metrics by sending ICE requests over specific interfaces. At the very least, this should only be enabled via some sort of configuration option which should be disabled by default. I understand that using only default routes can decrease the chances of connection, but from my experience* we are talking about less then 0.1% of all the users. ------------------- https://mailarchive.ietf.org/arch/msg/rtcweb/QMge-U2tkfkTdZy2X_qA9vjd5fY
User preferences don't solve the privacy violation in bug 939893, unless it's blocked by default. The default setting must be secure and private. I don't think this here is the right solution to bug 939893 at all.
Tracking for FF41.
status-firefox41: --- → affected
tracking-firefox41: --- → +
Untracked for FF41. Moved tracking to FF43. While the original plan was to land all related uplifts in Beta41, that has changed to 42 AFAIK.
tracking-firefox41: + → -
tracking-firefox42: --- → +
Stop tracking as tracking meta bugs is rarely actionable. Anyway, this is too late in the 42 cycle to uplift changes like these.
tracking-firefox42: + → -
You need to log in before you can comment on or make changes to this bug.