> the harm in that case is the embarrassment and you can achieve the same results in 10 minutes with any image editing software
The harm is not the "embarrassment" of seeing someone in the likeness of yourself (or your son, your friend, your partner, etc) doing something shameful. The harm is the fact that people are very likely to believe it is true and it's not a fake obviously edited photo or video.
You can disagree on the seriousness of the harm or risk or danger or whatever but I think the distinction between an obviously silly/embarrassing fake (a puppet, papier mache, badly done photoshop picture) and a realistic convincing deepfake video is pretty obvious. They aren't even in the same ballpark.
> IMO most of the harm from AI is likely to come from people not believing things that are real, and dismissing reality with “that’s just a deepfake”.
This is also a really good point and I agree it's a danger.
> Consider avoiding the entire formatting arguments as part of the code review process.
That is not going to help me if people send code to review that has formatting problems. We catch a lot of stuff using automated tools, but there's some stuff that you cannot catch. Some people declare every variable as global rather than private, and then I have to follow up with "This variable/constant should be private, any reason you marked it as external?" etc.
You can't just automate everything, and we also have our own specific code formatting guidelines that a lot of tools don't automatically detect by default. I have raised some of these points to our toolchain and engineer productivity teams but it's not my job to dig deep into our tooling and automation so until there's better support in our internal tools (we don't use github + actions) to detect that, I'll keep pointing out any formatting mishap that gets through our linters.
> * Don't give orders ("Do this", "Do that") to your colleagues, since they are not your employees, and it doesn't help promote learning & growth by not exposing the reasoning behind the demand;
I think this depends a lot. I do "readability" reviews at my company to make sure people apply good coding standards and adhere to the coding guidelines that we have. A lot of these are very "mechanical" in nature and when I am reviewing changes that have obvious coding standard mistakes I will write comments like a "linter" would. One of the most common examples:
> Use descriptive ("Uses") rather than imperative ("Use") style for function docstrings. See: <url-explaining-docstring-guidelines>
I think this type of "giving orders" in reviews is fine as long as it's clear this is an obvious misuse/misunderstanding/miss of the readability guidelines. For any other kind of comment I'll phrase it differently ("Is there a reason why you did X? I think doing Y might be more appropriate because <reasons>, what do you think?", etc) but for stuff that linter should've caught I don't think it's necessary to be verbose and "sweeten" the comments too much.
Still, I'm not an expert and this might be entirely unfeasible but I can totally imagine some kind of trusted execution environment that cross checks specific instructions at the API level when the client communicates with the server using some kind of trusted operation (backed by cryptography).
There are already VMs that are used to run trusted instructions on a target (read: client) machine and regardless of you knowing how the VM works and what the code does, if you don't "play by the rules" (as is the world of cryptography), your data will not be accepted and you will get kicked/banned/disconnected.
Is it computationally expensive? Probably. Is it feasible? I don't know. Is it theoretically possible? I'd say so.
>Increasing the time and skill needed to reverse engineer your anticheat increases the time it takes for someone to develop a cheat.
This is the good ol' security by obscurity fallacy. Having it open increases the amount of people who have eyes on the code and contribute to the code and finds exploits to patch, etc. It's two sides of the same coin.
I don't think this is really a given. I admit I'm not familiar with whether or not there exist some free and open source anti-cheat software out there but I can definitely imagine a world where if people put enough resources in developing such software it'd be totally possible to be as good as current proprietary anti-cheat techniques.
Claiming that knowing how the code works lets you break the code is basically advocating for security by obscurity which I'm fairly sure we're all aware it's not the holy grail of a secure system. If you will allow me a bit of a hyperbole, it'd be like saying that since I have access to the entire code of my SSH client, that gives me the capability of modifying it so it lets me connect to every server (even those that I do not own) without a password. That's simply not how it works.
> - open folder selection dialog - click a folder by mistake without double clicking it - clicking the select folder button now enters the folder instead of selecting the current folder - there no way to unselect the selection. -> you have to enter the folder, then go a level up and then select the folder
Glad I'm not the only one with this problem, it's so frustrating and there's literally nothing you can do about it, you just gotta go up one level and come back down.
Really nice, it's so weird that format strings support %n, it's such a massive security vulnerability that I don't really know what was going on in the mind of the guy that decided to implement this.
The harm is not the "embarrassment" of seeing someone in the likeness of yourself (or your son, your friend, your partner, etc) doing something shameful. The harm is the fact that people are very likely to believe it is true and it's not a fake obviously edited photo or video.
You can disagree on the seriousness of the harm or risk or danger or whatever but I think the distinction between an obviously silly/embarrassing fake (a puppet, papier mache, badly done photoshop picture) and a realistic convincing deepfake video is pretty obvious. They aren't even in the same ballpark.
> IMO most of the harm from AI is likely to come from people not believing things that are real, and dismissing reality with “that’s just a deepfake”.
This is also a really good point and I agree it's a danger.