Open
Bug 1189167
Opened 9 years ago
Updated 2 years ago
[meta] ICE candidate generation control and user authorization
Categories
(Core :: WebRTC, defect)
Core
WebRTC
Tracking
()
People
(Reporter: jesup, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: meta)
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•9 years ago
|
||
Whatever is done here should probably aim to solve the threats described in bug 959893.
Depends on: 959893
Comment 2•9 years ago
|
||
(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•9 years ago
|
||
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•9 years ago
|
||
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-firefox42:
--- → +
Comment 7•9 years ago
|
||
Stop tracking as tracking meta bugs is rarely actionable. Anyway, this is too late in the 42 cycle to uplift changes like these.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•