tbb-dev August 2017

tbb-dev@lists.torproject.org

5 participants
7 discussions

Re: [tbb-dev] [tor-dev] RFC: porting torbrowser (was: Re: GNU Guix and Tor Browser Packaging)
by ng0 09 Mar '18

09 Mar '18

Hi, It seems as if tbb-dev(a)lists.torproject.org is the list which would be more appropriate. If the 7 days without a reaction are simply due to the holidays in some countries, it's my mistake. If you need internal discussion about this to respond appropriately, let me know that you are reviewing this message at all. I have no expectation for "neoliberal optimized" reply times. Thanks. ng0 transcribed 7.9K bytes: > Hi folks, > > as your trademarks team / person suggested to me I get in touch with the > dev team of torproject. While I'm more involved in GNUnet, I work at the > intersection of projects. Currently this means I'm involved in system > integration. At Guix we are interested in working closer with projects > like tor, TAILS, Whonix and the like. Porting torbrowser is not only in > the interest of the Guix community but also in the interest of Wonix who > recently expressed interest in selectively using Guix for their work. > For me as maintainer of the system (in development) pragmaOS it also > means that we can decide between icecat OR torless torbrowser for > proxied GNUnet connections. > > I'm interested in your response to the actions listed below and wether > you think this will still qualify as torbrowser or what other option you > propose for us at Guix to use. "Option" here means that I am not sure > what other graphical theme you have for versions of the browser which do > not use the trademark when they can (logically) also not use the firefox > trademarks. > I would reflect in the description of the package that it is not > torbrowser but a reconstruction of the way torbrowser is build, tracking > upstream as closely as possible while removing (list of features which > were removed goes here). > This can be compared to what the inoffical Gentoo maintainer does in the > .ebuild file here: > https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/ > > My request here is just in the position as a contributor to Guix, not > for pragmatique (the project which works on pragmaOS etc), Whonix, > GNUnet or any other project I mentioned before. > > Thanks in advance. Now the content I've been talking about: > > It looks like the changes I need to make to torbrowser are not so > grave at all. Someone pointed me to the gnu-linux-libre(a)nongnu.org list > to reach out to other FSDG systems. > The thread can be reviewed here: > https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-03/msg00002.html > > Basically: > > I will need to discourage Mozilla leftovers: > - the mozilla addon service will be overwritten, in other words: > Where you would find https://addons.mozilla.org/ at "Preferences > AddOns" > it will be replaced by the thing Icecat points to. Longterm plan is > to offer firefox extensions native through "guix package -i > youraddonnamehere". > > Privacy / Tracking reasons: > - Firefox "Sync" will be disabled. > - Google will be removed from the search plugins if I understood the > procedure correctly (at least it is not in Icecat) > > A question directly for torbrowser team: > - about:license does not list licenses the torbrowser project uses, only > firefox. Why? > > DRM > - Luke from parabola mentioned that drm has been enabled in recent > versions of torbrowser. This needs to be removed aswell. > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js#n23 > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/mozconfig#n39 > https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/fire… > > ng0 transcribed 3.4K bytes: > > bancfc(a)openmailbox.org transcribed 1.9K bytes: > > > There is a serious Tor Browser packaging effort [3][4] being done by ng0 > > > (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports > > > > Eh, now that the cat is out of the bag (cat's don't belong into bags > > anyway), I think I have to do this now and not on my own conditions. > > > > Hi! > > > > As I told bancfc somewhere else, I've had a short contact with the > > trademarks team of torproject. I will get back to you when someone was > > able to identify issues in torbrowser which might lead to modifications > > of torbrowser (for more details I just hope trademarks(a)tp.o can > > communicate it to you) because all packaged software which is included > > in upstream of Guix (master) must follow the GNU Free System > > Distribution Guidelines. > > I hope that I have to make as little modifications as possible as I > > I am aware that the fingerprint of the browser could change depending on > > the kind of changes. > > > > I hope to get back to this task in about 3 weeks, right now I'm busy > > with getting more documentation done for another project. > > > > > transactional upgrades and roll-backs, unprivileged package management, > > > per-user profiles and most importantly reproducible builds. I have checked > > > with Guix's upstream and they are working on making a binary mirror > > > available over a Tor Hidden Service. [2] Also planned is resilience [2] to > > > the attack outlined in the TUF threat model. [1] > > > > > > Back to the topic of Tor Browser packaging. While there are good reasons for > > > Debian's pakaging policies they make packaging of fast evolving software > > > (and especially with TBB's reliance on a opaque binary VM for builds) > > > impractial. Both we and Micah have been doing a good effort to automate > > > downloading and validating TBB but I still believe its a maintenance burden > > > and Guix may be a way out of that for Linux distros in general. > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > *** > > > > > > [0] https://www.gnu.org/software/guix/ > > > [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md > > > [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html > > > [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html > > > [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- > PGP and more: https://people.pragmatique.xyz/ng0/ > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- PGP and more: https://people.pragmatique.xyz/ng0/

4 8

Pearl Crescent weekly status update
by Mark Smith 28 Aug '17

28 Aug '17

I should have mentioned last week that Kathy and I will be out of the office at various times this week, including all day tomorrow (Monday), all day Thursday, and parts of other days. I am sorry we will miss the weekly meeting again, but here is our status report: Last week, Kathy and I worked more on implementation of the configuration portion of the new Tor Launcher design (#23261). We made a "work in progress" add-on available so people can experiment with the new UI. Then we worked on integrating a simple progress bar into the Tor Launcher setup wizard (#23262). Doing this will get us closer to the full UX that Linda designed, although we will need to implement a more informative progress bar later. We also purchased airline tickets for the Montreal Tor meeting, so our travel plans are all set now. Kathy and I will arrive Wednesday morning and we will fly back to Michigan on Saturday afternoon. This week, we will continue to work on the new Tor Launcher UI, especially the integrated progress bar. Also, since we did not get to it last week, we plan to create follow up patches for #22618 ("Downloading pdf file via file:/// is stalling if the external helper dialog is enabled"). -- Mark Smith Pearl Crescent http://pearlcrescent.com/

1 0

Fwd: Intent to ship: Changing default Japanese fonts to modern fonts
by Tom Ritter 24 Aug '17

24 Aug '17

Some input on Asian font preferences we could consider. -tom ---------- Forwarded message ---------- From: "Masayuki Nakano" <masayuki(a)d-toybox.com> Date: Aug 23, 2017 12:20 AM Subject: Intent to ship: Changing default Japanese fonts to modern fonts To: <dev-platform(a)lists.mozilla.org> Cc: Hi, We decided that we should change our default Japanese fonts from legacy "MS PGothic" (sans-serif) and "MS PMincho" (serif) which have bitmap glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu Mincho" (serif). This has been enabled on Nightly and early Beta since 55 [1]. Then, I removed the |#ifdef EARLY_BETA_OR_EARLIER| in Nightly yesterday [2]. I.e., the new default settings are enabled on release build starting from 57. I'd like to introduce some backgrounds: "Meiryo" is installed on Vista or later (but not installed on Win10 unless you add Japanese in system language settings). "Yu Gothic" and "Yu Mincho" is installed on Win8.1 or later. Both Edge and Chrome already started to use "Meiryo" as their default Japanese fonts. So, using "Meiryo" improves the compatibility between browsers and just looks better and is easier to read than bitmap glyph. One of the reason why we didn't use "Meiryo" as default fonts is, "Meiryo" has normal style glyph as italic style glyph. E.g., |a<i>b</i>c| looks like |abc|, not |a/b/c|. The other browsers have this issue, but I see many users who complain about this issue. For solving this issue, we added a hack to ignore italic style family of "Meiryo" at loading fonts [3]. So, now, Gecko is the only one engine which supports italic style Japanese text with default fonts! On the other hand, there are still some problems. "Meiryo" has too big internal leading for supporting accent marks of Western languages. This causes increasing normal line height than other fonts. Additionally, Gecko's normal line height computation is not same as the other browsers. Therefore, this may cause compatibility issue with the other browsers. For example, our <input> allows to scroll its content. Therefore, if user drags text in <input> vertically, the text may be scrolled [4]. If we could use "Yu Gothic" as Japanese default font, it'd be really nicer except compatibility with the other browsers because it has nicer glyph than "Meiryo" ("Meiryo" was designed for UI, not for document. Therefore, it was designed as easier to read even if the font size is small) and does not have too big leading like "Meiryo". However, there is a big problem. Text renderer of Windows has a bug. Text of "Yu Gothic" is rendered as too light [5]. So, the contrast between text and background color may not be enough for some users. Therefore, currently, we use "Yu Gothic" as a fallback font only when "Meiryo" isn't available. Anyway, I believe that this makes 57 look nicer for Japanese users! [1] https://bugzilla.mozilla.org/show_bug.cgi?id=548311 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1354004 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1351332 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1378065 [5] https://bug548311.bmoattachments.org/attachment.cgi?id=8848439 -- Masayuki Nakano <masayuki(a)d-toybox.com> Software Engineer, Mozilla _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

2 1

status report from Pearl Crescent
by Mark Smith 21 Aug '17

21 Aug '17

Sorry for the late notice, but Kathy and I will probably not be at the team meeting today because we have decided to spend some time outside viewing the eclipse (even though the sun will only be about 81% blocked here). Here is our status report: Over the past two weeks, Kathy and I have mostly been spending time on Tor Launcher improvements. We created a patch for #23240 ("do not show progress bar at zero when bootstrap progress is greater than zero ") and are seeking feedback. We worked on #21542 some more ("use Subprocess.jsm to launch tor") but due to some issues with how the asynchronous Subprocess API interacts with browser startup, we have put this ticket on hold. We plan to revisit it after we have made more progress on the new Tor Launcher UI, because having fewer modal windows will make some things easier (the new Tor Launcher UI design eliminates the separate progress window). Speaking of the new design, we provided more feedback to Linda on the copy (text) and on the UI design itself. We started to implement the configuration aspects of the new design (#23261). We made a lot of progress and hope to provide something this week for other people to experiment with (not a finished product but a taste of what is to come). Also note that currently our focus is on existing functionality; we have not started to work on moat yet (bridgedb integration). Other things we did over the past two weeks: We helped with bug triage and user support. We participate in the IRC-based browser developer interviews. This week, we will continue to work on the new Tor Launcher UI. We also plan to create follow up patches for #22618 ("Downloading pdf file via file:/// is stalling if the external helper dialog is enabled"). -- Mark Smith Pearl Crescent http://pearlcrescent.com/

1 0

Next Tor Browser meeting on Monday, August 21 1800 UTC
by Georg Koppen 10 Aug '17

10 Aug '17

Hi, We will skip the Tor Browser meeting on Monday, August 14. The next one will be on Monday, August 21, time and place as usual: 1800 UTC in #tor-dev on the OFTC network. See you there, Georg

1 0

MacOS DMGs result in "no mountable file system" error message
by Jörg Hartmann 10 Aug '17

10 Aug '17

Hi, on my MacOS 10.12.5, both the stable 7.0.2 and the unstable 7.5a1 of the Tor Browser Bunde's DMG files, unlike all other (non-Tor) DMG files I come across, can't be mounted by the system's own DiskImageMounter. Trying to do so gives a "no mountable file system" error message. When extracting the included TorBrowser.app with BetterZip, the resulting file can't be run. Cheers, J.

2 1

Tag: sandboxed-tor-browser-0.0.12
by Yawning Angel 01 Aug '17

01 Aug '17

Hello, I tagged sandboxed-tor-browser 0.0.12 just now. Changes in version 0.0.12 - 2017-08-01: * Bug 22969: Disable the addon blocklist. * Bug 22984: Force IDNs to be displayed as punycode to thwart homograph attacks. * Bug 22967: Force disable crashdump reporting. * Bug 23058: Apply the SelfRando workaround to 7.5a3 as well. * Default disable `dom.securecontext.whitelist_onions`. Rationale for the potentially controversial changes are as follows: * Disabling the addon blocklist is done to thwart Mozilla from attempting to disable extensions critical to Tor Browser functionality. While this would have a net negative impact on user security if non-standard addons had security problems that required emergency disabling, the sandbox was changed to exclude non-standard addons when creating the container as of 0.0.11. Enabling non-standard addons in the sandbox would require altering the source code and rebuilding. Anyone who does that is on their own. * Forcing IDNs to be displayed as punycode is the mitigation for #21961. Mozilla isn't fixing this, the Tor Browser developers are apparently busy, so the sandbox will do it. * Force disabling crashdump reporting is a pre-emptive opt out from the GSOC crash reporting project. I do not have time to examine how crash dumps are sanitized, and until I do, I will treat them as a massive anonymity hazzard. Till crashdumps are enabled (hopefully as an opt-in with lots of warning labels), this will have no effect. * Default disabling `dom.securecontext.whitelist_onions` means that unless the user manually flips the pref, the `.onion` TLD will retain the existing 7.0.x behavior. As I've said before, I'm firmly against any changes that blur the line between Onion Services and TLS with a CA signed cert. People are free to disagree, but I'm unlikely to change my mind. Till the pref is actually implemented, this will have no effect. Regards, -- Yawning Angel

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev August 2017