janosdebugs
janosdebugs on Hacker News
Yeah, like the shares being transfered under duress. It's not like that can't be undone.
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.
AFAIK it's not enough to write it in your privacy policy. Art 21 of the GDPR makes this explicit:
> (4) At the latest at the time of the first communication with the data subject, the right referred to in paragraphs 1 and 2 shall be explicitly brought to the attention of the data subject and shall be presented clearly and separately from any other information.
I am not a lawyer, but as far as I can tell, there is no legal way to collect PII (including IP address) or place tracking identifiers on the user's device without at least informing the user explicitly under the GDPR and the ePrivacy Directive.
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.)
I'd say unlikely, games do a lot of work within graphics cards that are not as easily dumpable/restorable as memory.
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!
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.
Precisely zero sites have a legal obligation to post a cookie notice if all they do is use cookies for technically necessary purposes. If you want to track people on the other hand, that's a different story. Adobe should do a MUCH better job at clarifying their legalese and explaining what they can and cannot use data for. A blog post is not a legally binding agreement.
Also, if they want people to trust them with stuff under NDA, they should give people a simple switch that makes sure no Adobe employee or contractor gets to see sensitive documents or files. Or, as a matter of fact, a switch that lets people turn off online features completely. Adobe is not taking their customer's legal responsibilities seriously and this will lead to people needing to cancel subscriptions. (One example, not even NDA-related: transfering PII outside the EU under the GDPR needs special care.)
The icing on the cake is that when I tried a few weeks ago, you couldn't even log in to cancel your service without accepting the new terms.
Cheers: an ex-Adobe customer (please do better Adobe!)
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.