Posts by doublelayer 11428 publicly visible posts • joined 22 Feb 2018
It wouldn't make a difference. They're not attacking resolution of a domain. They're attacking the multiple servers serving that domain, including some targeted subdomains. The solution is more servers, and you could easily have those serving one domain anyway, but more servers is expensive and Canonical wants to be efficient.
"Disagree with framing it as a choice though, given all the research done into habituation effects"
I think it's valid given how many trainings I've seen or, in one case, written telling people to do it. We can and should improve the processes, but people not doing what they were told aren't going to magically start doing so when the information they're supposed to read is buried in a bunch of text they get used to scrolling past. We should make it easier for people to get the information, but we will still need them to take that extra bit of effort to check.
Some of the suggestions for sending warnings are good, and I've seen a few of them implemented. Many servers now tag any address outside the organization which makes impersonation attacks harder. Some warn about links or attachments. I expect these to have made some improvements, and we can probably target them more. These are worth adding and will probably have more effect than plain text will.
I doubt it in both cases. It's quite easy to see the from address in pretty much every email client. People who don't choose to look at it can ignore it just as well when it's in the longish blob of server logs they don't understand as when it's the only thing in the from box.
As for URLs, people can easily see the URLs and we show them how. I'd agree with you if I thought the tiny extra step to view that information was the problem, but all the evidence I've seen suggests it's really not. For example, on the most recent phishing message I had to clean up from, the senders included a shortened URL* but, I suppose in case someone reported it which is what I did, they also included the destination URL in plain text which went to [random letters].digital/[more random letters]. Neither of these struck the user as suspicious and they cheerfully loaded the site. Seeing where they were going was not enough to stop them in that case, and those who pay enough attention to that to check the URL can also remember to hover over a link to see it.
* One other downside with making mail plain text is the boost to shortened URLs it's going to cause. Many sites are set up such that they have very long URLs. Pasting such things into mails when they'll wrap onto multiple lines will be ugly, so people are going to shorten them so it's less so. Some will make their own link shortener which still indicates where they're going, but many will not be competent enough to do this and will use whatever shows up first in the search results. When everyone does that, it will be a lot more annoying to find out where the average URL goes because, instead of hovering over the link, you have to figure out how to expand the short URL from whichever service was popular this week.
You're building an argument by considering only one definition, among the multiple ones in common use, for the word "compensation". This is not a way to build any useful argument. Even if you think you're correct, which you're still not, substitute "payment" for "compensation" in their comment and read again because everyone else knows what they were saying, and you do too. Arguing against something they didn't mean doesn't convince us they're wrong.
The definitions aren't permanently set in stone. They can change. The advantages of having one that covers most of this is that you can better communicate about what you find, and that applies equally well to the Arctic residents reporting back about what they found near the equator. If they have to later adjust a rule about motion to clarify that carnivorous plants that have some limited motion are still plants, that's a far less confusing change to make than if one person is writing about plants and the other animals but they're talking about the same thing because they haven't defined them enough that they agree which is which.
I'm afraid you're once again mistaken about how this worked and appear to have decided based on a preference what the law says and whether it's justified. We'll start with the simple problem. The money for publishers does not go through the Australian government. The law specifically asks social media to make direct deals to pay money from them directly to publishers, punishing them with a tax if and only if they do not do so. With that structure, which was present in the earlier law and remains so here, the claims of "hypothecation" (I don't think that's a word) do not apply.
And since it's structured that way, you are not correct that this does anything about or is intended to do anything about tax avoidance. In my opinion, this is also an inappropriate way to deal with avoided tax. If companies are breaking tax laws, investigate and punish them. If they are following tax law and paying less tax than you think they should, fix the tax law. If you specifically tax companies only in a certain, narrow and poorly-defined industry and leave them a loophole if they sign up to a deal with another company, you have made the tax avoidance problem worse by introducing yet another easily gamed system instead of doing the proper job and defining the tax properly. Do that enough and I start to lose sympathy for the claims of avoiding tax when politicians had the opportunity to fix that and chose not to bother.
No, it isn't. If that was it, they'd keep the tax. They said the payments were earmarked for media as compensation for the copyright abuses, and they actually did direct payments that way. Even with this one, they're still letting companies opt out of the tax by paying media. This is not about taxation, and they don't claim it is. It is about redirecting funds from social media to news organizations, just as they claim, except they are no longer using the copyright abuses story because last time, Facebook actually stopped them instead of paying and they would have preferred the abuses continued.
The Australian government considered this a bad thing because they didn't want social media to follow the law they wrote. They wanted to pass the law they now appear to have done, one that boils down to "We're taking money from you because we don't like you [for the avoidance of doubt, I don't like social media companies either], and we're giving it to them because we like them". Facebook refusing to publish news was theoretically one of the options the law gave them, but it was an option legislators really didn't want because it didn't help the media companies, in fact the removal of links probably was a mild downside for them. That's why the results of the laws in Australia and Canada, though they're exactly what the politicians wrote the law to do, are not ones those politicians are pleased with.
That was the story last time. It is a real problem, but instead of solving that by putting restrictions on how much of an article social media companies could copy, Australia's and Canada's laws went far further by requiring them to not even link to news publishers unless they paid, and Facebook chose the "no quoting or linking to covered organizations" option. Once that happened, the harms you're describing were removed, along with plenty of helpful links, and therefore no longer work as justifications for new laws. The problem faced by both countries was that the thing they enacted wasn't what they actually wanted.
I think it's somewhere between the two options. Most LLMs are not trying to do that, and some parts of the process should be very easy, but neither is it as simple as you describe. Even checking the existence of a reference requires figuring out wherever they've stored the paper and whether you can easily just go read it. Do you need a membership to some journal or library which has a copy? Did you not have that but email for a PDF? Was it available to the public but someone reorganized the web server and you don't have a working link anymore? Normal LLMs don't have magic access to those things, even when someone did shovel a copy into the training data.
Checking that the reference says what you say it does is harder. It's less hard when someone's doing the paper correctly; they figured out what the paper did when they cited it the first time and wrote their summary or expansion after reading it. When an LLM does it, it's made a probabilistic guess, and that means one problem for anyone, human or LLM reviewing it and a bonus one for the LLM. The one that applies to everyone is that they now have to read the whole paper, or at least the complete relevant section, to know all the things it said. Finding a paragraph that seems to be in line with the information from the paper is no good if it's preceded by the sentence "We did notice one anomaly with 2% of the input data". If this paper is the kind written by someone who thinks, or whose employer/advisor/reviewer thinks, that long words and jargon makes the paper look more impressive, that process takes even longer. With an LLM checking, you end up making two probabilistic guesses which can both be wrong, allowing an invalid citation to persist, or only one of them is wrong, in which case it's difficult to fix the paper without having started the right way and including citations for a reason.
It is. They call it "human in the loop". The way it works is that someone gets the job of reviewing everything the LLM wants to do. Doing this correctly would, in most cases, take about as long as doing it manually, but skimming three paragraphs and clicking approve on each of them takes much less time so that's about as fast as the human will be expected to go. When it finally goes wrong, not only do you have your scapegoat who was supposed to prevent the problem but didn't, you have permission to treat that person in any way you like. Bonus, to anyone not entirely convinced that LLMs are the best, you look cautious because you're not accepting their output without reading it.
So far, it's usually the AI fans who get to decide who has to be and what happens to the human in the loop.
It would be very difficult to get anything like that because there's no defined set of functionality from model to model. That's the whole point; you can ask it to do literally anything and it will parse your request, run something, and give you a result that might have done what you wanted or might have destroyed anything it had access to. You can't standardize the inputs to that when the inputs are theoretically unlimited, and you can't restrict the outputs when nobody's found ways to keep them from going wrong on simple prompts every time, just most of the time.
Maybe, but that's also a relatively common thing for humans to say, which is one reason LLMs picked it up, and most of the times I've seen it from an LLM, it was used as an intensifier rather than a contradiction like this is. Perhaps we should stop ourselves from taking something as simple as "not just" and jumping to conclusions like bad models do.
"I don't know why governmental distros are not a thing."
Because most of the work required to run a distro isn't different for a government, so why should they, and if they change it too much, it's not useful for anyone else so they end up with the maintenance burden alone. What you'd end up with is either something almost the same as another distro or something so different that it gets out of date. The more users a distro has, the more people the cost of maintenance is spread between, and there's usually nothing secret in them so that sharing works fine between governments, businesses, individuals, and other organizations.
"what fraction of global software doesn't see external users?"
Not only is there a ton of internal code running every company and industry, but even if we don't consider any of that, we have a definitional question, namely when we speak of X% of code, how can we count that? Do we count by lines (impossible for commercial software where source is not public)? Do we count by users (unavailable for many commercial and open source things that don't collect or at least don't report that value)? Do we count by projects, in which case you're going to get far more open source by counting every similar GitHub fork than one product.
The creators of that report have not obtained copies of every commercial piece of software and run tools against it to find open source components. They're using vague numbers based on cursory searches. That isn't a problem as it's true that most of that software does include open source components, but to put a number on it, they'd have to have better answers and more thorough methods than they have. From a user's perspective, it also doesn't matter, because a bunch of programs that are all proprietary but use the same open source compiler would easily count as having an open source component but don't result in any more open source code for the public, and I think that's the perspective that started this thread.
That report, and the sources behind it, have poor sourcing for the statistics they provide and those statistics don't represent the claim from the article. When they say that 96% of commercial code includes open source components, they have no way of knowing how many code bases exist and would almost certainly fail to consider many of those that don't include open source components because they couldn't know about them. Not that the number is wrong. While it's probably lower than that, it's still going to be a very large percentage because libraries and dev tools are the most likely things to be open with many companies releasing or contributing to those. That's because those things aren't the thing those companies are selling. The product code that they make their money from is far less likely to be open source.
"I doubt that's the case for many banks."
You doubt, or you have any reason whatsoever to think your approaches actually get implemented? The code that would implement them is sent to your browser before you log in, can you find me a single example of a page that does that? One reason you'll have trouble finding that is that the approaches you recommend don't do what you think they do:
"a bank can certainly hash the password on the user's end of the internet": In this case, anyone who has the hashes can log into any account, defeating the original purpose of the hashes which required them to be individually broken.
"and/or send down a bespoke public key for the submission.": Anyone intercepting that communication could replace it with their public key. In effect, that's what TLS does already, and the discussion was partially about what happens if TLS is defeated.
You are mistaken. The hash is computed on the destination, not the source. One reason is that, if the hashes from the destination were compromised, computing them on the source means an attacker can instantly log into every account by sending the pre-stored hashes. The transmit password, compute hash on destination flow is what is done in almost all flows, from HTTP logins to SSH, and you can verify this very easily by looking at the traffic sent and watching the cleartext password zoom by.
Encryption on that channel means this is often not a big problem, but that and machine authentication of the destination are the advantages of passkeys. Only by knowing the real differences between the methods can you decide whether you think one is better. If you assume that passwords do something they don't, you'll have an incorrect basis for comparison.
Ah, I see what's happening here. This is a test to see how much a relatively unimportant comment board can stress out people who know what they're doing. We appear to have quite a few people who don't understand what hashing passwords protects you from (recovery of the passwords from the data on the remote service) and what it doesn't (retrieval and replay of the passwords from the ephemeral communication between an authorized user and the remote service) and that there are places that don't hash passwords even though they definitely need to, and all on a place where the readers are generally expected to be knowledgeable about IT. This is one of the main reasons we have security problems: smug people who think "hash" is a magic word meaning nothing bad can happen with passwords if you use it making the same mistakes over and over, whether about passwords or something else. If you don't care about this, that might be sufficient justification, but if you think hashing the password means it can't be seen during communication, then you are wrong and you will be wrong until you learn how it works.
You know you can generate passkeys yourself, no corporation involved? A service can choose not to support them the same way they can choose not to support any passkeys at all, but the structure does not require any third party at all, let alone whichever corporation you think is mandated. There are a lot of annoyances with passkeys, but there are a ton of people here who seem to think they're something completely different than they actually are.
How do you think passwords are verified? The hash is what is stored at the remote end, if they're doing it right. Even then, we frequently find that services store passwords in plain text or encrypted but not hashed, you know, services with only a few users and no technical staff like Facebook. But how does the service verify the password when you log in? It still involves the user sending a string for verification on the remote system. Encryption in transit makes interception harder, but not impossible. I'm holding out hope that I'm misunderstanding what you're saying, but it's looking like one of those people who heard about hashing passwords and doesn't know how that works and what it does.
A passkey can be synced with equal ease as a password and doesn't require any specific service. They are long enough that, unlike most passwords, you are unlikely to be able to memorize them. If you're using a password manager already and relying on passwords you don't have memorized, you are no more independent with your approach than you would be using passkeys.
Because a password gets transmitted to the service you're logging into. Anyone who can intercept it has the password too. The external service also frequently receives the plain password and you are relying on them to throw it away every time when they no longer need it. A passkey is a cryptographic key where the secret part you have does not get transmitted, so neither an intercept nor the external service ever sees the bytes you have which allow access.
Consider that part of the problem might be local effectiveness. If one company has not experienced any incidents, they may not be too worried about someone else that has unless someone comes along to scare them. Corporate leadership don't tend to spend much time reading about security incidents that happened to someone else, especially when compared to IT people who read IT news, so they no little about those incidents, and if they do, they probably assume there's a reason why those companies were attacked and their one wasn't, a reason other than scale and luck. Security teams usually don't think they need to bring scare stories to management because they have the same context as you do and assume management is aware of that. In my experience, it's also seen as unethical to exaggerate threats or speculate about what an attack on this company might look like, the approaches most likely to increase support for adding resources to security.
I had the same theory. CircuitPython would make sense for that. In my experience, it can sometimes reboot itself a couple times on connection which rapidly disconnects and reconnects that drive. The interface code tends not to care about this too much, though if it's a serial connection there's more work to handle it than if it's sending HID events. The OS that is trying to mount and unmount things often likes it less.
I think a lot of network admins, at least many I've met, don't care, especially on a guest network. As long as you're not attacking their infrastructure and not degrading their network, a lot of them are content to ignore you. Security cares more when someone does it from the non-guest networks because they have to tell whether it's malware or not, so they're more likely to stop such activity, but usually more to eliminate the possibility of risk than because they consider it a problem worth caring about.
I've occasionally needed to VPN out of my company's network, albeit into other company or partner networks. You could detect which VPN I've connected to and identify whether it's a trusted one relatively easily, but it's more complex than all VPNs being unexpected.
In hindsight I'm sure he's asking the same question. That's why it's relevant to consider the approach, what was done to put him at his ease, and how to be more wary if it happened to you.
There's a lot of friction with VMs. It's not a simple or fast process to spin one up with all the tools you need and keep it around. You have the choice of taking a few hours to install and configure the software you already have on the base machine inside the VM or keeping gigabytes of VM disk images around for next time, the latter more annoying on a laptop and a Mac where upgrading internal storage is difficult or impossible. If you do it lots of times, you may have base images that speed up some of this, but it's still an annoying process that even those knowledgeable don't frequently do unless they think they need to. That doesn't lessen the need for doing it, but I hope we can be honest with ourselves about how often we incur this pain; do you go through this every time you run any open source code?
The benefit of a story like this is as a reminder that preparing a VM for situations like this could be useful and as a warning about how far scammers can be willing to go. Neither the article nor the victim claimed this was impossible to prevent or detect.
The UK already taxes that. This is a special tax for tech companies above existing ones for any international company operating in the UK. It mostly exists because those large tech companies have a lot of accountants and lawyers specializing in finding every way to legally not pay tax, and possibly some illegal ones but it has not been proven. They have an easier time of that because many of their products are intangible, which makes it easier to define value in ways that mean they're not taxable in the UK.
I still think this tax is a blunt tool which doesn't really fix the problem. The inclusion criteria are too arbitrary and basically just names a couple large companies as the only ones covered, making it quite easy to slip out of this tax for everyone else. It seems that the better approach, identifying the loopholes that are successfully used to avoid taxes but shouldn't be and then removing them, is too much work for politicians. The blanket tax also has international trade problems since it is specifically targeting specific companies from one country, which when others do it is considered a violation of trade treaties. With the US, that's not a major problem as they have already violated every trade treaty in existence so can't hope to get remedies in the WTO when they've broken the rules far more actively and substantially.
Not quite, so far only the first method, the most theoretically powerful one, was ruled illegal. He has a whole catalog of other ways he thinks he's allowed to set tariffs, the second of which is currently in place. That is why there are still tariffs on current trade with the U.S. even as they're trying to figure out what to do about the last round of illegal ones and why there are more court proceedings about attempt number 2, and if those are struck down then they'll move on to law number 3 that looks like it gives some power over this.
The sales promises add credence to this possibility. They can't tell us what can actually be done over an HDMI cable, but they can promise that their device blocks all the threats. Given the complexity of HDMI as an interface, I can believe that there are problems in HDMI stacks which could be exploited, and if you knew about them, then a device that looks for them and blocks them would guard against those threats although one that looks for them and sounds an alarm would be more useful. But that wouldn't be threat-agnostic unless it simply blocked some channels, and those channels presumably have a point or you could block them yourself. Maybe it's as simple as disconnecting some things that they assume people buying this, who are probably using monitors in an office environment, probably aren't using, assuming that those pathways could be abused somehow.
It sounds like they've got a Mac in dark mode but want Thunderbird to be an exception without changing everything. I'm not sure whether that's possible to configure. While in principle there's no reason you shouldn't have that desire and it could be implemented with a follow-system/light/dark setting, they're still taking the complaining too far.
Well, I got a surprise today. I wouldn't have thought you would support this or express any of the very bad arguments you've just used. You'd think that someone who covers open source and participates actively in the comments section here where people use pseudonyms almost all the time would understand how many people do not want everything they've ever said tied permanently to their identity and how there are websites that benefit from having comments.
This is useful background, but I'm still a bit lost on what the solution is supposed to be. When they stop building an XFCE-based version, then those extensions will be orphaned anyway. The only way to continue work is to start building on the source, and it seems that most of these have the source publicly available, meaning anyone who wants, including those who previously built them with Zorin, is free to do so. They can also form an organization to manage this, but since Zorin's dropping the entire version, they're probably not going to take a leading role.
It sounds like your desired solution is for Zorin to keep building that version and put more effort into it by simultaneously building a project with everyone else. There's a reason they are dropping that and it's probably not because they hate XFCE supporters, which suggests they don't have the willingness and possibly not the reasonable ability to accelerate their XFCE efforts.
One possibility is that a new user thought it would be good to switch to Linux, went to conversations like this one to decide which distro to pick, grew immediately disheartened, and went with the names they heard most frequently which does include Mint and doesn't include CachyOS. a generally more positive outcome to the usual one, they grew disheartened and put Linux off to next time they've got lots of free time.
The new user reads a comment like this one and has no idea what the problem with Canonical is and why; if it's bad, why so many other distros build around it; what is better about Arch; why, if Arch is so good they should use CachyOS instead of Arch; in short every point you tried to make would have sailed over their heads. A number of them sailed over the heads of people who have used Linux for a while; I've used Arch and Ubuntu and variants of both and I'd still have to guess what specific problems and advantages you care about. So when you ask why people don't do what you recommend, maybe this is a point where you can start the introspection.
"I would like to see, say, Mint and Zorin both donate their tools and customisations of Xfce to Linux Lite, which could then continue to make them available."
Do they have a lot of internal tools they haven't released? If not, couldn't anyone take their code already to do that? It might be useful for those who wrote it to make an easier transition process or even go over there to keep working on it, but you write as if there's a copyright issue or the code's not available.
Your response makes no sense. Of course we aren't talking about secondhand refurbs; that's why neither of us mentioned it. Why did you bring it up now? Everyone buys a computer for specs at some level which is why those cheap Chromebooks aren't on every desk. Someone needs enough specs to do their job. If a low-end machine like the Neo is enough specs for you, then buy it, but don't pretend it's comparable to something with far higher ones when making comparisons of value because if you didn't need more, you wouldn't be considering the 13 Pro, and if you did need more, the Neo wouldn't be sufficient and would not be your alternative. Even with Framework, there are cheaper models with performance closer to the Neo, so you are deliberately picking two very different machines and the comparison will never be valid.
Your point that Framework customers are ideologically motivated is basically true, but it makes any cost comparison less important, which is where you started. You've used a bad comparison and now deny the usefulness of your own comparison. As I stated above, if you truly wanted to compare costs, you could have easily done so with a comparable Mac with the M4 or the M5 for the higher CPU tiers or a machine sold with Windows or Linux which uses exactly the same CPU. That would have been valid, and people deciding how much repairability is worth to them would be able to use that.
That's true, the prices are very different. Also, the base config you're talking about has twice the RAM that any Neo can have, a CPU (Ultra 5 325) that's much faster than the A18 Pro chip running the Neo*, a display with a higher resolution (256 vs 219 PPI), and a touchscreen. Frameworks, all of them, are expensive, and as long as you search for a while, you can find machines from manufacturers with the same specs as a Framework for less. By comparing it to something much different, you have failed to make that very easy point, because using the same logic, I can proclaim that the Neo is ridiculous and let me introduce you to the real bargain of the decade: this landfill Chromebook which costs £99 and you really don't want to learn how that happened.
* The Ultra 5 325 benchmarks 80% higher than the Neo on multi-core. Perhaps you don't need that, but that doesn't make the price less justifiable, it makes you a less likely customer. The Mac with the most similar CPU performance-wise is the 8-core M4. Machines containing that are not as expensive as the Framework but a lot closer to that level than the Neo is.
Fair enough on the display. I'm not sure what you need, but if the thing they have isn't good enough, there are no other options so that's a good reason not to buy it.
For Thunderbolt, the 16-inch laptop does have two Thunderbolt 3 capable ports (USB 4, which is based on TB 3). It doesn't have Thundderbolt 4 support because AMD processors don't, so no laptop with an AMD CPU offers that. I do wonder what you have that Thunderbolt 3 isn't sufficient for.
Some people want to use their laptops for quite a long time but get annoyed when a single failed part means it's uneconomical to do so. This is the computer that makes it easy to deal with that. That said, with the number of complaints you have about every single piece of hardware, I have no idea what you think is normal and must assume you just like complaining about things.
"I wonder when we're just going to accept humans are not secure and built the system around that?"
Probably as soon as one of the people who say things like this explains how you can do that. The suggestion, if interpreted literally, means that you build a computer such that a person, no matter how stupid, cannot possibly do anything dangerous but can still do the things they need done. A person with a little experience of basically anything will notice this as the way that nothing works.
We can implement layer after layer of safeguards. We can make it possible for admins to limit what users can execute. We can implement detailed authentication mechanisms where everyone logs in to a separate account with multiple factors and the accounts are limited very specifically to the activities they are granted. None of that helps if the people who are supposed to set those requirements deliberately choose to not configure the former and create one account with all privileges within the latter. They still sometimes choose to do this because properly setting very granular roles for a user takes more time and causes delays when a user first finds another one they need but don't have, so the insecure option is the easier and faster one. If you can do it better, please do so. If you can tell us how to do it better, I'm eager to hear, but expect that I'm going to question the approach heavily because most suggestions along this line I've seen so far are simplistic and weak if they work at all.
The schools near me I'm aware of have locked doors, but other than that, they are not fortresses. I'm not sure a bunch of locked student phones would be a very tempting target, but if it was, I wouldn't expect physical security to be the limiting factor to someone succeeding there. In the theft case, you have two other methods by which someone might attempt to steal devices. A student who already has access could try to carry out a mass-theft, or for that matter so could a staff member who would probably have an easier time of it. Even easier, students could probably quite easily steal one or a few devices that don't belong to them in the big afternoon everyone pick up a phone rush. The last one wouldn't be too hard to prevent but most methods would slow down the process which could be a problem when you have a lot of students and need to get them to their transport or after-school activities quickly.
From that list, the timetable would seem obviously necessary during school hours although it also seems the weakest option unless the schedule is constantly being changed and people just find out what they'll be doing every morning. The lesson agendas would also sound like they'd be used during class, likely instead of printing copies as happened when I was a student. The online quizzes could be homework or in-class material, but they happen frequently during class time, so I don't think those can be ruled out.
The question is not whether these things are necessary but whether they are currently being done, because until someone changes the system to avoid them, it does conflict with this policy.
The difference seems pretty clear to me, the law requires "intent to kill or cause grievous bodily harm", the jury decides they have "common goal to cause serious harm or death", those align. Ransomware operators usually have a goal to get money, not to kill or cause the physical injury that the law requires, which would make it manslaughter by the CPS's requirements.
It is not. For example, let's consider what's murder and what's manslaughter in the UK. The Crown Prosecution Service has a guide to explain it. Here's the important difference which makes this more likely manslaughter than murder. One of the requirements to charge murder in the UK is "with intent to kill or cause grievous bodily harm (in contrast to the offence of attempted murder, where only intent to kill will suffice)". If you do something which does kill but you intended something else to happen, that's manslaughter. To quote the guide again: "Conduct taking the form of an unlawful act involving a danger of some harm that resulted in death ("unlawful and dangerous act manslaughter")."
I'm not sure whether it's murder in the US either, except that, from news I've seen, it seems that US states have various conflicting definitions of murder. This has been a problem in cases where someone would like a murder charged under a higher degree but the law has established extra rules which make that difficult, and therefore with a potential 51 different definitions of murder, I'd have to do more reading to find out.
I suggest it's not the most useful for them either, since if they can't measure actual usage, it's harder to project the long-term performance of the vendors. This report mixes spending on cloud and spending on software, so if you're trying to limit yourself to databases alone, you have to do more work to figure out how to do that without polluting your data with infrastructure companies who are likely in a different sector of your diversified tech portfolio.
