1189167 - [meta] ICE candidate generation control and user authorization

Status: NEW

(Core :: WebRTC, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 1

[Zack Weinberg (:zwol)]

Whatever is done here should probably aim to solve the threats described in bug 959893.

Comment 2

[Xidorn Quan [:xidorn] UTC+11]

(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.

Comment 3

[Daniel Roesler]

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

Comment 4

[Ben Bucksch (:BenB)]

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.

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracking for FF41.

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Stop tracking as tracking meta bugs is rarely actionable. Anyway, this is too late in the 42 cycle to uplift changes like these.