1969210 - Getting HTMLMediaElement#preload with missing attribute should reflect the preload behavior

Status: NEW

(Core :: Audio/Video: Playback, defect)

Description

[Karl Tomlinson (:karlt)]

Gecko's default preload behavior, for a missing attribute, is "metadata" for wifi and "none" on cellular.

The preload getter returns "auto" when the attribute is missing, regardless of the default behavior affected by preference and network type.

STR:

1. load data:text/html,<audio>
2. In Web Console, enter document.getElementsByTagName("audio")[0].preload.
   Actual: "auto".
   Expected: "metadata" or "none".

https://html.spec.whatwg.org/multipage/media.html#dom-media-have_enough_data
"The attribute's missing value default and invalid value default are both implementation-defined, though the Metadata state is suggested as a compromise between reducing server load and providing an optimal user experience."

Comment 1

[Karl Tomlinson (:karlt)]

Before https://phabricator.services.mozilla.com/D249523, the empty string, "" was returned instead of "auto". The empty string means the same as "auto".

Comment 2

[Karl Tomlinson (:karlt)]

A value that depends on network status would add to fingerprinting surface if that is not exposed elsewhere, though perhaps that could be ascertained through behavior of the media element anyway.
Perhaps picking "metadata" or "none" based on desktop or mobile might be good enough, given we don't know of sites actually using this value.

Comment 3

[Thorin [:thorin]]

ni'ing some people: my choice for RFP (fyi: RFPTarget NavigatorConnection is old and no longer used since netinfo is disabled) would be to mask the network status and return a value based on desktop vs mobile (we can't hide the major platform so this is not any new information/entropy) - in other words enforce the default per platform

Comment 4

[Thorin [:thorin]]

Attachment: test.png

part of TZP now - karl, are there any prefs (I couldn't see any) or other "things" that can affect this property?

Comment 5

[Tom Ritter [:tjr]]

There should be an RFPTarget that hardcodes a value. I am fine with hardcoding a behavior per platform.

though perhaps that could be ascertained through behavior of the media element anyway.

This comment concerns me though - There's the preload attribute which is just a string that tells you what you want to know. Does the audio element change its behavior based on the underlaying state though? Because controlling the `preload attribute is all well and good, but if the element is changing its behavior and the website is able to observe it, that's leaking the same data.

Comment 6

[Karl Tomlinson (:karlt)]

(In reply to Tom Ritter [:tjr] from comment #5)

Does the audio element change its behavior based on the underlaying state though?

It does. It can leak the same data.

AFAICS nsINetworkLinkService::GetLinkType() is implemented only for Android.

Behavior is affected by media.preload.default, media.preload.default.cellular, media.preload.auto, and media.preload.auto.cellular prefs.

(In reply to Thorin [:thorin] from comment #4)

are there any prefs (I couldn't see any) or other "things" that can affect this property?

No prefs nor anything else affect the property currently reported.

Comment 7

[Thorin [:thorin]]

Behavior is affected by

How do you measure the behavior?

Comment 8

[Tom Ritter [:tjr]]

How do you measure the behavior?

AIUI those four prefs determine the behavior. They are set not by default, but a user can create them.

Because they aren't set by default the provided default values where they are used are used instead.

If the preload attribute is not set in HTML then GetPreloadDefault() is used; and if it is set and it is set to auto then it will use GetPreloadDefaultAuto().

On Android, the only place we check if you're on cellular, you could distinguish between Cellular or WiFi connection.

I think the fix is on these two lines to do

if (OnCellularConnection() && !ShouldResistFingerprinting(RFPTarget::MediaPreloadConnectionLink) {

which will go use this member function. That RFPTarget doesn't exist, it would be added here.

I think that will control both the loading behavior and the value reported for the default value of the preload attribute. It will also mean that RFP users will use more bandwidth preloading things on cellular connections. Tor can voice their opinion, but from a user experience POV the added bandwidth will mean a Tor user will see the media much faster because of the Tor network's added latency.

Comment 9

[Thorin [:thorin]]

I think that will control both the loading behavior and the value reported

Sounds good to me. IANAE on media - but how do we measure the loading behavior? We/TZP still needs to check all methods of obtaining a value. thx