• 3 Posts
  • 256 Comments
Joined 6 years ago
cake
Cake day: January 21st, 2021

help-circle


  • Honestly AI has been used for moderation for decades. The newer models will be quite effective. It could be very useful for limiting lower effort spam. Sure dedicated spammers will figure it out and get by it but as the models get better that will get harder.

    Of course like every use of probabilistic technology like AI it should still go to human review. We shouldn’t be shadowbanning people because computer said no. But holding suspicious posts in a review queue for the moderators seems quite reasonable (much like they already do with their current systems).

    Honestly this sounds more like an investor update showing how innovative we are using modern technology and how it is going to really improve the platform and stonks will go up up up than any meaningful change to their current moderation systems.


  • kevincox@lemmy.mltoLinux@lemmy.ml•Is multi user nix safe?
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    3 months ago

    In theory it is safe. When a Nix package is built it isn’t “installed”. Unless root is running/installing random packages out of the Nix store there is no problem. As long as the user’s aren’t added to the trusted-users option they shouldn’t be able to cause any problems for other users.

    However like any multi-user system you are sharing a Linux kernel. A kernel is a very complex piece of software with a huge attack surface. Privileged escalation vulnerabilities are commonly found. (This also applies to the nix-daemon, but it is a bit smaller attack surface but vulnerabilities are still occasionally found.) So you shouldn’t assume strong security isolation. I would say that a setup like this is acceptable for mostly-trusted people like coworkers or friends that are not expected to actively exploit vulnerabilities but definitely wouldn’t let random unknown users use the system.

    So if you want strong isolation use a VM or separate hardware, but then you won’t be able to share the builds and packages defeating the point in this case.




  • Reverse DNS is different than static IP.

    But yes for outbound email, if you can’t control reverse DNS you will have pain. (Inbound is totally fine) You can in theory just use whatever hostname the ISP’s reverse DNS resolves to however you will get some spam score (or be rejected) as it doesn’t match your “from” domain.

    Outbound email is a huge pain really no matter what. Unless you have a long-term lease on the IP and it isn’t in a bad network you really have to pay someone else if you want reliable delivery.


  • Yeah, it is very important to consider how dependant you are on third parties. At the very least the more dependence the more power they have over you. But also how screwed you are if they just go under.

    • If you use SaaS they can interrupt your use at any time and you can only react (for example demanding a reversal or lawsuits).
    • If you host closed source software they can’t interrupt service on an existing contract but can legally require you to stop using it if they don’t renew the contract. (And if the company goes under you can likely get away with using the software as long as it doesn’t need code fixes.)
    • If the software is open source you can continue using the software indefinitely including making code fixes. (Maintenance may be expensive as it is now your problem but that can be costed and an exit plan made if required.)


  • Yeah, I finally pulled the trigger and moved to my own domain from matrix.org. Man, it is just so much faster. Which is sad, because the performance is pretty bad. (Element Web seems to do some per-room request as part of the initial loading screen which is obviously not scalable) but getting off of matrix.org is a huge performance improvement.

    That being said there is nothing really wrong with matrix.org. The problem is really public rooms. People will join and spam. It is true of any protocol (have you heard about email?) but Matrix definitely needs to (and they are slowly working on) make it more expensive for spammers.



  • Sort of…

    You can just hope that /favicon.ico works. But 1. it often doesn’t and 2. it is often of low quality.

    To find a favicon on a modern site you need to load the HTML and check Link headers and `` elements. However you likely can’t do this client-side for most sites because of CORS. So you need some server (at the very least to strip CORS). That lets you get the URL but 1. you probably don’t want to have connections to external domains for user privacy and 2. some domains will have hot-link protection so you need to fetch the image via your server. You will also want to consider different image formats and sizes to serve the right image to the right client. On top of all of this the site may be using some sort of bot protection which you will have to fight. Google is almost always whitelisted. The site may also have temporary outages so having a cache would be nice, especially if that is almost always populated before you even know the domain exists.

    At the end of the day you do want some sort of API. And while it isn’t complex it isn’t trivial. So it is nice to just let Google handle it. (Other than tracking risks, but you could proxy Google’s API.)


  • Its a problem but it isn’t a major problem. I am using rspamd without any sort of exotic configuration (basically just enabling things that are provided, not my own rules) and I only get a few spam messages leaking through a week. Maybe slightly worse than GMail but not considerably slow.

    IMHO the only real missing thing out of the box is contacts checking. Which is a huge thing because it is great to have reliable delivery from contacts. But my false-positive ratio is so low anyways that it isn’t a big issue and things like the known_senders module mostly mitigates it.


  • Yes, blocking port 25 outbound is incredibly common by default. Even on some server connections. It is probably better overall for exactly the reasons that you mentioned.

    Or just don’t self-host email

    IMHO this is a bit overblown. Hosting inbound is fairly easy. Mail senders (probably for the worst) are very forgiving even if your TLS cert is expired you will probably get mail. Plus senders are supposed to retry for days if you have downtime.

    However it is unfortunately true that due to spam sending is a huge pain because IPv4 reputation is a huge component. Sure you can get GMail to trust your domain after a month or so of sending if you have decent volume. But other providers who you may mail once a year are just going to go off of IP reputation. However email was basically designed for forwarding and you can use a service like AWS SES to forward your email from a trusted IP pretty easily. If you are low volume (like personal mail) there are tons of services that will do this for free.



  • Off topic. But I can’t help but rate the trash cans.

    • 1995: Excellent can. Obviously not that many pixels to work with but it is clear, legible and clean.
    • 1998: I mean its fine, but a bit of a downgrade. Why so much black? Especially that top rim that apparently was painted black. The shading on the arrows also just hurts legibility, why do 2D arrows have shading anyways?
    • 2000: Nope. The only good thing about it is that it is throwing away Windows. The shading is to simple arrows are strange colours and lacks a sense of depth.
    • 2001: I don’t love the theme but the execution is great. It looks clean shiny and bright. The only real weird thing is the bag inside, it is a bit strangely round despite seemingly not going over the edge.
    • 2006: This is a nice refinement of the last one. Cleaner look, skip the bag, more realistic trash. This is the second best executed after 1995.
    • 2015: This one is bland and lacks contrast and detail. The arrows are also oddly stubby for some reason. It’s not bad, but also not good.