I’m the administrator of kbin.life, a general purpose/tech orientated kbin instance.

  • 0 Posts
  • 11 Comments
Joined 3 years ago
cake
Cake day: June 29th, 2023

help-circle
  • r00ty@kbin.lifetolinuxmemes@lemmy.world•Just do it.
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    The thing is. Any year can be the year of IPv6. Google is on ipv6, youtube is on ipv6, facebook is on ipv6. Pretty much every datacentre I’ve used (OK limited to Europe) give you IPv6 for free by default. Deploying a web site to be IPv4 and IPv6 is trivial and people that use automation should be able to quite easily apply ipv6 to those scripts.

    It’s really just the ISPs (more so in the US as I understand it), lazy IT people and the FUD myths holding us back at this point.






  • Yes, but my point is I cannot tell the difference. If they can convince cloudflare they deserve special treatment and exemption then they can probably get it.

    I would argue there being a difference “depends” though. There’s two problems I see. They are only potentially not guilty of one.

    The first problem is, that AI crawlers are a true DDoS and this is I think the main reason most (including myself) do not want them. They cause performance issues by essentially speed running collecting every unique piece of data from your site. If they’re dynamic as the article says then they are potentially not doing this. I cannot say for sure here.

    The second problem is, many sites are monetized from advert revenue or otherwise motivated by actual organic traffic. In this case, I would bet some money that this company is taking the data from these sites, not providing ad revenue or organic traffic and serving it to the querying user with their own ads included. In which case, this is also very very bad.

    So, their beef is only potentially partially valid. Like I say, if they can convince cloudflare, and people like me to add exceptions for them, then great. So far though, I’m not convinced. AI scrapers have a bad reputation in general, and it’s deserved. They need to do a LOT to escape that stigma.


  • Well. Try running a web server and you’ll find quite quickly that you get hit quick and hard by AI crawlers that do not respect server operators. Unlike web crawlers of old, these will hit a site over and over with sometimes 100s, even 1000s of requests per second to strip mine all the content they can find, as quickly as possible.

    When you try to block them by user agent, they start faking real client user agents.

    When you block the AS Numbers involved traffic starts to go down. But there’s still a large number of non organic requests, coming from, well frankly everywhere. Cellular network in Brazil, cable internet in the USA, other non business subcribers in other countries around the world.

    How do I know they’re not organic? Turn on cloudflare managed challenge and they all go away.

    So, personally that’s my biggest beef against them. Yes ripping off data without permission is bad already, but this level of trying to bypass any clear sign we do not want you is far worse.



  • Yep. I entirely agree about the good points. I am just always weary about removing options like this, regardless of intention.

    I’d be fine if for example I’m running my own wireguard implementation, I could choose the suite to use, not negotiate anything and ensure my client has the same configuration.

    I’d probably not use it, but I like the option, and knowing that anyone that wants to try to break this now also needs to guess what options I’m running.


  • I only have one problem with this. When they say wireguard being crypto opinionated is a good thing. I am weary to agree with that statement entirely.

    While it is good for stability (only one stack to support and get right, and to be secure and efficient) I do wonder about overall and future security. Saying “You must use this specific cipher suite because we think it’s the best” is a bit of a dangerous road to take.

    I say this just because Curve 25519 is considered a very secure elliptic curve, to the best of my very limited knowledge on this subject. But we had a certain dual elliptic curve pseudo random number generator was pushed as “best practice” (NIST backed) some time ago, which didn’t turn out so well, even omitting possible conspiracy scenarios, it had known weaknesses even before it was recommended. [1]

    Since then I’ve generally not been a huge fan of being given one option as “the right way” when it comes to cryptography. Even if it is the “best” it gives one target to try to find a weakness in, rather than many.

    I say all this as a wireguard user, it’s a great, fast and reliable VPN. I just have concerns when the choice of using other algorithms and especially putting my own chosen chain together is taken away. Because it puts the exact same target to break on every one of us, rather than having to work out how to break multiple methods and algorithms and multiple combinations.

    [1] https://en.wikipedia.org/wiki/Dual_EC_DRBG


  • Here you go

    #include <iostream>
    #include <csignal>
    #include <unistd.h>
    
    void sigusr1_handler(int signal)
    {
    	std::cout << "Signal USR1" << std::endl;
    }
    
    int main()
    {
    	std::cout << "Installed handler for USR1" << std::endl;
    	std::signal(SIGUSR1, sigusr1_handler);
    	while (1 == 1)
    	{
    		usleep(5000000);	// 5 seconds
    		std::cout << "Waiting for signal" << std::endl;
    	}
    }
    

    That will help you read at least one of them.