• 1 Post
  • 966 Comments
Joined 1 year ago
cake
Cake day: March 20th, 2025

help-circle



  • I think this is a very well thought out approach to handling it. I can’t personally think of any better solutions, at least. I probably would have chosen some different phrasing for the tags, (CBH feels… Disconnected? I’d probably go with something like “No AI” or “AI-Free” instead), but that’s just a matter of personal diction. Outright banning posts about projects that use AI likely isn’t going to be feasible in the long run, and I think that simple declaration requirements will go a long way towards encouraging people to actually disclose their usage.

    If you outright ban it, people will simply hide their usage. It feels like it’s akin to the US War On DrugsTM in that way. If you allow it and simply require responsible disclosure, more people will be inclined to be upfront about it. And that allows projects to be more accurately audited and vetted. The same way the war on drugs consolidated power to organized gangs (by making them the only ones capable of producing and transporting illegal drugs at scale), an outright ban on AI would only encourage people to hide their usage.

    One potential way I see people trying to skirt the rules regarding self-promos is via proxy/strawman accounts. It would be trivial for me to spin up a dummy account and post my own project as an “I found this cool project but don’t have to disclose my AI use because I didn’t make it” post. I don’t personally have any projects in the works to post about, but I can easily see someone using it to try and skirt the disclosure requirements. Especially when we have seen situations like the (now infamous) Huntarr debacle, where the vibe-coder dev was actively avoiding AI disclosures. Because they knew it would tank the project’s popularity if people knew it was vibe coded.

    I’m not sure if there is a good solution for this potential issue, except maybe to limit posts by new users. But even that is trivial to bypass. If you limit them based on account age, simply making a few strawman accounts and waiting for them to age is easy. Hell, I already have a few old throwaway accounts that I could swap over to whenever I want, and I’m not even planning anything nefarious.

    There are similar problems with restricting users based on post/comment count, as that will likely stifle discussion from new users who are trying to be active in the community. One of the more frustrating parts about Reddit was that many of the most popular subs banned posts from users who were below a certain post karma threshold or who didn’t have enough previous posts. It created a catch-22 where you needed to have a few popular posts before you were allowed to make any posts. So there were people posting on random niche subs, simply for karma farming before they could then post on the larger subs. And if I was a vibe coder without scruples who is already looking to skirt the rules, it would be trivial for me to spin up an LLM and let it make a few comments before I start using it as a dummy account.

    This may end up being a non-issue in the grand scheme of things. But I figured I’d mention it, because I genuinely don’t see a good solution for patching the big glaring hole in the self-promo rule. You’re absolutely correct that requiring disclosure for every post is unrealistic, because lots of users who post projects here aren’t the devs. They just stumbled across a cool project and wanted to share it, and they have no realistic way of knowing if the project uses AI. And if you restrict promo posts to only devs, you’ll only get posts from the people who fall into the (likely very small) overlapping section on the “is a Lemmy user” and “makes projects” Venn diagram. Lemmy is already a small community in the grand scheme of things. And restricting promo posts to only the people actively developing the projects would make it feel even smaller.

    If I do use mine, I’ll put it up on codeberg so everyone can see exactly what its doing… and then get mad and tell me there is a better way.

    Poe’s Law is always in effect. The best way to get an answer on the internet is not to ask a question; it is to post an incorrect answer, because people will go out of their way to correct you.






  • Yeah, I keep a “Kids” profile on my Plex/Jellyfin server, specifically so I can throw Bluey, Mr Rogers Neighborhood, Miss Rachel, etc on and not worry about it. Elsagate (which is still a big problem) means you can’t just put on YouTube Kids and expect auto-played content to stay safe. But with my server, running solely on content I have curated, I know that everything in that “Kids” profile is going to be safe.





  • Yeah, the *Arr stack has effectively eliminated the need to permanently retain media. I want to watch something? I just request it, and 10-20 minutes later it is available on my server. I tend to treat *Arr requests the same way I used to treat Blockbuster trips. It takes a few minutes to get what you want to watch, but that’s also a chance to make some popcorn, grab a beer, and settle in.

    I only (“only”) keep ~25-30TB of media available at any one moment. And even that is plenty. It’s literally hundreds of movies and TV shows. And if I want to purge old content, that’s easy to do too. Hell, I can even sort by the last time it was watched, and start with the shit that hasn’t been touched in like 18 months.




  • Here is a write-up about one of the old 2015 audits. And here is one from 2017. And it’s worth noting that new audit results aren’t readily available, because the TSA started classifying their results around 2017 instead of releasing the numbers, when David Pekoske was installed as administrator. Because that definitely screams “our numbers are improving!”

    Basically, a thorough search of 10-15% of passengers would more accurately catch threats, when compared to searching everyone with a ~95% miss rate. There are even systems designed to randomly select people for searches. Usually used in jobs where employees are subject to searches/drug tests as they’re arriving/leaving. For instance, if a company needs to drug test 5% of their employees every day, they can set their random selector to ping on 5% of people as they’re arriving.

    They’re usually triggered automatically by walking across a mat, by employees badging through a controlled access door, or via a button push as security buzzes you in. But it could also be configured to be triggered based on something like ticket scans for passengers. Passengers get their ticket scanned, the random selector system randomly selects the pre-programmed percentage of passengers, and they’re the only ones who get pulled aside. All the rest are free to continue to their gate as usual. That way there are no accusations of random searches being discriminatory, because the random selector system is doing the choosing based on the defined percentage.


  • There is actually an entire industry focused on testing security measures to ensure they work. It is called penetration testing. For something like the TSA, they’ll do audits where test passengers are sent through with contraband. Sort of like secret shoppers who evaluate a retail store by pretending to shop there. In one particular audit, they only successfully caught 3 out of 70. Some audits estimate a 95% failure rate.

    The audits have consistently found that TSA’s catch rates are lower than random searches, by a wide margin. As in, they’d be better off not searching everyone, and just doing randomized searches on ~10-15% of passengers. That random “10-15% of passengers get a full search” system would catch more than the current “search everyone but miss 95% of contraband” system.

    They could literally just roll a d8 die for each passenger in the line, and on a 1 they initiate a full search. And that would be more effective than their current methods.