• Re: PSA: IPv6 browser privacy leaks are caused by the host yet there's a simple fix

    From Nuno Silva@nunojsilva@invalid.invalid to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 09:47:43 2026
    From Newsgroup: comp.mobile.android

    On 2026-07-21, Carlos E. R. wrote:

    On 2026-07-21 08:59, Nuno Silva wrote:

    Two things:

    Yeah, if you want to remove IPv6 from the equation, if you have e.g. a
    "router" device with a wireless AP that can be configured to handle (and
    hand out) only IPv4, configuring it so and connecting through it would
    be a way to be more confident that the issue wouldn't arise.

    Were this another network application and protocol, I'd wonder what's
    prompting the software to connect over IPv6, given the VPN should
    provide DNS with IPv4 only, but I'm guessing this is about IPv6
    addresses in bittorrent, either of peers or of trackers.

    If the torrent application connects outside of the VPN, this is a bug
    that should be reported to the app developers. Or to the developers of
    the VPN software. I'm unsure which is at fault.

    If it's a VPN-specific software in a service promoting privacy or
    anonimity, or if it's a non-provider-specific VPN software focusing on
    that, then I'd say it's a fault in the VPN software. And, otherwise,
    it'd be a feature request for the VPN software?
    --
    Nuno Silva
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Nuno Silva@nunojsilva@invalid.invalid to comp.mobile.android on Wed Jul 22 09:51:54 2026
    From Newsgroup: comp.mobile.android

    On 2026-07-21, Maria Sophia wrote:


    Torrenting on VPN with a bittorrent client aside, IPv6 is more revealing in the sense that it gives each device a unique, stable & too public identity unless privacy extensions are used (and even those don't fully hide the device). So it still behooves all of us to protect against IPv6 leaks.

    If what you're trying to avoid is legal action from the MAFIAA or
    actions from the ISP itself, then it really doesn't matter if it's the
    NATed IPv4 address which gets leaked or an IPv6 one. Both would point to
    your subscription with the ISP.
    --
    Nuno Silva
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 15:40:57 2026
    From Newsgroup: comp.mobile.android

    Nuno Silva wrote:
    The privacy leak occurs because the host has a IPv6 identity
    available.

    I still stand by the point that the leak occurs because the VPN system somehow does not preclude usage of non-VPN routes. Now this might be
    okay for some uses of VPNs, where the goal is to access internal
    services (corporate, school), but not for others, where the goal is to
    have a separate "environment" for network access.

    Hi Nuno Silva,

    My "goal" on VPN is simply to obfuscate my IP address, whether that is IPv6
    or IPv4, and, it turns out after all, that I've accomplished that goal.

    At least on Windows I have. (Linux even more so had I been booting to it.)
    For Android, it's more complicated.

    Some things I'm an expert on, and other things I'm just ignorant about.
    I was right about a few things in this PSA, but I was wrong about some.

    So if I were to write this thread now, instead of a couple of days ago, it would be very different because the problem is the same, but the solution
    is different.

    As for the 'problem', the problem remains that IPv6 is very different from IPv4 in terms of device privacy, but the solutions I first proposed was correct strategically, but I would change it greatly tactically today.

    Now I know that the only free VPN that I know of that "says" it protects against IPv6 leaks, for example, is ProtonVPN (which has other issues).

    The free VPN from whom I get thousands of config files and which I've been using since 2013 for free apparently does not say either way or the other.

    So it probably does not. So, we "could" call that a bug, but I won't.
    It's just how it works. It's like me asking an MUA to filter out spam.

    The real PSA is to learn how to identify how IPv6 privacy leaks can occur.

    So, the good news in this PSA is that people on these newsgroups are now
    aware to L@@K for IPv6 privacy leaks when they're on "their VPN" of choice.

    Hence, this PSA suggests the *simplest* effective privacy solution is...
    modem <--> silent bridge <--> router <--> any device <--> any application >>
    Although, there are other solutions, all of which are more complex (IMHO). >>
    Aside from the cost of the hardware, the main downside of the silent bridge >> approach offered in this PSA is that it disables IPv6 entirely.

    Anyone who actually relies on IPv6-only services would lose the capability. >> Would full loss of IPv6 be acceptable for most users on these
    newsgroups?

    Who here is actually using IPv6 for anything that would be impacted?

    Probably a few people who are behind NAT, or worse, CGNAT, but do get
    IPv6 prefixes might have interest in retaining that connectivity.

    Completely axing IPv6 also gets rid of link-local addresses, that can be useful for internal networking.

    Not that I'm taking advantage of that on Android. (Yet. :-P)

    I must be clear here that I was dead wrong that the bridge solves anything.

    What I've learned in the past couple of days is that almost nobody is
    "using" IPv6 (and, in fact, it turns out, my own WISP doesn't even do it).

    But other ISP's likely do hand out routable IPv6 addresses, so the privacy issue is real, and much worse (in many ways) than it ever was with IPv4.

    With NAT, every house had a unique IPv4 address, but with IPv6, every
    single device has a unique IPv6 address, whether it's rotated or not.

    And, that RFC 8981 rotation only rotates the unique-to-the-device half
    of the IPv6 address. RFC 8981 does nothing for the home-identifier part.

    If we don't want to worry about IPv6 privacy issues, we have to either stop
    it at the router (which my router apparently has the option to do), or, we have to stop it at the device (which Windows & Linux devices can do).

    Both Carlos and I have been describing ways to stop IPv6 at the device.
    But, my original suggestion to stop IPv6 with a bridge was pure hogwash.

    I was deluded by the fact that my most comprehensive checks were done only *after* I was forced to add a wireless bridge repeater to replace the fact that my Wi-Fi (and VPN tunnels) were destroyed by the use of this sequence
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f
    pnputil /remove-device "PCI\VEN_168C&DEV_002A..."
    pnputil /delete-driver netathrx.inf /uninstall /force

    That was catastrophic because it doesn't destroy just a driver.
    It permanently wipes out the entire networking subsystem on Windows!

    Luckily, I learned a lot recovering from that networking faux pas,
    so I'm not only back online, but I'm testing Wi-Fi speeds with and
    without the wireless bridge, finding out very interesting things.

    In summary, the *first* thing any of us should do if we care to think about IPv6 privacy is to check with our ISP to find out whether they serve it.

    If not, the next thing we need to learn is how to check for whether or not they serve it, and then whether or not our router is set up to stop it.

    If they serve it and if our router can't stop it, then (and only then),
    should we think about stopping it at the host level, where the solution for Windows is different than Linux or Android but fundamentally the same.

    Note that RFC 8981 is "partial privacy" (IMHO), because it only rotates the second half of the IPv6 identifier, which, for some people may be enough.

    Fundamentally, RFC 8981 turns IPv6 issues back into IPv4 privacy issues.
    Kind of sort of but not exactly.
    --
    Sometimes you learn everything only after you started out knowing nothing.



    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 16:30:05 2026
    From Newsgroup: comp.mobile.android

    Nuno Silva wrote:
    If the torrent application connects outside of the VPN, this is a bug
    that should be reported to the app developers. Or to the developers of
    the VPN software. I'm unsure which is at fault.

    If it's a VPN-specific software in a service promoting privacy or
    anonimity, or if it's a non-provider-specific VPN software focusing on
    that, then I'd say it's a fault in the VPN software. And, otherwise,
    it'd be a feature request for the VPN software?

    The lesson learned for VPN/IPv6 is to check with the VPN provider.

    UPDATE:

    Don't do this sequence (which I did when trying to rip IPv6 out of Windows)
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f
    pnputil /remove-device "PCI\VEN_168C&DEV_002A..."
    pnputil /delete-driver netathrx.inf /uninstall /force

    The result is a catastrophic loss of IPv4 routing on the Wi-Fi interface.
    It resets the Wi-Fi stack and forces Windows to rebuild routing tables.

    Specifically, by disabling IPv6 at the registry level and forcibly removing the Atheros Wi-Fi driver, the subsequent pnputil /force step permanently
    wiped out the Wi-Fi networking stack.

    When Windows attempted to rebuild routing tables, because the networking
    stack was completely gone, the OS could not restore IPv4 routing for Wi-Fi.

    As a result both Wi-Fi and VPNs were completely & permanently dead.
    Wi-Fi didn't work because it depends on a ton of things now removed!
    a. NetworkUX
    b. OOBENetwork packages
    c. NetworkConnectionFlow
    d. immersivecontrolpanel dependencies
    e. ShellExperienceHost networking hooks
    f. Edge legacy system package
    g. CBS servicing metadata
    h. RPC endpoint mapper entries
    VPN didn't work because the connection depends on the OS routing table.

    For a temporary workaround, I used a spare router as a wireless bridge,
    which only required Ethernet connectivity between the desktop & bridge.
    a. The PC connected via Ethernet to the bridge
    b. The bridge connected to my SOHO router Wi-Fi AP
    c. Psiphon provided the IP obfuscation while Wi-Fi routing was broken

    Ethernet works because it's simple & Psiphon worked because it bypasses the
    OS routing table by creating its own tunnel & forwarding logic.
    netsh interface set interface "wlan0" admin=disabled
    netsh interface set interface "eth0" admin=enabled
    netsh interface ipv4 set address name="eth0" static 192.168.1.15 255.255.255.0 192.168.1.1
    netsh interface ipv4 set dns name="eth0" static 1.1.1.1
    netsh interface ipv4 add dns name="eth0" 1.0.0.1
    netsh interface ipv4 show dnsservers
    netsh interface ipv4 show config name="eth0"
    netsh interface ipv4 show config
    netsh interface ipv4 show dnsservers
    ping -n 1 192.168.1.1
    ping -n 1 1.1.1.1
    ping -n 1 www.google.com
    wmic nic where (NetEnabled=true) get Name, Speed
    curl -o NUL http://speedtest.tele2.net/1MB.zip
    curl -o NUL http://speedtest.tele2.net/10MB.zip
    curl -o NUL http://speedtest.tele2.net/100MB.zip
    speedtest.exe (from <https://www.speedtest.net/apps/cli>)
    route print -4
    ipconfig /all
    psiphon.bat

    This kept me online long enough to perform recovery using the MCT Media Creation Tool & Rufus to create a MBR (BIOS + UEFI) recovery USB stick.

    AFAIK, there are only two solutions since the stack cannot be re-installed.
    1. Revert to a previous known-good restore point
    2. Create a Windows recovery flash, boot & recover

    Once I had the Wi-F back up, I could revert from Ethernet back to Wi-Fi.
    netsh interface set interface "eth0" admin=disabled
    netsh interface set interface "wlan0" admin=enabled
    netsh interface ipv4 set address name="wlan0" static 192.168.1.16 255.255.255.0 192.168.1.1
    netsh interface ipv4 set dns name="wlan0" static 1.1.1.1
    netsh interface ipv4 add dns name="wlan0" 1.0.0.1
    netsh wlan connect name="my.ssid_nomap"
    netsh interface ipv4 show dnsservers
    netsh interface ipv4 show config name="wlan0"
    netsh interface ipv4 show config
    netsh interface ipv4 show dnsservers
    ping -n 1 192.168.1.1
    ping -n 1 1.1.1.1
    ping -n 1 www.google.com
    wmic nic where (NetEnabled=true) get Name, Speed
    curl -o NUL http://speedtest.tele2.net/1MB.zip
    curl -o NUL http://speedtest.tele2.net/10MB.zip
    curl -o NUL http://speedtest.tele2.net/100MB.zip
    speedtest.exe (from <https://www.speedtest.net/apps/cli>)
    route print -4
    ipconfig /all
    vpn.bat

    These steps are useful for anyone to save into their debugging checklist.
    --
    Sometimes, ripping the heart out of WIndows isn't always a good thing.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Brian Gregory@void-invalid-dead-dontuse@email.invalid to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 21:32:17 2026
    From Newsgroup: comp.mobile.android

    On 20/07/2026 07:45, Maria Sophia wrote:
    PSA:
    IPv6 browser privacy leaks are caused by the host, yet there's a fix.
    ISP modem > IPv6-silent bridge > normal home router > Wi-Fi devices

    On all platforms, web browsers can leak your globally-routable IPv6 address (even when you're using a VPN). This IPV6 privacy leak happens because the browsers prefer IPv6 and the OS host itself participates in IPv6 routing.

    Basically, if the host has a global IPv6 address, a browser can expose it.
    Browsers leak IPv6... but bridges stop it cold!

    Specifically, a silent bridge is a bridge that passes IPv4 but never hands out or forwards IPv6, so no device behind it ever gets a global IPv6
    address. If the host never receives IPv6, the browser cannot leak IPv6.

    Long story short, recently I delved into the *simplest* way to completely protect us (on any OS) from any web browser (Mozilla or Chromium) leaking IPV6 privacy (after recovering from a dreadful Windows IPV6 0xFF disaster).
    Newsgroups: alt.comp.os.windows-10,alt.comp.microsoft.windows,alt.comp.os.windows-11
    Subject: Have you ever disabled IPv6 for privacy (to prevent IP leaks)?
    Date: Sat, 18 Jul 2026 12:47:22 -0400
    Message-ID: <113gamq$ii0$1@nnrp.usenet.blueworldhosting.com>

    There are lots of tricks, such as RFC 8981 IPV6 rotation privacy, but
    here's the important part I learned when I fully disabled IPv6 (0xFF)
    instead of only partially disabling it (0x20) as most people would do.

    If a router is in bridge mode (no IPv6 delegation, no prefix assignment),
    all connected devices never receive a global IPv6 address.
    *No global IPv6 address = nothing for the browser to leak.*

    This protects IPV6 privacy on all operating systems and all web browsers.
    a. It doesn't matter which browser you use (Chromium, Firefox, etc.).
    b. It doesn't matter which OS you use.
    c. If the host never receives an IPv6 address, the leak cannot occur.

    IMHO, this is the simplest way to eliminate IPv6 browser leaks:
    Disable IPv6 at the router level by using a bridged configuration.

    Host-level IPv6 participation is the root cause of IPV6 leaks.
    Hence, if we remove the host from IPv6 routing, that IPV6 leak disappears!

    In summary, the topic of this PSA is likely not discussed anywhere else on this planet, but what I just learned was this simple IPv6 privacy epiphany.
    1. Browsers leak IPv6 because they prefer IPv6 when available.
    2. If the host receives a global IPv6 address (via SLAAC or DHCPv6),
    the browser may expose it even if IPv4 traffic is tunneled thru VPN.
    3. However, bridge mode prevents prefix delegation, so hosts never
    obtain global IPv6 addresses.

    No IPv6 address = no IPv6 leak!
    Who knew! Not me. Now I do!

    As always, if you have a simpler solution, let's discuss it as the whole point of this thread is to ensure we can protect from IPv6 privacy leaks.

    You are spouting a load of meaningless gibberish.
    It sounds like you are basically disabling IPv6 but coming up with a
    load of complete rubbish to make it sound like you are doing something
    more clever. YOU ARE NOT DOING ANYTHING OTHER THAN DISABLING IPv6.
    --
    Brian Gregory (in England).
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Brian Gregory@void-invalid-dead-dontuse@email.invalid to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 21:35:33 2026
    From Newsgroup: comp.mobile.android

    On 20/07/2026 20:59, Carlos E. R. wrote:
    Because he is torrenting via a tunnel to VPN servers. Apparently the torrrent app bypasses the VPN and connects directly via IPv6, so his identity becomes known.

    So he should complain about his VPN client then. NOT ABOUT IPv6.
    What a cry baby.
    --
    Brian Gregory (in England).
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Richmond@dnomhcir@gmx.com to comp.mobile.android on Wed Jul 22 21:38:39 2026
    From Newsgroup: comp.mobile.android

    Maria Sophia <mariasophia@comprehension.com> writes:

    Nuno Silva wrote:
    The privacy leak occurs because the host has a IPv6 identity
    available.

    I still stand by the point that the leak occurs because the VPN
    system somehow does not preclude usage of non-VPN routes. Now this
    might be okay for some uses of VPNs, where the goal is to access
    internal services (corporate, school), but not for others, where the
    goal is to have a separate "environment" for network access.

    Hi Nuno Silva,

    My "goal" on VPN is simply to obfuscate my IP address, whether that is
    IPv6 or IPv4, and, it turns out after all, that I've accomplished that
    goal.

    At least on Windows I have. (Linux even more so had I been booting to
    it.) For Android, it's more complicated.

    Some things I'm an expert on, and other things I'm just ignorant
    about. I was right about a few things in this PSA, but I was wrong
    about some.

    So if I were to write this thread now, instead of a couple of days
    ago, it would be very different because the problem is the same, but
    the solution is different.

    As for the 'problem', the problem remains that IPv6 is very different
    from IPv4 in terms of device privacy, but the solutions I first
    proposed was correct strategically, but I would change it greatly
    tactically today.

    Now I know that the only free VPN that I know of that "says" it
    protects against IPv6 leaks, for example, is ProtonVPN (which has
    other issues).

    The free VPN from whom I get thousands of config files and which I've
    been using since 2013 for free apparently does not say either way or
    the other.

    So it probably does not. So, we "could" call that a bug, but I won't.
    It's just how it works. It's like me asking an MUA to filter out spam.

    The real PSA is to learn how to identify how IPv6 privacy leaks can
    occur.

    So, the good news in this PSA is that people on these newsgroups are
    now aware to L@@K for IPv6 privacy leaks when they're on "their VPN"
    of choice.

    Hence, this PSA suggests the *simplest* effective privacy solution
    is... modem <--> silent bridge <--> router <--> any device <-->
    any application

    Although, there are other solutions, all of which are more complex
    (IMHO).

    Aside from the cost of the hardware, the main downside of the silent
    bridge approach offered in this PSA is that it disables IPv6
    entirely.

    Anyone who actually relies on IPv6-only services would lose the
    capability. Would full loss of IPv6 be acceptable for most users on
    these newsgroups?

    Who here is actually using IPv6 for anything that would be impacted?

    Probably a few people who are behind NAT, or worse, CGNAT, but do get
    IPv6 prefixes might have interest in retaining that connectivity.

    Completely axing IPv6 also gets rid of link-local addresses, that can
    be useful for internal networking.

    Not that I'm taking advantage of that on Android. (Yet. :-P)

    I must be clear here that I was dead wrong that the bridge solves
    anything.

    What I've learned in the past couple of days is that almost nobody is
    "using" IPv6 (and, in fact, it turns out, my own WISP doesn't even do
    it).

    But other ISP's likely do hand out routable IPv6 addresses, so the
    privacy issue is real, and much worse (in many ways) than it ever was
    with IPv4.

    With NAT, every house had a unique IPv4 address, but with IPv6, every
    single device has a unique IPv6 address, whether it's rotated or not.

    And, that RFC 8981 rotation only rotates the unique-to-the-device half
    of the IPv6 address. RFC 8981 does nothing for the home-identifier
    part.

    If we don't want to worry about IPv6 privacy issues, we have to either
    stop it at the router (which my router apparently has the option to
    do), or, we have to stop it at the device (which Windows & Linux
    devices can do).

    Both Carlos and I have been describing ways to stop IPv6 at the
    device. But, my original suggestion to stop IPv6 with a bridge was
    pure hogwash.

    I was deluded by the fact that my most comprehensive checks were done
    only *after* I was forced to add a wireless bridge repeater to replace
    the fact that my Wi-Fi (and VPN tunnels) were destroyed by the use of
    this sequence reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f pnputil /remove-device "PCI\VEN_168C&DEV_002A..." pnputil /delete-driver netathrx.inf
    /uninstall /force

    That was catastrophic because it doesn't destroy just a driver. It permanently wipes out the entire networking subsystem on Windows!

    Luckily, I learned a lot recovering from that networking faux pas, so
    I'm not only back online, but I'm testing Wi-Fi speeds with and
    without the wireless bridge, finding out very interesting things.

    In summary, the *first* thing any of us should do if we care to think
    about IPv6 privacy is to check with our ISP to find out whether they
    serve it.

    If not, the next thing we need to learn is how to check for whether or
    not they serve it, and then whether or not our router is set up to
    stop it.

    If they serve it and if our router can't stop it, then (and only
    then), should we think about stopping it at the host level, where the solution for Windows is different than Linux or Android but
    fundamentally the same.

    Note that RFC 8981 is "partial privacy" (IMHO), because it only
    rotates the second half of the IPv6 identifier, which, for some people
    may be enough.

    Fundamentally, RFC 8981 turns IPv6 issues back into IPv4 privacy
    issues. Kind of sort of but not exactly.

    My ISP provides IPV6. I switched on ProtonVPN on Android and visited
    ip.wtf and test-ipv6.com and they say there is no ipv6 address. (Brave browser). But without the VPN switched on there is an ipv6 address which
    I recognise as on my own network.

    Quick update, I got connected to Norway and got an IPv6 address, but it
    is not one of mine, it is different at the top level. It must be
    Proton's. Same results with Firefox.

    I am not sure what PSA is about, but if you are using VPN then it should
    hide your IPv6 address and either not provide one or provide one of its
    own, and that is what ProtonVPN is doing for me on Android. If it is
    letting your own IPv6 address through then it is broken. But as your ISP doesn't provide IPv6 I think something else must be going on.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 16:46:05 2026
    From Newsgroup: comp.mobile.android

    Brian Gregory wrote:
    On 20/07/2026 20:59, Carlos E. R. wrote:
    Because he is torrenting via a tunnel to VPN servers. Apparently the
    torrrent app bypasses the VPN and connects directly via IPv6, so his
    identity becomes known.

    So he should complain about his VPN client then. NOT ABOUT IPv6.
    What a cry baby.

    Hi Brian Gregory,

    The VPN issue is, fundamentally, a red herring since some VPNs block IPv6
    leaks and some don't, so it's simply a matter of VPN functionality specs.

    As for the bridge router being used to block IPv6 before it gets to the
    host, you were right all along. I was wrong. Well, I was right about the
    top level strategy, but I was wrong about the bridge solving the problem.

    You want to block IPv6 either at the ISP, the router, or at the host.
    If I knew then what I knew now, this PSA would have been very different.

    It doesn't matter to me who "was" right or wrong though.
    What matters is the correct understanding of the problem & solution now.

    The problem, as I see it, wrt privacy, is while IPv4 (with NAT) gave every
    home a unique IP address, IPv6 gives every device a unique IP address.

    As you astutely and helpfully noted, we can ameliorate 'some' of that IPV6 privacy flaw by employing RFC 8981 privacy extensions, but they only rotate
    the latter half of the IPv6 address & even so, only after a period of time.

    Then IPv6 becomes only slightly worse than IPv4 with respect to IP privacy.
    --
    On Usenet, you can find people who know a lot more than you do about IPv6.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 16:54:00 2026
    From Newsgroup: comp.mobile.android

    Brian Gregory wrote:
    As always, if you have a simpler solution, let's discuss it as the whole
    point of this thread is to ensure we can protect from IPv6 privacy leaks.

    You are spouting a load of meaningless gibberish.
    It sounds like you are basically disabling IPv6 but coming up with a
    load of complete rubbish to make it sound like you are doing something
    more clever. YOU ARE NOT DOING ANYTHING OTHER THAN DISABLING IPv6.

    Hi Brian Gregory,

    Thank you for being blunt, as there is no doubt you are right about this.
    I was wrong.

    The reason I was wrong was simply that I read too much into the fact that I couldn't find IPv6 once I set up the bridge after wiping out my network,
    but, in reality, I didn't check the network well before I wiped it out.

    The bridge, as bridges are wont to do, did nothing to the IPv6 address!

    And the only reason I set up the bridge was because I wiped out networking
    in my attempt to rip the heart out of Windows IPv6 routing capability.

    I wrote up a recovery checklist so that anyone following this thread has
    all the steps necessary to wipe out IPv6 properly (hex 20) from Windows.

    And Carlos wrote up the steps so that anyone on Linux can follow suit.
    Plus, I added the steps necessary to wipe IPv6 out of the Firefox browser.

    So there is a *lot* of good value which came of this IPv6 privacy effort. Thanks again for not beating around the bush to let us know what you think!
    --
    We all strive to add privacy that marketing doesn't want us to have.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 18:53:31 2026
    From Newsgroup: comp.mobile.android

    Richmond wrote:
    Fundamentally, RFC 8981 turns IPv6 issues back into IPv4 privacy
    issues. Kind of sort of but not exactly.

    My ISP provides IPV6. I switched on ProtonVPN on Android and visited
    ip.wtf and test-ipv6.com and they say there is no ipv6 address. (Brave browser). But without the VPN switched on there is an ipv6 address which
    I recognise as on my own network.

    Quick update, I got connected to Norway and got an IPv6 address, but it
    is not one of mine, it is different at the top level. It must be
    Proton's. Same results with Firefox.

    I am not sure what PSA is about, but if you are using VPN then it should
    hide your IPv6 address and either not provide one or provide one of its
    own, and that is what ProtonVPN is doing for me on Android. If it is
    letting your own IPv6 address through then it is broken. But as your ISP doesn't provide IPv6 I think something else must be going on.

    Hi Richmond,

    Thanks for that useful information about your ISP providing you IPv6
    addresses where, from looking it up, it seems that the router assigns each device a unique globally routable IP address.

    As noted, there are web sites to check this, on and off VPN, where you confirmed what I had found out independently that of all the free VPNs out there, one that advertises IPv6 privacy is ProtonVPN (which I don't use).

    As for my situation, my free VPN which I've been using since 2013 doesn't
    stop IPv6 but in my case, it turns out the WISP doesn't provide it anyway.

    If the ISP did provide IPv6, then we could block it at the router.
    And if we wanted to, we could block it at the device (Windows or Linux).
    And, if we cared to, we could block it at the application, e.g.,
    Firefox also prefer IPv6 over IPv4 unless configured otherwise:
    about:config > network.dns.disableIPv6 > change from false to true Optionally, to prevent WebRTC IPv6 leaks in Mozilla-based web browsers:
    media.peerconnection.ice.no_ipv6 > change from false to true
    media.peerconnection.ice.default_address_only > change from false to true

    Worst case, we can implement RFC 8981 privacy extensions, but they only
    rotate the latter half of the IPv6 address, and even then, after time.
    1. Test external visibility
    start firefox https://test-ipv6.com (Windows)
    firefox https://test-ipv6.com (Linux)
    xdg-open https://test-ipv6.com (Android Termux)
    2. Check external reachability
    ping -6 google.com
    3. Identify the local interface configuration
    a. ipconfig (Windows)
    b. ifconfig / ip a (Linux)
    c. Termux > pkg install iproute2 > ip a (Android)
    d. Termux > pkg install net-tools > ifconfig (Android
    4. Test DNS resolution
    nslookup -type=AAAA google.com (Windows)
    dig AAAA google.com (Linux, Android Termux)
    5. Test IPv6 routing table
    route print -6 (Windows)
    ip -6 route (Linux/Android Termux)
    6. Test IPv6 WebRTC leaks
    firefox https://browserleaks.com/webrtc
    firefox https://ipleak.net
    7. Test IPv6 prefix delegation
    dhclient -6 -v (Linux/Android Termux)
    8. Test for VPN leaks
    firefox https://ipleak.net
    firefox https://browserleaks.com/ip
    9. Router setup
    Netgear > Advanced > Advanced Setup > IPv6 > Internet Connection Type
    Disabled (IPv6 is completely off)
    Auto Detect (Router tries to detect IPv6 from your ISP)
    6to4 Tunnel (Legacy IPv6-over-IPv4 tunneling)
    Pass Through (Router passes IPv6 directly to LAN devices)
    Fixed (Manual IPv6 configuration)
    DHCP (Used when the ISP hands out IPv6 via DHCPv6)
    PPPoE (Used by DSL providers)
    Auto Config (Router uses SLAAC (stateless autoconfiguration)
    6rd Tunnel (An IPv6-over-IPv4 method used by some ISPs)
    Dual-Stack Lite (Used by ISPs that provide IPv6 but tunnel IPv4.\)
    v6plus (Japan-specific IPv6 service)

    For example
    a. No IPv6 addresses were detected by https://test-ipv6.com
    b. ping -6 google.com fails
    c. My Windows host only has link-local IPv6 (fe80::...)
    d. I have no global IPv6 (2000::/3)
    e. I have no IPv6 default gateway
    f. I have no IPv6 DNS
    g. All IPv6-only sites timed out

    Specifically for https://test-ipv6.com my IPv6 Firefox score was 0/10
    Test with IPv4 DNS record = ok (2.421s) using ipv4
    Test with IPv6 DNS record = timeout (5.611s)
    Test with Dual Stack DNS record = ok (2.821s) using ipv4
    Test for Dual Stack DNS and large packet = ok (1.230s) using ipv4
    Test IPv6 large packet = bad (3.898s)
    Test if your ISP's DNS server uses IPv6 = ok (1.293) using ipv4
    Find IPv4 Service Provider = ok (2.300s) using ipv4
    Find IPv6 Service Provider = bad (3.815s)

    So, it turns out, I never had an IPv6 leak in the first place.
    Because, if IPv6 doesn't exist past the router, it can't leak.
    --
    The journey on Usenet taught me more than the destination ever could.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Wed Jul 22 19:13:53 2026
    From Newsgroup: comp.mobile.android

    Nuno Silva wrote:
    Torrenting on VPN with a bittorrent client aside, IPv6 is more revealing in >> the sense that it gives each device a unique, stable & too public identity >> unless privacy extensions are used (and even those don't fully hide the
    device). So it still behooves all of us to protect against IPv6 leaks.

    If what you're trying to avoid is legal action from the MAFIAA or
    actions from the ISP itself, then it really doesn't matter if it's the
    NATed IPv4 address which gets leaked or an IPv6 one. Both would point to
    your subscription with the ISP.

    Hi Nuno Silva,

    Thanks for worrying about motives, where it's really a technical issue only
    as privacy is like hygiene where it has to be constantly practiced daily.

    There are a million things to do for privacy but most people only know 3.

    But just to be clear, I'm not worried about "legal action", if for no other reason that the knowledge that no litigant in the USA has ever been
    successful in a court of law against an individual torrenting movies.

    But that known fact is not the reason for practicing good privacy hygiene. Privacy hygiene is a thousand things, which, on a computer, gets technical.

    Most marketing organizations don't want us to have privacy, but as
    individuals, privacy is what we need to think about when we're online.

    What I have done as a matter of basic networking hygiene for decades is I
    try to obfuscate my IP address when possible. VPN is just one factor.

    Never registering for any product is yet another factor, just as never
    paying for a product is another factor in the privacy hygiene equation.

    As you may know, almost all my posts are about privacy in one form or
    another, where in the case of IPv6 privacy, I didn't know how bad it was.

    If we're oblivious to the issues, we're likely to befall them, so it
    behooves us to, at the very least, UNDERSTAND how IPv6 leaks can occur.

    If our ISP provides an IPv6 address, and if the router let's it pass, and
    if the host doesn't stop it, and if we don't stop it at the application,
    and if the VPN client doesn't stop it, then every device leaks our privacy.

    Even with RFC 8981 privacy extensions.
    --
    Privacy is a million technical things, of which most people know about 3.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From agris@agris@invalid.tld to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless on Wed Jul 22 17:05:36 2026
    From Newsgroup: comp.mobile.android

    On Wed, 22 Jul 2026 16:54:00 -0400
    Maria Sophia <mariasophia@comprehension.com> wrote:

    Brian Gregory wrote:
    As always, if you have a simpler solution, let's discuss it as the
    whole point of this thread is to ensure we can protect from IPv6
    privacy leaks.

    You are spouting a load of meaningless gibberish.
    It sounds like you are basically disabling IPv6 but coming up with
    a load of complete rubbish to make it sound like you are doing
    something more clever. YOU ARE NOT DOING ANYTHING OTHER THAN
    DISABLING IPv6.

    Hi Brian Gregory,

    Thank you for being blunt, as there is no doubt you are right about
    this. I was wrong.

    The reason I was wrong was simply that I read too much into the fact
    that I couldn't find IPv6 once I set up the bridge after wiping out
    my network, but, in reality, I didn't check the network well before I
    wiped it out.

    The bridge, as bridges are wont to do, did nothing to the IPv6
    address!

    And the only reason I set up the bridge was because I wiped out
    networking in my attempt to rip the heart out of Windows IPv6 routing capability.

    I wrote up a recovery checklist so that anyone following this thread
    has all the steps necessary to wipe out IPv6 properly (hex 20) from
    Windows.

    And Carlos wrote up the steps so that anyone on Linux can follow suit.
    Plus, I added the steps necessary to wipe IPv6 out of the Firefox
    browser.

    So there is a *lot* of good value which came of this IPv6 privacy
    effort. Thanks again for not beating around the bush to let us know
    what you think!

    You shouldn't disable IPv6. It is the current generation of Internet
    Protocol. Rather then disabling it just turn on IPv6 privacy.

    sysctl net.ipv6.conf.eth0.use_tempaddr = 2

    If your VPN doesn't support IPv6 that's your VPN's problem. Switch to
    one that does. NAT was never intended as a privacy or security feature.
    When it set use_tempaddr to 2 you use different addresses for outgoing connections and those addresses expire after a certain (configurable)
    amount of time. Disabling IPv6 and only using a legacy protocol just
    because you don't understand it is like shooting yourself in the foot.
    Don't do it.

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless on Wed Jul 22 23:06:37 2026
    From Newsgroup: comp.mobile.android

    agris wrote:
    So there is a *lot* of good value which came of this IPv6 privacy
    effort. Thanks again for not beating around the bush to let us know
    what you think!

    You shouldn't disable IPv6. It is the current generation of Internet Protocol. Rather then disabling it just turn on IPv6 privacy.

    sysctl net.ipv6.conf.eth0.use_tempaddr = 2

    If your VPN doesn't support IPv6 that's your VPN's problem. Switch to
    one that does. NAT was never intended as a privacy or security feature.
    When it set use_tempaddr to 2 you use different addresses for outgoing connections and those addresses expire after a certain (configurable)
    amount of time. Disabling IPv6 and only using a legacy protocol just
    because you don't understand it is like shooting yourself in the foot.
    Don't do it.

    This thread has been a learning experience for me & hopefully for others.
    To be clear, I'll never disagree with a logically defensible viewpoint.

    While NAT was never a security feature and while IPv6 is a modern Internet protocol, we must agree RFC 8981 privacy extensions exist for a reason.

    As you noted, RFC 8981 enabling of IPv6 Privacy Extensions generates
    temporary, randomized outgoing addresses which rotate periodically.
    sysctl net.ipv6.conf.eth0.use_tempaddr = 2

    Meanwhile, the stable IPv6 address remains available for inbound
    connections, but outbound traffic uses those ephemeral identities. .

    With that in mind, this is one of those technical debates where smart
    people land on different sides because the trade-offs aren't trivial.
    a. VPN leaks are a real, practical concern.
    b. IPv6 privacy extensions aren't a magic shield.
    c. Some users simply don't need IPv6 yet.

    Whether unilaterally disabling IPv6 is "shooting yourself in the foot"
    depends on whether or not we need IPv6 in the first place. Do we?

    I would ask everyone here who cares about this topic to ask themselves...
    Q1: Do you use any services, apps, or devices that require direct
    inbound connections from the internet (such as hosting a game server,
    running a self-hosting services, or accessing your network remotely)?
    Q2: Do you ever use a VPN (either always, often, or occasionally)
    for privacy, work, or bypassing geo-restrictions?
    Q3: When you use VPNs, is your priority mainly IP obfuscation or security?
    Q4: Does your ISP currently give you an IPv6 address?
    Q5: Do you ever connect multiple devices through your home network
    (PC, phone, tablet, smart TV, etc.) and care about them communicating
    smoothly with each other (such as with file sharing, casting, local
    streaming, or LAN gaming)?
    Q6: Do you ever use modern devices or apps that require IPv6 to work
    such as smart-home devices, peer-to-peer apps, or anything that
    requires "IPv6 connectivity" in its settings?

    The point of these questions is to ascertain if we even need IPv6.
    For example,
    a. I do not host anything that needs IPv6
    b. I don't have apps that require IPv6
    c. My WISP doesn't even give me IPv6
    d. I bittorrent only through a VPN
    e. When I switch networks (e.g., a hotspot) I only care about privacy

    So, in my case, IPv6 adds no value and only leaks my real identity.
    Even if my ISP does not give me IPv6, my devices device (Windows, Linux, Android, etc.) & browsers will still try to use IPv6 whenever possible.

    At home, IPv6 is NOT a privacy threat because there is nothing to leak.

    But when my device is *outside* my network (admittedly, that's for laptops
    and phones), the device will happily use IPv6 which leaks our identities.

    When I go to the public library and connect my phone & laptop to their
    Wi-Fi network, the laptop & phone get an IPv6 address which websites see.

    But the latter half of that IPv6 address is unique to the device!
    However, when I just looked that up, I found something we haven't stated.
    A. Android rotates temporary IPv6 addresses regularly
    B. Windows 10/11 generates temporary IPv6 addresses by default
    C. Most Linux variants enable IPv6 privacy extensions by default

    Android, Windows, and modern Linux all use temporary IPv6 addresses!
    By default.

    Windows uses two timers:
    a. Preferred lifetime (generally 24 hours)
    b. Valid lifetime (generally 7 days)

    Android rotates temporary IPv6 addresses every 24 hours.

    Modern Linux distros ship with:
    net.ipv6.conf.default.use_tempaddr = 2
    net.ipv6.conf.all.use_tempaddr = 2
    a. Preferred lifetime (generally 24 hours)
    b. Valid lifetime (generally 7 days, but this isn't used in most Linux's)

    Since our IPv6 temporary address (RFC 8981) lasts ~24 hours, we're
    trackable if we, for example visit the same network twice in a day.

    Two visits to the same website on the same day, from home, could be linked.
    a. With IPv4 they know it's the same household.
    b. With IPv6 they know it's the same device.

    Please correct me if I'm wrong, as the whole point is to understand IPv6.
    --
    Once we understand the complexities, the whole thing becomes very simple.





























    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Brian Gregory@void-invalid-dead-dontuse@email.invalid to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Thu Jul 23 04:33:58 2026
    From Newsgroup: comp.mobile.android

    On 22/07/2026 21:46, Maria Sophia wrote:
    The problem, as I see it, wrt privacy, is while IPv4 (with NAT) gave every home a unique IP address, IPv6 gives every device a unique IP address.

    As you astutely and helpfully noted, we can ameliorate 'some' of that IPV6 privacy flaw by employing RFC 8981 privacy extensions, but they only rotate the latter half of the IPv6 address & even so, only after a period of time.

    And, of course, for most people, with only one LAN, using only a single
    /64 the first half of the IPv6 address gives away no more than your IPv4 address gives away -- that it's something of yours.

    Although I always run dual stack when I can and tend to urge others to
    do so too, I do accept that running IPv4 only is a valid option if you
    have certain priorities, that differ from mine.
    --
    Brian Gregory (in England).
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Brian Gregory@void-invalid-dead-dontuse@email.invalid to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless on Thu Jul 23 04:50:17 2026
    From Newsgroup: comp.mobile.android

    On 23/07/2026 04:06, Maria Sophia wrote:
    agris wrote:
    So there is a *lot* of good value which came of this IPv6 privacy
    effort. Thanks again for not beating around the bush to let us know
    what you think!

    You shouldn't disable IPv6. It is the current generation of Internet
    Protocol. Rather then disabling it just turn on IPv6 privacy.

    sysctl net.ipv6.conf.eth0.use_tempaddr = 2

    If your VPN doesn't support IPv6 that's your VPN's problem. Switch to
    one that does. NAT was never intended as a privacy or security feature.
    When it set use_tempaddr to 2 you use different addresses for outgoing
    connections and those addresses expire after a certain (configurable)
    amount of time. Disabling IPv6 and only using a legacy protocol just
    because you don't understand it is like shooting yourself in the foot.
    Don't do it.

    This thread has been a learning experience for me & hopefully for others.
    To be clear, I'll never disagree with a logically defensible viewpoint.

    While NAT was never a security feature and while IPv6 is a modern Internet protocol, we must agree RFC 8981 privacy extensions exist for a reason.

    As you noted, RFC 8981 enabling of IPv6 Privacy Extensions generates temporary, randomized outgoing addresses which rotate periodically.
    sysctl net.ipv6.conf.eth0.use_tempaddr = 2

    Meanwhile, the stable IPv6 address remains available for inbound
    connections, but outbound traffic uses those ephemeral identities. .

    With that in mind, this is one of those technical debates where smart
    people land on different sides because the trade-offs aren't trivial.
    a. VPN leaks are a real, practical concern.
    b. IPv6 privacy extensions aren't a magic shield.
    c. Some users simply don't need IPv6 yet.

    Whether unilaterally disabling IPv6 is "shooting yourself in the foot" depends on whether or not we need IPv6 in the first place. Do we?

    I would ask everyone here who cares about this topic to ask themselves...
    Q1: Do you use any services, apps, or devices that require direct
    inbound connections from the internet (such as hosting a game server,
    running a self-hosting services, or accessing your network remotely)? Q2: Do you ever use a VPN (either always, often, or occasionally)
    for privacy, work, or bypassing geo-restrictions?
    Q3: When you use VPNs, is your priority mainly IP obfuscation or security? Q4: Does your ISP currently give you an IPv6 address?
    Q5: Do you ever connect multiple devices through your home network
    (PC, phone, tablet, smart TV, etc.) and care about them communicating
    smoothly with each other (such as with file sharing, casting, local
    streaming, or LAN gaming)?
    Q6: Do you ever use modern devices or apps that require IPv6 to work
    such as smart-home devices, peer-to-peer apps, or anything that
    requires "IPv6 connectivity" in its settings?

    The point of these questions is to ascertain if we even need IPv6.
    For example,
    a. I do not host anything that needs IPv6
    b. I don't have apps that require IPv6
    c. My WISP doesn't even give me IPv6
    d. I bittorrent only through a VPN
    e. When I switch networks (e.g., a hotspot) I only care about privacy

    So, in my case, IPv6 adds no value and only leaks my real identity.
    Even if my ISP does not give me IPv6, my devices device (Windows, Linux, Android, etc.) & browsers will still try to use IPv6 whenever possible.

    At home, IPv6 is NOT a privacy threat because there is nothing to leak.

    But when my device is *outside* my network (admittedly, that's for laptops and phones), the device will happily use IPv6 which leaks our identities.

    When I go to the public library and connect my phone & laptop to their
    Wi-Fi network, the laptop & phone get an IPv6 address which websites see.

    But the latter half of that IPv6 address is unique to the device!
    However, when I just looked that up, I found something we haven't stated.
    A. Android rotates temporary IPv6 addresses regularly
    B. Windows 10/11 generates temporary IPv6 addresses by default
    C. Most Linux variants enable IPv6 privacy extensions by default

    Android, Windows, and modern Linux all use temporary IPv6 addresses!
    By default.

    Windows uses two timers:
    a. Preferred lifetime (generally 24 hours)
    b. Valid lifetime (generally 7 days)

    Android rotates temporary IPv6 addresses every 24 hours.

    Modern Linux distros ship with:
    net.ipv6.conf.default.use_tempaddr = 2
    net.ipv6.conf.all.use_tempaddr = 2
    a. Preferred lifetime (generally 24 hours)
    b. Valid lifetime (generally 7 days, but this isn't used in most Linux's)

    Since our IPv6 temporary address (RFC 8981) lasts ~24 hours, we're
    trackable if we, for example visit the same network twice in a day.

    Two visits to the same website on the same day, from home, could be linked.
    a. With IPv4 they know it's the same household.
    b. With IPv6 they know it's the same device.

    Please correct me if I'm wrong, as the whole point is to understand IPv6.

    Sounds right.
    In theory you can change things so that RFC 8981 privacy addresses
    change more often, but I believe it isn't often simple to do and can
    cause unexpected problems in certain situations. Plus, of course, it has
    to be done once on each device you want to keep private.
    --
    Brian Gregory (in England).
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Nuno Silva@nunojsilva@invalid.invalid to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Thu Jul 23 08:12:11 2026
    From Newsgroup: comp.mobile.android

    On 2026-07-23, Brian Gregory wrote:

    On 22/07/2026 21:46, Maria Sophia wrote:
    The problem, as I see it, wrt privacy, is while IPv4 (with NAT) gave every >> home a unique IP address, IPv6 gives every device a unique IP address.

    As you astutely and helpfully noted, we can ameliorate 'some' of that IPV6 >> privacy flaw by employing RFC 8981 privacy extensions, but they only rotate >> the latter half of the IPv6 address & even so, only after a period of time.

    And, of course, for most people, with only one LAN, using only a
    single /64 the first half of the IPv6 address gives away no more than
    your IPv4 address gives away -- that it's something of yours.

    Yeah, if you're in a context where IPv4 is NATed at your premises
    because the ISP hands you one address, and you also get IPv6 prefix
    delegation, then... it's the same thing, your IPv4 address identifies
    the connection, as does the prefix present in the RAs.

    The part that is "rotated" or otherwise randomized in such
    privacy-centered SLAAC configurations is the one that'd allow tracking
    the *device*, not the connection.

    That's not meant to stop tracking your e.g. residential connection, it's
    meant to stop tracking the device based on the device-specific portion
    of the address, which without this may e.g. contain the MAC address.

    <https://en.wikipedia.org/wiki/IPv6_address#Interface_identifier>


    But for e.g. MAFIAA this only matters if you're not using your own
    connection, because otherwise you've already been identified by the
    delegated prefix, they'd pester you the same.

    Do note: the prefix used in SLAAC isn't (or shouldn't be...) something a residential ISP uses for several costumers, it's meant to be one prefix
    for each contract/ISP connection/modem.

    Although I always run dual stack when I can and tend to urge others to
    do so too, I do accept that running IPv4 only is a valid option if you
    have certain priorities, that differ from mine.
    --
    Nuno Silva
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Richmond@dnomhcir@gmx.com to comp.mobile.android on Thu Jul 23 10:00:54 2026
    From Newsgroup: comp.mobile.android

    Maria Sophia <mariasophia@comprehension.com> writes:

    Thanks for that useful information about your ISP providing you IPv6 addresses where, from looking it up, it seems that the router assigns each device a unique globally routable IP address.

    It is entirely the router which does this. The router assigns one puplic
    ipv4 address and one public ipv6 address. And it sends linux and android
    etc the prefix /64, then linux assigns a temporary dynamic address
    within that network and so does Android.

    As for my situation, my free VPN which I've been using since 2013 doesn't stop IPv6 but in my case, it turns out the WISP doesn't provide it anyway.

    How did you determine this (that it does not stop ipv6) if you have no
    ipv6 address? Did the website display your local address? or was it an
    address from the VPN? I can tell my ipv6 addresses because they all
    begin with the same 64 bits allocated by my ISP.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Richmond@dnomhcir@gmx.com to comp.mobile.android on Thu Jul 23 10:01:54 2026
    From Newsgroup: comp.mobile.android

    Richmond <dnomhcir@gmx.com> writes:

    It is entirely the router which does this

    That should be NOT entirely. :/

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Carlos E. R.@robin_listas@es.invalid to comp.mobile.android on Thu Jul 23 11:13:24 2026
    From Newsgroup: comp.mobile.android

    On 2026-07-23 11:00, Richmond wrote:
    Maria Sophia <mariasophia@comprehension.com> writes:

    Thanks for that useful information about your ISP providing you IPv6
    addresses where, from looking it up, it seems that the router assigns each >> device a unique globally routable IP address.

    It is entirely the router which does this. The router assigns one puplic
    ipv4 address and one public ipv6 address. And it sends linux and android
    etc the prefix /64, then linux assigns a temporary dynamic address
    within that network and so does Android.

    As for my situation, my free VPN which I've been using since 2013 doesn't
    stop IPv6 but in my case, it turns out the WISP doesn't provide it anyway.

    How did you determine this (that it does not stop ipv6) if you have no
    ipv6 address? Did the website display your local address? or was it an address from the VPN? I can tell my ipv6 addresses because they all
    begin with the same 64 bits allocated by my ISP.

    I don't know how he did, it is a good question :-)

    However, the concept of ipv6 leak is actually a known thing. You can
    google "ipv6 leak in the context of vpn" (worded to get an answer from
    the AI), and it says:


    AI Overview

    An IPv6 leak occurs when your VPN protects only IPv4 traffic, allowing
    your device's IPv6 requests to bypass the encrypted tunnel. This means
    your real ISP-assigned IPv6 address is exposed to the websites you
    visit, completely defeating the privacy and security purposes of using a
    VPN.

    Why It Happens

    Many modern VPN providers route all your data through a secure IPv4
    tunnel but fail to support or encrypt IPv6 traffic. If your internet
    service provider (ISP) supports IPv6 and you visit a website with IPv6 enabled, your browser will prioritize the IPv6 connection and
    communicate directly with the site, completely outside the VPN's
    protection.

    How to Check for Leaks

    You shouldn't rely solely on your VPN applicationrCOs "connected" status,
    as it often cannot detect background IPv6 traffic. You can verify your connection by doing the following:

    1. Disconnect from your VPN and visit an IPv6 testing tool like
    IPleak.net or Test-IPv6 to see your default IPv6 address.

    2. Connect to your VPN and refresh the page.
    If the test still shows your real IPv6 address or your VPN's IPv4
    address but a separate native IPv6 address, you are experiencing a leak.


    How to Prevent IPv6 Leaks

    To secure your connection against IPv6 leaks, use one of the following methods:

    * Enable IPv6 Leak Protection: Many top-tier VPN clients feature
    built-in IPv6 leak protection, which either routes IPv6 traffic through
    the secure tunnel or blocks it entirely. Check your VPN apprCOs settings (e.g., in Proton VPN, this is found under connection or advanced settings).

    * Disable IPv6 on Your Device: If your VPN provider does not
    support IPv6 routing, you can manually disable the IPv6 protocol in your operating system's network adapter settings. This forces all data to use
    the IPv4 protocol, which is fully encrypted by your VPN.

    * Use a Kill Switch: While not an IPv6-specific fix, enabling a VPN
    kill switch will instantly sever your internet connection if the VPN
    drops, preventing any unauthorized traffic (including IPv6 leaks) from
    leaving your device.

    Could you tell me what VPN provider and which operating system (Windows, macOS, iOS, Android, Linux) you are currently using? I can then provide
    you with step-by-step instructions to fix the leak.


    And then it lists some links.
    --
    Cheers,
    Carlos E.R.
    ESEfc-Efc+, EUEfc-Efc|;
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Richmond@dnomhcir@gmx.com to comp.mobile.android on Thu Jul 23 11:03:07 2026
    From Newsgroup: comp.mobile.android

    "Carlos E. R." <robin_listas@es.invalid> writes:

    I don't know how he did, it is a good question :-)

    However, the concept of ipv6 leak is actually a known thing. You can
    google "ipv6 leak in the context of vpn" (worded to get an answer from
    the AI), and it says:


    If WebRTC is leaking the IP address then you can switch it off. But that
    stops Google Meet from working. But then if you are using Google Meet
    then you've blown your privacy out of the window anyway. In fact if you
    are using android then you've blown your privacy out of the window
    probably.

    If your browser has a unique fingerprint then hiding your IP address
    won't be enough to really hide.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Carlos E. R.@robin_listas@es.invalid to comp.mobile.android on Thu Jul 23 12:58:01 2026
    From Newsgroup: comp.mobile.android

    On 2026-07-23 12:03, Richmond wrote:
    "Carlos E. R." <robin_listas@es.invalid> writes:

    I don't know how he did, it is a good question :-)

    However, the concept of ipv6 leak is actually a known thing. You can
    google "ipv6 leak in the context of vpn" (worded to get an answer from
    the AI), and it says:


    If WebRTC is leaking the IP address then you can switch it off. But that stops Google Meet from working. But then if you are using Google Meet
    then you've blown your privacy out of the window anyway. In fact if you
    are using android then you've blown your privacy out of the window
    probably.


    With IPv6 you can do a video conferencing without involving any
    intermediary. Direct call. Think of fixed IP global addressing as having
    a phone number. You just dial the number of the destination machine and
    start talking.

    This is improved privacy. Another type of it. Google, microsoft,
    yahoo... no one knows who you are talking with. Well, the ISP knows, but
    at least in the EU they can not use that information.

    If your browser has a unique fingerprint then hiding your IP address
    won't be enough to really hide.
    --
    Cheers,
    Carlos E.R.
    ESEfc-Efc+, EUEfc-Efc|;
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Thu Jul 23 16:23:44 2026
    From Newsgroup: comp.mobile.android

    Nuno Silva wrote:
    The problem, as I see it, wrt privacy, is while IPv4 (with NAT) gave every >>> home a unique IP address, IPv6 gives every device a unique IP address.

    As you astutely and helpfully noted, we can ameliorate 'some' of that IPV6 >>> privacy flaw by employing RFC 8981 privacy extensions, but they only rotate >>> the latter half of the IPv6 address & even so, only after a period of time. >>
    And, of course, for most people, with only one LAN, using only a
    single /64 the first half of the IPv6 address gives away no more than
    your IPv4 address gives away -- that it's something of yours.
    Although I always run dual stack when I can and tend to urge others to
    do so too, I do accept that running IPv4 only is a valid option if you
    have certain priorities, that differ from mine.

    Yeah, if you're in a context where IPv4 is NATed at your premises
    because the ISP hands you one address, and you also get IPv6 prefix delegation, then... it's the same thing, your IPv4 address identifies
    the connection, as does the prefix present in the RAs.

    The part that is "rotated" or otherwise randomized in such
    privacy-centered SLAAC configurations is the one that'd allow tracking
    the *device*, not the connection.

    That's not meant to stop tracking your e.g. residential connection, it's meant to stop tracking the device based on the device-specific portion
    of the address, which without this may e.g. contain the MAC address.

    <https://en.wikipedia.org/wiki/IPv6_address#Interface_identifier>

    But for e.g. MAFIAA this only matters if you're not using your own connection, because otherwise you've already been identified by the
    delegated prefix, they'd pester you the same.

    Do note: the prefix used in SLAAC isn't (or shouldn't be...) something a residential ISP uses for several costumers, it's meant to be one prefix
    for each contract/ISP connection/modem.

    Although I always run dual stack when I can and tend to urge others to
    do so too, I do accept that running IPv4 only is a valid option if you
    have certain priorities, that differ from mine.

    Thank you all for this very useful information about IPv6 privacy issues.

    Since Usenet is for learning from people like Nuno Silva & Brian Gregory,
    who know far more about this IPv6-privacy stuff than I will ever know...

    Looking up the terms they're using is helpful to understand the network.

    When Brian says "dual stack", he's meaning both the IPv4 & IPv6 stacks.
    They're two parallel protocol stacks, where his devices can use either
    protocol depending on what the remote service supports. If a site has IPv6,
    his device may prefer it; if not, it falls back to IPv4, which provides
    Brian benefit from IPv6's performance and routing improvements without
    losing any IPv4 compatibility.

    When Nuno says SLAAC, he's using the acronym for Stateless Address Autoconfiguration, which is the IPv6 mechanism that lets a device
    automatically generate its own IPv6 address without needing a DHCP server.

    The ISP gives us the network prefix (the first 64 bits) IPv6 address and
    each device builds the second half (the Interface Identifier) IID address
    on its own. It used to be derived from the MAC address, but not in modern systems anymore, the point being if the IID half is stable, websites can
    track specific devices across sessions. RFC 8981 destabilizes that, but
    only after a set time period (generally defaulting to 24 hours).

    An example is if you go to Starbucks in the morning and afternoon, and
    visit the same web site in two different sessions, they know it's you in
    both sessions.

    Note that the web site knows it's starbucks too, which is why the first
    half of IPV6 is no worse in terms of privacy than IPv4 is; but it's that festugenah second half of the IPv5 prefix that we have to keep in mind.

    His MAFIAA terminology is a play on the mafia-like behavior of copyright trolls, combining RIAA (Recording Industry Association of America) with
    MPAA (Motion Picture Association of America), where I would stress that
    many people pay up but nobody who ever fought them in the USA ever lost.

    With respect to VPN, I just found out that OpenVPN 2.5+ added a directive specifically meant to prevent the very IPv6 leaks we've been discussing!
    block-ipv6 ; block IPv6 traffic by adding firewall rules to prevent leaks Apparently it magically installs firewall rules on our devices that somehow know to drop all IPv6 traffic unless it is going through the VPN tunnel.

    It forces all IPv6 traffic to go through the VPN, or be blocked entirely. .

    If running older OpenVPN on linux, we can add firewall rules manually:
    ip6tables -P OUTPUT DROP
    ip6tables -P INPUT DROP

    In short, I thank Nuno & Brian for bringing this up at a level far above my
    pay grade since I just learned the simplest solution of all to the problem.

    Apparently block-ivp6 blocks IPv6 only when the tunnel doesn't support it. Which is perfect because understanding networking is what this is about.

    BTW, while looking this up, I learned these potentially useful directives:
    block-outside-dns ; force DNS queries to stay inside the VPN interface
    This says, if a program tries to resolve DNS through wlan0, eth0, or
    anything other than the TAP adapter, then block it (to prevent leaks).

    Then, inside the VPN tunnel, we can explicitly set the DNS servers.
    dhcp-option DNS 1.1.1.1 ; set primary DNS to Cloudflare inside the tunnel
    dhcp-option DNS 9.9.9.9 ; set secondary DNS to Quad9 for secure fallback

    I just tested them; now I see a full, healthy DNS stack inside the tunnel.
    NETSH: ... set dns 19 static 1.1.1.1
    NETSH: ... add dns 19 9.9.9.9
    NETSH: ... add dns 19 8.8.8.8

    I knew absolutely nothing about IPv6 before this thread, so I thank
    everyone for quickly correcting my newbie mistakes without pulling punches!

    I still have work to do because apparently curl leaks outside of the VPN.
    --
    I learn best from helpful people who know a hellova lot more than I do.


































    .
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless on Thu Jul 23 16:51:25 2026
    From Newsgroup: comp.mobile.android

    Brian Gregory wrote:
    Two visits to the same website on the same day, from home, could be linked. >> a. With IPv4 they know it's the same household.
    b. With IPv6 they know it's the same device.

    Please correct me if I'm wrong, as the whole point is to understand IPv6.

    Sounds right.
    In theory you can change things so that RFC 8981 privacy addresses
    change more often, but I believe it isn't often simple to do and can
    cause unexpected problems in certain situations. Plus, of course, it has
    to be done once on each device you want to keep private.

    Thanks Brian for checking me as I never even looked at IPv6 until I started modifying the LiquidVPN killswitch (which simply removed the gateway)
    because when I changed from a USB dongle Wi-Fi on my Ethernet-only desktop,
    the Wi-Fi card I added was so much more complex, that Windows "fixed
    itself" every time I wiped out the gateway, so the killswitch didn't work.

    When I started writing that killswitch, I ran into IPv6 considerations for
    the first time, which I never thought about since I didn't use IPv6.

    What I didn't know was that EVERYTHING uses IPv6 if it can, nowadays.

    So, for example, in the IPv4-only days, if I take a device (phone or
    laptop) to a local hotspot, and visit a website twice within the same day,
    then they only know that "something" connected from that particular site.

    But, in these dual-stack IPv4+IPv6 days, all our device operating systems
    and browsers prefer IPv6 over IPv4 so we connect using the IPv6 IP address.

    Now, if I take a device (phone or laptop) to a local hotspot, and visit a website twice within the same day, now they know that the "same device" connected from that particular site, which is a recent elevation to me.

    That "oh shit!" moment is the same as when I realized that the pixel imperfections in two camera photos uniquely identifies that same camera,
    such that if I post two photos to two websites, anyone scraping those two
    web sites can tell both pictures were taken from the same camera.

    Only after those "oh shit!" moments can I begin to implement ameliorations.

    Hence, I thank you for correcting all my false statements about IPv6
    privacy, as I love it when someone sets me straight on my assumptions.
    --
    Of the million things we need to know about privacy, most know 3.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Thu Jul 23 17:40:03 2026
    From Newsgroup: comp.mobile.android

    Nuno Silva wrote:
    Who here is actually using IPv6 for anything that would be impacted?

    Probably a few people who are behind NAT, or worse, CGNAT, but do get
    IPv6 prefixes might have interest in retaining that connectivity.

    Completely axing IPv6 also gets rid of link-local addresses, that can be useful for internal networking.

    Not that I'm taking advantage of that on Android. (Yet. :-P)

    This is going only to Android users...

    The biggest danger to android users, as I see it, is they need to *know*
    that if they are at a hotspot twice within 24 hours, their exact unique
    device is what is likely known to any web site that they visit.

    It changes "per network", but what if we connect to the same network?

    What we need to learn, as Android users, is how to stop that privacy leak.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Jim Jackson@jj@franjam.org.uk to comp.mobile.android on Fri Jul 24 10:33:36 2026
    From Newsgroup: comp.mobile.android

    On 2026-07-23, Maria Sophia <mariasophia@comprehension.com> wrote:
    Nuno Silva wrote:
    Who here is actually using IPv6 for anything that would be impacted?

    Probably a few people who are behind NAT, or worse, CGNAT, but do get
    IPv6 prefixes might have interest in retaining that connectivity.

    Completely axing IPv6 also gets rid of link-local addresses, that can be
    useful for internal networking.

    Not that I'm taking advantage of that on Android. (Yet. :-P)

    This is going only to Android users...

    The biggest danger to android users, as I see it, is they need to *know*
    that if they are at a hotspot twice within 24 hours, their exact unique device is what is likely known to any web site that they visit.

    It changes "per network", but what if we connect to the same network?

    What we need to learn, as Android users, is how to stop that privacy leak.

    (sorry if this has been metioned before, I'vce not been reading
    reacently and not read the whole thread)

    My Android Fairphone 5 is configured (by default) to create a random MAC address per network connection. As the MAC is used to create your global
    IPv6 address you get a changing address to help prevent tracking.

    Not that I've actually checked this out. But it should be simple to
    check by visiting one of "tell-me-your-ip address" sites, and noting if
    it changes after a reconnect to the local network.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to comp.mobile.android on Fri Jul 24 04:20:09 2026
    From Newsgroup: comp.mobile.android

    Jim Jackson wrote:
    What we need to learn, as Android users, is how to stop that privacy leak.

    (sorry if this has been metioned before, I'vce not been reading
    reacently and not read the whole thread)

    My Android Fairphone 5 is configured (by default) to create a random MAC address per network connection. As the MAC is used to create your global IPv6 address you get a changing address to help prevent tracking.

    Not that I've actually checked this out. But it should be simple to
    check by visiting one of "tell-me-your-ip address" sites, and noting if
    it changes after a reconnect to the local network.

    It's good that people are thinking about privacy as it's a complicated
    thing that we should all work together to improve our knowledge of.

    That randomizing of the MAC address you speak of is real, but it is a
    different component of the Android privacy picture when we visit a hotspot.

    Most Android phones, nowadays, randomize the MAC address per network.
    In Developer Options is a switch to also randomize the MAC per connection.

    So yes, the Starbucks would know it's the same device, forever, if we only randomize per network.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Fri Jul 24 11:36:57 2026
    From Newsgroup: comp.mobile.android

    As a related aside, if your network ever does go to hell in a handbasket,
    the following manual commands seem to surgically fix mine in a flash.
    a. This sequence touches every networking layer that commonly breaks.
    b. Renaming interfaces removes whitespace headaches & makes scripting sane.
    c. Toggling up/down forces driver rebinding and flushes stale states.
    d. Setting static IP + DNS eliminates DHCP weirdness
    e. The connectivity validation is in the proper escalation order
    i. Local gateway
    ii. Public IP
    iii. DNS resolution
    iv. HTTP throughput
    v. Full speed test
    f. route print -4 confirms the metrics and/or stale routes
    g. Resetting Winsock is the nuclear option for corrupt proxies.

    One-time commands to simplify the networking scripts:
    netsh interface set interface name="Ethernet 2" newname="eth0"
    netsh interface set interface name="Wi-Fi 2" newname="wlan0"
    One-time commands to set a networking metric baseline:
    netsh interface ipv4 set interface "eth0" metric=10
    netsh interface ipv4 set interface "wlan0" metric=20

    Set your network for Ethernet (in my case, via a wireless router):
    netsh interface set interface "wlan0" admin=disabled
    netsh interface set interface "eth0" admin=enabled
    netsh interface ipv4 set address name="eth0" static 192.168.1.15 255.255.255.0 192.168.1.1
    netsh interface ipv4 set dns name="eth0" static 1.1.1.1
    netsh interface ipv4 add dns name="eth0" 1.0.0.1
    netsh interface ipv4 show dnsservers
    netsh interface ipv4 show config name="eth0"
    netsh interface ipv4 show config
    netsh interface ipv4 show dnsservers
    ping -n 1 192.168.1.1
    ping -n 1 1.1.1.1
    ping -n 1 www.google.com
    wmic nic where (NetEnabled=true) get Name, Speed
    curl -o NUL http://speedtest.tele2.net/1MB.zip
    curl -o NUL http://speedtest.tele2.net/10MB.zip
    curl -o NUL http://speedtest.tele2.net/100MB.zip
    speedtest.exe (from <https://www.speedtest.net/apps/cli>)
    route print -4
    ipconfig /all
    At this point you can now run psiphon.bat or vpn.bat

    Set your network for Wi-Fi (in my case, via a Wi-Fi NIC card):
    netsh interface set interface "eth0" admin=disabled
    netsh interface set interface "wlan0" admin=enabled
    netsh interface ipv4 set address name="wlan0" static 192.168.1.16 255.255.255.0 192.168.1.1
    netsh interface ipv4 set dns name="wlan0" static 1.1.1.1
    netsh interface ipv4 add dns name="wlan0" 1.0.0.1
    netsh wlan connect name="my.ssid_nomap"
    (note that the SSID should always be hidden broadcast!)
    netsh interface ipv4 show config
    netsh interface ipv4 show config name="wlan0"
    netsh interface ipv4 show dnsservers
    ping -n 1 192.168.1.1
    ping -n 1 1.1.1.1
    ping -n 1 www.google.com
    wmic nic where (NetEnabled=true) get Name, Speed
    curl -o NUL http://speedtest.tele2.net/1MB.zip
    curl -o NUL http://speedtest.tele2.net/10MB.zip
    curl -o NUL http://speedtest.tele2.net/100MB.zip
    speedtest.exe (from <https://www.speedtest.net/apps/cli>)
    route print -4
    ipconfig /all
    At this point you can now run psiphon.bat or vpn.bat

    ============================================================
    Here's a networking cheat sheet if anyone needs the commands. ============================================================
    Layer 1: link & adapter state
    check NIC driver + link status
    wmic nic get Name,NetEnabled,Speed
    show adapter statistics (errors/drops)
    netstat -e
    show interface statistics
    netsh interface ipv4 show interfaces ============================================================
    Layer 2: arp & neighbor discovery
    show arp table
    arp -a
    show ipv4 neighbor cache
    netsh interface ipv4 show neighbors
    clearing arp can fix phantom MAC mappings
    arp -d *
    ============================================================
    Layer 3: ip configuration & routing
    show ipv4 global settings
    netsh interface ipv4 show global
    show ipv4 addresses
    netsh interface ipv4 show address
    show routing table (ipv4 only)
    route print -4
    show active tcp/udp endpoints
    netstat -an
    check for leftover VPN static routes
    route print -4
    route delete <network> ============================================================
    Layer 4: dhcp
    check dhcp server discovery
    netsh dhcp show server
    show dhcp-assigned addresses
    netsh interface ip show addresses
    force dhcp renew
    ipconfig /release && ipconfig /renew ============================================================
    Layer 5: dns
    test dns resolution
    nslookup example.com
    show dns cache
    ipconfig /displaydns
    flush dns cache
    ipconfig /flushdns
    check browser DNS-over-HTTPS interference
    Chrome: chrome://settings/security
    Firefox: about:preferences#privacy ============================================================
    Layer 6: firewall
    show firewall rules
    netsh advfirewall firewall show rule name=all
    show firewall profile state
    netsh advfirewall show allprofiles ============================================================
    Layer 7: winsock
    show winsock providers
    netsh winsock show catalog
    reset winsock (fixes corruption)
    netsh winsock reset
    reset tcp/ip stack (deeper than winsock)
    netsh int ip reset ============================================================
    Layer 8: connectivity tests
    ping gateway
    ping <gateway>
    ping ipv4-only target
    ping -4 8.8.8.8
    trace ipv4 route
    tracert 8.8.8.8
    test ipv4 http
    curl -4 http://example.com ============================================================
    Layer 9: system logs
    open event viewer
    eventvwr.msc
    check dhcp logs
    (event viewer > microsoft > windows > dhcp-client)
    check tcp/ip logs
    (event viewer > system > tcpip)
    check ndis driver logs
    (event viewer > system > ndis) ============================================================
    Layer 10: advanced routing & bindings
    show interface metrics
    netsh interface ipv4 show interfaces
    show binding joins
    netsh interface ip show joins
    show tcp global parameters
    netsh interface tcp show global ============================================================
    Layer 11: proxy cleanup
    show winhttp proxy
    netsh winhttp show proxy
    reset winhttp proxy
    netsh winhttp reset proxy ============================================================
    Layer 12: NIC driver rebinding
    disable NIC driver
    wmic path win32_networkadapter where NetEnabled=true call disable
    enable NIC driver
    wmic path win32_networkadapter where NetEnabled=false call enable ============================================================
    Verify no leftover VPN routes
    route print -4
    route delete eth0
    Some browsers override system DNS:
    about:preferences#privacy
    chrome://settings/security
    --
    On Usenet, friendly kind-hearted people help each other out daily.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Oregonian Haruspex@no_email@invalid.invalid to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Sat Jul 25 04:58:33 2026
    From Newsgroup: comp.mobile.android

    David Higton <dave@davehigton.me.uk> wrote:
    In message <113kg6k$s72$1@nnrp.usenet.blueworldhosting.com>
    Maria Sophia <mariasophia@comprehension.com> wrote:

    PSA:
    IPv6 browser privacy leaks are caused by the host, yet there's a fix.
    ISP modem > IPv6-silent bridge > normal home router > Wi-Fi devices

    On all platforms, web browsers can leak your globally-routable IPv6
    address (even when you're using a VPN). This IPV6 privacy leak happens
    because the browsers prefer IPv6 and the OS host itself participates in
    IPv6 routing.

    I don't understand why you think there's a problem. Very much the whole point of IPv6 is that all your globally routable IPv6 addresses are,
    well, globally routable. I'd be happy for the whole world to know what
    mine are.

    The only ports that are open on any of these addresses to incoming connections are as a result of my opening a pinhole in the firewall.

    So, knowing your globally routable addresses is one thing. Allowing connections in to any of them is entirely another matter.

    David


    NSA-coded post right here lol.

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@mariasophia@comprehension.com to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Sun Jul 26 14:25:39 2026
    From Newsgroup: comp.mobile.android

    Oregonian Haruspex wrote:
    NSA-coded post right here lol.

    To ensure DNS is working right, I explicitly set it in the openvpn config.

    These are the commands I add to every one of hundreds of free config files. Notice the DNS-related commands are brand new, to keep DNS inside the tunnel.

    auth-nocache ; prevent caching of auth credentials in memory
    auth-retry nointeract ; retry silently using stored username/password
    auth-user-pass C:\\tmp\\vpn\\0\\require\\userpass.txt ; login file path
    block-ipv6 ; block IPv6 traffic to prevent IPv6 leaks
    block-outside-dns ; force DNS queries to stay inside the VPN TAP interface
    ; NB block-outside-dns breaks OS DNS if the VPN's DNS server is dead
    ; dhcp-option DNS 1.1.1.1 ; set primary DNS to Cloudflare inside the tunnel
    ; dhcp-option DNS 9.9.9.9 ; set secondary DNS to Quad9 for secure fallback
    connect-retry-max 20 ; increase max reconnect attempts (default=8)
    connect-retry 5 ; shorten delay between reconnect attempts
    connect-timeout 30 ; time before initial connect attempt times out
    data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC ; required by vpngate.net
    explicit-exit-notify 2 ; send disconnect notice to UDP servers
    float ; accept server IP changes during session
    hand-window 180 ; extend TLS handshake window (default=60)
    inactive 3600 ; allow long idle periods before timeout (default=off)
    ip-win32 adaptive ; choose best Windows IP/DNS routing method
    keepalive 10 60 ; ping every 10s, restart after 60s silence
    mssfix 1400 ; adjust TCP MSS to reduce fragmentation
    tun-mtu 1400 ; set tunnel MTU to avoid packet fragmentation
    ; pull-filter ignore "redirect-gateway" ; prevent server from setting gateway
    pull-filter accept "redirect-gateway" ; accept the vpn server routing changes
    pull ; accept configuration pushed by the VPN server
    replay-window 128 ; enlarge replay protection packet window
    route-delay 10 ; delay route setup to avoid race conditions
    server-poll-timeout 120 ; wait longer for server PUSH reply (default=2)
    tls-timeout 180 ; extend TLS negotiation timeout (default=60)
    verb 4 ; moderate verbosity, show key events without packet spam

    During testing, on Windows, I made use of the old curlit shortcut:
    Win+R > curlit
    Which calls curlit.exe which is defined only in the Windows Registry
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\curlit.exe
    Default=C:\path-to\curlit.lnk
    Where the TARGET of that curlit.lnk shortcut does the IP check.
    Target=%comspec% /k echo "C:\data\sys\pgm\lnk\curlit.lnk $MYIP" & %Windir%\System32\curl.exe icanhazip.com
    NB: There is no command called "curlit.exe"; that's a unique reg keyword.

    I tried to make it fancier with curlvpn but that errored out on Windows:
    TARGET=%comspec% /k echo "curlvpn: forcing curl through VPN TAP adapter" & %Windir%\System32\curl.exe --interface Ethernet --dns-servers 1.1.1.1,9.9.9.9 icanhazip.com
    I'm sure that curl syntax would work if curl were compiled differently.
    "curlvpn: forcing curl through VPN TAP adapter"
    curl: option --dns-servers: the installed libcurl version does not support this
    curl: try 'curl --help' for more information

    But I like my commands to work universally so I changed it to
    Win+R > curldns
    Which calls curldns.exe which is defined only in the Windows Registry
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\curldns.exe
    Default=C:\path-to\curldns.lnk
    Where the TARGET of that curldns.lnk shortcut does the IP check.
    %comspec% /k echo "C:\data\sys\pgm\lnk\curldns.lnk $MYIP" & echo curldns & nslookup icanhazip.com & powershell -Command "Resolve-DnsName icanhazip.com" & curl icanhazip.com
    NB: There is no command called "curldns.exe"; that's just a reg keyword.

    I post it here so that others, at least on Windows, can instantly replicate this shortcut efficiency to make sure their VPN DNS remains in the tunnel.
    --
    I strive to add technical value, if possible, with every post to Usenet.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Brian Gregory@void-invalid-dead-dontuse@email.invalid to alt.comp.software.firefox,alt.os.linux,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10 on Tue Jul 28 00:36:35 2026
    From Newsgroup: comp.mobile.android

    On 20/07/2026 13:03, Carlos E. R. wrote:
    On 2026-07-20 08:45, Maria Sophia wrote:
    If a router is in bridge mode (no IPv6 delegation, no prefix assignment),
    all connected devices never receive a global IPv6 address.
    -a-a-a-a *No global IPv6 address = nothing for the browser to leak.*

    Look up Teredo, in Windows.

    In Linux, disabling Ipv6 is feasible.


    It's 100% feasible in Windows if you look it up or ask an AI instead of
    just guessing.

    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v "DisabledComponents" /t REG_DWORD /d 1 /f

    then reboot.
    --
    Brian Gregory (in England).
    --- Synchronet 3.22a-Linux NewsLink 1.2