Indeed this is an odd disclosure and I am not familiar with past posts by them.
Moreover, no CVE is associated with this claimed vulnerability. It's not even stated which Android version or automotive head-unit variant version is affected.
Wikipedia's source policy makes it nearly impossible to refer to anything that is not in the media, and any sensitive article has to use weasel words like this. Are you just noting the issue with the article, or actually doubting that Kaspersky Labs is a de-facto FSB branch since at least 2015?
Up until 2015 all was good with Kaspersky. But then in February of that year they posted a detailed writeup on malware created by the Equation Group, the NSA. [1] Within a month US media outlets, relying on anonymous sources, began posting endless claims that Kaspersky was a part of the Russian government. Over the next years Kaspersky opened a bunch of 'transparency centers' offering full code audits and inspection, relocated their core infrastructure and customer data to Switzerland - subsequently falling under their data regulations, and so on.
And if they were in any way affiliated with the Russian (or any) government, there seems no logical reason they'd publicly share their findings of the NSA malware, let alone the other transparency actions. Their data would be vastly more valuable if kept secret, because it'd open the door to greater exploitation of US cyber activities and being able to covertly secure desired systems. Instead their actions benefited everybody, but obviously embarrassed the NSA and as a result the US.
KL is a credible shop, they basically founded the modern anti-malware industry and pioneered most basic techniques in the 90's and early 2000's, together with some of their then-rivals like Dr. Web. There's a reason they were trusted, and there's a reason they tried to deny their takeover, they have a genuinely earned reputation.
This doesn't mean they aren't a FSB branch, in the same way e.g. NSO Group is a Mossad branch, with one difference that KL sell themselves as defensive and NSO Group doesn't. It was confirmed by KL employees in their socials that the management has been largely taken over by actual FSB officers. Some have left the company out of protest because they felt it's getting raided (отжим in Russia is not like your usual corporate takeover...). It's impossible to link it now as most of these people are living abroad since 2022 or earlier and either removed all their stuff or their socials entirely, some have renounced their citizenship by this point. But as a general rule, assume every important business in Russia is taken over by the government since 2022, either directly or indirectly. In 2026, whitewashing Kaspersky Labs of all companies is weird.
>But then in February of that year they posted a detailed writeup on malware created by the Equation Group, the NSA. [1] Within a month US media outlets, relying on anonymous sources, began posting endless claims that Kaspersky was a part of the Russian government
There was also a war happening, which you aren't saying.
>Over the next years Kaspersky opened a bunch of 'transparency centers' offering full code audits and inspection, relocated their core infrastructure and customer data to Switzerland - subsequently falling under their data regulations
The audits are to check the checkboxes, they mean very little. Plenty of former Russian companies that moved abroad are keeping ties with the developers at home, despite all audits, fronting campaigns, and otherwise pretending they aren't (not all though, others did actually migrate).
>if they were in any way affiliated with the Russian (or any) government
I mean, YK himself is KGB and there are no former ones, as they say. KL is one of the main government cybersec contractors, for starters. In a country where the government controls most of the economy they are producing critical industrial security systems like data diodes and secure gateways with their own OS, you can go to their site and look at all this yourself.
Cybersec industry in general is heavily affiliated with their respective governments, I don't think it's a secret for anyone and denying this is just silly. Some of them are more than others.
>there seems no logical reason they'd publicly share their findings of the NSA malware ... Their data would be vastly more valuable if kept secret, because it'd open the door to greater exploitation of US cyber activities and being able to covertly secure desired systems.
What? This doesn't make any sense, sorry. Security agencies usually publish or leak actions of their adversaries.
>Instead their actions benefited everybody
Did their inaction benefited anyone? RuNet which has been great got basically destroyed and turned into a safe haven for half of world's cybercriminals on their proud watch, and they aren't writing anything on this. They serve as part of their "roof".
Note I'm not saying they aren't doing good things, you're right, it's pretty good when the spooks keep each other and cybercriminals in check, see the article in OP, Apple's hardware backdoors (Operation Triangulation), and many other cases.
Kaspersky isn't just a credible lab. They were, and remain, the best antivirus provider, by their results on basically any and all test batteries. Similarly their founder (Eugen Kaspersky - I assume who you are referencing with "YK") has never worked for the KGB. He was educated at at a KGB affiliated school and afterwards went to work for the Ministry of Defense. Within a few years the USSR collapsed and he then went, and stayed, within the private sector.
But most importantly - companies (let alone other governments) providing detailed information on how other governments' cyber operations is most certainly not a thing that's done. That report I linked to is not just speaking in evidence free vagaries of the geopolitical 'leak' type you are alluding to. It provided extensive operational details and includes things such as even naming a specific driver as which is implied as being a Windows backdoor with plausible deniability.
They chose to publish it letting the NSA know exactly which methods had been discovered, how they were discovered, and even exact versions they detected and potentially on exactly which machines (if the NSA salts binaries), given that the hash/date info were also provided. All of this is immensely valuable information that could have been both weaponized and 'defensized' for Russian cyber purposes. Providing it helped the NSA more than anybody. Outside of Trumpian 5d chess, there's no rational explanation for this, if one assumes they are in any meaningful way controlled by the Russian government.
The article is about a controversy involving allegations. There is plenty of evidence presented that the controversy and the allegations exist. (And if you dig into the links, there is plenty of evidence that the allegations are not without basis.)
Using web apps on Firefox really is the way given its support for uBlock Origin.
Screen real estate is precious on phones, so being able to permanently block "Install our app!" and even entire navigation categories (shorts on LinkedIn) is quite valuable.
Then you can "install" the site on your home screen or simply place it in collection folders so it's sitting ready on your "New Tab" page.
Firefox the privacy browser that is directly selling all its users searches to Google for decades? Not to mention all its other build in telemetry and ads.
If you want an actual private Firefox Browser use a fork like Mullvad Browser, LibreWolf and Tor Browser.
Mozilla with Firefox does not sell and does not have ads. You have downloaded a modified spyware version or have convonced yourself that this is true due to a bad dream. Take more care online is my advice yo you and don't spread false information either.
> December's headline feature was teaching the planner to push a whole correlated EXISTS subquery down as a single LEFT SEMI JOIN instead of a nested loop with one ClickHouse round trip per outer row. This moved the needle from 3 of 22 TPC-H queries all the way to 12.
LLMs sure love throwing in archaic expressions such as "move the needle". The abrupt contrast in jargons is so unpleasant and keeps throwing me off right in the middle of reading.
Yeah. There's some solid work in there, but it reads like an LLM without a review pass.
This paragraph has an awkward rhythm:
> Getting more into the nitty-gritty, we also closed a subsecond-precision loss when inserting timestamps over HTTP (#300), and to top it all off, a broader static-analysis pass over the codebase turned up and fixed a handful of other latent bugs (#313); these hadn't showed up in the field, but were worth closing before they could.
Even just asking Claude to apply Strunk and White makes it much easier to read:
> We also fixed a loss of subsecond precision in timestamps inserted over HTTP (#300). A static-analysis pass over the codebase turned up several other latent bugs (#313); none had surfaced in the field, but we fixed them anyway.
And its diagnosis of why the original is tricky shows an LLM is more than capable of improving readability given a couple of review passes:
> Three things make it awkward, and they pile up:
> 1. Two bits of throat-clearing. "Getting more into the nitty-gritty" and "to top it all off" both just say here comes the next thing. Neither tells you anything. Back to back, they read as filler.
> 2. Mixed tone. "Nitty-gritty" and "to top it all off" are chatty; "subsecond-precision loss" and "static-analysis pass" are dry and technical. The sentence keeps switching voice.
> 3. Too much in one sentence. Two unrelated fixes joined by a semicolon, plus a clause hanging off the second one, plus the trailing "before they could." By the end, you've lost track of what "they could" was about — the thing it points back to is thirty words behind you.
It's a shame when solid technical work gets obscured by the poor SNR of default LLM output, when clarity is only a few iterations away.
It's a weird feeling, having my prose reviewed as if they were written by a machine. "Move the needle" is a scar from my time at Google. Nitty-gritty is an artefact of all the iteration I did on that paragraph; the original was far too technical to justify its place in a little writeup. "To top it all off" was just how I chose to set a tone of wrapping up after a list that was at least as exhausting to write as it seems to be to read. And just for the record, multiple people from my team reviewed this, so if it turns out we lack your proclivity for good English style or your journalistic rigor and standards for what's ready to publish, it wasn't for a lack of "a few iterations." I suppose it would have been good of me to give my team more time with the draft; a good chunk of what you cited was a byproduct of me hastily responding to their comments.
> Instead of one row per item with a quantity column, we use one row per sellable unit. An item with 10 units has 10 rows.
> But one row per unit for all inventory would break down at scale—an item with 50,000 units across 10 locations would mean 500,000 rows, and the reserve query would slow as it scans through them. Instead, we maintain a bounded pool of available rows, capped at 1,000 per item/location combination. Reservations consume rows from this pool; a replenishment process refills it from the inventory ledger.
Shouldn't I feel uncomfortable with such approach? It seems to create a backoff (pool) for lowering the chance of having a synchronization issue.
I agree, it does seem awfully complicated and there are quite a few pieces missing for this to be a complete solution.
I'm a bit surprised about the scalability case against a simpler solution. This is not about Shopify's scale. We're talking about contention for a specific SKU of a specific seller at a specific warehouse location.
How many shopping carts are competing for a single SKU at the payment stage at peak hours? Can this really be too much lock contention for a single database row?
I realise Shopify engineers are neither stupid nor inexperienced. Hence my surprise. I would have liked to hear more about that specific problem.
> Can this really be too much lock contention for a single database row?
When you consider how many other (often poorly-crafted) DB queries and service calls are being performed while holding the row locked, yes, it can rapidly add up. If the entire pipeline takes 500 msec, congratulations, you can’t sell more than 2 units per second of that SKU. If the item is popular and being actively hyped, then yes, that can be a problem.
Flash sales are a huge scaling issue for Shopify. There are celebrities who want to sell thousands of items in a few minutes window at the end of an advertised countdown.
Basically this is an incredibly rare case but a feature that they want to support.
We observe 200+ (can’t say closer number) purchases per second for single SKU with good marketing and price.
The other thing that bothers me - why not real stable, but maybe „too old, medieval” solution with Redis as the main source of through - without any sync with SQL at all in terms of stock… it worked in my previous job with much higher traffic (1000s/s). Yup, we ended up with app-side sharding, but it was stupid-simple.
Comes down to type of items, when you have physical inventory the number is limited so more manageable and interestingly enough the problem only applies to physical inventory.
You are just spending some more disk space to avoid synchronization issues. Denormalization for performance is a really common pattern, just that people do not start with it in the first place itself
I would call this one-row-per-contract-type, and this is the most general model for the problem (e.g. the model cannot be further broken down into finer level), thus, the most scalable model given storage is dirt cheap.
Yeah, I'd be uncomfortable with that approach. One of their key design goals was to minimize underselling, recognizing that it results in lost revenue. But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that error out before the replenishment process succeeds?
I'm skeptical of this approach. Sure, row contention means that you cannot have a database transaction per customer order attempting to decrease inventory count by 1 each time. But you can have a batch transaction whereby the transaction decreases inventory by 100 (thus touching the high-contention inventory row once) and credits each of 100 different customer cart database rows (which are not under heavy contention and can be on a different disk entirely). Attempted customer orders are submitted to a reservation system put in charge of assembling the batches. Customers wait some short period of time - say, 15 seconds - for the reservation attempt to be batched and to be notified that they successfully locked a reservation. Arguing that "slow reservations trigger throttling and a worse buyer experience", without an actual number for what counts as "slow" to serve as an SLO and as a design target, is a cop-out inviting over-engineering.
> But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that error out before the replenishment process succeeds?
They explicitly cover this in the article, saying they do reservation inline. It does increase latency for these orders, but it doesn’t result in an error
> But you can have a batch transaction whereby the transaction decreases inventory by 100 (thus touching the high-contention inventory row once) and credits each of 100 different customer cart database rows (which are not under heavy contention and can be on a different disk entirely).
They mention this as well, checkout batching increased implementation complexity.
> Arguing that "slow reservations trigger throttling and a worse buyer experience", without an actual number for what counts as "slow" to serve as an SLO and as a design target, is a cop-out inviting over-engineering.
True. The article would’ve been better if they included such numbers. However the fact that they didn’t mention this doesn’t imply they haven’t done research. I haven’t found anything related to checkout specifically, however there are in general articles, indicating that increased latency correlates with revenue drop.
The problem is that in this case you have to do splits/merges. And while there are products that are sold by 100 units at a time, I think in most cases people by 1-2 items so the hassle might be not worth it.
Also you might not understand the original problem. Imagine if 100 customers want to buy product A. One thread starts a transaction, searches for amount of product A and UPDATE's it and goes searching for other products. The database locks the row until the end of transaction and other 99 treads cannot continue until first transaction commits (they can read but cannot update the rows).
This is why they made a row per item. In this case, transaction 1 hopefully locks only several rows with items of product A. Transaction 2 instead of waiting for lock release skips them (due to SKIP LOCK) and locks several next rows. And so on.
Obviously you do not need to make a row per item - if the available amount is really large (10 000 items), you could have for example 100 rows having 100 items each. In this case each transaction locks the whole row (100 items) even if it wants to reserve just one item. The problem though is that now every row might have different amount of available items and you have to do more work to reserve the amount you want.
ok, lets model situation of 100 customers and one last remaining item. Who will get the last item?
in shopify's design, it is a user who was the first to lock the row and have successful payment. Sounds good, but how often does it happen ? It's a rare and extreme case and they model their entire system after the rare even, and incur the overhead of 1000 rows per SKU per shop for all combination of SKU and shop_id for all the normal items that are not sold out in flash sale.
the same outcome could be achieved without locking and without creating 1000 rows:
1. keep track of all active carts at the checkout in a table
2. for each cart, record the timestamp in nanoseconds when user clicked Pay (but I would prefer timestamp of clicking Checkout)
3. that timestamp will decide who gets the last available item.
4. in a shopping cart, have explicit field for each SKU: inventory_reserved.
5. this decision mechanism is now explicit via global monotonic non-decreasing counter. It is no longer tied to payment processing gateway timeouts, not opaque and implicit mechanism relying on database internals and quirks of how DB engine locks and releases some placeholder rows.
On a large scale "rare" events happen every day. That is why people use locks and transactions or other measures.
In case with shopify, they want to decide whether the user may place order or not, at the moment when the user clicks "Pay" or some other button. If the user cannot place an order, they are shown the error, if they can, the items are reserved and the user is redirected to the payment page. So payment is processed only after successful reservation, and reservation is made only if the user wants to pay. The similar system works for buying train tickets online in my country, for example.
In you case, when user A clicks a button, following happens (as I understand):
1 the server increments the counter
2 the server calculates available amount as (amount_in_stock - amount reserved by carts with time < counter)
3 if the amount is large enough, the server updates the "time" field for user's cart thus reserving the item
Imagine that at step 2 the user A sees that there is one item left. However before user A does step 3, another user B might reserve the item (complete all 3 steps), and proceed to the payment. Then user A then completes step 3 and proceeds to the payment too. Now we end up with both user A and B paying for the last remaining item which doesn't solve the stated problem. Shopify's solution doesn't have such issues.
This is a classical TOCTTOU situation. There were exploits against Linux kernel based on similar issues.
shopify is wrapping their entire dance with locking and moving rows inside a transaction. if you wrap step 1-3 inside transaction you will get same atomicity guarantee
but again, my idea was:
1) do not use throwaway placeholder rows to imitate a single item
2) do not rely on db engine to decide which transaction gets committed first (which customer gets the last item)
3) model queue explicitly by introducing counter field that sorts and prioritizes customers' orders and decides which order gets fulfilled and which customers gets the last item
Can you explain how that works? With the row-per-item I can see how you’d use locking primitives etc easily to deal with multiple concurrent shopping carts claiming available inventory.. but how does your solution solve contention? There’d need to be some “number of items in inventory” row, wouldn’t there be contention on that?
The point of one row per item is that thousands of concurrent shoppers don’t need to block each other as they can each claim as many free rows as they need for themselves?
One other advantage is item serial numbers. Or something else that makes an item that seems the same but actually be unique (perhaps the warehouse it’s in?)
"Number of locations" is an input so if the system has been designed to handle up to 10, and not 100, then yes I would absolutely expect it to fail with the higher value.
Developers (and everyone else really) need to think about systems, with the system taking inputs like "number of locations", and producing outputs like "available inventory", and when the input parameters change outside of the designed scope, without the system itself changing, then you should expect things to break.
Very nice. Can you elaborate why you chose mTLS authentication vs. SSH as a mean to deploy the policies.
Regarding the docs, the diagrams should really be replaced with something more familiar and readable such as Mermaid (currently it looks like a mixture of ad-hoc ASCII charts).
The general documentation is something that definitely needs a lot of improvement, but it's currently under active development.
Policies are delivered over a persistent gRPC stream, secured with mTLS, where each node gets it's own cert from Bor's built-in CA at enrollment - so there's no SSH key sprawl and no credentials on the server that could log into machines. Since agents connect outbound to the server, it works through NAT and firewalls without opening any inbound ports on desktops, and policy changes propagate in seconds over the already-open stream. SHH-push would have meant maintaining an inventory of searchable hosts and a server that can shell into the whole fleet - a much bigger attach surface for less capability.
I don't have the app and I use reddit (although not often) via my mobile browser (firefox) and it never forced me to download the app, as far as I recall.
I encountered that blocker today, so I decided to try Safari's Hide Distracting Items (1) feature, which blocked it once and for all, which I was pretty impressed by.
It does it occasionally to me (Safari on iOS). When it happens, I just close the page. I hope this is enough of a signal to make someone think.
I land on Reddit every couple of days or so, and if they don’t kick me I read the thread and sometimes browse a bit a couple of subreddits I used to participate in.
I am curious which of these places still exist today, as some menus depict the building. It would've be nice to have additional historical information.
Moreover, no CVE is associated with this claimed vulnerability. It's not even stated which Android version or automotive head-unit variant version is affected.