There are two answers to this depending on what the reason is for asking.

If you are asking because you are concerned about scrapers reading your posts and violating your privacy and your rights, then understand that even if an instance is 100% effective at blocking them, the post is sent all over the place in clear text anyway. It doesn’t matter for them which of the federated servers your post is read from. They will read your post many times over. For this case, then, there is little incentive for a server owner to block bots if it’s just to protect your posts from ingestion.

If you are asking because you are concerned about scrapers sucking the life out of a server because there are multiple different AI companies trying to read every single post in the database multiple times over for training, which ends up causing gateway timeout errors and poor performance, then admins, for this reason, should take action.

On my PieFed server, feddit.online, as of yesterday, the firewall discarded 99K requests it deemed were for AI scraping while processing the remaining 300K requests. Those 99K requests would have been expensive requests, not just upvotes and such, but requests asking for huge amounts of text, and so the impact on the server and infrastructure would have been much more than a 25% tax on the system.

And if the bots realize your server is not well protected, it gets worse. 3 months ago I peaked at 1.2 million requests in one day, of which over 700K were AI bots. Now it’s down to consistently under 100K from bots because many of them have given up, I like to believe.

Lemmy is t-i-m-eless.

Good point.

This is supposed to be a gifted article and so no paywall.

So many companies claim “collaboration” is a prime reason for Return To Office and yet these same companies gladly use offshore teams for development work if they believe they can save money, proving that collaboration as a goal is a lie. A short overlap in time, if any, between onshore and offshore teams proves the claim is gaslighting.

You’re reading the wrong stuff: https://medium.com/@ovenplayer/does-proton-really-support-trump-a-deeper-analysis-and-surprising-findings-aed4fee4305e

They are doing no such thing. https://www.reddit.com/r/ProtonMail/comments/1u05xs2/comment/oqgihvq/

" You’re right to raise this, and we want to address it directly and provide you important context on how this happened.

Vincent Lapierre’s channel should never have been part of our affiliate and sponsorship program, because we intentionally avoid association with channels whose content could distract from our message and divide our community. "

He made thousands of dollars a month off MAGA men who believed she was real. But when he tried to create an AI woman for the Democrats, it bombed because they knew it was just AI slop.

Any questions?

I think the article basically says current symmetric key encryption, even 128-bit, but especially 256-bit, is safe from quantum computers, maybe forever. It’s the asymmetric encryption that’s going to be easily broken, and this is what Google says needs to be addressed by 2029.

We’re glad you are here!

According to the Google Play Store, there are 467 reviews (4.8 stars) but “0+” downloads. Like everything else about the White House, it doesn’t add up.

And maybe most people know to keep it off their phones.

You are asking a reasonable question that many ask.

Each account will be a unique and separate account on each instance. Instances do not share accounts.

Although you can, on some applications, authenticate with a federated account, like Google or even a Mastodon account, you still will have an entirely different account on the server.

Wine requires Linux knowledge to get the configurations correct. I don’t think many Windows users will be able to get any Windows applications running under Wine. And it’s the same Wine that any Linux user can install for free.

If Zorin came packaged with Crossover, then maybe it would run Windows apps better because Crossover would manage the Wine configurations and the required Windows infrastructure installs.

Maybe.

But not many old machines will have the capacity to run Linux, Wine, and a Windows application. But Zorin’s hype leads one to believe that a 15-year-old machine won’t struggle.

I tried it about a month ago and found it had nothing more than what you get with an Ubuntu install, save for the look of the screen. I couldn’t understand why the media was making a big deal about it. And I saw no reason why anyone should pay for Pro. My conclusions matched what is in the article.

The headline of this post is technically accurate but purposely provocative. The article’s headline is more informative: " Fake 7-Zip downloads are turning home PCs into proxy nodes".

The point is that 7zip.com is not the official website, and this is where many people are going for it, and getting malware.

@rimu@piefed.social
But the logins from Voyager are returning 400 (Bad Request), although the username and password are correct, and to me, the request looks good.

I posted what is coming into the server. The only anomaly I saw was that the session cookie referrer seemed odd. Can you look at the request I posted? Do you see any reason it would be seen as a bad request?

The odd thing is that while I get an error 95% of the time trying to log into Voyager, twice it did let me log in. I don’t know what was different about those 2 times.

Nothing gets logged to syslog, any nginx logs, pyfedi.log, or journalctl.

Nope. I posted below what is coming into the server. The only thing I can think of is that the referrer is coming in as https://localhost/inbox which might explain the 400 error (Bad Request). Does your nginx configuration drop incoming cookies for the login endpoint?

Help me here. I’m not an expert. Here is the request going into the server. The error code is 400 (Bad Request)

@x..@x..  
18:24:10.580462 IP 127.0.0.1.49126 > 127.0.0.1.5000: Flags [P.], seq 5107:5771, ack 1755, win 8143, options [nop,nop,TS val 1081650450 ecr 1081650382], length 664  
E....3@.@...............kz.....n...........  
@x..@x..POST /api/alpha/user/login HTTP/1.1  
X-Forwarded-For: 162.120.199.186, 172.70.111.121  
X-Forwarded-Proto: https  
Host: feddit.online  
Content-Length: 56  
accept-language: en-US,en;q=0.5  
content-type: application/json  
accept-encoding: gzip, br  
cf-ray: 9c85ae25b9720f65-EWR  
user-agent: Dalvik/2.1.0 (Linux; U; Android 16; Pixel 10 Pro XL Build/BP4A.260105.004.E1)  
cdn-loop: cloudflare; loops=1  
cf-connecting-ip: 162.120.199.186  
cf-ipcountry: US  
cf-visitor: {"scheme":"https"}  
cookie: session=eyJSZWZlcmVyIjoiaHR0cHM6Ly9sb2NhbGhvc3QvaW5ib3giLCJfZnJlc2giOmZhbHNlfQ.aYJgEQ.nMo4SDt0iKOrzFvSItQuquLp4qo  

{"password":"<hidden>","username":"testuser"}  
18:24:10.584409 IP 127.0.0.1.49120 > 127.0.0.1.5000: Flags [P.], seq 8671:10383, ack 2866, win 22123, options [nop,nop,TS val 1081650454 ecr 1081650338], length 1712  
E.....@.@.CB.............BO.+Ngj..Vk.......  

The session string is: eyJSZWZlcmVyIjoiaHR0cHM6Ly9sb2NhbGhvc3QvaW5ib3giLCJfZnJlc2giOmZhbHNlfQ
This decodes to a referrer of: https://localhost/inbox

I wonder if this is the issue. Will Piefed accept a session claiming to be from localhost? Will it see this as a potential attack or misconfiguration? Should I reconfigure nginx to drop incoming cookies for the login endpoint?

I’m grasping at straws.

Very odd thing. Sometimes I am able to log in via Voyager. Mostly not.

At one point I put a space after the user name, and then it logged me in. Once I didn’t, and it logged me in. But it isn’t consistent. The server is complaining that there’s a problem in the request format. i don’t see anything different that allowed the log in those 2 times.

The Cloudflare WAF log shows that it allowed the login request to go through. I’ll have to look more this evening.