You can easily put phpMyAdmin behind basic auth as an additional security layer, completely bypassing any PHP execution and letting the web server completely handle the authentication. It's exactly what I have done multiple times in the past. Arguably phpMyAdmin's direct integration is a less secure way of doing it, but do we even know if it's the basic auth itself that was bypassed, or was it just the case of a weak password?
Again, the premise was that phpMyAdmin is secured behind basic auth. It doesn't matter how secure or insecure phpMyAdmin is, it only matters how secure whatever webserver is that it is served through. phpMyAdmin code isn't even touched before the basic auth login was successful. Only after that, it becomes relevant, in that you either find a hole in phpMyAdmin itself, or you have to break another (hopefully strong) password for the MySQL login itself.
Then you should also be worried about bugs that let you log into an SSH session without providing your SSH certificate, passkey or whatever. Authentication bypass can happen with pretty much any buggy authentication method. None of this is inherently a problem of passwords or basic auth.
That's my point - if you have a reasonably secure password (let's say 50-100 characters, fully random), it's extremely unlikely that anyone is ever going to even get beyond the basic auth prompt.
Can you please elaborate how it is "asking for it" if we assume the basic auth password is reasonably complex and kept as safe as, say, the SSH login credentials of the same server?
The point of the fish doorbell is educating people about what lives in the water. There would be much less resource-intensive ways of "solving" the problem, if that was the goal.
Changing the duty cycle of a square wave is called Pulse Width Modulation and is an extremely audible and iconic sound. If you have ever heared music any on the Commodore 64, you will familiar with its sound. PWM is also available in many professional synthesizers of the same era.
I was using a W500 (same generation) until 2018 or so. Upgraded RAM, installed an SSD, and it was my daily driver until the end. But already back then it started to become unbearbly slow especially with background procesesses like file syncing to different machines.
Not the same thing at all if atop runs as root and you are a user on that system that has no root access. With a well-prepared exploit you could achieve code execution as root. That's a bit more than a simple Denial of Service by filling up the disk.
If you are serving a Git repository browser and all of those IPs are hitting all the expensive endpoints such as git blame, it becomes something to worry about very quickly.
We're affected by this. The only thing that would realistically work is the first suggestion. The most unscrupulous AI crawlers distribute their inhuman request rate over dozens of IPs, so every IP just makes 1-2 requests in total. And they use real-world browser user agents, so blocking those could lock out real users. However, sometimes they claim to be using really old Chrome versions, so I feel less bad about locking those out.
That would allow you to specifically lock out that bot based on its user-agent string. That's the main problem with AI scrapers, many of them normally use user-agents that cannot be easily blocked, so other means have to be found to keep them off your grounds.
There's source repository browsers (git/svn) way, way leaner than GitLab that have the same issues. Any repo browser offering a blame view for files can be brought down by those bots' traffic patterns. I have been hosting such repository browsers for 10+ years and it was never an issue until the arrival of these bots.
> They're looking for commits because it's nicely chunked, I'm taking a guess.
They're not looking for anything specifically from what I can tell. If that was the case, they would be just cloning the git repository, as it would be the easiest way to ingest such information. Instead, they just want to guzzle every single URL they can get hold of. And a web frontend for git generates thousands of those. Every file in a repository results in dozens, if not hundreds of unique links for file revisions, blame, etc. and many of those are expensive to serve. Which is why they are often put in robots.txt, so everything was fine until the LLM crawlers came along and ignored robots.txt.
As someone that is also affected by this: We see a manifold increase in requests since this LLM crap is going on. Many of these IPs come from companies that obviously work with LLM technology, but the problem is that it's 100s of IPs doing 1 request, not 1 IP doing 100s of requests. It's just extremely unlikely that anyone else is responsible for this.
We have seen competitors (big, well-known apps) do things on iOS that most definitely are not possible with public APIs. Either Apple willingfully provides access to these APIs to a select few companies, or they don't care that they reverse-engineer private APIs and then use them. If it's the latter, the competitor app was probably too big to be banned from the app store for this.
Apple was unwilling to comment on the situation when we asked them.
> Its funny how "bad" we are as an industry, making rational choices. Like WHY do NVME SSD not implement TRIM? What is it about them that "TRIM" didn't make sense?
Maybe CrystalDiskInfo is simplifying things (combining TRIM and the mentioned DEALLOCATE command?), but all my NVMe SSDs support TRIM according to it. And it would be really strange if NVMe didn't support any sort of trimming, as SSD performance and health heavily relies on it.
It could also be that what the author is observing is specific to macOS?
Two things come to mind:
- Maximum stack depth greatly varies between targets. If you wanted to support a recursion depth of, say, 50, that may already be too much for some of the hardware this library needs to be able to run on, so the original problem still exists.
- This would be add an arbitrary limit to the parsing capabilities of the library. Stack space is very limited to begin with compared to heap space, So any solution that remains recursive would probably require a limit way lower than a heap-based solution could offer.
If you are in control of the domain of your email address, enable SPF and DKIM for that domain, together with strict policies that mail servers should reject spoofed mails claiming to come from that domain. If your own mail server supports validating SPF and DKIM, you would no longer receive such forged mails, nor anyone else behind a mail server supporting SPF and DKIM.
If you aren't in control... just ignore it like any other spam mail.
1. Artists / labels can pull releases from streaming services, so an album may completely disappear from one day to another. They won't come to your house and rip the CD out of your CD player.
2. They can also replace one version of a song for another, like a remastered version. Especially remasters from the "loudness war" era are often worse in quality than original releases. On a streaming service, you often don't have the choice of which version you can listen to (and if you have the choice, point 1 is still a danger). This is also a problem with songs that contain explicit lyrics. The streaming version may force you to listen to the version with those lyrics removed (e.g. US release vs. EU release). Again, you are not affected by this if you have the physical media or a copy on your computer.
Having a copy of the music that noone can take away from you is important. Tons of music keeps disappearing from streaming services. This is not just a made-up scenario. Yes, technically speaking you only "own" a license to the music. The important thing is that this license is practically irrevocable.