• 0 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle







  • The short version is that the creators of this API are doing something more secure than what the client wants to do.

    A reasonable analogy would be trying to access a building locked by a biometric scanner vs. a guard looking for a piece of paper with a password on it. In the first case, only people entered into the scanner can get in (this is the cookie scenario). In the second case, anyone with a piece of paper with the right password on it will be let in (this is the Bearer token scenario).

    More technical version: the API is made more secure because the “HttpOnly” cookie - which, basically, means the cookie’s contents can’t be read with JavaScript in the browser - is used to hold the credentials the server is looking for.

    By allowing a third party to access the application, this means you have to allow methods that can be set “client-side” (e.g. via JavaScript in a browser). The most common method is in the “Authorization” HTTP Header - headers are metadata sent along with a request, they include things like the page you’re coming from and cookies associated with the domain. A “Bearer” token is one of the methods specified by the “Authorization” header. It’s usually implemented via passing the authorization credentials prefixed with the word “Bearer” (hence the name) and, often, are static, password-like text.

    Basically, because this header has to be settable by a script, that means an attacker/hacker could possibly inject malicious code to steal the tokens because they must, at some point, be accessible.


  • In this thread, everyone getting caught up on the first toot and not the second where he clarifies his point.

    If you step past the initial investment of buying a house, the analogy makes perfect sense. When you rent an apartment, your landlord (the provider) takes care of all the maintenance; you just live there and you get what you get. When you own a home, you take care of all of the maintenance, but you get to set the place up however you like. This isn’t that different from a lot of FOSS out there.


  • This misunderstands the premise. You cannot intuit someone’s subjective experience of reality because it is impossible for you to experience their experience of reality. You have only what they’re able to explain to you.

    To come at this from the other direction, if a friend says to you “I’m having a good day” and does not appear obviously distressed, how could you judge the relative goodness of their day or if it was actually good at all?



  • Getting repeatedly beaten in competitive multiplayer games is just kinda par for the course if you haven’t learned the meta, strategies, etc. If you lack game knowledge and your opponents have that game knowledge, you will mostly lose.

    If winning in the game is the only way you find enjoyment in them, then those kinds of games require significant investments of time and energy to “git good”.

    I say this as someone who is repeatedly shit on in every game of CoD I’ve ever played and will play in the future. That said, I don’t gain particular enjoyment from winning alone - not that it isn’t fun to win, just that I get just as much enjoyment from other aspects of the game.

    It sounds to me, mostly, that these games just don’t really appeal to your idea of what’s fun.




  • Put simply, yes. Without explicit help to those that have less now, future generations simply lack the means to access those opportunities.

    Take, for example, the situation ultimately presented in the article: if the person/people that are doling out the money have even a small amount of bias against a class of people, the result is that - outside of forcing investors to make what they see as bad investments - they will categorically invest less in that class of people. It doesn’t actually matter what class it is.

    These laws might prevent us from codifying our biases into contract or other law, but they do absolutely nothing to solve the problem the bias itself causes.


  • My (limited) understanding of ActivityPub is that it functions on a publish-subscribe model. If you and I both ran instances and federated with each other, every time a message was posted to my instance I’d send a message to you and vice-versa. Now, let’s say a new person comes along with their own instance and they want to federate with us, but they have 1000x more users than we do. If we federate with this new instance, we now both have to handle 1000x more traffic.

    This is effectively a Denial Of Service attack.

    Threads currently (supposedly) has 70 million users. If only 0.001% of those users are interacting with federated content every second, that’s still 1000 messages every second. Smaller instances are likely not configured or tuned to handle this level of traffic on top of their existing traffic.