1913 - library established in Houston by a black community. Years later, the city disbanded the all 8 black board members and shut the library down

1939 - 5 black people thrown out of a Virginia library for “disturbing the peace” (they were quietly reading).

1961 - Geraldine Edwards Hollis and eight other students from historically-black Tougaloo College — a group known as the Tougaloo Nine — held a sit-in at a “whites-only” public library in Jackson, Mississippi, as an act of civil disobedience.

1970 - the first meeting of the Black Caucus of the American Library Association formed to address the fact that the ALA wasn’t meeting the needs of Black library professionals.

The late 1990s started to become the sweet spot for library inclusion and governance. Everyone was welcome to access books and media without restriction.

In the 2000s, technology emerged in public libraries in a quite inclusive way. There some libraries had PCs and some had ethernet and/or Wi-Fi (free of captive portals). Anyone could use any of those technologies.

2024:

• Ethernet becomes nearly non-existent, thus excluding:

  • people running FOSS systems (which often lack FOSS Wi-Fi firmware)
  • people with old hardware
  • people who oppose the energy waste of Wi-Fi
  • people who do not accept the security compromise of Wi-Fi (AP spoofing/mitm, traffic evesdropping, arbitrary tracking by all iOS and Android devices in range)

• Wi-Fi service itself has become more exclusive at public libraries:

  • captive portals -- not all devices can even handle a captive portal, full stop. Some captive portals are already imposing TLS 1.3 so people with slightly older hardware cannot even reach the ToS page. Some devices cannot handle a captive portal due to DNS resolution being dysfunctional before the captive portal is passed and the captive portal itself is designed to need DNS resolution.
  • GSM requirement -- some public library captive portals now require patrons to complete an SMS verification. This of course excludes these demographics of people:
    • People who do not own a mobile phone
    • People who do not carry a mobile phone around with them
    • People who do not subscribe to mobile phone service (due to poverty, or for countless privacy reasons)
    • People who object to disclosing their mobile phone number and who intend to exercise their right to data minimisation (under the GDPR or their country’s version thereof)

• Web access restrictions intensified:

  • e-books outsourced to Cloudflared services, thus excluding all demographics of people who Cloudflare excludes.
  • Invidious blocked. This means people who do not have internet at home have lost the ability to download videos to watch in their home.
  • Egress Tor connections recently blocked by some libraries, which effectively excludes people whose systems are designed to use Tor to function. So if someone’s email account is on an onion service, those people are excluded from email.

There’s a bit of irony in recent developments that exclude privacy seekers who, for example, deliberately choose not to have a GSM phone out of protest against compulsory GSM registration with national IDs, because the library traditionally respects people’s privacy. Now they’re evolving to actually deny service to people for exercising their privacy rights.

There needs to be pushback to get public libraries back on track to becoming as inclusive as they were in the 1990s. A big part of the problem is outsourcing. The libraries are no longer administrating technology themselves. They have started outsourcing to tech giants like Oracle who have a commercial motivation to save money, which means marginalising demographics of people who don’t fit in their simplified canned workflow. When a patron gets excluded by arbitrary tech restrictions, the library is unable to remedy the problem. Librarians have lost control as a consequence of outsourcing.

One factor has improved: some libraries are starting to nix their annual membership fee. It tends to be quite small anyway (e.g. $/€ 5/year), so doesn’t even begin to offset those excluded by technology.

I plugged into ethernet (as wifi w/captive portal does not work for me). I think clearnet worked but I have no interest in that. Egress Tor traffic was blocked and so was VPN. I’m not interested in editing all my scripts and configs to use clearnet, so the library’s internet is useless to me (unless I bother to try a tor bridge).

I was packing my laptop and a librarian spotted me unplugging my ethernet cable and approached me with big wide open eyes and pannicked angry voice (as if to be addressing a child that did something naughty), and said “you can’t do that!”

I have a lot of reasons for favoring ethernet, like not carrying a mobile phone that can facilitate the SMS verify that the library’s captive portal imposes, not to mention I’m not eager to share my mobile number willy nilly. The reason I actually gave her was that that I run a free software based system and the wifi drivers or firmware are proprietary so my wifi card doesn’t work¹. She was also worried that I was stealing an ethernet cable and I had to explain that I carry an ethernet cable with me, which she struggled to believe for a moment. When I said it didn’t work, she was like “good, I’m not surprised”, or something like that.

¹ In reality, I have whatever proprietary garbage my wifi NIC needs, but have a principled objection to a service financed by public money forcing people to install and execute proprietary non-free software on their own hardware. But there’s little hope for getting through to a librarian in the situation at hand, whereby I might as well have been caught disassembling their PCs.

IMO this is a #netneutrality issue due to lack of access equality. People with old phones are discriminated against.

cross-posted from: https://infosec.pub/post/11021006

…
TLS-encumbered captive portal (transit service)

A transit service offered wi-fi but the network forcibly redirected me to a captive portal that triggers this error:

net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

I tried a couple browsers and tried rewriting the https:// scheme as http:// but SSL redirect was forced consistently. The error apparently implies my phone’s browser can’t do TLS 1.3.

It seems like a shitty move for a transit service to require passengers to use TLS 1.3 just to tick a fucking box that says “I agree” (to the terms no one reads anyway). Couple questions:

• I’m generally in the /protect everything by default/ school of thought. But I cannot get my head around why a captive portal where people just tap “I agree” would warrant disclosure protection that could hinder availability. In reality, I don’t really know what the captive portal at hand requests.. maybe it demands people’s phone# or email, in which case it might make sense (though I would object to them collecting that info in a GDPR region in the 1st place).

• Is there a good reason for a captive portal to require TLS 1.3? It seems either the network provider does not trust their own network, or they’re simply incompetent (assumes everyone runs the latest phones). But if I’m missing something I would like to understand it.

I still have to investigate what limitation my browser has and whether I can update this whilst being trapped on an unrooted Android 5.

Bypass methods

I guess I need to study:

• ICMP tunnel (slow, but IIUC it’s the least commonly blocked)
• SSH tunnel
• others?

Are there any decent FOSS tools that implement the client side of tunnels without needing root? I have openvpn but have not tested to see if that can circumvent captive portals. I’ve only found:

• MultiVNC - VNC over SSH
• AVNC - VNC over SSH
• ConnectBot - Can all traffic be routed over this SSH tunnel, or just a shell session?
• VX ConnectBot - same as connectBot but expanded

I’m curious if the VNC clients would work but at the same time I’m not keen to bring in the complexity of then having to find a VNC server. Running my own server at home is not an option.

My to-do list of things to tinker with so far:

• Captive Portal Controller
• ~~CaptivePortalLogin~~ (AOS 6+, and no Izzy archives on this)
• Hotspot Login

Legal options

If a supplier advertises Wi-Fi but then they render it dysfunctional by imposing arbitrary tech requirements after consumers have already bought the product/service it was included with (coffee, train/bus/plane fare, etc), then they neglect to support it, doesn’t that constitute false advertising? Guess this is out of scope for the community but I might be ½ tempted to file false advertising claims with consumer protection agencies in some cases.

And when a captive portal demands email or phone number, it would seem to be a GDPR violation. Some public libraries make wi-fi access conditional on sharing a mobile phone number which then entails an SMS verification loop.

This is likely a Lemmy bug but infosec.pub is related because there are so many Android communities that are federated from bad places so I thought I would mention it here as well.

cross-posted from: https://infosec.pub/post/11060800

The cross-post mechanism has a limitation whereby you cannot simply enter a precise community to post to. Users are forced to search and select. When searching for “android” on infosec.pub within the cross-post page, the list of possible communities is totally clusterfucked with shitty centralized Cloudflare instances (lemmy world, sh itjust works, lemm ee, programming dev, etc). The list of these junk instances is so long !android@hilariouschaos.com does not make it to the list.

The workaround is of course to just create a new post with the same contents. And that is what I will do.

There are multiple bugs here:
① First of all, when a list of communities is given in this context, the centralized instances should be listed last (at best) because they are antithetical to fedi philosophy.
② Subscribed communities should be listed first, at the top
③ Users should always be able to name a community in its full form, e.g.:

• [!android@hilariouschaos.com](/c/android@hilariouschaos.com)
• hilariouschaos.com/android

④ Users should be able to name just the instance (e.g. hilariouschaos.com) and the search should populate with subscribed communities therein.

The cross-post mechanism has a limitation whereby you cannot simply enter a precise community to post to. Users are forced to search and select. When searching for “android” on infosec.pub within the cross-post page, the list of possible communities is totally clusterfucked with shitty centralized Cloudflare instances (lemmy world, sh itjust works, lemm ee, programming dev, etc). The list of these junk instances is so long !android@hilariouschaos.com does not make it to the list.

The workaround is of course to just create a new post with the same contents. And that is what I will do.

There are multiple bugs here:
① First of all, when a list of communities is given in this context, the centralized instances should be listed last (at best) because they are antithetical to fedi philosophy.
② Subscribed communities should be listed first, at the top
③ Users should always be able to name a community in its full form, e.g.:

• [!android@hilariouschaos.com](/c/android@hilariouschaos.com)
• hilariouschaos.com/android

④ Users should be able to name just the instance (e.g. hilariouschaos.com) and the search should populate with subscribed communities therein.

cross-posted from: https://infosec.pub/post/11021006

…
TLS-encumbered captive portal (transit service)

A transit service offered wi-fi but the network forcibly redirected me to a captive portal that triggers this error:

net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

I tried a couple browsers and tried rewriting the https:// scheme as http:// but SSL redirect was forced consistently. The error apparently implies my phone’s browser can’t do TLS 1.3.

It seems like a shitty move for a transit service to require passengers to use TLS 1.3 just to tick a fucking box that says “I agree” (to the terms no one reads anyway). Couple questions:

• I’m generally in the /protect everything by default/ school of thought. But I cannot get my head around why a captive portal where people just tap “I agree” would warrant disclosure protection that could hinder availability. In reality, I don’t really know what the captive portal at hand requests.. maybe it demands people’s phone# or email, in which case it might make sense (though I would object to them collecting that info in a GDPR region in the 1st place).

• Is there a good reason for a captive portal to require TLS 1.3? It seems either the network provider does not trust their own network, or they’re simply incompetent (assumes everyone runs the latest phones). But if I’m missing something I would like to understand it.

I still have to investigate what limitation my browser has and whether I can update this whilst being trapped on an unrooted Android 5.

Bypass methods

I guess I need to study:

• ICMP tunnel (slow, but IIUC it’s the least commonly blocked)
• SSH tunnel
• others?

Are there any decent FOSS tools that implement the client side of tunnels without needing root? I have openvpn but have not tested to see if that can circumvent captive portals. I’ve only found:

• MultiVNC - VNC over SSH
• AVNC - VNC over SSH
• ConnectBot - Can all traffic be routed over this SSH tunnel, or just a shell session?
• VX ConnectBot - same as connectBot but expanded

I’m curious if the VNC clients would work but at the same time I’m not keen to bring in the complexity of then having to find a VNC server. Running my own server at home is not an option.

My to-do list of things to tinker with so far:

• Captive Portal Controller
• ~~CaptivePortalLogin~~ (AOS 6+, and no Izzy archives on this)
• Hotspot Login

Legal options

If a supplier advertises Wi-Fi but then they render it dysfunctional by imposing arbitrary tech requirements after consumers have already bought the product/service it was included with (coffee, train/bus/plane fare, etc), then they neglect to support it, doesn’t that constitute false advertising? Guess this is out of scope for the community but I might be ½ tempted to file false advertising claims with consumer protection agencies in some cases.

And when a captive portal demands email or phone number, it would seem to be a GDPR violation. Some public libraries make wi-fi access conditional on sharing a mobile phone number which then entails an SMS verification loop.

The red padlock (at a cafe)

The captive portal of a cafe simply rendered a red padlock on with a line through it. Essentially, it was apparently telling me I am being denied access arbitrarily without using any words. There was no other screen before that. Immediately after wifi handshaking Android’s built-in captive portal detection app just went straight to a padlock. I have never been in that cafe in my life and never use my device maliciously.

Showed the screen to the staff who said “works for me on my phone”, who then noticed the airplane on my status bar and said “oh, you got the little airplane, that’s the problem”. Shit; so then I had to explain that wi-fi works in airplane mode. It was just a distraction for them. I couldn’t really convince them that the problem isn’t anything I’m doing wrong. There is no tech support for this situation -- like pretty much all captive portal scenarios. Being the customer of the customer is a very weak position to be in when the direct customer doesn’t really give a shit if it works or not.

So, has anyone seen this kind of behavior? I run into shitty broken captive portals often enough that I guess I really need to get a better understanding of them, and ways to bypass them.

TLS-encumbered captive portal (transit service)

A transit service offered wi-fi but the network forcibly redirected me to a captive portal that triggers this error:

net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

I tried a couple browsers and tried rewriting the https:// scheme as http:// but SSL redirect was forced consistently. The error apparently implies my phone’s browser can’t do TLS 1.3.

It seems like a shitty move for a transit service to require passengers to use TLS 1.3 just to tick a fucking box that says “I agree” (to the terms no one reads anyway). Couple questions:

• I’m generally in the /protect everything by default/ school of thought. But I cannot get my head around why a captive portal where people just tap “I agree” would warrant disclosure protection that could hinder availability. In reality, I don’t really know what the captive portal at hand requests.. maybe it demands people’s phone# or email, in which case it might make sense (though I would object to them collecting that info in a GDPR region in the 1st place).

• Is there a good reason for a captive portal to require TLS 1.3? It seems either the network provider does not trust their own network, or they’re simply incompetent (assumes everyone runs the latest phones). But if I’m missing something I would like to understand it.

I still have to investigate what limitation my browser has and whether I can update this whilst being trapped on an unrooted Android 5.

Bypass methods

I guess I need to study:

• ICMP tunnel (slow, but IIUC it’s the least commonly blocked)
• SSH tunnel
• others?

Are there any decent FOSS tools that implement the client side of tunnels without needing root? I have openvpn but have not tested to see if that can circumvent captive portals. I’ve only found:

• MultiVNC - VNC over SSH
• AVNC - VNC over SSH
• ConnectBot - Can all traffic be routed over this SSH tunnel, or just a shell session?
• VX ConnectBot - same as connectBot but expanded

I’m curious if the VNC clients would work but at the same time I’m not keen to bring in the complexity of then having to find a VNC server. Running my own server at home is not an option.

My to-do list of things to tinker with so far:

• Captive Portal Controller
• ~~CaptivePortalLogin~~ (AOS 6+, and no Izzy archives on this)
• Hotspot Login

Legal options

If a supplier advertises Wi-Fi but then they render it dysfunctional by imposing arbitrary tech requirements after consumers have already bought the product/service it was included with (coffee, train/bus/plane fare, etc), then they neglect to support it, doesn’t that constitute false advertising? Guess this is out of scope for the community but I might be ½ tempted to file false advertising claims with consumer protection agencies in some cases.

And when a captive portal demands email or phone number, it would seem to be a GDPR violation. Some public libraries make wi-fi access conditional on sharing a mobile phone number which then entails an SMS verification loop.

update (phones bought last year already obsolete)

TLS 1.3 was not introduced until Android OS 10 (sept.2019). That was the release date of AOS 10. Older devices like AOS 9 would still be sold at that time and continuing at least into 2023. Shops do not pull their stock from the shelves when the end of support arrives. This means people buying new COTS Android devices just last year or even this year are already too out of date for the TLS 1.3 captive portal to function.

It’s seriously disgusting how many people expect consumers to upgrade this chronically fast.

Looking for a SIP provider for my very low usage. So I’m after:

1. prepaid without monthly fee, pay per unit time (no DID needed)
2. security (TLS or SRTP)
3. caller ID control (I have no inbound voice line; I have an inbound fax line I prefer to use; freetyping CID info nanny-free is the best)
4. web portals must support Tor, no Cloudflare
5. (not critical) support for lightweight codecs like speex, gsm, or bv16

The closest provider to satisfying that criteria I’ve found so far is leap.tel, but they lack TLS/SRTP and only support G.711. DID Logic supports TLS/SRTP, but they only have plans with monthly fees.

cross-posted from: https://infosec.pub/post/10262373

Question for people willing to visit Cloudflare sites:

How do you determine whether to trust a login page on a CF site? A sloppy or naïve admin would simply take the basic steps to putting their site on Cloudflare, in which case the authentication traffic traverses CF. Diligent admins setup a separate non-CF host for authentication.

Doing a view-source on the login page and inspecting the code seems like a lot of effort. The source for the lemmy.world login page is not humanly readable. It looks as if they obfuscated the URLs to make them less readable. Is there a reasonably convenient way to check where the creds go? Do you supply bogus login info and then check the httpput headers?

There are apparently only two documented ways to reverse tether an Android via USB to a linux host:

• openVPN method
• Gnirehtet

OpenVPN dead
I really wanted the #openVPN method to work because I’m a fan of reducing special-purpose installations and using Swiss army knives of sorts. In principle we might expect openVPN to be well maintained well into the future. But openVPN turns out to be a shit show in this niche context. Features have been dropped from the Android version.

Gnirehtet dying
Gnirehtet works but it’s falling out of maintenance. ~~It’s also unclear if~~ #Gnirehtet really works without root. There is mixed info:

• Ade Malsasa Akbar from Ubuntubuzz claims root is not needed (and devs agree).
• OSradar claims root is needed. (edit: they are mistaken)

If anyone has managed to reverse tether an unrooted Android over USB to a linux host using free software, please chime in. Thanks!

update on Gnirehtet

Gnirehtet indeed works without root. But some apps (like VOIP apps) fail to detect an internet connection and refuse to communicate.

#askFedi

Question for people willing to visit Cloudflare sites:

How do you determine whether to trust a login page on a CF site? A sloppy or naïve admin would simply take the basic steps to putting their site on Cloudflare, in which case the authentication traffic traverses CF. Diligent admins setup a separate non-CF host for authentication.

Doing a view-source on the login page and inspecting the code seems like a lot of effort. The source for the lemmy.world login page is not humanly readable. It looks as if they obfuscated the URLs to make them less readable. Is there a reasonably convenient way to check where the creds go? Do you supply bogus login info and then check the httpput headers?

An HTML-only email from a gov agency has a logo referencing an URL that looks like this:

https://1wy1y.mjt.lu/tplimg/1wy1y/f/l9hl7/g3q3v.png

It’s not exactly that (apart from the domain) but of course it’s rather unique looking. They send email routinely. The initial emails had an obviously non-suspicious basic logo, like “(their office domain)/files/logo.png”. But then later they switched and every message from them is the URL in the mjt.lu domain. It’s not unique per message but it could be unique to the user, perhaps to keep tabs on when each person reads their messages.

The output of torsocks curl -LI looks like this:

HTTP/2 200
date: (exactly now)
content-type: image/png
accept-ranges: bytes

That’s it. It’s the shortest HTTP header I’ve seen. There’s no content-length. I find that suspicious because if this is a service that facilitates tracker pixels, then they would want to withhold the length in order to dodge detection. Although from its usage in my case it wouldn’t just be a pixel -- it’s a logo.

The date is also suspect. Shouldn’t the date be the date of the object, not the current time this second?

Are there any other checks to investigate this?