tbb-dev

tbb-dev@lists.torproject.org

447 discussions

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

Ticket #19479 closed
by Bob Ham 30 Jul '17

30 Jul '17

Hi all, I've closed ticket #19479 as this bug has already been fixed by another ticket, #16337. An explanation is in the ticket comments: https://trac.torproject.org/projects/tor/ticket/19479#comment:9 Regards, Bob

1 0

nsIUserInfo (browser developer candidate)
by Richard Pospesel 21 Jul '17

21 Jul '17

Hi tor devs! I've spent today getting ramped up on building/debugging tor-browser and investigating a solution to issue #13398 <https://trac.torproject.org/projects/tor/ticket/13398> (NsUserInfo object scrapes user's name, username, email, and domain). My first instinct was to just completely remove the offending code and interface. It looks like some things have changed in this area since the issue was filed, as this information is no longer cached on firefox startup, but is still accessible via Add-Ons through the userinfo object ( https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/ Reference/Interface/nsIUserInfo ). So my question to you is in this case, do we prefer to completely excise the nsIUserInfo interface from the codebase (and break any user Add-Ons which use it) or do we prefer to replace all the per-system implementations with a single 'mock' implementation which returns empty string (or errors) for each property getter? Having read the design-doc (particularly the parts on finger printing) it seems like ripping out the class entirely is a bad idea as it would immediately identify the browser as a modern Tor Browser (given how old the API is and that vanilla Firefox still has it) and potentially break Add-Ons using it. However, simply returning empty-string for these properties would also identify the browser as Tor Browser. I know for certain that on windows the username (at least) will always return *something* so getting empty string here would also point to Tor Browser. All that said, I suspect either of the above solutions are preferable to leaking user identifying information. What do you think? best, -Richard

2 4

Ticket 21830
by Neill Miller 21 Jul '17

21 Jul '17

Hello, I have proposed a solution to this ticket: https://trac.torproject.org/projects/tor/ticket/21830 This issue is more involved than it seems, as there are a number of places that the nsTransferable is initialized and used without a loadContext, and it's not clear that the information required can always be passed along with it (e.g. when Invoked via the JS DOM path). That said, I think my proposal is better than what's there now, and am open to feedback/criticism of this method, as there may be configurations I'm not aware of (since I've only looked at this code for a couple days now). Please advise. Thanks, -Neill.

2 1

Tag: sandboxed-tor-browser-0.0.11
by Yawning Angel 18 Jul '17

18 Jul '17

Hello, Release early, release often and whatnot. As it is unlikely that I will have much time to work on this before the next alpha[0], I will tag 0.0.11 now. Changes in version 0.0.11 - 2017-07-18: * Bug 22910: Deprecate the volatile extension dir option. * Bug 22932: Add experimental Amensiac Profile Directory support. As of this release `about:addons`'s get addon pane is no longer supported at all, reflecting the (unrelased) change made to Tor Browser. As an additional defense in depth measure, addons inside the profile directory are explicitly and individually read-only bind mounted into the container, and even installing addons manually by copying the XPI into the profiles.default/extensions subdirectory will not work without altering the container setup and recompiling the sandbox. Note that the mechanism for whitelisting addons is somewhat more fragile than I would like, and in an ideal world, the Tor Browser addons would both be stored in `browser/extensions`, and cryptographically signed with a Tor Browser specific signing key. But it's an imperfect world, and in a perfect one, I'd be dealing with chromium instead[1]. The Amnesiac Profile Directory feature behaves basically as one would expect. At launch time the profile directory is copied into a tmpfs mount inside the container, so all changes made to the profile are non-persistent. The option is hidden under the `--advanced` command line flag, because it's experimental and I don't want to deal with people asking why the browser ate their preferences/bookmarks. The emphasis is on "Profile Directory", any files in the Downloads/Desktop directories inside the container are left as is, because I couldn't think of a sensible way to handle that, and a browser that can't be effectively used for downloads is rather worthless. No special handling "the user ran the update with the setting enabled". Odd/undesirable behavior may happen, so don't do that. The UI option to enable the setting is clearly marked as "Experimental" for a reason. Regards, -- Yawning Angel [0]: I reserve the right to totally flip out over more hideous evil in Firefox, if such things should come to light. [1]: I am being somewhat facetious here, and I am well aware of why this isn't the case. But since I just had to add code to deal with defanging "telemetery"...

1 0

get-tb-version broken
by Colin Childs 17 Jul '17

17 Jul '17

Hi everyone, Currently the Tor Browser user manual relies on the get-tb-version[1] script to build. This script broke some number of weeks ago, so I'm now looking into stripping that functionality from the manual. Before I go ahead and remove the functionality, I'd like to confirm that this script is no longer maintained? Thanks! [1]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/g… -- Colin Childs Tor Project https://www.torproject.org Twitter: @Phoul

2 3

← Newer
1
...
20
21
22
23
24
25
26
...
45
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev