bookmark_borderImproving our Ad-Blocking VPN service: Now with anycast DNS.

We manage our own DNS servers that our ad, tracker, and other “BS” blocking VPN service uses. For the beta period, we were hosting DNS in a single location (Luxembourg), which held strong and served it’s purpose. But we decided to take things to a new level…

A single DNS server location to serve the requests for multiple VPN locations is not an ideal solution in a production environment, especially one that is being built for commercial use (IE: Us selling VPN services). While it served it’s purpose for the initial beta testing of the network and to allow us to develop and tune our blocklists, it does present a couple of downsides in that it’s a single point of failure for the entire VPN network and means performance isn’t the absolute best that it could be given that some VPN locations are geographically on the other side of the world from where the DNS was being served from.

So, we did what any bunch of geeks would do who love making things work better: We went from one DNS server, to three DNS servers that are each located in strategic geographical locations to ensure that your DNS lookups from our VPN network is done by the server closest to your VPN’s location. This offers a quite measurable decrease in overall query time while also hardening the network from attacks, as our service is able to sustain multiple outages at once (god forbid) and still keep humming along, serving you your favorite web content without all the ads, trackers and other bullshit associated with the modern era of websites and mobile apps. Aside from beefing up the overall specs of these servers to accommodate future growth and use, we can also add more in a relatively simple fashion to make scaling a much easier task.

But, if you’re like us, you’d rather see numbers and data, right? Below are some before/after results of a simple ping test done from several locations around the globe. One being done to our existing, soon to be decommissioned DNS server in Luxembourg, and the other being done to our new anycast DDoS protected DNS cluster. Check out the results below.

LocationOld DNS (Avg. RTT)New DNS (Avg. RTT)Difference
Amsterdam, North Holland, Netherlands39.16833.230-5.938
Dallas, Texas, United States157.440140.246-17.194
Frankfurt, Hesse, Germany51.30833.630-17.678
Hong Kong230.435200.940-29.505
London, England, United Kingdom54.58755.204+0.617
Madrid, Spain89.55773.626-16.297
Milan, Lombardia, Italy48.77437.104-11.67
Montreal, Quebec, Canada121.07511.503-109.572
Moscow, Moscow City, Russian Federation65.85573.915+8.06
Paris, Île-de-France, France38.06548.756+10.691
Singapore357.186202.650-154.536
Stockholm, Stockholms Lan, Sweden55.55466.514+10.96
Tokyo, Kanto, Japan290.306269.833-20.473

It’s improvement almost everywhere globally, with only a slight increase in response time in Sweden, France, UK and Russia. Though, this gives us the data we need to see where we can improve the setup by possibly adding a new DNS server in an area that will better serve these locations.

Our VPN service is currently ‘out of stock’, but we plan to re-launch with the new, updated DNS service in the coming week.

bookmark_borderHere is what is new, and what is coming soon.

As you may have noticed, we have done a bit of rebranding from ‘INCOG.HOST’ to ‘IncogNet’. This rebranding stems from two major factors:

  • First, the ‘.host’ TLD is cheap and a bit spammy. It’s automatically filtered as spam on some websites when shared (such as on reddit) and generally isn’t associated with legitimate business. The domain will possibly still be used internally where needed, such as for nameservers, hostnames, etc.
  • Second, we are legally operating our business under the entity of, “IncogNet LLC”, short for “Incognito Networks”. As such, changing our website URL to represent that of our business name just sort of made sense.

With this update in our name came a slight update in our branding. You may still see the old URL used in some areas of the site until we make the complete move over, things like our customer portal still reside under the old name but will soon be moved over as well.


Big improvements and upgrades are coming to our services! We’re rolling out DDoS protected, distributed anycast DNS for our ad-blocking VPN service!

This means that your VPN location will query the closest DNS server to it to serve your request. This is a BIG upgrade to our current VPN offering which is currently utilizing a single location (Luxembourg) to serve your DNS requests from. Not only will this new setup decrease the total lookup time for each request, it will also harden the entire service by removing a point of service failure. This new setup will allow for one or more DNS server to be offline (due to outage, maintenance, etc) without impacting the ability of the VPN service to still function as intended. If one server fails to respond, the request will be sent to another one until the lookup is complete.

But that’s not all! We’re obsessed with quality. We may be a small team of people here but we’ve all been in this industry a long time and have been a customer of many other providers over the years. We will only offer you services that we ourselves would use for our own projects. That’s why we’re revamping our shared hosting offerings. The new shared hosting service will include more super fast storage, on a much larger server with faster, and more CPU cores, and will utilize CloudLinuxOS to better allocate guaranteed resources to each customer while improving security and performance of your hosting. The previous features such as DDoS filtering, I2P network and Tor network hosting and encrypted webmail will certainly be included as well!


When will you start offering your Virtual Private Server or Network Node service?

We’ve had this question in our ticket queue often recently. To be honest, we can not yet quite say for sure. We’re still locating server hardware and trying to shop for good deals, which are harder to find than they were pre-COVID. Rest assured however that we still plan to launch our VPS and Network Node service on our own, owned hardware located in private rackspace in our Luxembourg location. We’re offering our current and existing services from rented resources until we’re able to transition them onto our own hardware in the future, but want to wait until we own our hardware before we jump into the VPS and Network Node market. We want to do this proper, we want to do this right. That means we need to outright own our hardware, maintain our own ASN / IP space and be in control over as much as possible. This will allow us to not only provide you a better, more cost efficient service but will allow us more freedom in operation. While we are very eager to begin offering these services, we do not want to rush into it and want to do it right.


But wait, there’s more! We’ve got something else up our sleeve that we are building and may offer as a beta-service in the coming months. Without going into much detail or naming what the service may be, imagine a way to take your Content and Deliver it over an anycast Network so that your content is delivered to the viewer from a server that is closest to them…. This is a project that is currently on the roadmap but something we have yet to break ground on, so to speak. But be on the lookout for this.

Until next time,
-IncogNet

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 https://tube.incognet.io/ (Ex: If I click on https://www.youtube.com/watch?v=dQw4w9WgXcQ , then it automatically sends me to https://tube.incognet.io/watch?v=dQw4w9WgXcQ )

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 used for the month of April. This is 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.

From https://yggdrasil-network.github.io/

Installation is a breeze, and you can find the install notes on Yggdrasil’s official website here: https://yggdrasil-network.github.io/installation-linux-deb.html


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: [
tls://107.189.4.167:42024
]

You can find more public peers here: https://publicpeers.neilalexander.dev/ (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: 107.189.4.167
  • 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 https://tube.incog.host/ !

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.

https://www.man7.org/linux/man-pages/man5/machine-id.5.html

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:

a9976154f0084a3782892638656ad9fd

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
a9976154f0084a3782892638656ad9fd

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

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
a78badce3e73beced163bbef7e55232a
a78badce3e73beced163bbef7e55232a

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
b722903d87994e24b6378289262c3021
b722903d87994e24b6378289262c3021

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

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.