Just the raw amount of data is not enough metrics to judge whether postgres is "enough".
They seem to value horizontal scalability e.g. in terms of write throughput, which is easier to handle with something like their solution compared to postgres.
297 karma · joined August 3, 2016
Usually you start small and grow bigger, so there is only rare exceptions where it makes sense to merge microservices back into a monolith, except maybe for cases where going for a microservice architecture was a bad decision taken without actually having the above mentioned problem.
However, in Germany, police is taught in a very different way than US: They are only allowed to use firearms as a last resort, and only to use it after non-lethal measures like the taser have been used beforehand.
They are also asked to only use it to wound, not to kill suspects. In contrast, US police is e.g. trained to shoot at the center of mass as they argue that anything else would be more difficult under stressful circumstances.
I see the situation itself as the problem (that fake reports can lead to it), but realistically, there is probably no way to avoid them compeletely, so just looking at the way how such interactions are going on from there on can make the difference as well.
There are many non-constitutional rights (such as this one) that are not everlasting and laws can also be adapted.
I really don't understand the value of your post as it sounds like speculation based on wrong preconditions.
I think the argument would be that the risk wasn't mitigated although it should've been known. There may be other known risks as well.
> [...] informatique (French), Informatik (German), informatica (Italian, Dutch), informática (Spanish, Portuguese), informatika (Slavic languages and Hungarian) or pliroforiki (πληροφορική, which means informatics) in Greek. Similar words have also been adopted in the UK (as in the School of Informatics of the University of Edinburgh). In the U.S., however, informatics is linked with applied computing, or computing in the context of another domain. [1]
[1] https://en.wikipedia.org/wiki/Computer_science#Etymology
True indeed.
> Are you saying that they're polling all the hijacked accounts at a high frequency to detect trades they could intercept?
Yes.
I have to admit, the "milliseconds before" part was just wrong because I failed when trying to oversimplify for attention.
> it's "a trade with foo (whom you've had as a friend for 20 days), where you give a xyzzy and receive a quux". Are the users just blindly approving trades worth thousands without even verifying?
Often, the attackers focus on swapping trade offers that are initiated from a 3rd party, e.g., a trusted middleman marketplace site that requests your item (with nothing in return) that you want to offer. 3rd party sites take a lot of blame for "stolen items" because people don't even understand how this scam works.
Here, the few seconds are between the 3rd party offering the trade and the compromised user accepting the trade, not between the user accepting the trade in the browser and on his phone. Since the phished user is not aware of the 3rd party site's account in the first place (it is not one of his friends), it is very easy to clone all the observed account details and transform a scam bot account into looking like it is the one from the 3rd party site. Actually, there are characteristics that cannot be spoofed, but an ordinary user, not even aware that he was phished and that someone has control over his account who can do such things, will not notice this.
Now, you could argue that preventing 3rd party sites from existing could also solve this issue. However, I see a valid use case in these 3rd party sites. The goal of my suggestion is to counter these attacks with minimal effort without disabling automated trading capabilities completely:
> A captcha would be just be minor irritation for the attacker, and anyone who can be phished into logging in can be phished to approve the key generation.
I agree that it would only make the attack harder, not impossible, but considering the usual workflow I still see this as an improvement - as a first step.
The phishing is usually done by setting up a "legit" website, e.g. for skin trading, skin gambling or even any other non-financial purpose that requires authentication via Steam. This "legit" website then spawns a malicious "Login with Steam" OpenID credentials popup, rendered inside (!) the web page. This means, the website itself draws (depending on your OS and browser) a perfectly fine looking Browser popup window inside the legit page. It basically spoofs the browser UI itself. Laypeople get fooled easily by this, they sometimes do not even question why the window cannot be dragged out of the page, if they even try. These web apps are built in top-tier quality because obviously, the profit potential is huge. There is probably even a framework sold to easily recreate such pages at this point.
What I'm trying to say is: Getting the user to login is easy because it's part of the legit workflow. The API key generation - not so much.
Basically, everything I'm asking for is to make it hard to automatically transform a normal user account into a bot account used to automate trade offers. I know that there is a valid use case for automated bot accounts and automated trade offers. But the automation of the action to enable such functionality for an account should be prevented at all cost, and it should be explicitly requested from the user, including a warning.
Probably you are saying something similar with that statement with which I agree:
> the bigger problem here is that the API keys are unscoped
TL;DR: I think that preventing automated Steam web API key generation is the best short-term solution considering effort to make the attack a lot harder for the scammers.
There is this so-called "Steam web API key scam" which is ongoing for years at this point: Scammers create phishing Steam login pages to grab people's credentials. Just with these credentials, the damage an attacker can do is still limited because of 2FA. However, the biggest flaw is that it is possible to automatically create API keys for the phished accounts that allow 24/7 remote access of these Steam accounts without the user even noticing. With this access, scammers then automatically modify and alter trades at will and at any time in the future, milliseconds before people confirm them using their mobile device (2FA), e.g., by declining the original trade and setting up a new trade with a scammer's bot account that has changed its profile data to the one of the actually intended trading partner.
This attack is mostly based on phishing, spoofing and confusion, but it could at least be made much harder by preventing automated API key generation and therefore indefinite access to an account (e.g., by implementing email confirmations or captchas for API key generation).
Each day lots of children or laypeople are losing in-game items worth thousands of dollars. I'm admin on a popular CS:GO and gaming Discord server with ~30k members and we see such reports multiple times a week.
Valve has no incentive to fix this as long as it's not their money or regulators start applying pressure.
It is currently unclear whether there is a publicly available PoC or any exploitation going on in the wild.
[1] https://twitter.com/AntiCheatPD/status/1380873722966503426
I think the main issue is the false marketing w.r.t. last-gen consoles. Hyping their product more than they could deliver seems to be the reason they are facing this backlash. But who could condemn them? Others are doing great with this strategy, see e.g. Tesla with their "Autopilot" (last-gen console are some older European roads here).
This is used e.g. to swap trade offers in realtime, i.e., a trade offer with the actual account is replaced by a trade offer with a bot with a similar looking profile (all set up automatically). All of this is done in the timeframe between the user setting up the trade offer and the actual 2FA mobile confirmation of this trade.
People are being phished like this for years and Valve fails to take the responsibility to implement a simple anti automation measure at the part of API key generation (e.g. email confirmation or captcha).
The monetary damage done to users is probably in the high thousands, if not millions, at this point in time.
But we also agreed that it's not the most important factor whether it's code, a graphical user interface or a command line interface to make a tool usable for a lay person. What's more important is that the entry point is easy, and that the complexity and flexibility is abstracted away in layers that do not have to be fully understood from the beginning, so that the learning curve is not too steep.
Of course, my first post was not meant to be criticism of the project, just some pseudo philosophical thoughts that crossed my mind when reading that sentence. Sorry for being too off topic with that. :)
I recently had a discussion about the requirements that a text file format (like YAML) has to fulfill to be considered "code". :)
They basically revoked this comment about capacity. The new reason is that mobile service providers don't offer this type of broadcast in Germany and that it's checked whether this can be implemented in the future.
Some 2019 streaming numbers from pre-Corona era which I found interesting at that time. Mixer declined in hours watched after summer of 2019. Also interesting to see that Facebook "Gaming"'s top games only feature mobile games. Being a gamer myself I therefore find it difficult to really view them as a serious competitor to the game streaming market of YouTube and Twitch. Maybe this will change with Mixer's user base.
I always thought the EU doesn't want this procedure because it effectively allows farmers to take a short cut and cover up bad practices used earlier in the chain. Under this premise, this quote just argues against a straw man for an otherwise meaningless counterargument.
Is it too much to assume that the government would try to figure out some rescue operations (whatever they may look like) to save Boeing financially in case that this is required? One reason for the trade dispute with the EU is Airbus.