nickburns

we're talking here about the ability to control what NIC localhost traffic egresses a device with multiple NICs—even when some of said NICs may be be virtualized, like a TUN interface for example. anything and everything else is upstream.

ah, now i understand. your earlier comment very much read like you were accusing kfreds personally of making such a statement about ad networks. but you meant to say one (or more) of the ads you've seen yourself appears to makes such a claim. thanks for clarifying.

stop what?

never even thought to check if iMazing had any of this functionality. disclaimer noted, great tip regardless. thank you.

i see your careful edit. (i ran out of time myself.) they're called parts of speech. your comment makes much more sense now. welcome.

  To claim that you stop online ad networks is a downright falsehood and you know it.

can you link to these remarks? i can't see kfreds making any reference to ad networks anywhere.

adjectives modify nouns.

sure is.

thank you for offering up in this forum at least your own personal contributions to your organization's position on its advertising campaigns. not sure if any official statements on the matter have been made elsewhere, but you've assuaged at least my own slight concern about it with this one. truly. (and by 'truly' i mean i've been meaning to stuff some cash in an envelope addressed to you guys!)

transparency is absolutely a corporate virtue.

  who uses checks anymore, btw?

business organizations. the rest of your points are well said.

doesn't matter. plenty of elaboration elsewhere in the discussion.

categorical ≠ silly

...unless you care to elaborate on why you disagree with this statement in substance and/or on point?

i agree the whole concept is not too far past proof at present.

i'm almost certain i've had it happen on iOS, too. only reason i can't definitively say—is because i can't rule myself out always having to manually toggle cell data on/off, both radio-level and per-app, when i'm coming/going from my own networks to my mobile VPN.

that's a *deliberate choice.

crazy. it's remarkable to me that lawyers actually do explicitly, if not expressly, account for these kinds of technical decisions, ultimately made in surreptitious fashion by the business, when drafting usage terms. i.e., you would've (or, a lawyer determind, should've) been able to find notice of this change somewhere buried in the new service terms. i at least have faith in that much.

i hope you switched back, lol.

  This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.  

  Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course).

outbound filtering by source and/or destination address and/or port is both a fundamental firewalling concept and standard configuration on all firewall-routing platforms. (policy-based routing[0], i.e. filtering by gateway, is the same.) generally speaking, only the con/prosumer products allow everything out by default.

just curious, what was your "main router" in this setup? ISP-supplied?

[0] https://en.wikipedia.org/wiki/Policy-based_routing

lol, hit me up with your rate. my only term is that i get to be watching over your shoulder the whole time.

Apple is no less culpable of the same, they just put it behind the garden walls (which, in fairness, would appear to be just barely more trustworthy than Alphabet).

what if a system-level (read: root) process doesn't respect your user-configured routing table? that's the real issue here. only mitigation would be to physically remove the undesirable NIC/s from the system, which is obviously impossible on SoC hardware.

Mullvad's not really in the business of developing for Alphabet. but any of us could though, sure.

fair point. but that assumes:

1.) the system strictly respects user-configured DNS; and

2.) that the leak of some private data is acceptable. leaked traffic is still leaked even if otherwise encapsulated by some other encryption mechanism outside of an otherwise properly-configured VPN tunnel.

#1 is of course a much larger risk assumption to swallow.

there is (or at least can be) some risk tolerance within any so-called 'threat model.' but i absolutely take your point and agree with you.

nary the case but i suppose if i absolutely needed to access any finances from my mobile device, it certainly wouldn't be from one of said institution's own mobile apps, but via web browser.

ironically SMS/MMS and VVS are two of maybe a few other operations/functions (system updates maybe? maybe?) that are justifiably 'hard-coded' to the carrier connection.

i've done the dance re: VVS with advanced AT&T support on VPN'ed iOS—so can confirm your point is not limited to Android.

still the same. Alphabet nor Apple have any real incentive to change this (commercial incentivization to maintain it notwithstanding).

nope. no DNS service, not even a self-hosted one, can mitigate what's happening here.

the matter at-hand considers Android (and iOS both) operating system- and kernel-level insecurities by-design. the operating system (together with all root-level or otherwise authorized system activity), under certain conditions—e.g. connectivity change, hard-coded system function, apps with permission to hardcode their own network functions, etc.—will refuse to use any NIC, whether physical or virtualized, except the one containing the cellular carrier's connection/routes. that traffic might then necessarily include DNS queries and any/all other private but now-leaked data.

a point as salient as it is germane. this is exactly why open-source software and hardware mobile device projects[0] will only continue to proliferate.

[0] https://en.wikipedia.org/wiki/PinePhone_Pro

it's true.

even bigger nightmare on iOS where 'always-on VPN' can only be configured on devices 'supervised' by an Apple-approved (documented application and telephone call with current employee required) organization's MDM solution—or you otherwise need a Mac to use the Apple Configurator app to even create a Configuration Profile containing the 'always-on VPN' key.

regulatory costs, legal fees, and smaller revenue projections than they've been enjoying over the past two or so decades perhaps.

such a deplorable legacy. shameful that only this degree of hedonism piques the 'moral sense' of some, and yet for others not even.

i've quoted that language here:

https://news.ycombinator.com/item?id=40199825