15 Matching Annotations
  1. Mar 2021
  2. Jan 2021
    1. Group Rules from the Admins1NO POSTING LINKS INSIDE OF POST - FOR ANY REASONWe've seen way too many groups become a glorified classified ad & members don't like that. We don't want the quality of our group negatively impacted because of endless links everywhere. NO LINKS2NO POST FROM FAN PAGES / ARTICLES / VIDEO LINKSOur mission is to cultivate the highest quality content inside the group. If we allowed videos, fan page shares, & outside websites, our group would turn into spam fest. Original written content only3NO SELF PROMOTION, RECRUITING, OR DM SPAMMINGMembers love our group because it's SAFE. We are very strict on banning members who blatantly self promote their product or services in the group OR secretly private message members to recruit them.4NO POSTING OR UPLOADING VIDEOS OF ANY KINDTo protect the quality of our group & prevent members from being solicited products & services - we don't allow any videos because we can't monitor what's being said word for word. Written post only.

      Wow, that's strict.

  3. Oct 2020
    1. A while ago we put a system in place to monitor our servers for abusive request patterns and send 503 Service Unavailable responses with custom text depending on the nature of the abuse. Our hope was that the authors of misbehaving software and the administrators of sites who deployed it would notice these errors and make the necessary fixes to the software responsible.
    2. Take responsibility for your outgoing network traffic If you install software that interacts with other sites over the network, you should be aware how it works and what kind of traffic it generates. If it has the potential to make thousands of requests to other sites, make sure it uses an HTTP cache to prevent inflicting abuse on other sites.
    1. Another thing you can do is to add pain to the second part of it. Attackers want the list of valid usernames, so they can then try to guess or brute force the password. You can put protections in place with that as well, whether they are lockouts or multi-factor authentication, so even if they have a valid username, it's much harder to gain access.
    1. Customizable mitigation policies provide multiple response options including block, rate limit, geo fence, or deception. Using deception allows you to send a custom response to the attacker, effectively putting guardrails around their activities.
  4. Jun 2020
    1. Google’s novel response has been to compare each app to its peers, identifying those that seem to be asking for more than they should, and alerting developers when that’s the case. In its update today, Google says “we aim to help developers boost the trust of their users—we surface a message to developers when we think their app is asking for a permission that is likely unnecessary.”
  5. May 2020
    1. Website administrators then get access to their visitors’ risk scores and can decide how to handle them: For instance, if a user with a high risk score attempts to log in, the website can set rules to ask them to enter additional verification information through two-factor authentication. As Khormaee put it, the “worst case is we have a little inconvenience for legitimate users, but if there is an adversary, we prevent your account from being stolen.”
  6. Apr 2020
    1. Browser fingerprinting is quite a powerful method of tracking users around the Internet. There are some defensive measures that can be taken with existing browsers, but none of them are ideal. In practice, the most realistic protection is using the Tor Browser, which has put a lot of effort into reducing browser fingerprintability. For day-to-day use, the best options are to run tools like Privacy Badger or Disconnect that will block some (but unfortunately not all) of the domains that try to perform fingerprinting, and/or to use a tool like NoScript for Firefox, which greatly reduces the amount of data available to fingerprinters.
    1. Anti-automation on the form where a key can be requested is one thing, stopping someone from manually registering, say, 20 of them with different email addresses and massively amplifying their request rate is quite another.
    2. I got way too many emails from people about API requests being blocked to respond to. Often this was due to simply not meeting the API requirements, for example providing a descriptive UA string. Other times it was because they were on the same network as abusive users. There were also those who simply smashed through the rate limit too quickly and got themselves banned for a day. Other times, there were genuine API users in that West African country who found themselves unable to use the service. I was constantly balancing the desire to make the API easily accessible whilst simultaneously trying to ensure it wasn't taken advantage of.
    3. Combating Abuse with Firewall Rules
    4. Make more than 40 requests in a minute and you're in the naughty corner for a day. Only thing is, that's IP-based and per the earlier section on abusive patterns, actors with large numbers of IP addresses can largely circumvent this approach. It's still a fantastic turn-key solution that seriously raises the bar for anyone wanting to get around it, but someone determined enough will find a way.