Bumps gradle from 7.3.0 to 7.3.1. --- updated-dependencies: - dependency-name: com.android.tools.build:gradle dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <firstname.lastname@example.org>
|4 weeks ago|
|.github||4 months ago|
|.idea||2 months ago|
|app||4 weeks ago|
|fastlane/metadata/android/en-US||1 month ago|
|gradle/wrapper||4 months ago|
|.gitattributes||3 years ago|
|.gitignore||2 years ago|
|LICENSE||2 years ago|
|README.md||5 months ago|
|build.gradle||4 weeks ago|
|gradle.properties||3 years ago|
|gradlew||3 years ago|
|gradlew.bat||3 years ago|
|settings.gradle||3 years ago|
RethinkDNS + Firewall for Android
In other words, RethinkDNS has two primary modes, DNS and Firewall. The DNS mode routes all DNS traffic generated by apps to any user chosen DNS-over-HTTPS or DNSCrypt resolver. The Firewall mode lets the user deny internet-access to entire applications based on events like screen-on / screen-off, app-foreground / app-background, unmetered-connection / metered-connection; or based on play-store defined categories like Social, Games, Utility, Productivity; or additionally, based on user-defined denylists.
The firewall doesn't really care about the connections per se rather what's making those connections. This is different from the traditional firewalls but in-line with Little Snitch, LuLu, Glasswire and others.
Currently, per-app connection mapping is implemented by capturing
tcp connections managed by
firestack (written in golang) and asking ConnectivityService for the owner, an API available only on Android 10 or higher.
/proc/net/udp) is read on-demand to track per-app connections like NetGuard or OpenSnitch do, on Android 9 and lower versions.
A network monitor is a per-app report-card of sorts on when connections were made, how many were made, and to where. Tracking TCP has turned out to be so far straight-forward. DNS packets are trickier to track, and so a rough heuristic is used for now, which may not hold good in all cases.
DNS over HTTPS client
Almost all of the network related code (
firestack), including DNS over HTTPS split-tunnel, is a very minimal fork of Jigsaw-Code/outline-go-tun2socks written in golang. A majority of work is on the UI with other parts remaining same as on Jigsaw-Code/Intra. A split-tunnel traps requests sent to the VPN's DNS endpoint and relays it to a DNS over HTTPS endpoint of the user's choosing, logging the end-to-end latency, time of request, the dns request query itself and its answer.
The RethinkDNS Resolver
A malware and ad-blocking DNS over HTTPS resolver at
https://basic.rethinkdns.com/1:IAAgAA== (deployed to 200+ locations world-wide via Cloudflare Workers) is the default DNS endpoint on the app, though the user is free to change that. A configurable DNS resolver that lets users add or remove denylists and allowlists, add rewrites, analyse DNS requests is launching late 2022. Right now, a free-to-use DNS over HTTPS endpoint with custom blocklists can be setup here: rethinkdns.com/configure.
The RethinkDNS resolver is open source software: serverless-dns.
- The telegram community is super active and full of crypto-bros. Kidding. We are generally a welcoming bunch. Feel free to get in touch: t.me/rethinkdns.
- Or, email us: email@example.com (we read all emails immediately and reply once we fix the issues being reported).
What RethinkDNS is not
RethinkDNS is not an anonymity tool: It helps users tackle unabated censorship and surveillance but doesn't lay claim to protecting a user's identity at all times, if ever.
RethinkDNS doesn't aim to be a feature-rich traditional firewall: It is more in-line with Little Snitch than IP tables, say.
RethinkDNS is not an anti-virus: RethinkDNS may stop users from phishing attacks, malware, scareware websites through its DNS-based blocklists, but it doesn't actively mitigate threats or even look for them or act on them, otherwise.
What RethinkDNS aspires to be
To turn Android devices into user-agents: Something that users can control as they please without requiring root-access. A big part of this, for an always-on, always-connected devices, is capturing network traffic and reporting it in a way that makes sense to the end-users who can then take a series of actions to limit their exposure but not necessarily eliminate it. Take DNS for example-- for most if not all connections, apps send out a DNS request first, and by tracking just those one can glean a lot of intelligence about what's happening with the phone and which app's responsible.
To deliver the promise of open-internet for all: With the inevitable ESNI standardization and the imminent adoption of DNS over HTTPS and DNS over TLS across operating systems, we're that much closer to an open internet. Of course, Deep Packet Inspection remains a credible threat that can't be mitigated with this, but it is one example of delivering maximum impact (circumvent internet censorship in most countries) with minimal effort (not requiring use of a VPN or access via IPFS, for example). RethinkDNS would continue to make these technologies accessible in the most simplest way possible, especially the ones that get 90% of the way there with 10% effort.
- Feel free to fork and send along a pull request for any reproducible bug fixes.
- The codebase is raw and is lacking documentation and comprehensive tests. If you need help, feel free to create a Wikipage to highlight the pain with building, testing, writing, committing code.
- Write descriptive commit messages that explain concisely the changes made.
- Each commit must reference an open issue on the project. This is to make sure there isn't duplicated effort more than anything else.
- If you plan to work on a feature, please create a github issue on the project first to kickstart the discussion before committing to doing any work. Again, this is to avoid duplicate work more than anything else.
- Release cycles are undecided, but we're leaning towards bi-monthly once automated tests are up, whenever that may be.
Tenets (unless you know better ones)
We aren't there yet, may never will be but these are some tenets for the project for the foreseeable future.
- Make it right, make it secure, make it resilient, make it fast. In that order.
- Easy to use, no-root, no-gimmicks features that are anti-censorship and anti-surveillance.
- Easy to use: Any of the 2B+ Android users must be able to use it. Think CleanMaster / Instagram levels of ease-of-use.
- no-root: Shouldn't require root-access for any functionality added to it.
- no-gimmicks: Misleading material bordering on scareware, for example.
- anti-censorship: Features focused on helping bring an open internet to everyone, preferably in the most efficient way possible (both monetarily and technically).
- Anti-surveillance: As above, but features that further limit (may not necessarily eliminate) surveillance by apps.
- Incremental changes in balance with newer features.
- For example, work on nagging UI issues or OEM specific bugs, must be taken up on equal weight to newer features, and a release must probably establish a good balance between the two. However; working on only incremental changes for a release is fine.
- Opinionated. Chip-away complexity. Do not expect users to require a PhD in Computer Science to use the app.
- No duplicate functionality.
- A concerted effort to not provide too many tunable knobs and settings. To err on the side of easy over simple.
- Ignore all tenets.
- Common sense always takes over when tenets get in the way.
- Must be distributable on the PlayStore, at least some toned down version of it.
- Practice what you preach: Be obsessively private and secure.
Internet censorship (sometimes ISP-enforced and often times government-enforced), unabated dragnet surveillance (by pretty much every company and app) stirred us upon this path. The three of us university classmates, Mohammed, Murtaza, Santhosh got together in late 2019 in the sleepy town of Coimbatore, India to do something about it. Our main gripe was there were all these wonderful tools that people could use but couldn't, either due to cost or due to inability to grok Computer-specific jargon. A lot has happened since we started and a lot has changed but our focus has always been on Android and its 2B+ unsuspecting users. The current idea has been in the works for since May 2020, with the pandemic derailing a bit of progress, and a bit of snafu with abandoning our previous version in favour of the current fork, which we aren't proud of yet, but it is a start. All's good now that we've won a grant from the Mozilla Builders MVP program to go ahead and build this thing that we wanted to... do so faster... and not simply sleep our way through the execution. I hope you're excited but not as much as us that you quit your jobs for this like we did.