Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add powerEfficient[En/De]coder (#666) and fingerprint mitigations (#675). #670

Merged
merged 7 commits into from
Sep 27, 2022
Merged

Add powerEfficient[En/De]coder (#666) and fingerprint mitigations (#675). #670

Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
a71d74b
Fixes #666
henbos Sep 7, 2022
ac898f9
Add fingerprint warning
henbos Sep 8, 2022
8f5e223
Fix #675
henbos Sep 13, 2022
f68fc4e
Rebase
henbos Sep 21, 2022
402d64c
Merge branch 'main' into 220907_powerEfficientEncoder
henbos Sep 26, 2022
4b33759
Add 'check if hardware exposure is allowed' algorithm
henbos Sep 26, 2022
e983a31
Remove double-the
henbos Sep 27, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 73 additions & 8 deletions webrtc-stats.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -356,6 +356,39 @@ <h3>
</p>
</section>
</section>
<section>
<h2>
Privacy considerations
henbos marked this conversation as resolved.
Show resolved Hide resolved
</h2>
<p class="fingerprint">
The WebRTC's Statistics API exposes information about the the system,
henbos marked this conversation as resolved.
Show resolved Hide resolved
including hardware capabilities and network characteristics. To limit
the finger printing surface imposed by this API, some metrics are only
exposed if allowed by the algorithms in this section.
</p>
<section>
<h3>
Limiting exposure of hardware capabilities
</h3>
<p>
To <dfn data-lt="exposing hardware is allowed">check if hardware
exposure is allowed</dfn>, run the following steps:
<ol>
<li>
<p>
If the <a href="https://w3c.github.io/mediacapture-main/#context-capturing-state">
context capturing state</a> is true, return true.
</p>
</li>
<li>
<p>
Return false.
</p>
</li>
</ol>
</p>
</section>
</section>
<section id="rtctatstype-*">
<h2>
{{RTCStatsType}}
Expand Down Expand Up @@ -961,6 +994,7 @@ <h3>
unsigned long framesReceived;
DOMString decoderImplementation;
DOMString playoutId;
boolean powerEfficientDecoder;
};</pre>
<section>
<h2>
Expand Down Expand Up @@ -1509,13 +1543,12 @@ <h2>
"idlMemberType">DOMString</span>
</dt>
<dd>
<p>
Identifies the decoder implementation used. This is useful for diagnosing
interoperability issues.
</p>
<p class="fingerprint">
If too much information is given here, it increases the fingerprint surface.
Since it is only given for active tracks, the incremental exposure is small.
Only defined when [= exposing hardware is allowed =].
</p>
<p>
Identifies the decoder implementation used. This is useful for
diagnosing interoperability issues.
</p>
</dd>
<dt>
Expand All @@ -1528,6 +1561,22 @@ <h2>
corresponding {{RTCAudioPlayoutStats}}.
</p>
</dd>
<dt>
<dfn>powerEfficientDecoder</dfn> of type <span class=
"idlMemberType">boolean</span>
</dt>
<dd>
<p class="fingerprint">
Only defined when [= exposing hardware is allowed =].
</p>
<p>
Whether the decoder currently used is considered power
efficient by the user agent. This SHOULD reflect if the
configuration results in hardware acceleration, but the user
agent MAY take other information into account when deciding if
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have examples of such information? Is it to cover the case of small resolutions for instance where some OSes may decide to go with software implementations

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It gives implementations some wiggle-room, like if a HW implementation isn't performant we could still report false without violating the spec. I don't know if this is a real problem in practise though.

I also think that it is OK for an implementation to say that SW is power efficient if the resolution is so small that SW would be more performant than HW, but I don't think finding that cutoff point is required of the implementation.

the configuration is considered power efficient.
</p>
</dd>
</dl>
</section>
</div>
Expand Down Expand Up @@ -1692,6 +1741,7 @@ <h3>
unsigned long firCount;
unsigned long pliCount;
DOMString encoderImplementation;
boolean powerEfficientEncoder;
boolean active;
};</pre>
<section>
Expand Down Expand Up @@ -2030,13 +2080,28 @@ <h2>
"idlMemberType">DOMString</span>
</dt>
<dd>
<p class="fingerprint">
Only defined when [= exposing hardware is allowed =].
</p>
<p>
Identifies the encoder implementation used. This is useful for diagnosing
interoperability issues.
</p>
</dd>
<dt>
<dfn>powerEfficientEncoder</dfn> of type <span class=
"idlMemberType">boolean</span>
</dt>
<dd>
<p class="fingerprint">
If too much information is given here, it increases the fingerprint surface.
Since it is only given for active tracks, the incremental exposure is small.
Only defined when [= exposing hardware is allowed =].
</p>
<p>
Whether the encoder currently used is considered power
efficient by the user agent. This SHOULD reflect if the
configuration results in hardware acceleration, but the user
agent MAY take other information into account when deciding if
the configuration is considered power efficient.
</p>
</dd>
<dt>
Expand Down