No you are correct. My bad. It works. But how did you find the AS number?
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.
10.x.x.x IP addresses are non-routable private network addresses like the 192.168.x.x addresses commonly used in home networks.
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.
Wellā¦ I knew, at least, that it wasnāt what I needed.
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.
Well, if you want your feedback to be taken seriously, create a separate thread in the Feedback category or email Purism Feedback.
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.
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
andTracker 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.
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.
And I would suggest deploying your own (local) DNS recursive resolver instead of trusting any third-party.
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.
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.
[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.
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.
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.
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.
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.