If the origin server uses any proper TLS configuration, even a self-signed certificate, this method stops working. It only succeeds when the upstream connection to the origin is unsecured.
If you want to test this on a random site without Cloudflare or reverse proxy in general on HTTP:
curl http://www.digiboy.ir/boobs.jpg -v
> Why would anyone pick the flexible/potentially-insecure option?
Because having a connection that's encrypted between a user and Cloudflare, then unencrypted between Cloudflare and your server is often better than unencrypted all the way. Sketchy ISPs could insert/replace ads, and anyone hosting a free wifi hotspot could learn things your users wouldn't want them to know (e.g. their address if they order a delivery).
Setting up TLS properly on your server is harder than using Cloudflare (disclaimer: I have not used Cloudflare, though I have sorted out a certificate for an https server).
The problem is that users can't tell if their connection is encrypted all the way to your server. Visiting an https url might lead someone to assume that no-one can eavesdrop on their connection by tapping a cross-ocean cable (TLS can deliver this property). Cloudflare breaks that assumption.
Cloudflare's marketing on this is deceptive: https://www.cloudflare.com/application-services/products/ssl... says "TLS ensures data passing between users and servers is encrypted". This is true, but the servers it's talking about are Cloudflare's, not the website owner's.
Going through to "compare plans", the description of "Universal SSL Certificate" says "If you do not currently use SSL, Cloudflare can provide you with SSL capabilities — no configuration required." This could mislead users and server operators into thinking that they are more secure than they actually are. You cannot get the full benefits of TLS without a private key on your web server.
Despite this, I would guess that Cloudflare's "encryption remover" improves security compared to a world where Cloudflare did not offer this. I might feel differently about this if I knew more about people who interact with traffic between Cloudflare's servers and the servers of Cloudflare's customers.
Let's encrypt and ACME hasn't always been available. Lots of companies also use appliances for the reverse proxy/Ingress.
If they don't support ACME, it's actually quite the chore to do - at least it was the last time I had to before acme was a thing (which is admittedly over 10 yrs ago)
To be fair, Cloudflare is also the reason why most sites even have TLS at all, because it offered free certs (through letsencrypt I think?) in a fairly easy to set up way.
Certs used to be expensive, and had way more operational overhead and quirks (even setting up ACME/LE)
Let's Encrypt is unusable for me because they want you to install that certbot thing. I don't know what that is or what it does. I don't want some magical auto update thing. Is it so hard to just make a generate button that gives you cert.pem and pkey.pem? Cloudflare managed to do it.
Cloudflare has native integration with Let's encrypt, which makes using TLS with a CDN much easier than if you had to acquire the ACME cert and deploy it to the CDN yourself.
Granted, most CDNs these days have some form of free certicate system, but that wasn't always the case.
People on this website will just type any wild lie. I kinda love it.
The sky is purple! Charlie Brown had hoes! Cloudflare invented Let's Encrypt! Just say anything you want! We live in a post-truth world- there's no need for anything you say to correspond to any external reality!
I agree, Let’s encrypt and ACME played a massive role. But it’s still far easier having Cloudflare handle TLS encryption for you.
And i say this as someone who uses ACME in certmanager and certbot at home and still prefers the ease with which Cloudflare generates a cert for my domain and terminates TLS for the public side of my cloudflare tunnel.
For my home stuff I just use nginx-proxy-manager and haven't thought about it since I set it up a couple of years ago.
For work, I used to use certbot directly at my old place. Now I am building my new stuff on k8s, and I have the ingress manage my certs for me (likely using certbot or similar behind the scenes). Both have been extremely low setup effort and no ongoing effort.
I don't like giving Cloudflare my (or my companies/customers) data in exchange for being able to click a checkbox.
I don't think this is true... a reverse proxy/CDN can see the full request URL even if the origin server is using TLS (unless you're using mTLS, which almost nobody is), and we don't even know if it's the proxy/CDN or the origin that is filtering based on keywords... but all of them could be doing it.
Interesting. I was just setting up a LB like this:
client ->LB(nginx) ->TLS terminate for LB conn -> proxy_pass to backend which is behind nginx and has separate TLS certs. it's surprisingly easy to configure. Wonder why people still use HTTP at all. Even at home, I have setup LE certs for all local domains
On a side note, nginx doesn't support HTTP/2 for https load balancing so I am thinking of switching to haproxy which supports it
How's this work with https like in the example? The hops along the way shouldn't see the path.
Is this implying that all TLS is terminated at the Iran border and proxied from there? And all Iranian sites are required to host via http? That has significantly more implications than what this post is about.
Maybe certificate authorities aren't allowed to issue private certs to Iranian organizations? Even LetsEncrypt?
This is referring to something else: to detect whether the backend server host itself is inside or outside Iran. TLS doesn't prevent the backend network from reading the URL of course.
Again, you are assuming a normal situation. The point is the country itself is operating (or has a heavy grip and perhaps even subsidizes) the backend CDN and enforcing that stuff in a rudimentary way.
"TLS between backend connections" usually involves termination and decryption on the frontend webserver and re-encryption of the upstream traffic, whatever it may be.
A lot of CF upstreams are (or at least used to be) plaintext. It is one of the criticisms of CF since it "whitewashed" plaintext to look like proper TLS when it was only TLS for client<->CF and then plaintext for CF<->server.
This is a problem for the visitor, not for the server's owner. There is no way to know whether the traffic is encrypted between the server and CloudFlare.
Regardless of Cloudflare, there is no way to know whether the traffic is encrypted between your apparent end-point and where it's actually used, nor whether that traffic is subsequently revealed to other parties, on purpose or by mistake.
When you type your password into e.g. Hacker News, you are sending that password to the server. It doesn't matter that they're using bcrypt tuned for $1Bn attackers and you chose a sixteen character random alphanumeric string because that precise string, the valid password, is deliberately sent by you, to them, to authenticate and so if they accidentally reveal that or get compromised in any way, game over.
It's getting a little bit better in some areas. My good bank actually has halfway decent security now, but the bank with most of my money (which is owned by my government, and thus avoids any risk consideration - if that bank fails, the currency my money is denominated in also fails, so, it doesn't matter any more) still thinks passwords are a good idea. Google lets me use a Security Key, but most web sites I authenticate with still use passwords.
SSH is slightly better, because of its target audience. A lot of people use public key auth for SSH, which doesn't have this issue. But that's not the web.
> Regardless of Cloudflare, there is no way to know whether the traffic is encrypted between your apparent end-point and where it's actually used, nor whether that traffic is subsequently revealed to other parties, on purpose or by mistake.
Any server could be leaking plaintext data, sure, but Cloudflare offers and even promotes wrong-thing-as-a-service.
Have they started to use per-domain certificates for this, or can anyone who finds the origin bypass the check by creating their own (different) Cloudflare domain and pointing it at your origin?
Edit: Looks still the same by default, but at least they're (somewhat obscurely) documenting the issue and providing the option to use a custom cert now...
> Is this implying that all TLS is terminated at the Iran border and proxied from there?
Yeah, the law-abiding type on the Iranian National Information Network(NIN), either using the Electronic Commerce Council's I.R.Iran CA for HTTPS or just HTTP.
> Maybe certificate authorities aren't allowed to issue private certs to Iranian organizations? Even LetsEncrypt?
Due to NIN registrations being not very much not anonymous, https://xkcd.com/538/ seems pretty appropriate if you want to use an unapproved certificate authority.
Would assume it's to check if a site is foreign propaganda. A lot of the lesser-known news sites that you see linked on social media are actually psy-ops pushing an agenda, many of them foreign-based. Follow the technique in the article and you can easily blacklist Iranian ones.
Why are people in the (presumed) West particularly afraid of the propaganda of a Middle Eastern country? Is the intelligence/propaganda unit there so good that they can program minds from a different continent better than Western oligarchs? This has got “Russia stole American democracy with millions worth of FB ads” vibes to it.
But if there is an easy technical implement to avoid some propaganda then good on them I guess. Why not. One less thing to worry about.
It's a CDN, not an IP router. CDNs usually terminate TCP+TLS as close to the client as possible. This used to be done right at the edge - within the NIC for a long time, but CPUs have been more than capable for the last decade+
Few guesses:
1) CDN connects to backend server over TLS, using the national I.R. Iran root CA
2) CDN connects to backend server over HTTP
3) Backend server is running a nationally blessed Linux OS
For 1 & 2, the National Information Network would be implementing this DigiNotar style but they already own the root keys. For #3, the backend does so itself. These are the people who p0wned DigiNotar after all.
A long time ago, my friends and I found a "scary"-looking image, written in a mixture of English and Arabic, warning the viewer that they'd come afoul of ... I forget, some Iranian government department of censorship?
Naturally, we made it so that 1% of the requests to a forum we ran at the time displayed it to the viewer. :)
I guess that if you GET https://somedomain.com/boobs.jpg you get a 404 (not found) from a web server hosted outside of Iran but if the server for the domain is hosted in Iran, you get a 403 (forbidden) because the request is intercepted by a firewall that detect the word "boobs" and reject it with a 403 without forwarding it to the webserver that would usually return the 404.
> Why wouldn't the Iranian government just use its own ip space for the censorship message?
IP addresses are expensive if you're not the US. Also they might be reusing a standard corporate filtering product that expects to be deployed on a private network (and in a way, that's what the Iranian internet is).
I wonder if this could be broadened to a list of Wikipedia links to humanitarian content folks in repressed regimes are or might get blocked from. Tiananmen Square [1]. Wen Jiabao's staggering corruption [2]. Epstein's e-mails [3]. Et cetera.
Like Netflix launching Fast.com, this would directly weaponise these regimes' censoring tendencies against themselves.
Wow. The screenshot had the IP address exactly where I placed my finger to scroll, and iOS Safari briefly opened a popup window where it started connecting to that IP.
Fuck this shit, I’m moving to a hovel in the woods.
Along the same lines, I occasionally find myself cursing iOS for its willingness to just bring up the dialer and call a number. I really, really wish that it would confirm any dialing before doing it, especially if you didn't click on a phone number on a contact. Couple times I've ended up dialing a recent spam caller, which is the last thing I ever want to do.
Occasionally, if you're lucky enough, an option to copy the phone number shows up, it seems like completely at the whim of the OS. And that's after accidentally starting to dial the number, of course.
Thanks for posting this. I mostly gave up on viewing the one or two Twitter feeds that interest me after nitter stopped working. It wasn't ideological, I just wasn't able to reliably view and navigate without an account, and when I made an account it just kept showing me like "black HS football player bad sportsmanship".
Look like I've got about two years of James Cage White story arcs to check in on.
This is a hosted instance of nitter, the reason why nearly all nitter instances died is because "guest" accounts got removed, so now you need tons of real twitter/x accounts instead of just generating thousands of "guest" accounts.
This behavior only works when the reverse proxy or CDN is configured like this:
Proxy/CDN: HTTPS (443) → Origin server: plain HTTP (80)
(example: Cloudflare in Flexible mode)
If the origin server uses any proper TLS configuration, even a self-signed certificate, this method stops working. It only succeeds when the upstream connection to the origin is unsecured.
If you want to test this on a random site without Cloudflare or reverse proxy in general on HTTP: curl http://www.digiboy.ir/boobs.jpg -v
Ah, Cloudflare. The world's most widely deployed encryption remover.
Could someone help me understand. I looked at: https://developers.cloudflare.com/ssl/origin-configuration/s... it seems to support multiple modes.
I didn't quite get if Automatic TLS (https://developers.cloudflare.com/ssl/origin-configuration/s...) could use plain transfers.
So:
* Is it insecure by default or you have to be intentionally insecure?
* Why would anyone pick the flexible/potentially-insecure option?
> Why would anyone pick the flexible/potentially-insecure option?
Because having a connection that's encrypted between a user and Cloudflare, then unencrypted between Cloudflare and your server is often better than unencrypted all the way. Sketchy ISPs could insert/replace ads, and anyone hosting a free wifi hotspot could learn things your users wouldn't want them to know (e.g. their address if they order a delivery).
Setting up TLS properly on your server is harder than using Cloudflare (disclaimer: I have not used Cloudflare, though I have sorted out a certificate for an https server).
The problem is that users can't tell if their connection is encrypted all the way to your server. Visiting an https url might lead someone to assume that no-one can eavesdrop on their connection by tapping a cross-ocean cable (TLS can deliver this property). Cloudflare breaks that assumption.
Cloudflare's marketing on this is deceptive: https://www.cloudflare.com/application-services/products/ssl... says "TLS ensures data passing between users and servers is encrypted". This is true, but the servers it's talking about are Cloudflare's, not the website owner's.
Going through to "compare plans", the description of "Universal SSL Certificate" says "If you do not currently use SSL, Cloudflare can provide you with SSL capabilities — no configuration required." This could mislead users and server operators into thinking that they are more secure than they actually are. You cannot get the full benefits of TLS without a private key on your web server.
Despite this, I would guess that Cloudflare's "encryption remover" improves security compared to a world where Cloudflare did not offer this. I might feel differently about this if I knew more about people who interact with traffic between Cloudflare's servers and the servers of Cloudflare's customers.
> Setting up TLS properly on your server is harder than using Cloudflare
This is probably technically true, but setting up TLS properly on your server is really ridiculously simple.
These days, absolutely... I usually use Caddy for reverse proxy chores and it's been a great option to deal with. Traefic hasn't been bad either.
...in 2025
Let's encrypt and ACME hasn't always been available. Lots of companies also use appliances for the reverse proxy/Ingress.
If they don't support ACME, it's actually quite the chore to do - at least it was the last time I had to before acme was a thing (which is admittedly over 10 yrs ago)
Historically?
1. Because TLS certificates were not free
2. Because firewall was "enough" in most people's minds
3. Because TLS was the most CPU intensive part of serving a static site
4. Because some people were using cheap shared hosting providers that upcharged for TLS
> * Why would anyone pick the flexible/potentially-insecure option?
I pick it whenever I don't want to setup HTTPS on my origin but still want HTTPS. Just for projects where I really don't care.
Is it really that different than AWS? You either trust your service provider or you don't.
AWS doesn't route requests from their load balancer to your server across the public internet. Cloudflare does.
You can do that with AWS if you really want to.
It will cost you a ton.
EU should simply do the global surveillance quietly on cloudflare, instead of asking all the countries for the law
</Irony>
To be fair, Cloudflare is also the reason why most sites even have TLS at all, because it offered free certs (through letsencrypt I think?) in a fairly easy to set up way.
Certs used to be expensive, and had way more operational overhead and quirks (even setting up ACME/LE)
Absolutely not, no. That is all thanks to Let's Encrypt.
This was true before Let's Encrypt existed, they'd buy massive 500 domain wildcard SSL certs that free users would split.
Let's Encrypt is unusable for me because they want you to install that certbot thing. I don't know what that is or what it does. I don't want some magical auto update thing. Is it so hard to just make a generate button that gives you cert.pem and pkey.pem? Cloudflare managed to do it.
Cloudflare has native integration with Let's encrypt, which makes using TLS with a CDN much easier than if you had to acquire the ACME cert and deploy it to the CDN yourself.
Granted, most CDNs these days have some form of free certicate system, but that wasn't always the case.
People on this website will just type any wild lie. I kinda love it.
The sky is purple! Charlie Brown had hoes! Cloudflare invented Let's Encrypt! Just say anything you want! We live in a post-truth world- there's no need for anything you say to correspond to any external reality!
I'm pretty sure Lincoln said that first...
> this website
you must be new to the internet...
Congrats! You get it!
I'm not going to give them credit for the work that Lets Encrypt did.
I agree, Let’s encrypt and ACME played a massive role. But it’s still far easier having Cloudflare handle TLS encryption for you.
And i say this as someone who uses ACME in certmanager and certbot at home and still prefers the ease with which Cloudflare generates a cert for my domain and terminates TLS for the public side of my cloudflare tunnel.
For my home stuff I just use nginx-proxy-manager and haven't thought about it since I set it up a couple of years ago.
For work, I used to use certbot directly at my old place. Now I am building my new stuff on k8s, and I have the ingress manage my certs for me (likely using certbot or similar behind the scenes). Both have been extremely low setup effort and no ongoing effort.
I don't like giving Cloudflare my (or my companies/customers) data in exchange for being able to click a checkbox.
Lets Encrypt can proxy my old http only website to show as https? Without access to server configuration? How?
With nginx-proxy-manager which uses Let's Encrypt for certs you can... This isn't the gotcha you think it is.
I don't have access to the server.
It can be run anywhere. You don't need it on the same server. Cloudflare isn't running on the same server either.
Cloudflare is a checkbox.
And you only let them see every bit of traffic to and from your site in exchange.
What a deal.
You changed the subject btw.
I didn't. I said that Cloudflare is the one that allowed my http only site to become https.
We have a clownflare fanboy here, spreading misinformation!
It'll also work DigiNotar-style, when using the only root CA blessed by the National Information Network for general use: I.R. Iran.
I don't think this is true... a reverse proxy/CDN can see the full request URL even if the origin server is using TLS (unless you're using mTLS, which almost nobody is), and we don't even know if it's the proxy/CDN or the origin that is filtering based on keywords... but all of them could be doing it.
Interesting. I was just setting up a LB like this: client ->LB(nginx) ->TLS terminate for LB conn -> proxy_pass to backend which is behind nginx and has separate TLS certs. it's surprisingly easy to configure. Wonder why people still use HTTP at all. Even at home, I have setup LE certs for all local domains
On a side note, nginx doesn't support HTTP/2 for https load balancing so I am thinking of switching to haproxy which supports it
Because you've now published your internal machine names. Look up certificate transparency logs.
What do you mean? I used self-signed for communication b/w LB and the nginx serving backend
Edit: I don't see any "machine name" on crt.sh for public LB which uses LE
Ah, you meant the DNS address is on CT now. You think I wouldn't know that? Regardless, a dns01 challenge is far better than using self-signed at home
Digiboy is a treasure trove of enterprise software. Where else would I get a pirated hpe ilo license from?
How's this work with https like in the example? The hops along the way shouldn't see the path.
Is this implying that all TLS is terminated at the Iran border and proxied from there? And all Iranian sites are required to host via http? That has significantly more implications than what this post is about.
Maybe certificate authorities aren't allowed to issue private certs to Iranian organizations? Even LetsEncrypt?
This is referring to something else: to detect whether the backend server host itself is inside or outside Iran. TLS doesn't prevent the backend network from reading the URL of course.
Well it would if things are setup according to best practises (i.e. use TLS between the backend connections). Presumably most people dont do that.
Again, you are assuming a normal situation. The point is the country itself is operating (or has a heavy grip and perhaps even subsidizes) the backend CDN and enforcing that stuff in a rudimentary way.
"TLS between backend connections" usually involves termination and decryption on the frontend webserver and re-encryption of the upstream traffic, whatever it may be.
A lot of CF upstreams are (or at least used to be) plaintext. It is one of the criticisms of CF since it "whitewashed" plaintext to look like proper TLS when it was only TLS for client<->CF and then plaintext for CF<->server.
Has anything ever prevented you from having TLS on your origin server? You can even get a certificate from Cloudflare.
This is a problem for the visitor, not for the server's owner. There is no way to know whether the traffic is encrypted between the server and CloudFlare.
Regardless of Cloudflare, there is no way to know whether the traffic is encrypted between your apparent end-point and where it's actually used, nor whether that traffic is subsequently revealed to other parties, on purpose or by mistake.
When you type your password into e.g. Hacker News, you are sending that password to the server. It doesn't matter that they're using bcrypt tuned for $1Bn attackers and you chose a sixteen character random alphanumeric string because that precise string, the valid password, is deliberately sent by you, to them, to authenticate and so if they accidentally reveal that or get compromised in any way, game over.
It's getting a little bit better in some areas. My good bank actually has halfway decent security now, but the bank with most of my money (which is owned by my government, and thus avoids any risk consideration - if that bank fails, the currency my money is denominated in also fails, so, it doesn't matter any more) still thinks passwords are a good idea. Google lets me use a Security Key, but most web sites I authenticate with still use passwords.
SSH is slightly better, because of its target audience. A lot of people use public key auth for SSH, which doesn't have this issue. But that's not the web.
> Regardless of Cloudflare, there is no way to know whether the traffic is encrypted between your apparent end-point and where it's actually used, nor whether that traffic is subsequently revealed to other parties, on purpose or by mistake.
Any server could be leaking plaintext data, sure, but Cloudflare offers and even promotes wrong-thing-as-a-service.
I've set up CF for a personal site and I even tell CF to use a client certificate (called "Origin CA") so nothing else can even connect to it.
Have they started to use per-domain certificates for this, or can anyone who finds the origin bypass the check by creating their own (different) Cloudflare domain and pointing it at your origin?
Edit: Looks still the same by default, but at least they're (somewhat obscurely) documenting the issue and providing the option to use a custom cert now...
https://developers.cloudflare.com/ssl/origin-configuration/a...
> Is this implying that all TLS is terminated at the Iran border and proxied from there?
Yeah, the law-abiding type on the Iranian National Information Network(NIN), either using the Electronic Commerce Council's I.R.Iran CA for HTTPS or just HTTP.
> Maybe certificate authorities aren't allowed to issue private certs to Iranian organizations? Even LetsEncrypt?
Due to NIN registrations being not very much not anonymous, https://xkcd.com/538/ seems pretty appropriate if you want to use an unapproved certificate authority.
I'm wondering for what purpose one would be interested in finding out if a site is hosted in Iran or not.
Would assume it's to check if a site is foreign propaganda. A lot of the lesser-known news sites that you see linked on social media are actually psy-ops pushing an agenda, many of them foreign-based. Follow the technique in the article and you can easily blacklist Iranian ones.
I don’t buy psy-ops unless it’s American-made
Why are people in the (presumed) West particularly afraid of the propaganda of a Middle Eastern country? Is the intelligence/propaganda unit there so good that they can program minds from a different continent better than Western oligarchs? This has got “Russia stole American democracy with millions worth of FB ads” vibes to it.
But if there is an easy technical implement to avoid some propaganda then good on them I guess. Why not. One less thing to worry about.
It’s illegal for US companies to do business with anyone in Iran.
I'd rather not do business there.
Im guessing - its for some protest action? ... but really I have NO IDEA.
Does anyone have sample sites that return this?
Also interested in a sample site where the request successfully resolves ;)
If search in google search with site:ir it returns lots .ir links. I clicked on one and it went to a .com domain site.
This may or may not be useful. How all this works is beyond my knowledge ..
Here: tehranpich.com
It's behind CF
Are you asking if there are pictures of boobs on the internet?
You never know! Maybe they've all disappeared!
So presumably Iran has a reverse proxy in front of the entire internet for HTTP?
I really want to know what's on the webpage for the iframe.
> So presumably Iran has a reverse proxy in front of the entire internet for HTTP?
Standard DPI firewalls can do that for you. Absolutely no issue.
For the path component, in a TLS secured request?
It's a CDN, not an IP router. CDNs usually terminate TCP+TLS as close to the client as possible. This used to be done right at the edge - within the NIC for a long time, but CPUs have been more than capable for the last decade+
Few guesses:
1) CDN connects to backend server over TLS, using the national I.R. Iran root CA
2) CDN connects to backend server over HTTP
3) Backend server is running a nationally blessed Linux OS
For 1 & 2, the National Information Network would be implementing this DigiNotar style but they already own the root keys. For #3, the backend does so itself. These are the people who p0wned DigiNotar after all.
A long time ago, my friends and I found a "scary"-looking image, written in a mixture of English and Arabic, warning the viewer that they'd come afoul of ... I forget, some Iranian government department of censorship?
Naturally, we made it so that 1% of the requests to a forum we ran at the time displayed it to the viewer. :)
I am probably a little dumb, i read the article but dont understand what happened. can some HNer kindly explain?
I guess that if you GET https://somedomain.com/boobs.jpg you get a 404 (not found) from a web server hosted outside of Iran but if the server for the domain is hosted in Iran, you get a 403 (forbidden) because the request is intercepted by a firewall that detect the word "boobs" and reject it with a 403 without forwarding it to the webserver that would usually return the 404.
So does this mean 10.x.x.x is publicly routable inside iran? Why wouldn't the Iranian government just use its own ip space for the censorship message?
> Why wouldn't the Iranian government just use its own ip space for the censorship message?
IP addresses are expensive if you're not the US. Also they might be reusing a standard corporate filtering product that expects to be deployed on a private network (and in a way, that's what the Iranian internet is).
I just tried this on a few Iranian websites and never got a 403, let alone an iframe.
Is there a Scunthorpe problem looming there? Birdwatchers might seek out information about boobies - are they treated like boobs.jpg is?
I wonder if this could be broadened to a list of Wikipedia links to humanitarian content folks in repressed regimes are or might get blocked from. Tiananmen Square [1]. Wen Jiabao's staggering corruption [2]. Epstein's e-mails [3]. Et cetera.
Like Netflix launching Fast.com, this would directly weaponise these regimes' censoring tendencies against themselves.
[1] https://en.wikipedia.org/wiki/1989_Tiananmen_Square_protests...
[2] https://www.nytimes.com/2012/10/26/business/global/family-of...
[3] https://jmail.world
Wow. The screenshot had the IP address exactly where I placed my finger to scroll, and iOS Safari briefly opened a popup window where it started connecting to that IP.
Fuck this shit, I’m moving to a hovel in the woods.
Along the same lines, I occasionally find myself cursing iOS for its willingness to just bring up the dialer and call a number. I really, really wish that it would confirm any dialing before doing it, especially if you didn't click on a phone number on a contact. Couple times I've ended up dialing a recent spam caller, which is the last thing I ever want to do.
On top of that, the only possible interaction with the number is to call it or to not call it.
Want to copy the number into the clipboard to call it later, call it from a different app, or forward it to somebody else? Tough luck.
There are a few options available if you press and hold it (Call, Message, Add to Existing Contact, Create New Contact, Delete).
I feel this only make the fact that tapping calls without confirmation more annoying though.
That's assuming there is something I can press and hold, e.g. a phone number displayed in Safari or an email.
Some apps seem to call some "make a phone call now" API, and that opens a modal pop-up with exactly two options – make the call or don't.
One workaround is to take a screenshot of the number being displayed, but... Come on, Apple.
Occasionally, if you're lucky enough, an option to copy the phone number shows up, it seems like completely at the whim of the OS. And that's after accidentally starting to dial the number, of course.
iOS presents me with "Dial NPA-NXX-XXXX" and "Cancel" options in a bottom-raised dialog, when I tap a tel link.
I don't recall doing anything special to make this happen, but I wouldn't put it past me.
That may be specific to a web browser hyperlink. Click on an entry in your recent calls list and it'll immediately dial the number that called you.
Got it, I missed the context.
Agreed, now that I remember the self-training I had to do to avoid the issue, this is an obnoxiously awkward design choice!
It’s in a private Ip range so unless you’re inside Iran you’re fine.
I don't think that works in Iran either
Agree it's a stupid default but you can (and imo should) turn off link previews in iOS
https://xcancel.com/hkashfi/status/1995109785679573167
Thanks for posting this. I mostly gave up on viewing the one or two Twitter feeds that interest me after nitter stopped working. It wasn't ideological, I just wasn't able to reliably view and navigate without an account, and when I made an account it just kept showing me like "black HS football player bad sportsmanship".
Look like I've got about two years of James Cage White story arcs to check in on.
This has been so useful to me that I've created a filter in URLCheck[0] that automatically converts all X-related links.
[0] https://github.com/TrianguloY/URLCheck
Why does this work while nitter doesn’t?
This is a hosted instance of nitter, the reason why nearly all nitter instances died is because "guest" accounts got removed, so now you need tons of real twitter/x accounts instead of just generating thousands of "guest" accounts.
Why not?
I saw “boobs” so I ran.
-Iran