If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[meta] ICE candidate generation control and user authorization

NEW
Unassigned

Status

()

Core
WebRTC
2 years ago
a month ago

People

(Reporter: jesup, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug, {meta})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox41- affected, firefox42- affected)

Details

(Reporter)

Description

2 years ago
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.
Blocks: 959893
No longer depends on: 959893

Comment 3

2 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

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

Updated

2 years ago
Depends on: 1194259

Comment 5

2 years ago
Tracking for FF41.
status-firefox41: --- → affected
tracking-firefox41: --- → +

Comment 6

2 years ago
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: + → -

Updated

a year ago
Depends on: 1297416
You need to log in before you can comment on or make changes to this bug.