I use two devices. The first runs a kernel+userland I can edit and acts as the gateway/AP and DNS server for the second, which runs some commercially-motivated, "locked-down" consumer OS.
What hardware are you using for the gateway/AP? What's the backhaul, a USB LTE modem? Do you carry it in a handbag with a USB battery pack?
I've been thinking about doing this and scrapping all but one of my data plans, and having a robust default-deny whitelist of allowed IPs/netblocks/hostnames on the phone vlan/ssid, but haven't worked out all the details yet.
The gateway is a small form-factor computer with a rechargeable battery, e.g., a netbook or laptop. The AP is a SBC that the preferred kernel, e.g., NetBSD, OpenBSD, Linux, etc., supports. The AP draws power from the gateway's battery via USB.
Regarding LTE modems, I do not use a data plan on "locked-down" mobile devices for personal use. Somehow I have been able to survive on WiFi alone.
So you carry around a laptop powered on all day when you are out? What about battery life?
I’m looking at something like a raspberry pi zero, using the built in wifi to serve as an AP, powered from a large-ish USB battery pack, something that could run 18h+, with a USB LTE modem. Ideally I could get it small enough to strap to an ankle or something so I don’t need to bring a bag.
You load a list of rules into it, and the only thing it is allowed to do is make a classification of where the URL should go (if you're paranoid, make this classification strictly binary). It cannot write any state out, nor connect to the internet itself.
It's a solution for some situations, but not the one userbinator was talking about.
The problem here is needing to trust the filter program. Moving code into a sandbox doesn't help, because you still need an app outside the sandbox to make it actually filter, and the problem is not being able to trust an app.
I mean, you really can't trust that the app just isn't a dud and does nothing. But with sandboxing you can prevent the app from reporting your browsing history.
You have X inside a sandbox. It has the filtering logic, and can't report home. Cool.
But you need Y outside the sandbox so that your content actually gets filtered. Without Y, your "filtering app" does nothing. You need code that is outside the sandbox.
But how do we set up Y? In the context of a mobile device, Y would have to be a VPN app.
But the original problem is that we can't trust VPN apps to do what they say.
So even though you moved the actual filtering logic into X, and put it in a secure sandbox, you didn't solve the problem of needing to trust an app.
(And "put Y into the trusted OS" is not a valid solution toward getting filtering on "locked-down mobile platforms".)
Again, you can't trust that the app actually does filtering, because as you said the filter list is loaded and evaluated by code that has no obligation to do this. But it can't track your internet browsing because the component that could, the VPN extension, is inside a sandbox.
Interesting! So what you're really saying is that a VPN isn't needed. But this function only works on "supervised" devices. That's a pretty severe limitation.
It has to be able to take the web content, manipulate it to remove the stuff it is trying to block, and then return it to the browser... what is to stop if from returning content with image tags with sensitive data encoded in the url? The browser will have to load the content to display.
