A guide on how to completely block Fb and other companies

General Privacy & Security
40

Are you sure this is correct? I blocked it and still the browser shows tiktok.com
I also get other numbers. nslookup www.tiktok.com gives IPs such as
2.23.154.??? Eg 2.23.154.129
Running whois -h whois.radb.net 2.23.154.129 | grep origin
gives AS20940 and AS34164.

Now this comes here through a2047.api10.akamai.net
Is it proper to block AS20940 and AS34164? I wonder…

1 Like
41

No you are correct. My bad. It works. But how did you find the AS number?

1 Like
42

When I first used the terminal to find it, the result was some mobile IP (10.xxx.xxx.xxx)…? I knew that couldn’t be right. (Turns out, it’s because of the DNS filtering/blocking I have set up in my VPN service account.) When I switched that off and tried again, the return was an IP for Akamai. Also not helpful.

So I just went to the search engine and tried “ASN for Tiktok” and I got relevant results, e.g. AS138699 - ByteDance AS138699 - PeeringDB , https://www.netify.ai/resources/applications/tiktok , and AS396986 Bytedance Inc. details - IPinfo.io . That last one shows a different ASN for Bytedance, TikTok’s parent company; Tiktok’s is further down the page.

2 Likes
43

10.x.x.x IP addresses are non-routable private network addresses like the 192.168.x.x addresses commonly used in home networks.

3 Likes
44

And just to elaborate on that …

they are non-routable on the public internet. They are perfectly routable on a private network and in a corporate scenario this is quite common for businesses that are either multi-site or large enough to want more than one subnet.

But I’m sure @amarok already knew all this, which is what is meant by “I knew that couldn’t be right”.

Mobile service providers are today probably the biggest corporate users of NAT (as CGNAT) and handing out private network addresses - although it isn’t a “mobile IP” in @amarok’s scenario.

2 Likes
45

Well… I knew, at least, that it wasn’t what I needed. :rofl:

2 Likes
46

Maybe Purism should set up their own public DNS servers that blocks everything that is invasive or that could threaten privacy or Security. Then, if you can’t find something on the internet, you’ll know that there is probably a good reason. An update to Pureos on our phones could work together with Purism’s public DNS server to report new invasive sites to block those sites to everyone who opts-in to this new DNS server. Such a tool would cost little and could give the average Pureos user the same protection that would otherwise require the user to be a network Security Engineer. For large companies that want to be listed on Purism’s DNS server, Purism could have “Terms of Service” that the company must agree to, and maybe even a fee to be paid to Purism. Purism could then blacklist anything related to Google or to the Metaverse. Any violation of those terms and Purism promptly boots them off. Any commercial site should by default, not be listed in the DNS listing. Only those businesses that sign the terms of service get listed.

Just for fun, Purism’s “Terms of Service” for commercial sites could be thirty or forty pages of 5-point font that has paragraphs to describe terms like “Privacy” and “Security”. The web browsers in Pureos could be altered to not allow links from explicit IP addresses if you enable that feature in your browser, unless the explicit IP address is also listed in Purism’s DNS server.

Although this might cause large portions of the internet to become unavailable, that’s ok. You put a stake in the ground and say to the world “these are my boundaries”. Then you build a new world for yourself within that space that is what you want the world to be. Suddenly one day, there is no Google, no Meta, much of the internet is gone, but what remains is friendly and respectful.

47

Well, if you want your feedback to be taken seriously, create a separate thread in the Feedback category or email Purism Feedback.

48

There are some challenges with that:

  • Is it provided at no cost?
  • Is it vulnerable to DDoS? Is it mirrored widely enough to combat that?
  • Is it vulnerable to malicious reporting of “new invasive sites”?
  • Is it vulnerable to centralised logging problems / interception?
  • One size is not likely to fit all. (In other words, what you consider blockworthy might not be identical to what I do.)

Here’s an alternative proposal that partially addresses some of the above.

Let’s say that people running PureOS are using systemd-resolved for name resolution. Let’s say that it is using a local stub resolver (typically runs on port 53 on IP address 127.0.0.53 - but NB: local programs may bypass IP in order to perform name resolution, so the actual change needs to be deeper within the name resolution code).

Purism offers a package. The package contains a blacklist of unpleasant domain names. If you install the package then your local stub resolver will blackhole all the domains on the blacklist. You will automatically get blacklist updates as part of the normal package update mechanism.

2 Likes
49

In any case, there are already many options for blocking connections to “bad-actor” sites:

  • publicly available (and constantly updated) open-source block lists
  • applications like OpenSnitch
  • various Android/iOS apps, such as Blokada and Tracker Control
  • local hosts file (typically bypassed if you’re connected to a VPN, though)
  • VPN services that provide built-in tracker-blocking
  • Browser extensions
  • Pi-hole (local network, but remote is also possible)
  • etc.
2 Likes
50

Or you could even run Pi-hole locally.

The problem for e.g. a Librem 5 if you run Pi-hole on the local network is that the Librem 5 is unprotected by that when it is out and about.

Another option for the person who is not a network engineer but which would have to be considered carefully:

  • use an existing public DNS blocking service (e.g. OpenDNS, now owned by Cisco)

You have to decide whether you trust the operator of the service and whether they block what you want to block. Regardless though the service will become a target for predatory governments and the provider will not legally be able to resist that. Hence a reason to prefer a somewhat decentralised approach.

2 Likes
51

I would suggest decloudus which blocks sites at the dns level

2 Likes
52

And I would suggest deploying your own (local) DNS recursive resolver instead of trusting any third-party.

2 Likes
53

It all depends on the extent to which a person is a “network engineer”.

Let’s say that for the purposes of the question as asked … the solution has to require bare minimum install and config.

As asked, it was suggested (by implication) that the bare minimum would be a few-click tutorial to override the dynamically configured DNS server IP address with an IP address provided by Purism. Easy peasy but I had concerns.

I suggested instead … install a Purism-provided package. But the problem is that, as far as I can tell, systemd-resolved doesn’t actually have blacklist capability, so it would also require Purism to upstream a hook for that. Easy peasy for the customer but may introduce a long delay getting that change in (even assuming someone upstream agrees to it).

I personally agree with your suggestion. I run my own local DNS server and it interferes greatly with lookups - both subtracting domains (like Google) and adding domains that the government removes.

1 Like
54

I do not do so myself at the moment, but I have been writing up a guide to install Technitium DNS Server locally on the Librem 5 with Crimson for the last few months. As a stopgap, I use AdGuard’s unfiltered DoH with Firefox ESR, but previously I used the Foundation for Applied Privacy’s DoH servers.

I have many projects coming out of the holiday season, so the guide will take a while to finish.

1 Like
55

[Edit: I didn’t realize how old the comment was when I replied. I thought it was Dec23, not Dec22.]

suid root is the biggest security problem ever allowed into unix. e.g. Anyone who has the ability to modify the program can become root. Anyone who has the ability to modify any program called by the script can become root. @antonis be aware of this.

A rule of thumb is to never to create suid programs simply to avoid using sudo with a password. It would be much better to use the sudo facility and list the particular users that are allowed to run the specific command (full path) as root without a password —> at least it restricts the users that can run the command as root and creates an auditable log event.

1 Like
56

As an aside, people use that term in differing, and hence confusing, ways. Here’s what Wikipedia says: Domain Name System - Wikipedia

Per that terminology, in order to be dependent on the minimum number of external parties, you want an iterative resolver (and that also reduces the prospects for surveillance at the endpoint). However if implementing an iterative resolver, you must also make it a caching resolver.

The key point is that a recursive resolver offers to resolve, on behalf of the client, domains for which the resolver is not authoritative - but that says nothing about how the recursive resolver goes about that task. It may in turn simply relay the request to another recursive resolver (which can be the subject of surveillance and/or interference even if the original recursive resolver was not) - or it may perform as an iterative resolver.

1 Like
57

Right, so my current line of thinking with the guide is to provide both options: one for a local iterative caching resolver; and the other one using the SOCKS5 protocol to resolve DNS queries using the Tor network instead.

1 Like
58

But in my guide here
https://myria.math.aegean.gr/~atsol/newpage/software/blockfacebook/blockfacebook.html

I nowhere wrote to use setuid. My instructions are setup to use systemd.

1 Like
59

I was replying to a comment that I thought was Dec2023 … when it was Dec2022. In Dec2022 you replied to A guide on how to completely block Fb and other companies - #2 by fralb5 with A guide on how to completely block Fb and other companies - #3 by antonis where you say

[antonis] “Thanks for the +s tip. It is cool.”.

I thought I should warn about using suid root … and didn’t realize your reply was a year old.

1 Like