Opened 14 months ago

Closed 12 months ago

Last modified 11 months ago

#31591 closed defect (fixed)

Feature review for ESR68

Reported by: pili Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-9.0-must-alpha, TorBrowserTeam201910, GeorgKoppen201910
Cc: mikeperry Actual Points: 6
Parent ID: Points: 3
Reviewer: Sponsor:

Description

Go over release notes and review any new features introduced in ESR68

Child Tickets

Change History (12)

comment:1 Changed 14 months ago by gk

Keywords: tbb-9.0-must-alpha added
Priority: MediumVery High

comment:2 Changed 14 months ago by pili

Points: 3

comment:3 Changed 13 months ago by pili

Keywords: TorBrowserTeam201910 added

comment:4 Changed 13 months ago by pili

Keywords: TorBrowserTeam201909 removed

comment:5 Changed 13 months ago by gk

Keywords: GeorgKoppen201910 added

comment:6 Changed 12 months ago by mikeperry

Ok I looked through FF68's dev docs in detail. The only thing that struck me as remotely concerning was the potential ability to build high precision timers for performance fingerprinting out of the Close Caption https://developer.mozilla.org/en-US/docs/Web/API/TextTrack/cuechange_event.. I don't think we have gone down that rabbithole of trying to eliminate such timers, right? And it's not even clear that the accuracy of this timer would be very high in the first place, so it might not even be possible.

comment:7 Changed 12 months ago by tom

We have not addressed techniques that build timers out of web features like this one would be. We have only addressed things that have explicit timestamps (either absolute or relative.)

Fuzzyfox would address constructed timers, but while we have all the code for it, we haven't investigated/tested it.

comment:8 Changed 12 months ago by gk

Parent ID: #31144

comment:9 Changed 12 months ago by gk

Here come my notes for Firefox 61-67 (inclusive) dev-doc reviews:

The developer docs can be found at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/XX (Where "XX" is the actual Firefox version to be investigated).

There was nothing concerning for Firefox 61 and 62.

For Firefox 63 we have the Media Capabilities API (https://bugzilla.mozilla.org/show_bug.cgi?id=1409664) which we addressed in #13543. I made a note on #16678 as changes might affect this bug and filed an investigated #31954. I skimmed https://bugzilla.mozilla.org/show_bug.cgi?id=1349799 and think the WebGL power preference in this bug is not a problem for us.

Nothing found for Firefox 64.

There are some items for Firefox 65: RelativeTimeFormat (https://bugzilla.mozilla.org/show_bug.cgi?id=1504334) which got investigated in #31985. Then we have the Streams API (#31997), Storage Access API (#32002) and new WebGL extensions (#32013)

Nothing found for Firefox 66.

New WebGL extension in Firefox 67. I opened #32057 and investigated the new feature.

All in all I think we are not in bad shape here.

comment:10 in reply to:  6 Changed 12 months ago by gk

Actual Points: 6
Resolution: fixed
Status: newclosed

Replying to mikeperry:

Ok I looked through FF68's dev docs in detail. The only thing that struck me as remotely concerning was the potential ability to build high precision timers for performance fingerprinting out of the Close Caption https://developer.mozilla.org/en-US/docs/Web/API/TextTrack/cuechange_event.. I don't think we have gone down that rabbithole of trying to eliminate such timers, right? And it's not even clear that the accuracy of this timer would be very high in the first place, so it might not even be possible.

Yeah, as Tom said we did no go down that rabbit hole yet. I think we have #16110 for the general area and now #32350 for your issue in particular.

comment:11 in reply to:  9 Changed 11 months ago by gk

Replying to gk:

Here come my notes for Firefox 61-67 (inclusive) dev-doc reviews:

The developer docs can be found at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/XX (Where "XX" is the actual Firefox version to be investigated).

There was nothing concerning for Firefox 61 and 62.

For Firefox 63 we have the Media Capabilities API (https://bugzilla.mozilla.org/show_bug.cgi?id=1409664) which we addressed in #13543. I made a note on #16678 as changes might affect this bug and filed an investigated #31954. I skimmed https://bugzilla.mozilla.org/show_bug.cgi?id=1349799 and think the WebGL power preference in this bug is not a problem for us.

Nothing found for Firefox 64.

Technically speaking this is not correct. Interaction Media Features got implemented including pointer/hover (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1035774 and https://bugzilla.mozilla.org/show_bug.cgi?id=1483111). However, thanks to Mozilla engineers fingerprinting issues have been taken into account right from the beginning. So, once resist fingerprinting mode is on a mouse-type pointer is given back. It seems to me this holds for mobile, too, which we might want to revisit (tjr mentioned it should be touchscreen values there (https://bugzilla.mozilla.org/show_bug.cgi?id=1035774#c25)).

Last edited 11 months ago by gk (previous) (diff)

comment:12 in reply to:  6 Changed 11 months ago by gk

Replying to mikeperry:

Ok I looked through FF68's dev docs in detail.

The Viewport API might be relavant here, too, even though it does not seem too critical. We have #30542 for that.

Note: See TracTickets for help on using tickets.