Integrate onion-routing?

[Kreyren]

I would like to use nyxt as a superior replacement to the Tor Browser Bundle.

Is it in the scope of this project to provide a module that can be integrated in nyxt on demand that would:

1. Deploy onion-router in a sandbox used as a standalone for nyxt instance
2. Integrate a method to create a new circuit on demand
3. Establish multiple circuits and change them per connection

[neophrema]

Just one thought:
If its possible to evaluate that you are using nyxt as a browser this would be a bad tell who you are. This project isn't widely adapted and you should try to blend in. Is this assumption correct?
As an addendum: Does Nyxt has or can get the capabilities to pose as an different Browser?

[Kreyren]

DISCLAIMER: This is my informed opinion that should be peer-reviewed.

If its possible to evaluate that you are using nyxt as a browser this would be a bad tell who you are. This project isn't widely adapted and you should try to blend in. Is this assumption correct?

Yes, TBB works on that principle, because the TorProject wants to be safe with the new and unknown methods that can be used to footprint the user which are things from just checking the user-agent to using AI to learn how you move your mouse on the screen the user which in theory wouldn't help even using TBB as long as you are using the same mouse.

Due to that the privacy issues in TBB are common e.g. recently the proof of concept on https://fingerprintjs.com/ that can fingerprint invidual TBB users even if they don't change the settings as per TorProject's recommendation.

So i am leaning towards alternative solution of using a browser which is loaded from a standardized virtual machine (which assumes that we can't in nyxt avoid fingerprinting from the used system e.g. using OpenGL pixels to get unique driver versions) AND that randomizes the values that we know can be used to track people (thanks to EFF and their HideYourTracks campaign and similar fingerprinting tools and researchers) and act on new issues as they are found.

For that i think that nyxt would open a door to better TBB integration with this and similar actions taken.

---

FWIW if nyxt is going to integrate a new browser engine in common lisp then making it integration independent for things to render the websites e.g. using rustlang to generate a website would be great too.

[Ambrevar]

This is high on my priority list too! The relevant discussion is here: #1014

Part of the work needed to implement this must happen on the renderer side (for now WebKit / WebKitGTK), so we will probably have to work with upstream at some point.

Having a Lisp-based renderer like https://github.com/atlas-engineer/closure would be awesome and this mission much easier, but Closure is far from being usable, so this might not happen before a very long while... assuming that the project would get enough compatibility with existing websites, which is not a given.

Does Nyxt has or can get the capabilities to pose as an different Browser?

Not yet, although it's easy to have it pose as a "webkit" browser. We need more work to have it pose as any browser.

[Kreyren]

I see O.o i've would rather have this as a module or something that can be integrated in nyxt while having nyxt bare minimum to make it efficient for standalone forking tbh

[Ambrevar]

Sorry, have what as a module?
If you mean the privacy options, then it's already part of a mode. Most Nyxt features are implemented as modes. which makes it very easy to have a bare bone browser by simply removing all modes.

[worstname]

To start with a simple tor-browser mode, what about working from the "safest" mode approach in tor browser: https://tb-manual.torproject.org/security-settings

• This level only allows website features required for static sites and basic services. These changes affect images, media, and scripts.
• Javascript is disabled by default on all sites; some fonts, icons, math symbols, and images are disabled; audio and video (HTML5 media) are click-to-play.

This simplification might then be easier to go about trying to follow the design and adversary model of TBB: https://2019.www.torproject.org/projects/torbrowser/design/

Working out the fundamental TBB-esque design and making sure the onion routing/circuits are correctly used and such is an important first step I'd think. Just throwing some thoughts out here because it interests me.

[Kreyren]

Sorry i didn't get a notification about your previous message so i try to answer now:

i rather argue for a toggle switch and private window on-demand in nyxt that deploys a sandboxed environment with a standalone tor daemon that can be used and is optimized to be managed through nyxt e.g. requesting new identity, routing and inspecting the taken routes for the routing.

such client should also provide a method to provide an alternative to firefox containers with their own route patch to tor (so that each container is using different routing and identity)

It is also important to NOT let tor to route non-onion traffic over HTTP as that will expose sensitive data to the exit node maintainer.

These should be considered for the implementation to be comparable to the implementation in the tor browser bundle.

Sorry, have what as a module? -- @Ambrevar (#1514 (comment))

I like the idea of making nyxt as bare as possible and then enabling users to configure it where i was thinking that this implementation could just be a module that can be sourced to the bare nyxt to provide this functionality e.g. like importing a library in rustlang.

To start with a simple tor-browser mode, what about working from the "safest" mode approach in tor browser: https://tb-manual.torproject.org/security-settings ... -- @winningluser (#1514 (comment))

I don't like the approach where the understood threat is javascript used for fingerprinting and hardware acceleration that can be fingerprinted using a WebGL pixel on the website.

For that i would rather argue these being integrated within nyxt as separate options.

[Ambrevar]

In Nyxt, we offer optional, opt-in features either via official, embedded modes or extensions.

Modes don't "burden" Nyxt until they are activated. Each mode has its own Common Lisp package, thus they are cleanly separated from the rest.

Extensions on the other hand must be installed separately, then loaded from the init file.
Extensions can contain new modes or anything else, they have full access to the core Lisp code.

That said, I believe that private browsing is such a core feature that I'd rather have it as part of official Nyxt.
As mentioned above, we can integrate it into reduce-tracking-mode or create another, more specific tor-mode.

[jmercouris]

What Pierre says is very true. Modes insofar as they are completely standalone and not meta-modes (modes that activate other modes) place no additional weight/complexity on Nyxt.

I have however been thinking about it, and many users are requesting compile time options to enable and disable aspects of Nyxt. One user requested the ability to not compile the password manager. While I don't think we should make the core of Nyxt have parts that are optionally compilable (due to the added complexity), I do think it would be possible for a user to specify a list of modes that they want compiled with Nyxt. This would allow them to not have a reading-line-mode in their Nyxt if they don't want it. However, this presents a new problem: what if a Nyxt extension depends on the presence of a given mode?

As a result, the only logical compromise I can think of is allowing modes to not appear in the M-x menu.

[jmercouris]

I think this is out of the scope of Nyxt. This could definitely be an extension, but we aren't really personally interested in onion routing, or Tor.