bookmark_borderOur YouTube proxy is live. Here’s why you should consider using it.

We love privacy. So much in fact, we’re building a business around it. But did you know that we also sponsor and promote the use of many free and publicly available projects that help protect your online privacy?

It’s no secret that Google, and therefore YouTube, is privacy nightmare. But in this modern age of internet, can you even watch YouTube videos privately, and without feeding information to Google? Can you watch a YouTube video without being fed irrelevant advertisements? Can you access YouTube’s content from anonymity networks such as Tor and I2P? You absolutely can!

We operate a public Invidious Instance in our Luxembourg location. Invidious is an opensource and actively developed and updated privacy front-end for YouTube.

You can view our Invidious install using the following URLs:

The main benefits of using our Invidious instance is that, by default, all videos are proxied through our network so that your requests for YouTube content is made to us, we make the request to YouTube, YouTube feeds it to us and we pass it on to you. Nowhere in this process do you and YouTube ever make a direct connection. (Useful for accessing YouTube on networks where it’s blocked).

Additionally, you can register for a free account with no personal information required. With registration, you may then build playlists and subscribe to the channels that you know and love.

The fact is, there are many great “YouTube alternatives”, but what they all lack is the only thing that keeps YouTube relevant today: Content.

(More on this in a future posting)

Here are the main benefits to using our YouTube proxy:

  • Powered by an open source, actively developed project.
  • Proxies all requests to YouTube through our network by default.
  • No ads! No ads embedded on the site, and no ads in the videos.
  • Great site to use on mobile. You can switch apps, browsers, watch picture in picture or listen to audio with the screen turned off. You can not do that with the official YouTube app.
  • No logging, no tracking. Google/YouTube can’t track you, and neither can we. We can’t determine what you are searching for, and quite frankly, don’t care what you’re watching. We can’t see your playlists or subscriptions.
  • Quickly / easily download YouTube videos straight from your browser. Watch later, offline.

It seems to be getting some use.

Below is a network graph from the last two weeks of our Invidious instance being online. We’ve got bandwidth to spare, and hope to see that the service gains more traction and use by others. I personally use it as a full replacement to YouTube, where any link or request on my local machine gets automatically redirected to (Ex: If I click on , then it automatically sends me to )

Last two weeks of traffic use. We’ve got bandwidth to spare
(Ignore the blip. A configuration error on our end left the software inaccessible for that period)

At the current rate, we should see about 10-15TB of bandwidth for videos that visitors have requested without feeding the beast that is Google.

We have a lot of public privacy projects online or in the works, and we’ll be doing write ups on them in the future. What sort of pro-privacy public projects (say that 5X fast) would you like to see us host and sponsor? Let us know!

bookmark_borderOur public Yggdrasil Network Peer is now online.

We love supporting network projects that aim to help keep users anonymous and private. It’s why we run high performance I2P Network Routers to help route traffic and donate bandwidth to the Invisible Internet Project and have plans to implement TOR relays and exits. Like most networks, the anonymity, reliability and overall performance is directly related to how many available nodes are available to handle and pass traffic. It appears Yggdrasil is no different in that regard, and we’re happy to announce our Luxembourg based Yggdrasil Network Peer is now online and available as a resource to all.

Yggdrasil is an early-stage implementation of a fully end-to-end encrypted IPv6 network. It is lightweight, self-arranging, supported on multiple platforms and allows pretty much any IPv6-capable application to communicate securely with other Yggdrasil nodes. Yggdrasil does not require you to have IPv6 Internet connectivity – it also works over IPv4.


Installation is a breeze, and you can find the install notes on Yggdrasil’s official website here:

Now, before you can get started browsing the Yggdrasil network, you must first configure Yggdrasil to peer with a network node. In the configuration example below, we’re using our own node.

Modify /etc/yggdrasil.conf so that your peers section reflects below.

Peers: [

You can find more public peers here: (Note, we are not yet listed on the public peers page but I suspect we will be soon) . One, two or three peers that are relatively geographically close to you should suffice in your setup.

So far, the Yggdrasil Peer is not pushing much traffic. We hope that it will get more use in the future. The image shows the last 48 hours of network traffic.

  • Public IP:
  • Yggdrasil IP: [200:9208:70c1:fd67:ddce:7c2f:f85a:8e20]
  • TCP port: 42069
  • TLS port: 42024
  • Location: Luxembourg

bookmark_borderThe ad, tracker, and other “bullshit” blocking VPN beta – How it’s going so far.

Almost a month ago we opened a free, public beta of our VPN service. The purpose of this beta was to help us make sure that our blocklists only blocked ads, trackers, malware, and other “BS” but did not prohibit users from accessing the content that they wish to view.

Preliminary testing shows that: So far, so good!

We have observed that anywhere between 15-30% of all DNS requests made by users are blocked from resolving over our VPN network. These are requests that are embedded into websites and apps that do not serve any meaningful purpose to you, the end-user. Instead, these elements exist to collect information about you (trackers), sell you stuff (advertisements) or in severe cases: Steal your information (phishing and fraud sites). What you receive by using our VPN service is a safer internet and the ability to protect your web identity while using less local bandwidth by us filtering out all the junk.

This public beta was initially launched in our Luxembourg location, but we decided shortly after to make it accessible from an American location as well (Las Vegas). Although our operation exists around privacy and anonymity, we will be offering one or two US-based locations for users who wish to access country-locked content in the USA. (Likely a West Coast option for good connectivity for the Asian region and an East Coast option for good connectivity to Europe)

After some testing of a Kiev, Ukraine based service provider, we have decided that our 3rd location for VPN services will launch there. We were very impressed with the speeds on the network, the connectivity to our other locations and the overall experience and communication with the upstream provider who shares our core values as a company.

In an effort to be as open and transparent as possible, we have released our existing blocklists which are available for public review here as well as available for your own use on any network device that accepts blocklists (pfBlockerNG, pi-hole, etc). These lists were created from current, publicly available and community sourced lists. What we did was simply merge, organize, and remove duplicate entries and known false positives while adding some of our own discoveries to the lists. These lists will evolve over time and be updated frequently.

Feedback has been positive so far.

The purpose of the free beta was to collect feedback, however many who have signed up haven’t actually provided us with any feedback yet. Those who have, however, have had this to say and share:

“Got 165 Mbit through directly wiring into Starlink just now for a test location in Michigan so from Michigan Test Location > Lux > Starlink > Me still hit 165 Mbit”

Beta tester using the Luxembourg location.
Pulling over 500Mbps from their fiber connection at home over our VPN!

“It seems to be as fast as what my Wi-Fi can handle.”

Beta tester using the Luxembourg location.

“I didn’t notice any (ads) on my computer.”

Beta tester using the Las Vegas location.

And although I may be personally biased, I can say with honesty that all my devices at home as well as my phone has been connected to our VPN network for a good month or so now. In every test environment that I have setup I have not installed the normal uBlock ad-blocker plugin for Firefox as I normally would. Instead, I’ve just let the VPN do it’s thing.

There are still some minor limitations. Some ads, such as those served over YouTube, will still load. This is due to how YouTube serves advertisements, using the same URL structure as the actual content they serve so blocking ads would mean blocking YouTube videos from working. Smart move on their behalf, but luckily it does seem that in-browser plugins such as uBlock does well in detecting and stopping those. You can also access YouTube via our Invidious installation, which is a privacy focused front-end for YouTube that disconnects you from Google and serves the videos and content through our network instead. With this method, before and in-video ads are eliminated. Check it out at !

With other services such as Spotify, we’ve had success in blocking most, but not all ads along their free service. In my own testing I have been prompted with the normal, “Watch this short video for 30 minutes of ad-free music” and when clicking it, it just goes straight to music and doesn’t try to load the ad. For now, we have the Spotify ad-block list running and will tweak it more as needed.

It would appear that your favorite adult sites will continue to function as normal, though do not be alarmed over the new lack of “hot singles in your area that want to meet you.” Those were ads, and now they are no more… But we’re sure hot singles still want to meet you.

We’re still testing with common and popular phone apps however nothing that we have tested so far has appeared to be broken.

What are your favorite sites or apps? We’ll test them over our VPN network and do everything we can to ensure that we’re stripping out any trackers, ads, or BS.

bookmark_borderLinux devices have a unique identifier called machine-id. Here is how to change it.

What is a machine-id, and why should you randomize it? From the machine-id man pages, it is defined as:

This ID uniquely identifies the host. It should be considered “confidential”, and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly.

In an effort to promote privacy, having a unique and unchanging identifier tied to your device seems like the wrong approach. It’s quite possible that poorly coded or even maliciously coded software could fetch this ID from your system. Let’s make sure that even if that does happen, that the value is constantly changing so that your device can not be uniquely identified as your device.

This is an incredibly simple and quick adjustment to your default Linux system. What we’re doing is showing you how to either adjust this value manually by hand, or by running a cronjob to change this value every minute with a new, randomized value.

Before we begin, a disclaimer: We’ve tested this on our own work desktops and development environments and I’ve tested it on my daily driver desktop. We have not found that anything has ‘broken’ because of this, but this is untested in many environments and may not be suitable for your use. It’s always reversible if you later wish to continue with a single, uniquely identifying ID attached to your device(s).

Debian / Ubuntu systems

To check your machine-id, open up your terminal and enter the following:

cat /etc/machine-id

The output should look a little something like this:


You’ll note that this value is also stored in /var/lib/dbus/machine-id and that a symlink between the two exist. Any change to one file, will be reflected in the other.

me@virtbox-testing:~$ cat /etc/machine-id

me@virtbox-testing:~$ cat /var/lib/dbus/machine-id

If you reboot your device, you’ll notice that this value remains unchanged. So, let’s change it ourselves!

Method 1: Manually.

Method 2 is automatically, every minute, as ran by a cron-job. If you don’t want to fully commit to that, you can change your machine-id by hand manually whenever you feel like it.

Step 1, remove the old machine-id file.

sudo rm /etc/machine-id

Step 2, recreate the machine-id file.

sudo systemd-machine-id-setup

Step 3, confirm that /etc/machine-id (and /var/lib/dbus/machine-id) now show a new value, different from the original.

cat /etc/machine-id && cat /var/lib/dbus/machine-id

That’s it! You should see two lines in your output with matching IDs that differ from the original machine-id you had in the beginning.

me@virtbox-testing:~$ cat /etc/machine-id && cat /var/lib/dbus/machine-id

You’ve changed your device’s uniquely identifying machine-id. This change will survive device reboots and will remain the same until you create a new one.

Method 2: Changing every 1 minute, automatically.

If the above didn’t satisfy your needs, than feel free to automate the creation of a new machine-id by creating a cronjob entry that will generate a new ID every minute.

Step 1, open up your crontab file.

sudo crontab -e

Step 2, enter at the bottom of the file the following:

*/1 * * * * sudo rm /etc/machine-id && sudo systemd-machine-id-setup

Save and Exit.

Step 3, wait a minute and confirm that your machine-id value has changed:

cat /etc/machine-id && cat /var/lib/dbus/machine-id

You should see two new matching values, that differs from the original value you had at the start. Wait a minute and run the step 3 command again, and you’ll see that these values have changed.

You’ll see that the command, when ran a minute or more apart, will produce new values now.

me@virtbox-testing:~$ cat /etc/machine-id && cat /var/lib/dbus/machine-id

me@virtbox-testing:~$ cat /etc/machine-id && cat /var/lib/dbus/machine-id

In closing

Uniquely identifying ID’s are rarely a good thing when you take privacy into consideration, and although these items have their purpose in limited use cases it doesn’t appear that generating a new unique ID every minute has any downsides.

What do you think? Is this a pointless privacy practice or a needed, but often overlooked part in maintaining privacy in the modern age? Let us know in the comments below.

Additional Thoughts

After publishing this article, we received some feedback that I’d like to touch base on here.

  • Testing the high privacy, pro-anonymity Tails-OS shows that you receive a new machine-id after every reboot. Props to Tails-OS!
  • Testing the privacy and anonymity promoting Whonix-OS shows that they do not issue a new machine-ID after every reboot and instead use the same ID for all Whonix users. Their response to this blog post can be read here with their reasoning and more information.
  • A commenter on a [RAMBLE] post mentions that MXLinux does not use systemd, and thus does not use a machine-id.
  • Here is a list of Linux operating systems that do not use systemd. (And will not have a machine-id)
  • Yes, there are other uniquely identifying aspects on all systems. From device serial numbers to MAC addresses. The purpose of this post was to discuss a lesser discussed unique identifer: machine-id.

What about your distro? Feel free to comment below and share your thoughts.