Left a note in IRC to link up with someone and implement Windows/Mac support for this - don't have anything but Linux boxes handy and no licenses for Windows.

It seems the path for macOS is /Library/Application Support/TorBrowser-Data/Browser/Mozilla/NativeMessagingHosts/ but I still didn't managed to get it working.

Remove all the translation file changes, please.

Remove all the translation file changes, please.

Restored from origin/develop in df6c858

It seems the path for macOS is /Library/Application Support/TorBrowser-Data/Browser/Mozilla/NativeMessagingHosts/ but I still didn't managed to get it working.

Pinged you on IRC, lets get to work on resolving.

Feedback needed

Issues found

• In implementing Windows support - looks like native-messaging-hosts is a registry entry for FF and other browsers. Is this the approach we want for Windows?
• Tor is self contained and portable on Windows and can be on other OSes.
• We'd need to add a registry cleanup to uninstallation. And portable installs are not guaranteed to work.

Resolution Ideas

• I believe I should at a UI component to point to the Tor Browser installation. If I can avoid registry I'd like to, no footprint is a good footprint.
• I can run experiments to see if I can use the same approach I used in Linux with the Tor Browser .mozilla directory for native-messaging-hosts. This way would solve portable installations on all OSes.

If it works is this agreeable?

Been working on Windows without much luck - segfaults in ctest and gdb says its coming from a UI function. EditEntryWidget::setupColorButton, or at least it did in a prior build. Need assistance. Time for bed.

The branch of interest is in my fork: feature/tor-browser-windows-support

@varjolintu - Okay, reordered and pushed - awaiting TeamCity results to check output to see if semantic -Wreorder warning is gone.

This is pretty neat, and well executed, but I'm a bit concerned that this would be encouraging unsafe Tor behaviour.

https://support.torproject.org/tbb/installing-add-on-extensions-tor-browser/

I feel as though KeePassXC should not suggest to folks (via the listed browser checkboxes) that it would be a good idea to install the keepassxc addon in the Tor browser.

This is pretty neat, and well executed, but I'm a bit concerned that this would be encouraging unsafe Tor behaviour.

https://support.torproject.org/tbb/installing-add-on-extensions-tor-browser/

I feel as though KeePassXC should not suggest to folks (via the listed browser checkboxes) that it would be a good idea to install the keepassxc addon in the Tor browser.

This is understood - however, it uses many open-source extensions itself and the way this communicates is completely local and through a socket on your machine. Siphoning back and forth without the fear of intereception unless your node is already compromised. What I am going to do is see if any revealing details are transmitted during the transaction once all OSes are functional. If so I will be looking into this and encrypting the pipes.

Stackoverflow

If the desktop app has a command-line interface, then you can easily write a proxy application that serves as a native messaging host and interacts with the desktop application. It is essentially the bridge between your Chrome extension and some other application. This proxy application can be written in any language that supports stdin/stdout, and it does not require any cooperation from the original developers of the desktop app.

We have an SSH-AGENT... How about some encryted reverse proxies :)

the way this communicates is completely local and through a socket on your machine.

That is great and reassuring, but the concern is not just about network traffic, but the uniqueness factor that addons introduce to your particular tor browser instance.

it uses many open-source extensions itself

It only uses HTTPS Everywhere and NoScript, which are vetted and identical across all Tor Browsers. Deviating from that is discouraged by the Tor Project.
https://www.torproject.org/download/download.html.en#warning

the way this communicates is completely local and through a socket on your machine.

That is great and reassuring, but the concern is not just about network traffic, but the uniqueness factor that addons introduce to your particular tor browser instance.

it uses many open-source extensions itself

It only uses HTTPS Everywhere and NoScript, which are vetted and identical across all Tor Browsers. Deviating from that is discouraged by the Tor Project.
https://www.torproject.org/download/download.html.en#warning

There is no forcing of adding the plugin. I suppose I just don't understand the issue at hand.

This is for users that would like access to their KeepassXC database in Tor Browser - not one I'm expecting to become standard on a Tor installation. I've read the warnings many times. The gist if I remember correctly is don't do it out of lack of trust for exposing new holes to your browser and changing the fingerprint of all of its users.

There are malicious addons, sure. However - I understand the underlying code and will use it myself. The real risk lies in malicious code being added to the program or extension. If you wish to step aside from using the Tor integration - just don't check the box and alt+tab to copy your credentials. To me, that holds more of a risk than encrypted transmission to your browser. That copy is stored in memory in plaintext without a hook to decrypt on the other end.

Make sense? We are just in two different camps of usability. The actual notion that having a highly secured and standardized browser with all the general noscript/httpseverywhere/user agent spoofers/etc is actually creating a different fingerprint that is easy to find, not an obfuscated unique entity.

I feel as though the points you're addressing are not the concerns I brought up, but also I think we're getting a little off topic. I think its great that you know the workings of the code enough to trust it in this context, but many users of both KeePassXC and the Tor Browser do not, myself included.

KeePassXC's documentation is clear when presenting options that are potentially insecure if not used correctly (or those that make trade offs of security for convenience), such as the TOTP plugin, which I feel knowledgeable enough about to use confidently (and adore!), but maybe some other folks don't. Alternatively, when KeePassXC options do not have such warnings, I feel that its implied that its an overall safe thing to use. This is helpful to less technical folks, and in my opinion, that differentiation contributes to why KeePassXC is mentioned in beginning privacy guides by the EFF, the Freedom of the Press Foundation, etc. It would be a shame if the guides had to start following every mention with a disclaimer about avoiding the Tor Browser integration.

I feel like your change falls into the category of potential for security versus convenience (again, I'm not a Tor Browser expert, so I yield to the project's recommendations when I use it). With that said, I also feel like tools shouldn't necessarily limit what the user can do, so I propose a compromise of removing the mention of the Tor Browser from the quickstart guide, and adding (not recommended by the Tor Project) next the Tor Browser checkbox in the Browser Integration settings widget.

As I said, this is slick, nicely executed, and the testing and thought you put into this is awesome 🙂. I hope you haven't felt like I've attacked your idea or work at all, I just want to make sure KeePassXC remains a by-default safe option for all folks, technical or otherwise. Looking forward to hearing your thoughts on that.

I feel as though the points you're addressing are not the concerns I brought up, but also I think we're getting a little off topic. I think its great that you know the workings of the code enough to trust it in this context, but many users of both KeePassXC and the Tor Browser do not, myself included.

KeePassXC's documentation is clear when presenting options that are potentially insecure if not used correctly (or those that make trade offs of security for convenience), such as the TOTP plugin, which I feel knowledgeable enough about to use confidently (and adore!), but maybe some other folks don't. Alternatively, when KeePassXC options do not have such warnings, I feel that its implied that its an overall safe thing to use. This is helpful to less technical folks, and in my opinion, that differentiation contributes to why KeePassXC is mentioned in beginning privacy guides by the EFF, the Freedom of the Press Foundation, etc. It would be a shame if the guides had to start following every mention with a disclaimer about avoiding the Tor Browser integration.

I feel like your change falls into the category of potential for security versus convenience (again, I'm not a Tor Browser expert, so I yield to the project's recommendations when I use it). With that said, I also feel like tools shouldn't necessarily limit what the user can do, so I propose a compromise of removing the mention of the Tor Browser from the quickstart guide, and adding (not recommended by the Tor Project) next the Tor Browser checkbox in the Browser Integration settings widget.

As I said, this is slick, nicely executed, and the testing and thought you put into this is awesome slightly_smiling_face. I hope you haven't felt like I've attacked your idea or work at all, I just want to make sure KeePassXC remains a by-default safe option for all folks, technical or otherwise. Looking forward to hearing your thoughts on that.

No attacking at all, I understand completely. I have no gripes about adding warnings and removing from documentation. I was in fact going to add a QT popup with a warning if selected when I did the portable UI portion. Thanks for the input. Will be working on the windows/UI side later tonight. Thanks for the input @kneitinger. The compromise of security for convenience is the exact reason I recommended not enabling it if that was such a concern. I look forward to many more contributions with all of you.

But yes you are correct, lets stay on topic - I'm with you good sir.

@kneitinger Added a warning UI component to the TODO. Thanks for the discussion.

Cheers to that! Also, congrats on the first PR 🎉

I dig the idea of a pop up confirmation. It keeps the checkboxes area nice and tidy!

Can anyone else look into this, I am not a Windows user and am having quite the time getting past these segfaults: #2392

Can anyone else look into this, I am not a Windows user and am having quite the time getting past these segfaults: #2392

This also includes the registry change for Windows.

Tor Browser shares Firefox settings on Windows. I made the changes and this is ready for merge once CI completes.