[tbb-dev] Media Codecs and the canPlayType/Media Capabilities API

Georg Koppen gk at torproject.org
Thu Jan 31 16:50:00 UTC 2019


Hi Tom!

Sorry for the delay in answering.

Tom Ritter:
> This is an old concern I'm trying to revive to figure out a path
> forward on. I'm going to do my best to summarize this issue.

Thanks for the great write-up!

[snip]

> As far as a path forward; there are a few ideas:
>  - Maybe we can allowlist codecs so only certain codecs are usable?
>  - In the short term; we can modify canPlayType and Media Capabilities
> to accurately report (effectively) whether or not the user has
> WMF/ffmpeg or not but lie about hardware acceleration and all other
> aspects.  (We have a patch for this written.)
>  - Alternately; we could lie and say no one has it installed (this
> would be a bad experience for most users) or everyone has it installed
> (bad for a small percentage of users)
>  - Tor Browser could detect whether or not you have ffmpeg / WMF and
> inform you in some capacity that installing this software will make
> you less identifiable
>  - Tor can probably bundle ffmpeg in some capacity; but it can't
> bundle WMF due to licensing.
> 
> All of these have some drawbacks; and we probably want to use data to
> make an informed decision.

Yes, I agree with that but I could think of Tor Browser generally
shipping the short term solution you already have a patch for to try it
out and see how big the fallout is. We might not be able to help much,
though, with the Media Capabilities API given that we are on ESR 60.

Skimming the spec a bit, following the advice of the spec in ยง4.1 in

https://wicg.github.io/media-capabilities/#security-privacy-considerations

seems not unreasonable to me at first glance. But I am still a bit
unsure about the trade-offs here as I'd need to look closer at all the
things besides the codec being exposed. Do we have a table somewhere
showing the entropy those things add? CanPlayType and actually trying to
play it give just a yes/no back per codec, right? How many bits get
exposed by the Media Capabilities API?

When the spec is saying:

"""
This information is expected to have a high correlation with other
information already available to the web pages as a given class of
device is expected to have very similar decoding/encoding capabilities.
"""

what other information available to web pages is it talking about? Do we
spoof/deal with that already? And if so, would it help here taking the
decisions that got made for them into account while developing defense?
And if not, would it help tackling those other vectors together with the
codec one?

> I don't think we know what codecs we care about; or are installed by ffmpeg/WMF.
> I (personally) don't know if Firefox will pass non-standard codec
> requests out to the system to see "Hey do you happen to have a codec
> for 'randomweirdthing'"
> I don't think we know what the install rate for ffmpeg/WMF is.
> We have some data about codec use; however I don't fully understand
> it: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-01-10&include_spill=0&keys=video%252Favc!audio%252Fmp4a-latm!audio%252Fopus!video%252Fvp9&max_channel_version=beta%252F65&measure=MEDIA_CODEC_USED&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-12-10&table=0&trim=1&use_submission_date=0

I wonder how we could get the answer to all of those questions to
actually make an informed decision as you suggest.

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20190131/c40b3c42/attachment.sig>


More information about the tbb-dev mailing list