tbb-dev

tbb-dev@lists.torproject.org

447 discussions

Media Codecs and the canPlayType/Media Capabilities API
by Tom Ritter 08 Feb '19

08 Feb '19

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. The issue at hand is that codec support is not uniform across all users. The 'why' for this is that ffmpeg is not installed on all Linux machines; and that certain versions of Windows (N and KN versions in Europe) don't have the Windows Media Pack. I don't know for certain of any other situations where unusual codecs might be present and usable that allow fingerprinting or situations where common codecs would be missing or disabled (excepting, of course, about:config changes.) But it seems likely? If a user has installed a weird and unusual codec, the browser might still be able to play the video because the codec's on the system? Or perhaps a user is on an old Linux that has an old ffmpeg that doesn't support a newer codec? I don't think we have data about how common/uncommon it is that Linux users don't have ffmpeg or Windows users are missing WMF; although an approximate answer was '90% or more people have it.' Firefox detects when a user tries to play a video with a codec and it doesn't work; MediaWMFNeeded is the most relevant; it redirects people to a page that tells them to install WMF: https://support.mozilla.org/en-US/kb/fix-video-audio-problems-firefox-windo… https://searchfox.org/mozilla-central/source/dom/locales/en-US/chrome/dom/d… https://searchfox.org/mozilla-central/rev/bee8cf15c901b9f4b0c074c9977da4bbe… So the codec is the issue; but how it gets exposed through the platform is three ways: - canPlayType - and 'old' API that asks if a <video> element can play a particular codec - The Media Capabilities API - the new style API - Just trying to play videos with different codecs and seeing if it works In addition to exposing codec information; it also exposes things like whether certain codecs are hardware accelerated or if a machine can handle high resolution video or not. My understanding is that the third one is essentially impossible to prevent; absent requiring the user to manually click play for each video. 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. 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… There is a bug on file here https://bugzilla.mozilla.org/show_bug.cgi?id=1461454 ; however most discussion over the months has taken place in an email thread. -tom

5 7

Fingerprinting Test Page
by Tom Ritter 30 Jan '19

30 Jan '19

There's a Mozilla contributor (https://github.com/ghacksuserjs/TorZillaPrint/commits?author=Thorin-Oakenpa…) who's been working on a unified fingerprinting test page. It is in-progress here: https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html (code: https://github.com/ghacksuserjs/TorZillaPrint) I am not sure how this compares to fpcentral, either in current incarnation or in architecture and future ease-of-evolution or ease-of-automated-integration BUT it seems to be pretty handy. I know he is interested in building it out to make it feature-complete. So if you're working on a fingerprinting bug and you need to code up a test; you might consider putting it in this framework to work towards keeping it all in one place? -tom

2 1

Tor Browser for Android Reviews on Google Play
by Matthew Finkel 28 Jan '19

28 Jan '19

Hi all, I read the reviews/comments of Tor Browser for Android on Google Play from November and December. Some of the requests were addressed/implemented in the December Tor Browser 8.5a5 release, but I'll mention them here for completeness. In November, the most frequent comment/request was about the lack of copy/paste functionality. This was tracked and fixed in #27256. The second most frequent comment referred to receiving a browser proxy error message (some mentioned "incorrect proxy setting" message). It seems possible this was due to Orbot not being installed or running. Before tor was bundled in the app, Tor Browser did warn the user if an Orbot installation wasn't detected and it tried starting Orbot if it was detected but wasn't running, but maybe this wasn't sufficient in all cases. Tor Browser now includes its own tor proxy, so those failures should be mitigated. The remaining comments were: - Requesting tor integration directly into the app (ticket #28051) - Requesting ability to take screenshots (ticket #27987) - Can't download images/pdfs/files (ticket #28705) - Tor is slow - Request for Russian localizations (ticket #26843) - Request for additional localizations (ticket #26843) - Lack of ad-blocker - Prevented from installing add-ons (primarily for installing an ad-blocker) - Request for a single button that disables all scripts - Request for supporting x86 devices (ticket #27210) - Observation Tor Browser is not a torrent client In December, including comments before and after the release where the app included its own tor client, the most frequent comment/request referred to the browser not connecting. I know there is currently a bug where Android stops the tor process but Tor Browser doesn't detect this, and the user only receives a proxy error. I'm not certain this why the users are saying the browser doesn't connect, but it's an annoying bug in any case. The second most frequent comment in December related to the app crashing after attempting a file download. There were multiple comments and questions about the Orbot integration. Some users asked if they needed Orbot installed anymore, others requested that development continue on Orbot and Tor Browser shouldn't replace Orbot. There were additional questions and concerns about Tor Browser's Orbot screen and configuring VPN mode - specifically using Tor Browser's (Orbot's) VPN mode for torifying other apps. This last issue should be resolved with the new bootstrapping UI and the enxt release should mitigate the Orbot/Tor Browser UI/UX confusion. We should be more clear about Tor Browser's dependency on the Orbot app. I'm not sure how we should communicate this, yet. There were more requests for Russian localization and Turkish localization. Users should see this automatically now if their device is configured with another language as the default. If the device is not configured with Russian/Turkish as their default language, then they can select another locale in Fennec/Tor Browser's settings menu, but maybe this isn't obvious. We can think about how we can/should make this easier. The remaining comments were: - The new update didn't work in Iran - Request for bridge support (ticket #28802) - It's not obvious when Tor isn't running - Request for x86 support (ticket #27210) - Updates aren't working, users are reinstalling the app after each update - Request for detecting and using the Orbot app if it's installed - A user noticed the app "randomly" start - A user noticed the app stop after a long period of use - Tor Browser is using the Orfox logo (ticket #27399) - Add-on installation is blocked - Request for a Javascript button (toggle on/off) - Tor is slow - Request for a circuit display - Tor Browser's Orbot doesn't start tor, progress hangs at startup without any errors - Tabs aren't restored after Android kills the app in the background - Request to make Tor Browser SDCard-compatible - Request for allowing taking of screenshots (ticket #27987) There were two comments about failure after installing the update and reinstalling the app as a result. We should investigate this. One instance was reported on a Blackberry Priv. - Matt

3 2

We move our meeting time to Monday 1830 UTC (in #tor-meeting2)
by Georg Koppen 23 Jan '19

23 Jan '19

Hi all! Due to conflicts some folks on the browser team have we are moving our meeting time. It's now half an hour earlier on Mondays: 1830 UTC. That results in a new meeting location as well as #tor-meeting will be occupied by the network team folks during that time. We'll therefore use #tor-meeting2. Thus, the next weekly meeting will be on Monday, 1/28/2019, at 1830 UTC in #tor-meeting2 at irc.oftc.net. See you there, Georg

1 0

Next Tor Browser meeting is on Tuesday, 1/22 1900 UTC
by Georg Koppen 15 Jan '19

15 Jan '19

Hi, As next Monday, 1/21, is a national holiday in the US (Martin Luther King Jr. day) we'll move the weekly Tor Browser meeting by one day. The next meeting will then be at Tue, 1/22, 1900 UTC in #tor-meeting on irc.oftc.net. See you there, Georg

1 0

Reproducible Builds Summit
by Nicolas Vigier 18 Dec '18

18 Dec '18

Hello, I was at the reproducible builds summit last week. During the meeting there were discussions about various topics related to reproducible builds: - reproducible builds for various languages, filesystems and distributions - bootstrapping - rebuilders and user verification - software transparency I think the two most interesting discussions for me were about rebuilders and user verification, and software transparency. = Rebuilders and user verification = Some people from New York University have been working on a framework called in-toto which can be used to verify before installing a build that it has been reproduced by a number of trusted builders: https://in-toto.io/ They have implemented some prototype for Debian. Here is how it works: - some independent organisations are running "rebuilders". Those rebuilders fetch new Debian source packages and rebuild them. When the build is finished they publish some json files containing informations about the source package, and the result of their build, and their signature. - apt is modified (using an apt-transport) so that before installing a new package, it connects to known rebuilders and fetch their build informations. If the build has been reproduced by enough rebuilders, then the package is installed. I think it might be possible to implement something similar in Tor Browser, maybe reusing some parts of their framework. = Software Distribution Transparency and Auditability = Benjamin Hof is working on tools for Software Distribution Transparency and Auditability: https://arxiv.org/abs/1711.07278 https://debconf18.debconf.org/talks/104-software-transparency-package-secur… He has implemented some prototypes to improve software distribution transparency in Debian, using a public log server which can be used to monitor the packages which have been distributed to users. I discussed with him how something similar could be done in Tor Browser. Here is how it could work: - we add a log server which can be used to cryptographically prove: * inclusion of an update in the log * append-only operation of the log - when we release a new Tor Browser version, we add checksums of the new mar files to the log. - when the Tor Browser updater receives a new update, it checks if the update is in the log, before applying it. If the update is not in the log, then the update is not applied. - independant monitors analyse the logs. They check that all checksums published in the log correspond to a known release. They can also check that the build corresponding to those checksums is reproducible. The log is public, so anybody can monitor it. The main improvement from this system is that it allows anyone to check that all the updates used by all users are reproductible builds, while today you can only verify that for one downloaded copy of the software. Nicolas

6 6

Fwd: Landing in 66: force opt-in to run extensions in private browsing
by Tom Ritter 18 Dec '18

18 Dec '18

I don't think this will be concerning for Tor Browser; aside from needing to set the appropriate bits for the bundled extensions. -tom ---------- Forwarded message --------- From: Shane Caraveo <scaraveo(a)mozilla.com> Date: Tue, Dec 18, 2018 at 3:39 PM Subject: Landing in 66: force opt-in to run extensions in private browsing To: <firefox-dev(a)mozilla.org>, <dev-platform(a)lists.mozilla.org> This is an FYI so you don't get surprised in the near future. The extensions API includes support for an "incognito" entry in the extension manifest where an extension may opt-out of running in private browsing windows. Chrome has since made that the default, and requires an opt-in by the user to run an extension in private browsing. We're playing a bit of followup on this, since we bypassed the feature during the crazy ramp-up for webextensions. The intention is to land this for 66, and a large chunk of it landed the other day. Extensions currently cannot make use of what has landed (though tests can and do). Extensions will continue to work as they previously did until we pref the feature on. The next part to land will be additional UI in about:addons[1] that allows the user to enable an extension for private browsing. A pref (off for now) will be introduced to enable this. At that point, you will be able to play with it, however there is more work to be done at the webextension API level. The pref will not be turned on until all necessary API modifications are completed. Assuming that everything goes according to plan, you will see this pref'd on during the 66 nightly cycle. At that point, all of your extensions, excluding system extensions, will stop working in private browsing until you enable those you want to work there. If you are curious you can look through the meta bug[2]. If you have questions, please feel free to reach out to me, mixedpuppy, on #webextensions irc channel or #add-ons on slack. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1511636 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1380809 _______________________________________________ firefox-dev mailing list firefox-dev(a)mozilla.org https://mail.mozilla.org/listinfo/firefox-dev

2 1

Torbutton and Tor-Launcher Webextensions
by Matthew Finkel 13 Dec '18

13 Dec '18

Hi all, The next steps for torbutton and tor-launcher will be migrating from the restartless pieces to webextensions. This will be a requirement for the next ESR, and it is already the situation with the current Firefox releases. Also, they must be system add-ons. Overall, we believe nearly everything torbutton and tor-launcher currently do can be accomplished with webextensions (assuming I remembered all the things they do). The key here is using a "Webextensions Experiment" for extending the Webextensions API for our needs. https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webex… This should be enough for interacting with the XPCOM services the extensions currently use. The one problem we will have is observing the profile-after-change topic. We'll likely need another Firefox patch so we can trigger the current functionality. The main reason we can't achieve this with webextensions is webextensions are run asynchronously, so a webextension won't block the browser start-up progress (needed for TorProcessService in tor-launcher, and parts of torbutton). In torbutton, we may be able to provide domain isolation using the webRequest.onBeforeRequest event: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/… On this event, we should receive information about the connection, including the ProxyInfo. I wonder if we can use the current implementation in torbutton and overwrite the ProxyInfo object we're given from the request with a new domain-isolated ProxyInfo object. I haven't looked at the Firefox code, so I'm not sure if Firefox will use the modifications or ignore it. Personally, I think we should begin working on this within the next month or two, and begin testing the new implementation in the alpha series before we start rebasing Tor Brower onto the next ESR. - Matt

3 3

Planning TBA-a3, the next major Tor Browser for Android milestone
by Georg Koppen 11 Dec '18

11 Dec '18

Hi all, We recently released Tor Browser for Android 8.5a5 which was the second big milestone on our roadmap for mobile[1] and we start planning for the next one, TBA-a3. I started to look over all the open mobile tickets (and filed some that were missing) and tagged all those that we should have fixed for the next big milestone, TBA-a3[2]. Criteria for that were Sponsor8 requirements and impact of bugs for users. Please go through the list and think about whether there are tickets/bugs missing or not needed on it. Additionally, there are "parity" items I started at the end of the roadmap. If there are things I missed in those sections, then let's get them added! TBA-a3 is planned to be the last milestone which should have all the major pieces in place, which we want to have for the first stable release. Please join us in our planning meeting if you are interested. It will be on Thursday, 1900UTC, presumably in #tor-meeting on the OFTC network. (igt0, I hope this works for you as well. Please speak up if not.) Georg [1] https://pad.riseup.net/p/tbb-roadmap-2018-19 [2] https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TBA…

5 5

Meeting for planning our future sandboxing work (Fri 11/30, 1900UTC)
by Georg Koppen 29 Nov '18

29 Nov '18

Hi! We thought about planning a bit our future sandboxing work before the Mozilla All-Hands week. We'll have a meeting about that tomorrow, Fri 11/30 1900UTC in #tor-meeting, on the OFTC IRC network. Please join if you are interested! Georg

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
45
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev