Mullvad Browser

[MikeWalsh]

We usually place stuff like this in /opt. Then simply write our own desktop entry pointing to its location. Works for Puppy, AND for us.

Mind you, we're a bunch of born tinkerers anyway. Most folks wouldn't know where to start to get around the problem, especially if the "recommended" procedure doesn't work for them.....which is a crying shame, given that Linux was pretty much developed for "tinkerers".

That's the one big difference between Linux and Windows/Mac. With them, you're kinda stuck with what someone else has decided is the way things have got to work. With Linux, you have full control over your system.....so you simply MAKE it work to suit yourself!

If I'm building a package for Puppy, and the app in question turns out to be an "awkward" one, I'll build-in any necessary workarounds as I go....


Mike.

 

[ML_113]

Following Sphen's instruction I got it in the menu, then I put it on the side panel.

Note: there is a typo, post #15
cd ~/.local/share/mullvad-browser

 

[sphen]

Following Sphen's instruction I got it in the menu, then I put it on the side panel.

Note: there is a typo, post #15
cd ~/.local/share/mullvad-browser

Typo fixed. Thank you for pointing it out.

 

[sphen]

We usually place stuff like this in /opt. Then simply write our own desktop entry pointing to its location. Works for Puppy, AND for us.

Mind you, we're a bunch of born tinkerers anyway. Most folks wouldn't know where to start to get around the problem, especially if the "recommended" procedure doesn't work for them.....which is a crying shame, given that Linux was pretty much developed for "tinkerers".

That's the one big difference between Linux and Windows/Mac. With them, you're kinda stuck with what someone else has decided is the way things have got to work. With Linux, you have full control over your system.....so you simply MAKE it work to suit yourself!

If I'm building a package for Puppy, and the app in question turns out to be an "awkward" one, I'll build-in any necessary workarounds as I go....

Mike.

While I appreciate the control and openness of Linux, that "tinkerer" flexibility can also make it more difficult to work with and support those who like to tinker and "make it work" in non-standard ways. While Windows/Mac leaves you "stuck" with someone else's decision as "the way things have got to work", they also provide common standard ways for doing things that everyone understands and follows, which makes training and support easier.

I suspect that there is a standard way in Linux to install shared applications in a common shared directory structure, but the people behind Mullvad recommend installing it as a local application for each user. I can think of several plausible explanations for why, but I do not know the reason for myself. The explanation could be as simple as lack of interest, time, or resources.

 

[sphen]

On the matter of where one might place the mullvad tarball in one's filesystem, it is useful to consider how the dotfiles can be used. In the case where a user wishes to refresh the configurations various applications make when one deletes the dotfiles in one's home directory and then re-runs the applications to recreate them, a deletion of the mullvad contents extracted from its tarball within the dotfiles filesystem will not be recreated by mullvad. It would be lost. That suggests one is wiser to place the mullvad tarball and decompress it elsewhere in it's own directory, especially in the case of a mass dotlfile deletion as sometimes is desired. It's a similar reason for users to place their own "homemade" executables in /home/user/bin rather than /home/user/.local.bin with a placing of the latter in the PATH.

This post was and is confusing to me. I hope that @osprey can clarify its basic meaning.

Part of the problem is that I do not understand "dotfiles" in this context. It must be about retaining configuration settings and not about "hidden files".

Another point of confusion for me is that the Mullvad browser should not be retaining state information (session information) between launches, to avoid fingerprinting and de-anonymization. The Mullvad and Tor browsers are not typical applications in that regard. In theory, they should operate in an identical way between the first launch and subsequent launches.

 

[osprey]

sphen, dotfiles are hidden files, one and the same. It's the pre-fixed dot that characterises them. Different terms for the same thing are common in IT, e.g. "thumb drive" for "usb", "hard drive" for "hard disk" etc.

On the dotfiles and configuration, usually if one deletes a dotfile for an application, e.g. htop, then when that application is run again, it re-creates the dotfiles which hold its configuration, e.g. /home/user/.config/htop. If one has altered a configuration in a dotfile, but has broken it or messed it up beyond retrieval, then deleting it entirely is an option to have it recreated in original format on a subsequent opening of the application. That process and function are not available for mullvad, or for any other binary or source tarballs placed and decompressed in the dotfile directories. So, in a perhaps unusual case, but nevertheless a real one, of the wish to refresh all configuration in the dotfiles, and one deletes them all, if a binary had been placed there, it would disappear and not be recreated. Of course one may never need, or actually to do that, and so it may make no practical difference, but there are other considerations too.

In my view a more functional solution is to create a specific directory in /home/user to hold programs such as mullvad or perhaps consider using the filesystem's /usr/local or /opt directories. They can still be held in hidden files (dotfiles) if one wishes to conceal them in that way, but as sub directories of their holding directory. It's not so much a matter of the mullvad and tor programs, but a matter of installing a program that is outside the packaging system of one's distribution, unlike those packages installed through package managers which create dotfiles for configurations when they are opened if those dotfiles don't already exist. In the particular case of tor, it actually recommends that it be installed from it's own directory, and I expect mullvad to benefit from the same procedure though I've not checked what the mullvad docs say on the matter. Tor recommends that it be installed in its pristine state, and installing it in it's own directory, as it recommends, preserves that. The subsidiary benefits of such programs in their own directories include the freedom to impose whatever permissions and access controls (ACLs) one might prefer, which is not so straight forward when dealing with the dotfiles used in conventional package management. YMMV.

 

[MikeWalsh]

@sphen :-

Whilst I absolutely agree with your assessment above, it's probably fair to say that all the "tinkerers" of my acquaintance are experienced, long-term users. These guys are perfectly well aware that as soon as they stray from the "beaten track", they abandon all hope of expecting assistance from those who are versed in the 'standard' ways of Linux.

To be frank, they don't expect it, since they - and to a similar extent, I - look to solve our own problems. We tend to keep such trouble-shooting sessions "in-house", because the Puppy community encompasses an almost unbelievable breadth of experience in many & diverse fields. Whatever your issue, somebody, somewhere in our community is prepared to help you solve it.

And that's why I stated, quite clearly - when I joined here last year - that I was here primarily for the chat & banter "community" side of things. Given that I run Puppy exclusively, and that Puppy has her own unique approach to so many things, it's fairly pointless my attempting to give advice to those users who want/need help with specific problems in most of the mainstream distros. 'Our Pup' simply doesn't function the same in many cases; different package management, for a start.....nor the usual, 'full' terminal experience that mainstream users are accustomed to (Busybox is somewhat 'minimal', shall we say..?). And don't get me started on the 'odd' stuff like 'on-the-fly' loading of SFS package files.....such things are SO far outside most user's experience we might as well be talking a foreign language.

I no longer 'push' Puppy to the same extent that I once did. While I still think, and always will think that it's a uniquely flexible system, able to fit a ton of odd use-cases, I'm as likely to suggest to noobs/'hoppers' that they look elsewhere for their change-of-scene. Puppy is something you come to as & when you're ready for it. You gain nothing by pushing people into trying it before they can appreciate it...

-------------------------------------------

As for shared apps utilising a common, shared file-system structure.....been there, done that, bought the T-shirt years ago. Several of us at one time were using a full file-system structure, self-contained within its own directory, running from a shared partition external to every Pup in the kennels, manually installing unzipped packages to standard locations, then manually sym-linking every part of these packages into each Puppy where she would expect to find it. Initial set-up took a long time, though many sooner or later discovered it was perfectly possible to create .pet packages that consisted of nothing BUT sym-links, thereby enabling the 'linking' of several apps simultaneously.

In recent years, I've concentrated much more on 'portable', self-contained applications, where the user has the choice of running either totally portable, OR to run from a 'set' location via a Menu entry if that's preferred. These things will run happily from a flash drive, so can be shared between multiple machines for ultimate flexibilty.

I can almost guarantee that, no matter what use-case/possible scenario anyone can dream up, somebody, somewhere, possibly many years ago, has already investigated it..!

As the old saw has it, "There's nothing new under the sun".


Mike.

 

[osprey]

In case any readers are interested in a comparison of the mullvad browser with other privacy oriented browsers, this may be an interesting video that looks into it:

.

Briefly, it compares well in the privacy stakes with brave and librewolf, though there are some differences.

 

[hacktheworld]

How to install Mullvad Browser: (https://mullvad.net/download/browser)
Download the latest version then extract:

cd Downloads
tar -xvf mullvad-browser-linux-x86_64-13.5.1.tar.xz

Then use the "cd" command into the folder that you extracted:

cd mullvad-browser

Then run this command to start the browser:

./start-mullvad-browser.desktop

then in the same directory:
cp ~/Downloads/mullvad-browser/start-mullvad-browser.desktop ~/.local/share/applications/
(to create the icon).

Have a good Sunday!

 

[wendy-lebaron]

You will have to do this everytime there's an update and you feel the urge as if you have used eg. Firefox for long enough.

But the Mullvad does have a "self-update" feature, like Palemoon, right?

 

[hacktheworld]

Mullvad Browser updates automatically after a notification.
You can also click on the hamburger menu in the
upper-right corner>help>About Mullvad Browser to check updates
Have a good Sunday!!