May 2020 - tbb-dev - lists.torproject.org

Re: [tbb-dev] Canvas Breakage Ideas
by Alex Catarineu 21 Sep '20

21 Sep '20

On 5/19/20 6:02 AM, Matthew Finkel wrote: > On Wed, Apr 29, 2020 at 01:07:40PM +0200, Alex Catarineu wrote: >> With respect to 2), I think it's interesting, but I also don't know whether >> it's feasible in practice. Specifically, I was thinking of Gijs idea of >> trying to keep state about whether the canvas is safe to read or not, >> fingerprinting-wise. I assume that there is a (non-empty) subset of canvas >> write operations that are "fingerprinting-safe". Probably a bit naively, I'd >> like to think that `canvas.drawImage` is "fp-safe" (irrespective of the >> image source). But even if we have to check the image source, I think >> implementing this could potentially unbreak some of these common legit >> canvas use cases. >> >> For example, in the WhatsApp case mentioned above, I'm quite sure it's >> just used for image format conversion, since the bug does not occur >> when uploading "jpeg" images. So, that would be something like >> `canvas.drawImage(pngImage, 0, 0);` plus `canvas.toDataURL('image/jpeg');`, >> which should be covered if we implement the `canvas.drawImage` exemption >> when the image was uploaded by the user. This "fingerprinting-tainting" >> canvas logic might start with just the `drawImage` case, but perhaps it >> would be possible to extend little by little, if we know that some >> canvas write operation is safe and can help fixing breakage for legit >> use cases. > > I generally agree with your message, but I am curious about this idea. > Are you saying that ctx.drawImage() is fingerprinting-safe, or are you > saying that any "canvas extraction" from a canvas element initialized by > ctx.drawImage is fingerprinting-safe? As far as I'm aware, drawImage() > is not protected by the Canvas prompt (so that should never be a > problem). If your comment was about "subsequent canvas extraction", then > that is worth investigating. Yes, by fingerprinting-safe I meant the subsequent canvas extraction after a `drawImage`. And by checking the image source I meant that we might consider a `drawImage` fp-safe if we know the input is an image uploaded by the user, even if `drawImage` was not "fingerprinting-safe" in general (with the idea that canvas extraction might not result in useful fingerprinting in that case). > Are any of the conversions passed onto the > GPU? Do we know if format conversation is deterministic? True, I did not consider that the extraction (e.g. `toDataURL('image/jpeg')`) might add some entropy by itself. Good questions, we would need to investigate if this approach is going to be pursued. And I agree with tom, it would be good first to investigate what these sites are doing exactly with the canvas to evaluate what would be the best approach.

5 10

Tor Browser: Re-enable 'javascript.enabled' on safest security level?
by analord＠secmail.pro 01 Jun '20

01 Jun '20

Hey, as far as I know, javascript.enabled was disabled by default on the safest security level due to an issue with NoScript not blocking scripts when it should have in certain cases. As far as I know, this issue has been fixed on the latest NoScript version. To me it would make sense to revert the change disabling javascript.enabled by default and use a tight NoScript permissions list by default on the safest security level, so users such as myself can decide to whitelist sites that require JavaScript through the NoScript panel, instead of having to open about:config and changing it manually. Thoughts? P.S: Excuse the posts to the other mailing lists, apparently I can't read and couldn't find the right mailing list. But eh, more exposure I guess..

2 1

So there apparently is a way to autoupdate firefox on startup on WIndows
by Keifer Bly 29 May '20

29 May '20

2 3

Lost my trac permissions somehow?
by Rusty Bird 28 May '20

28 May '20

Hi, I wanted to upload a patch for https://bugs.torproject.org/10394 but my account (rustybird, this email address) apparently can't reply, or do anything really: | TICKET_CREATE privileges are required to perform this operation on | Ticket #None. You don't have the required permissions. Rusty

2 2

Request for help: debugging Moat in Tails
by anonym 22 May '20

22 May '20

Hi, As I said to Matt and Georg during a meeting, I've had some major headaches with getting Moat to work in Tails, and even debugging it has been hard. To give you an idea of the latter, I couldn't get access to Tor Launcher's logs, so I had to ugly-patch it to always spam the full log into the clipboard just to get it some how. For the former, the actual error I see is this prompt, right after clicking "Request a bridge...": Unable to obtain a bridge from BridgeDB. NS_ERROR_NET_INTERRUPT I've attached the logs of Tor Launcher and obfs4proxy when this happens. To me it certainly seems like the problem is somewhere in their interaction. Note that Tails runs Tor Launcher as a standalone XUL application (via `firefox --app`, using the executable from Tor Browser) and not a (system) extension as in Tor Browser. This might be responsible for the issues I'm having, but if so I have no idea why, or even how to approach debugging it. Any ideas? How to reproduce inside Tails ============================= If you feel adventurous and would like to try to reproduce this and investigate further, you can fetch an image built from the feature branch here: https://nightly.tails.boum.org/build_Tails_ISO_feature-8243-meek/lastSucces… <Note> The Tails project is in the process of migrating from Redmine to GitLab, and as a result our Jenkins isn't building images for us. Therefore the last images available at the moment are built yesterday (2020-05-19) and lack a small fix I just pushed: enable obfs4proxy debug logging. You can enable the logging yourself by running the following as root: . /usr/local/lib/tails-shell-library/tor.sh tor_control_setconf 'ClientTransportPlugin="obfs2,obfs3,obfs4,meek_lite exec /usr/local/lib/obfs4proxy/obfs4proxy -enableLogging=true -logLevel DEBUG managed"' </Note> Booting the .iso in a VM of you choice is probably the easiest approach. If you want to look at the code of the feature branch, feature/8243-meek [0], you can do so here: https://git.tails.boum.org/tails/log/?h=feature/8243-meek or if you prefer to Git clone it: git clone https://git-tails.immerda.ch/tails && \ cd tails && \ git checkout feature/8243-meek The build script which installs Tor Browser and Tor Launcher is probably the most interesting bit for you (my guess is that you don't need to look at it, though): https://git.tails.boum.org/tails/tree/config/chroot_local-hooks/10-tbb?h=fe… Once you boot Tails and reach the Greeter you'll have to set two "Additional settings" by pressing the + button (in the GUI, not on the keyboard): * An administrative password so we can run stuff as root * Enable Tor Launcher via: Network configuration → Configure a Tor bridge or local proxy As soon as you have logged in and your network is up you need to run this as root: /usr/local/lib/do_not_ever_run_me which disables the firewall completely (I haven't bothered opening up properly for Moat yet). This command must be rerun if your network reconnects. As you may notice Tor Launcher will start automatically once you log in and have a network connection, but if you want to run it again without having to reboot (very likely!) you can do so by running this as root: tails-tor-launcher Some other things that might be useful when debugging ----------------------------------------------------- The path to the obfs4proxy executable (copied straight from the Tor Browser bundle): /usr/local/lib/obfs4proxy/obfs4proxy We run Tor Launcher under a dedicated 'tor-launcher' user whose $HOME is: /home/tor-launcher The Tor Launcher's app profile is located in: /home/tor-launcher/.tor-launcher/profile.default The obfs4proxy log can be found in: /home/tor-launcher/Tor/pt_state/obfs4proxy.log And as I already mentioned, Tor Launcher is patched to dump its full debug log into the clipboard for each log event, so just paste into Gedit or whatever. I also recommend quitting Tor Launcher as soon as you have done this, as it otherwise will keep spamming your clipboard and probably mess things up for you. :) Cheers! [0] It's in the branch for Meek because when we had (successfully) implemented a PoC for it, it occurred to us that we need to provide Moat at the same time as an alternative. Details: https://lists.torproject.org/pipermail/tor-dev/2020-March/014189.html

3 3

Canvas Breakage Ideas
by Tom Ritter 19 May '20

19 May '20

Sanketh is tackling some fingerprinting patches; he's doing great. We ran across two questions we wanted input on. Background: Frequently sites break from the canvas permission prompt in the following way: User uploads image Website tries to display image back to user Image is white because it rendered the image to a canvas then tries to read the canvas data Examples: https://bugzilla.mozilla.org/show_bug.cgi?id=1631673 https://bugzilla.mozilla.org/show_bug.cgi?id=1456378 https://bugzilla.mozilla.org/show_bug.cgi?id=1573834 1) Sanketh had the idea of after granting permission, we show an additional prompt suggesting the user reload the page; since websites are not built to handle our 'well just try it again, it'l work this time' change to canvas APIs. Thoughts? 2) In https://bugzilla.mozilla.org/show_bug.cgi?id=1631673 Gijs had the idea of changing our behavior if the user has uploaded a file, and using this as a queue to automatically allow canvas extraction. Specifically he focused on allowing the website to read out the file the user has just uploaded; and that only. That would be ideal, but -with no testing and just hypothesizing - I doubt it would work because some as simple as e.g resizing the image would cause the match to fail and be dis-allowed. But we could test this. My idea was much simpler: if the user has uploaded a file, we take that as a queue they trust the service; and then grant the canvas permission prompt. (In as tightly as scoped a manner as possible, but the scoping is really just a bandaid over the problem....) Sanketh and Simon pointed out that this is dangerous: just because a user uploaded a file doesn't mean they consented to be fingerprinted. And they're right; if a user is trying to have an anonymous account or something similar, uploading a file is not a trusted relationship permitting fingerprinting. So the question then is, it seems like given Tor's strict stance, the only way this could be implemented was if the data read from the canvas was an exact match on the uploaded data. Is that accurate? If so, the next step would be to test these websites, because if they don't behave that way it's probably not worth implementing this at all. -tom

4 5

Firefox 78 Will Fuzz the Canvas to Resist Fingerprinting
by Sanketh Menda 18 May '20

18 May '20

Hello, For the past few weeks, tjr and I have been working on a patch for Firefox RFP which will fuzz the canvas, the feature is now in Firefox Nightly and seems stable. The rationale for this change is already expressed very well by tjr in the description of <https://bugzilla.mozilla.org/show_bug.cgi?id=1621433> and I am not going to try to butcher it. With that, I invite you to test out this feature in Firefox Nightly. Best, Sanketh

1 0

Requesting feature for tor browser
by Keifer Bly 14 May '20

14 May '20

Hello, Is this the correct list to request features for tor browser? It would cool if there was an option to update tor browser automatically on start. --Keifer <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 1

Fontconfig warning / "blank" in fonts.conf
by clematis 06 May '20

06 May '20

Hello, "Fontconfig warning: line 145: blank doesn't take any effect anymore. please remove it from your fonts.conf" I did find multiple references of this in trac but nothing really recent. The font/fingerprinting seems to be a large topic. But I've got this message more often in 9.0.9 and still have it in 9.0.10. I don't recall seeing so many of them in <=9.0.8 Just a quick check, is it worth opening a new bug? or is that largely known. Platform is OpenBSD-current but this fonts.conf is the same in the linux build so I doubt it's specific to that platform. Thanks. Regards, -- clematis (0xA2C87EDB507B4C53)

3 3