janosdebugs

Yeah, like the shares being transfered under duress. It's not like that can't be undone. The only thing this would achieve is a bunch of prison time and possibly destruction if data.

Not to mention that modern-day IT systems are such a mess that you'd need a crazy amount if time to find and access them all.

This seems awfully complicated. A lot of applications will happily respect system proxy settings and connect to mitmproxy directly.

Content gating behind login screens. Scraping content behind a login screen could constitute a contract violation and would give rise to a lawsuit independent of copyright.

After reading the specs, this sounds like an awful lot of complexity for something that should be simple and low cost. The spec also seems to be very loosely defined, more like a recommendation than a spec. This means you'll likely have to integrate a library and that library will be the authoritative source of truth as far as the expected behavior is concerned.

Legitimate interest still requires the data subject to be informed under Art 13. Not sure how that would be accomplished without at least an info banner. (This goes for server logs too.)

Unreal Engine and Steam Audio may be worth looking into before you invest significant amounts of time into this.

Name recognition? You know exactly what you get, which isn't necessarily true for the bajilion clones out there. You know that if you buy an rPi, you can buy a replacement tomorrow and it will work the same. In a world where I can't even rebuy a laptop of the same make and model a few months later that's quite the advantage.

There are very legit reasons to use passwords, for example in conjunction with a second factor. Authentication methods can also be chained.

As far as OpenSSH is concerned, I believe the main problem is that there is no centralized revocation functionality. You have to distribute your revocation lists via an external mechanism and ensure that all your servers are up to date. There is no built-in mechanism like OCSP, or better yet, OCSP stapling in SSH. You could use Kerberos, but it's a royal pain to set up and OpenSSH is pretty much the defacto standard when it comes to SSH servers.

Not necessarily. There is a fork of OpenSSH that supports x509, but I remember reading somewhere that it's too complex and that's why it doesn't make it into mainline.

As I said, "should". In some places there will be enough people in the chain that won't be bothered to go to the LIR directly. Think small rural ISPs in small countries.

The provider doesn't care, the owner of the server who needs to log in from their home internet at 2AM in an emergency cares. Bad actors have access to botnets, the server admin doesn't.

Use TOTP (keyboard-interactive) and password away!

I saw a Postgres story like this one. Badly managed AWS org with way too wide permissions, a data scientist sort of person set it up and promptly reconfigured the security group to be open to the entire internet because they needed to access it from home. And this was a rather large IT company.

That may be true mathematically, but there are no guarantees that a small provider won't end up having only a single /64, which would likely be the default unit of range-based blocking. Yes, it "shouldn't" happen.

The hard part is making sure every one of your servers got the CRL update. Since last I checked OpenSSH doesn't have a mechanism to remotely check CRLs (like OCSP), nor does SSH have anything akin to OCSP stapling, it's a little bit of a footgun waiting to happen.

There is nothing wrong with this approach if enabled as an informed decision. It's the part where they want to enable this by default I have a problem with.

Things that could be done is making password auth harder to configure to encourage key use instead, or invest time into making SSH CAs less of a pain to use. (See the linked paper, it's not a long read.)

IPv6 has the potential to be even worse. You could be knocking an entire provider offline. At any rate, this behavior should not become default.

You can use SSH certificate authorities (not x509) with OpenSSH to authorize a new key without needing to deploy a new key on the server. Also, Yubikeys are useful for this.

Having written an SSH server that is used in a few larger places, I find the perspective of enabling these features on a per-address basis by default in the future troubling. First, with IPv4 this will have the potential to increasingly penalize innocent bystanders as CGNs are deployed. Worst case, this will give bad actors the option to lock the original owner out of their own server if they have a botnet host in the same network. With IPv6 on the other hand, it is trivially easy to get a new IP, so the protection method described here will be completely ineffective.

From my experiments with several honeypots over a longer period of time, most of these attacks are dumb dictionary attacks. Unless you are using default everything (user, port, password), these attacks don't represent a significant threat and more targeted attacks won't be caught by this. (Please use SSH keys.)

I have seen experienced sysadmins create the test user with the password of "test" on a live server on port 22 because they were having an "autopilot moment". It got hacked within 20 minutes of going online and these mechanisms wouldn't have saved it, the attacker got in on the second or third try.

If you want to have a read about unsolved problems around SSH that should be addressed, Tatu Ylonen (the inventor of SSH) has written a paper about it in 2019: https://helda.helsinki.fi/server/api/core/bitstreams/471f0ff...

It's for making game sounds. Fairlight looks like it could work though, thanks!

The deal fell through: https://www.theverge.com/2023/12/18/24005996/adobe-figma-acq...

NDAs are not the only problem. Adobe Acrobat is used to work on a whole host of documents that may be straight up illegal to share.

Does anyone have a reasonably feature complete alternative for Audition? I tried several paid and free ones, none seem to make it easy to work with multitrack audio in a non-destructive fashion.

Last I checked you are allowed to store CC info apart from the security code if you follow the PCI-DSS rules.

I had to switch back to X11 because both nVidia and nouveau would produce around 5 fps on my A2000 RTX on multiple distros. This is just for basic usage, not even painting-related.

Some very large entities have become quite open about them only wanting to take but contribute nothing back in the open source and adjecent spaces. While working on one of my former projects I also received requests for several hundred hours worth of compliance work from rather well-known entities. When I asked via back channels if they would be open to funding some of that work I got a clear "no" as a reply. This was one of the contributing factors why I decided to hand that project off.

If you maintain a project, it may be cool to hear the big names using something you make for free, but consider what they are asking for and if you are putting yourself in potential legal liability by providing said compliance work. They have money to spend and if it's important enough, they will.

I'm guessing it's relativity doing its job.

I'm confused. Why would they be forced to? Also, there's way more than copyright that covers this: trademarks, patents and trade secrets also play into it.

No, ever since PSD2 came into effect, banks here refuse to do SMS-based verification and have switched to apps. They also don't support hardware authenticators for consumers. I asked.