Why would one want this? Are there particular situation(s) that it's desirable to detect a TCP proxy? Does presence of a TCP proxy indicate some adverserial behaviour? E.g. surveillance, censorship, a particular attack?
Came here to ask the same thing. Why do I _care_ if connections to my server come from a TCP proxy? Particularly when a VPN is _not_ observable in a similar way?
Is there some class of bad actors who extensively use TCP proxies and not only _don't_ use VPNs, but would incur large costs in switching to them?
Web scrapers maybe aren't "bad actors", but many sites dont want them. They'll use tons of TCP proxies which route them through a rotating pool of end user devices (mobiles, routers, etc...). Its not really possible to block these IPs as you'd also be blocking legitimate customers so other ways to detect and block are required.
Can't/won't these scrapers just switch to using VPNs or sshuttle or basically anything else that doesn't leak timing info about termination of TCP vs HTTP?
Not really. You can have 100,000 IPs from proxies or use VPNs and have only 5 egress IPs.
Anybody who wants to stop the scraper could get browser fingerprints, cross reference similar ones with those IPs and quite safely ban them as its highly likely theyre not a legitimate customer.
Its a lot harder to do it for the 100k IPs because those IPs will also have legitimate customer traffic on them and its a lot more likely the browser fingerprint could just be legitimate.
The risk of false postives (blocking real people) is usually higher than just allowing the scrapers and the incetives of a lot of sites arent aligned with stopping scrapers anyway. Think eccommerce, do they _really_ care if the product is being sold to scalpers or real customers? If anything, that behaviour can raise perception of their brand, increase demand, increase prices.
This tool should have less false positives than most, so maybe it will see more adoption than others (TCP fingerprinting for example) but I dont think this is going to affect anyone doing scraping seriously/at scale.
I don't mean that you can't do it, just that there is no company offering it so right now those are the only two options.
It's something we're experimenting with currently. the other commenter is right about apple products, but on android, desktop, etc... it's pretty easy.
for phones its a bit difficult because i don't think you can egress out ip traffic without root or jailbreak on iphone and iOS. but i guess on desktop this should be possible
There was https://idiallo.com/blog/zipbomb-protection earlier this year. It sends highly compressed output of /dev/zero. No overlapping files or recursively compressed payloads.
Around 1999 I interned at Philips Semiconductor. I worked with one of the first or early engineers of Teletext (aka BBC Ceefax) - a system designed in the 1970s that encoded text pages within an analog TV signal.
The World Wide Web was just getting popular and he was happy to point out he managed to get @ into the limited character set (maybe called a codepage?) all the way back in the 1970s. However many (all?) international variants used different character sets that replaced @ and other uncommon characters with accented characters for their alphabets/languages.
As a result Teletext in the UK (using the english character set) could show email addresses, but not in most (all?) other countries.
This is how static type checkers are told that an imported object is part of the public API for that file. (In addition to anything else present in that file.)
C.f. "the intention here is that only names imported using the form X as X will be exported" from PEP484. [1]
I'm generally a fan of the style of putting all the implementation in private modules (whose names start with an underscore) and then using __init__.py files solely to declare the public API.
They are not going to pay anything I guarantee it. There is no randomware. They shut their services down before the attacker could deploy ransomware although the attacker likely accessed data.
> On Friday 16 May we discovered the attack was more extensive than originally understood and that the group behind it had accessed a large amount of information relating to legal aid applicants.
> We believe the group has accessed and downloaded a significant amount of personal data from those who applied for legal aid through our digital service since 2010.
> This data may have included contact details and addresses of applicants, their dates of birth, national ID numbers, criminal history, employment status and financial data such as contribution amounts, debts and payments.
