Posts by doublelayer

Polish officials may face criminal charges in Pegasus spyware probe

Re: in 99 percent it was used against criminals

What is your distinction here? If they are correct that the countries buying it are largely using it for oppression, not normal law enforcement of criminals, then they have a point they can argue. If you're alleging that the tool is primarily used for more obvious criminal cases and the public cases are unusual abuses, I'd like to see your reasoning for why you think that's the case. Just calling it a "law enforcement tool" proves nothing about what it is or how legitimate its uses can be. I could call a torture machine a "law enforcement tool", but it wouldn't make it legitimate to use on anyone even if I did only sell it to police.

Re: And if any non USA backed state developed this...

Yes, it's definitely the USA's fault. That's why the US sanctioned them in 2021. I'm sure that's a long con of some sort.

Ex-White House CIO tells The Reg: TikTok ban may be diplomatic disaster

"So a foreign company operating in China chooses whether to share the tech."

Sure, in the same way that if I'm your boss and I skim some money off your wages, you choose whether to let me do that or choose to not have a job. Not a free choice by any means. That's the stupid logic that makes this unjust law sound reasonable, after all, ByteDance only has to choose whether to give up their service at a hefty deadline discount or to cease operating in a good market, they get to decide when and how they do one of those things. Neither is a choice anyone makes unless they are required to.

That might work for Facebook, but not so much for ISPs or phone store providers. I think the requirements are easy enough for Apple and Google. TikTok comes out of their stores immediately and that's basically it. However, maybe they need to consider whether the government will want them to actively remove the app from people who already have it and whether they're willing to take that action and how they'll do it without annoying users too much.

ISPs have a trickier situation to consider if the article's theories about mandated connection blocks prove true. This seems extreme to me, but I think there's a chance that the ban is simply overturned by a court, so if I'm wrong, anything could happen.

No joke: FTC boss goes on the Daily Show and is told Apple tried to block her

Re: Exit objectivity

Maybe he assumed that someone at Apple would at least try looking at his previous work. I am not very familiar with his previous work, but it sounds like he was interviewing similar people and coming to conclusions that weren't in line with the sponsors regularly. Perhaps he assumed that Apple wouldn't hire someone like that if they wanted to control him more tightly, because it's obviously not a good fit. Just like Musk hiring someone who didn't agree not to ask the interview questions like "aren't you having trouble getting advertiser revenue after you yelled at all the advertisers", they may not have paid attention to who they were hiring.

Re: USA Free Market

It was kind of both. The taxation issue certainly got a lot of people angry, to judge from how much is written about it, but they were also influenced by ideas about political philosophy which originated from people who had no taxation-based complaints against the British government. Had they somehow arrived at a resolution around the tax issue, and I'm not sure how they would have managed that, that could have ended it in the mid 1760s. By the mid 1770s, they had more complaints to do with liberty* and governance**, and a tax law change wasn't going to fix them.

* Liberty: theirs, not anyone else's.

** Governance: not democracy, at least not yet. The complaints had to do with things like law enforcement practices and chains of command, not just who gets to vote for what.

Malicious xz backdoor reveals fragility of open source

Re: Run linux they said...

I think you're both wrong. They're wrong when they claim that easy modification makes open source worse. You're wrong when you say this:

"Oh please. Ever hear of Hex-Rays and similar tools? Any person or team with the level of skill needed to pull this off could just as easily change a small bit of assembler in some commercial binary and try to poison the well, in fact it would probably be easier since white hats in general aren't decompiling gigabytes of commercial binaries on a regular basis."

No, that wouldn't be enough. That gets your exploit in. It is not as easy as putting it in as source code, but you can definitely do it. Now you have a poisoned binary and you do what with it? Unless you somehow manage to replace the canonical one with yours, it's not getting installed everywhere. I can make a poisoned version of Windows, but if I can't put it on Microsoft's servers, it's not getting installed for the general public. This attack had the chance of working because and only because they got their backdoor into the canonical version of the xz source, the one that gets compiled and put into repositories. Putting it into a fork and then waiting for someone to install that fork would do very little. Doing the same to proprietary software isn't any more effective.

Re: Would This Have Been Caught Sooner In Proprietary Software?

"No problem in this case. It was a well organised long term con."

Yes, sort of, but it was an organized one on a small tool like XZ. The attacker wasn't writing code full time to do that. They could spend a bit of time writing something useful on occasion to keep their name in everyone's head as someone who knows what they're doing while spending more time on other things. Working at a company takes more time and thus makes an attack more expensive. You also can't divide effort. Jia Tan could have been a bunch of people. One wrote some modifications, one just worked on the malware, one did the pressure campaign, and they just used the same set of GitHub accounts. You can't do that as an employee of a company because your accomplices don't have access to the internal code and giving it to them is a detectable crime which businesses already try to prevent. Not so expensive that you can't do it, but it reduces the number of attempts.

"Are you impyling some sort of QA? That's what Microsoft's customers are for."

I don't think they were implying that. If you're writing code on a team with a lot of people, you have a lot of code reviews and a lot of changes. It makes it harder to slip something in than if you only have to slip it past one person. This is especially the case if you insert your backdoor and I, your colleague, have a feature change to the same area and end up breaking your backdoor while merging your feature with mine.

The main reason why it's hard is that you don't get to choose your project as closely when you're working for a company. If you get a job at Apple, maybe you end up working on some part of Safari, the iMessage or Facetime protocols, or some core OS component. You can probably put a backdoor in those. Maybe you end up working on the new headline feature they're going to announce next conference: yet another emoji thing that's not actual emoji, the sixth version now. Have fun doing anything malicious when you're writing code for a feature nobody ever uses. It's probably possible, but you don't get to pick a target and specifically add code to that, whereas targeting XZ is as simple as finding where the source for that is and sending a pull request.

OpenAI claims its software can clone your voice from 15 seconds of you talking

Re: Just make such tools illegal too.

The option of "just don't have the technology" is always considered, suggested, superficially functional, and impossible. The same way that "don't have an internet" didn't work when the first abuses were known. The same way that, when there were ten computers in the world and people's ideas of what they could do came from science fiction stories, fear of them did not mean that we just decided to ban them and keep going with manual methods. You can try to ban developing the technology, but it won't stop people, especially as multiple open source versions already exist. They have valid uses, and anyone making one will say they're intending those, whether they actually are or not. If you ban it in one country, it will just be developed in another one.

You can only try to ban a technology when it is prohibitively difficult to develop it, and even that doesn't always work as demonstrated by the number of countries that have or could develop nuclear weapons. Those take a lot of money and things that are hard to just buy, and yet programs to do so have succeeded. Someone can build a voice cloning tool on a home computer, even though it won't be as good as an organized corporate effort. You won't be able to do very much to prevent that.

Rust developers at Google are twice as productive as C++ teams

Re: confidence

"Call it "Csafe" or something. It can compile C code but will include bounds checking and all that guff to make it a little bit slower but a lot safer. After all, C++ exists and didn't replace C..."

Most of the time, that would work, but there would be some compatibility differences. For example, if I do go out of bounds, what happens? If I can catch and report on that error, then anything I write that does that isn't compatible with C. Basically all you can do is crash the program on any out of bounds access if you want to be as compatible with C as you can, and even that won't necessarily work on everything. For example, if you have a typical string ending in \0, and I write something else over the \0, is that out of bounds? From the perspective of a string, it is, because it will break all the string functions. From the perspective of an array, it isn't. If you write your language to check for that, then someone will use it in that way and your language will not be compatible with their thing.

So yes, you can do it, but it would end up being a different language. It is hard for a language that is effectively the same as another language to get adopted, whereas building that into a new language that can introduce other changes that people think are useful has a better chance of being adopted.

The Register meets the voice of Siri Down Under

"Which has no relevance at all to there being almost no choice in voices."

It really does. Let me explain. Your idea of how complex things are is flawed in multiple ways:

"Or to there being no easy way to make the voice models - they did this in 2002. It's clearly not cutting edge, mega gpu, nuclear powered datacentre work."

If the only metric in how hard something is is how much computing power you need, you're right. Obviously, that is not the only metric in how hard this is. The article should make this plain. In order to build that model in 2002, they needed many days of hours-long recording sessions in a professional studio with a professional voice actor who can take very specific instructions, not half an hour with a laptop mic. That's not the only thing they needed. I can guarantee you that they had a lot of audio editors chopping up that source data and programmers figuring out how to stitch them back together. I know this because open source groups have been doing the same thing. When you can't afford to spend a lot of time on those details, you get robots. When you try to do it with a small amount of source data, for example for projects that have been using the technology to provide people losing their ability to speak with a computer voice that sounds like them, you get this. They have to do that work separately for each person you record.

Nowadays, there are some systems using machine learning to automate a lot of this, and quality is much improved. However, we are getting into lots of GPU territory for training, and even though you don't need that much computing to run the generated models, they are large and intensive enough that they can't run in real time on embedded devices, for instance the phones and navigation units on which you would want them. So yes, the lack of choice is because you can't make a functioning model with a little time and effort.

Now, we have the complaint about Apple denying you choice. They are truly evil for denying you voice options. Looking through a modern iPhone's speech settings, they are cruelly providing only 48 choices for English alone, covering 7 accents. Imagine being so restricted.

Because the systems today don't want to have you regenerate voice files every time a new string comes along. With a pre-built voice model, it can say, usually reasonably accurately, any set of words. If a new street name is added to a map, nobody needs to record that name for you to hear it. And if I want to build something other than navigation which speaks, I don't need to hire someone to read things into a microphone for hours or do that myself. It also means you don't have to have as many pauses in sentences as clips are spliced together. I'd say those are net benefits to anyone who uses it.

FTX crypto-crook Sam Bankman-Fried gets 25 years in prison

Re: So he sold shady investments to willing suckers

It is quite simple. If I open an exchange where you can buy things, you are still in control. You give me your money, and you decide what to buy. If you choose to buy 2 bitcoin at the price I offer them, then you now own 2 bitcoin and whatever money is left after you purchased them. I don't get to decide that I'm going to sell you a different cryptocurrency instead, because I'm running an exchange. My job is to buy the stuff you said to buy. If you lose money because you bought something that went down in value, that's on you. If I choose to ignore what you said and spend on something else, it's on me and it is a crime.

Your description of what happened is just wrong.

"Didn't SBF say he'd hold the funds in a mix of cash and crypto-coins, and then 'sell' billions of dollars of his own crypto-coins to the exchange in return for the real money?"

Neither. He said he would hold exactly what the customers asked him to hold, whether that's just cash, just cryptocoins, or a combination, and they get to choose the proportions and which specific cryptocoins those were. As for the coin he invented, FTT, he didn't sell those to FTX, they were already the property of FTX, and they were supposed to be just one choice of things you could buy. Of course, he used that as a method to slightly hide the fraud on the balance sheet, not that it took people very long to notice even with that fiction.

Re: A message--the absolutely wrong one--has just been sent to all the sociopaths in the US...

From the judge's statement, it doesn't sound like his awkwardness was used to reduce his sentence, just to change where he served it. I admit that this was one of your points, although the recommendation was for a medium-security, not a low-security facility. Still, you may have overestimated how much that helped him.

Re: What ?

It's not about the weather. That's where his parents live, so if he is near there, it is easier for them to visit him. From the context, it seems they think that would be beneficial to his mental health.

Amazon fined in Europe for screwing shoppers with underhand dark patterns

That definitely fits with my experience. I do not have Prime because I order from them quite infrequently, and whenever I do, they like to push the option at every opportunity. I probably buy from Amazon twice a year or so, but when I do, the things I buy were usually not easy to find elsewhere. Either I didn't find them at all, I found something significantly worse, or I found the same thing at a much higher price. For many items, Amazon is not necessary, but I have yet to find anything as good for niche items.

I don't like to buy from Amazon, and I don't do it frequently, but when I have, my experience differs from yours. Other stores available to me usually have something that is similar to what I'm looking for, but the selection is worse, prices are usually worse, and information is less. If they sell only one item that meets my requirements, but Amazon has twenty, I can optimize better from that menu. That also means that I may be able to find someone who has put their prices down because they know people are considering their competition.

Of course, that selection also comes with some major downsides, like having to filter out fraudulent items. I'm thinking of storage mostly, because people do like to sell either refurbished hard drives as new ones or the ever-popular fake SD cards. However, the shops I know that sell storage devices usually have quite a large markup on them instead, and I don't buy enough of them to buy them wholesale. Amazon is far from perfect, but I don't know of many stores where I can find anything near the level of options other than AliExpress (like Amazon, but even more things are fraudulent) or eBay (basically random). For some types of products, I can find better stores, but if I don't already have one in mind, that's when Amazon starts to look like an appealing option, even if I don't go buy from them.

AI hallucinates software packages and devs download them – even if potentially poisoned with malware

Re: Not "hallucinates"

This has been covered at length in the first thread here. Your complaint is also not internally consistent. If using the term "hallucination" is giving the program too much credit, then surely so would "making things up" or "lying", as both require intent. "Misleading" fits a little better, but typical usage uses misleading most frequently for intentionally misleading, and your entire first sentence was trying to make sure that the terms make it clear that the program is not thinking. So all three of your terms don't meet your own goal, and if we tried to have one, it would likely be the ungainly "emit information that is either factually incorrect, likely to lead to unwarranted results, or irrelevant". Maybe choosing a word, a word that clearly indicates the degree to which the results are useless, is logical after all?

"While "lie" may technically require intent I am pretty sure most people will take uttering falsehood and untruth without intent as lying"

I don't think they do. I certainly don't. I class that as being wrong. I know lots of people who are frequently wrong but aren't trying to be dishonest, and the distinction is relevant to what I think of them. Of course, it can be difficult to know what the intent is, because I also know some types of people who say something they know is incorrect, and are thus lying, but are good at acting as if they're really deluded into thinking it's true. Those people are quite annoying.

Re: So nobody ever tried the commands before publishing?

Not if you lump it into a requirements file which says to install a bunch of packages, and you just assume that if you run that file and the program works, you must be fine. I'm guessing it was in a list of other packages so it wasn't a completely ineffectual install step and that they didn't have any testers of any competency checking on it.

Good news: HMRC offers a Linux version of Basic PAYE Tools. Bad news: It broke

Re: if status_code == 200

Given that the API I was working with sometimes issued responses with 204, and they had to be handled differently, not so much. There's a reason they have more than one code there. Handling every 200 code identically is almost as bad as the time I saw someone's program doing a retry on every 4xx code, including 403 and 404.

Re: I wonder why every request is showing an error

"I respectfully suggest that it is because you didn't read (and absorb) the documentation."

No, it's because I was writing quickly. I read the documentation, which is how I know where the status code is, but I was using an HTTP client that I hadn't used before, and I forgot that it was a string. Generally, you have to understand the documentation, not memorize it. In either case, the bug was identified and fixed quickly. I'm just pointing out that a compiler that detected that I had effectively written "if False" would have pointed it out even faster, with no doubt about the particular cause. Of course, if I keep using this HTTP client library, then I'll begin to write if status_code == "200" all the time, and if I go back to a different one I know where they are integers, that's when my automatic entry will end up being the wrong thing.

Re: the reason we use compilers is to somewhat limit the number of stupid things we can do

Those sound like the words of an overconfident person to me. People trying to write something quickly can write a stupid thing even though they would be smart enough to avoid it in another circumstance. Have you ever looked at some code and thought "who decided that was a good idea", checked the logs, and it was you? I have. Sometimes, I know it at the time, so the code is helpfully labeled with comments about why this stupid thing is what I've done right now, but it should be improved at some point. You don't even have to write a lot of code to know that. Are you really saying you've never done something on autopilot and realized, usually right after doing it, that you shouldn't have? Of course, we try to minimize how often that happens and I think I've done well enough at that goal, but I'd be lying if I said it wouldn't ever happen again.

Re: It's 2024

You are definitely correct about both things. The reason I bring them up anyway is that I've worked in many places where people wrote unit tests that were testing basic functionality because they occasionally caught errors made by the coders by testing every path, but that a compiler in other languages would have detected. I was required to write similar ones because otherwise, coverage reports would indicate that the function didn't test that the if statement did, in fact, execute the enclosed code when the condition was true. The time spent on unit tests like these that either did nothing or tested manually what a compiler could test automatically took out time. If I had insisted on writing even more tests that were actually useful, my performance would decrease and that doesn't end well.

This does not mean that I neglected useful tests, because I did try to include new ones whenever I thought the risk of someone changing a part was too high, but our project's testing was insufficient, and the time spent on pointless tests of basic things did not help. By all means, you can put the blame on my management for not caring about good tests or on me for listening to them. I certainly blamed myself every time I looked at our build tests which showed 40868 unit tests passed and gave me very little confidence that that meant anything useful.

I can't agree with you about the reasons. Python was not the language I learned in introductory courses. It was not the language I learned in advanced courses. Many of those were taught in C or C++ for me, though I learned about ten languages more or less for some course. Python was used in exactly one course, or roughly 0.5 courses because that one used some others as well. If I just stuck with what I learned first, I would not use Python.

I use Python for some purposes because it makes it easy for me to express the intended computation quickly and generally accurately. My typical example is string parsing, where one or two lines of Python can do what would take twenty in C. If I need to parse a million such strings per second, then I might reimplement it in something faster, but in many cases, I need to parse a smaller number and it doesn't really matter how quickly, so the faster and more accurately I can chop them up and reconstitute the parts I care about, the better. This does mean that, as a program gets larger, I am less likely to use Python to write it, but that doesn't kick in as fast as it might for you. I have and will continue to write quite large systems in it when it is better than the alternatives.

Re: It's 2024

I'm glad to hear it. I'm pretty good at not doing that myself, having had a lot of experience, but I can't claim never to have done it, especially as I did it not too long ago. I was writing a basic HTTP client, and I checked the return code with something like

if status_code == 200:

Huh, I wonder why every request is showing an error? Is it that I'm not connecting to the right place? Have I incorrectly implemented the authentication? Did my quick client mess up a character encoding thing? No, I have to compare against a string status code instead of a numeric one but Python doesn't mind comparing a string and an integer for equality, it just always says False. A simple error, quickly fixed, and I probably wouldn't have made it if I was writing a larger program rather than a quick script (because the larger program would have abstracted out the HTTP stuff into one part that I would have focused my attention on when writing it), but I do make mistakes.

If you never make mistakes, that's great, but two things are still true. First, there are many people who do make them and it can be helpful to catch them without requiring them to go through long, otherwise pointless processes because they might try to skip them or they might make another mistake*. Second, I don't believe that you actually never make a mistake. I think you probably catch it quickly instead.

* In a project I worked on, every function would start by checking all its parameters for unacceptable nulls. Every unit test would start by testing all the parameters with unacceptable nulls. We pointed out that, if someone forgot to check for nulls, they would probably forget to test for the null they missed because everyone just wrote tests in the same order that their checks appeared which made it really easy to miss such a thing a second time if they already missed it the first time.

Re: It's 2024

The problem with that is that manually writing unit tests that test obvious behavior takes time, and that time could be better spent on tests that might help in the future instead of catching obvious stuff now. I've written a lot of unit tests that will never catch a real error because they effectively duplicate the code in a function. Either the function remains the same and the test will pass, or someone changes the function and will have to change the test, but it won't detect anything useful. I have written it because it tests some types and names, the same thing a compiler for other languages would do. If I didn't have to write that, I could spend the time writing a test which tests the boundary between two units, the places where changes to one area can cause a failure in another. I've worked on codebases where we had complete test coverage and where the tests would never do anything for us. By wasting time with tests that could be done automatically, we end up spending less time on the tests that prevent bugs later.

I also disagree about some features like inheritance. I find that well-structured types make certain design challenges much easier to get around than doing without them. Of course, Python has plenty of those features, and I use them frequently. Since I complained about Python's type system, I'll give it some praise now: one of its major strengths is the number of syntactic and structural ideas it has gathered from other languages and made available. For example, if something is best written in a functional language style, I can do that easily in Python while C makes it a pain. That is what makes Python such a good language for getting something functioning quickly; I can express what I want very quickly and accurately.

Re: It's 2024

Of course it is, but the reason we use compilers is to somewhat limit the number of stupid things we can do. We could go back to times where nearly anything you typed was valid code and the computer would run it, and if it didn't do what you wanted then that was your business to find out and fix. Powerful languages get their power by making it easy to explain what you want and difficult or impossible to do certain classes of preventable errors. Having enough memory that you don't have to think about type storage doesn't change all the other things that a good type checker can do.

I like Python, and it is one of my more commonly used languages both for prototyping and for some types of production software, but if I had one complaint about it, it would be that it makes some things which, in another language, would be compile-time errors into runtime errors. Testing is often insufficient and we don't make that easier by having to write pointless manual tests that a compiler would already do.

Re: "for businesses with fewer than 10 employees."

The print as a function thing has confused me for years. I came to Python after a number of other languages where print was a function, so I never understood why it shouldn't be a function there either. It's the only imperative keyword, and without the parentheses, it still works exactly like a function would. Maybe someone who minds the change could explain why it's such a problem.

Windows Format dialog waited decades for UI revamp that never came

"Yes, yes it was elegant: neat, tidy, no guff, sensible, easy to use."

It is not bad, and I'll grant easy to use and compact, which are certainly in its favor. But not everything in there is sensible. For example, let's take a look at the fields.

First, we have a capacity box with only one option in it. In modern land, there's only ever one option in it. I can only guess that it's there to deal with floppy disks. Either way, I'm glad I've never had to explain to a user what that's there for. Then, we have a format box which often has only one option, but sometimes has two. More choices here would be useful. The "allocation unit size" box is something I understand, but not explained for anyone who doesn't. Those are your only parameters. We're lucky that this box can't create any complex file system because there's no place to configure extra features of one. Windows does support other filesystems, but they don't expose that to this box.

If you want something with three settings, two of which can't be changed and one of which nobody changes anyway, then writing a simple UI is pretty easy. It's when you want to have more options that it becomes difficult. For example, the nightmare that is trying to get Windows to change a partition table, because it uses a similar theoretically simple UI which is so simple that it would appear not to be able to do anything. There is a reason why I tend to boot Linux and use fdisk whenever I'm partitioning something, then create filesystems on the partitions, also from Linux, then bring the device back to Windows. That is not something that speaks in favor of those UI choices.

Time to examine the anatomy of the British Library ransomware nightmare

"To me that reads like a lot of today's thinking - let's blame someone else."

Yes, that's what I meant by "blame game". People do it all the time. One of the people doing it, right now, is you. You're going to find one person who did one thing wrong and put the blame on them: "track down the person whose password allowed the initial access and fire them". I'm guessing that you work in IT, so you're nicely exempting your profession from it by finding someone else and deciding that they're responsible. In my example, I gave you lots of single people we could put the blame on.

IT person: You could have had monitoring and more security, you didn't, so it's all your fault.

Management: You could have told the IT person to have monitoring and more security measures, you didn't, it's all your fault.

Finance: You could have increased budgets for security, you didn't, it's all your fault.

Senior management: You could have approved more leeway for IT security measures, you didn't, it's all your fault.

In reality, it is at least partially the fault of all five of those people, and possibly even more. Each person probably could have done something differently. Accurately estimating the correct amount of blame would involve trying to evaluate exactly where each person failed, but it doesn't really help much. If you're going to have blame-related consequences, doing that is the fairest way. If you're willing to fire the person who initially clicked on something they shouldn't have, imagine for a moment someone barging into your office, deciding that you should have done something differently, and announcing that you're the one to be fired. You probably could have done something, after all.

Re: "Too old to be safe, too expensive in time and money to replace"

You will never prevent vulnerabilities from existing. You can reduce their number by spending more time (remember that it will increase the time and slow the pace of updates, including those you want to have), but it will never be zero. But let's try this thought experiment. What was the last zero-day or vulnerability that caused a zero-click attack, I.E. one that would have happened without any user interaction and was all due to the software. How many attacks like that do you know? Many attacks aren't that simple. They often rely on a user to activate the initial vector or to leave it insecure (basic SSH or RDP access to the internet is popular), the configuration to allow them to brute force passwords or access methods, the configuration to allow their compromised tokens to access things for a long time, profiling systems to not exist. None of that is down to programmers shipping too fast, and all of it can be blamed on the administrators who could have configured it and didn't.

There are times when programmers are really at fault, but from your comment, I think you and the OP have overestimated how often this is. I am asking you again to consider how you would feel if it turns out that no vulnerability was found to be very important in this attack, but the administrator could have detected this and didn't with a different configuration, so they're the one bankrupted with penalties. If your response is "Fine with me. Let them suffer", then fair enough, we just disagree. If you think the administrators shouldn't face those consequences, then you should consider whether it's fair to have programmers face them in an analogous situation.

Re: No change

You learn who to say things to. I also work in security, and that's what I say to people who work in IT or programming. They assume that I'm also doing some kind of technology security, and if they know that I'm a programmer, they can draw the lines. Say that to someone who doesn't work in tech and they either don't get it or assume you're a security guard and try to figure out why a programmer is doing that. The term they use for the entire information or technology security area is "cybersecurity". We're lucky that shortening that to "cyber" hasn't entirely caught on. Now I could try to adopt something that's really no better and get everyone to call it "computer security", educate them on why we sometimes call it infosec and try to make them do that, or use the term they know. I often choose the low-effort method that still gets communication going.

Re: "Too old to be safe, too expensive in time and money to replace"

If you do that, you will certainly sometimes get the writers of the software to pay for damage caused while running their software, but you will also get a lot of something else: IT people raked over the coals and punished severely. Because if you're going to pin the blame on the writers, those writers are going to have a need to pin the blame on someone else, and there is usually something the administrators could have, and in many cases should have, done which makes it their fault. For example, maybe we blame a software writer if their code has a zero-day in it, but who gets the blame if the software had a vulnerability in it patched two months ago but the administrator didn't install the update? If you're willing to charge the programmers for any financial cost, are you willing to charge the administrator that could have but didn't install the update with the same thing? After all, if the coffee machine was not defective but the plumber installed the water line in such a way that it flooded the machine, heating the water, and collapsed in a wonderful fountain of steam, you would be blaming that plumber.

There are many situations where it's less clear, for example the programmers say the configuration was insecure, the administrators say the defaults were insecure, and they fight because neither wants to get stuck with the blame when it comes with that large a bill. So also budget for some lawyers to be involved, especially if the company who wrote the thing is large enough. They'll have a good incentive to make sure the court thinks it's your fault. Before you get too eager about finding someone who isn't you and blaming it all on them, think for a bit about whether it would be fair for someone to do the same to you. If it wouldn't, let's factor that in to the solution we propose.

Street newspaper appears to have Big Issue with Qilin ransomware gang

Re: What is the purpose?

The model of letting someone else get initial access and then just deploy your ransomware could be responsible. If there is someone who wants to get some ransoms but isn't capable of getting into anything with even mild protections on it, they may have been the one to select some low-hanging fruit because they could get into it and they didn't really think about the likelihood of getting anything out of it. Having done so, the software worked just as well as it would anywhere else and the organization responsible for collecting ransoms figured that they've already attacked this thing, so might as well try to get some money for it even if it's small.

Uncle Sam's had it up to here with 'unforgivable' SQL injection flaws

Re: SQL is the problem

"ADD B TO C" is fine. What we write now, c += b or c = c+b is no different semantically. The syntactic difference is unimportant. The problem is not with syntax that looks like English. The problem of injection is not unique to SQL or a language that looks like English, but is present in any language that can parse a generated string as code. Perl is notorious for this, because few Perl programs, at least the old ones when Perl was more popular, didn't use the eval function somewhere.

I wrote a comment in another thread above this one about why I think that SQL needs to look like it does here and accept a string query, because attempting to construct complex queries using a more traditional programming language either makes the code unreadable or makes the programmer do the work for the database (I.E. instead of running one query, running multiple ones and handling the intermediate stages manually). A language that looked like SQL but enforced parameterization could avoid the injection risks. One that looked more like code but didn't enforce them would be as vulnerable. One that looked like code and did enforce them could end up fixing the injection risk in such an ugly way that nobody used it.

Re: Coders vs Developers

Effectively, this requires them to completely change their interfaces in a way that makes them less flexible. Libraries that make it easy for you to parameterize a query are still turning it into a string when they send it to the engine, they're just doing it better than you would on your own. There are three reasons why database engines won't make that change:

1. Writing parsers becomes much harder. Consider all the possible parameters to a statement as simple as select. You can sort in a variety of ways, you can select from multiple things and combine them, you can use one statement to filter them. Now write a function contract in C that can do all the same things. What parameters do you need to take if the query might reference multiple tables. What parameters do you need to take to expose all of the internal functions of the database and construct a function that can be used to sort them? Your function is going to be huge. It is easy enough to handle this in the database because it can be split into subcommands with temporary storage for intermediate results, but the point of the database is that your users shouldn't have to do it themselves.

2. If you don't take a string or some other portable query syntax, then you have to write programmatic interfaces in every language. Most popular database engines have libraries for many popular languages already, but we also know that, if it really comes down to it, we can write a basic communication method to get bytes into the database server process and use a database in any language we like. If you use a more complex expression syntax, the library that executes queries becomes much more complex. A user who uses a language that isn't supported no longer has a hope of quickly writing one, and unofficial libraries are likely to have trouble keeping up with additions to the syntax.

3. The method has existed for a long time and inertia is hard to fight. There are newer database engines that do what you say, but it won't be easy to convince everyone to dump SQL and adopt one of them with its unfamiliar syntax and incompatible behavior as the new standard, porting all applications that used it over.

Re: Coders vs Developers

"How does SQL injection work with modern code?"

Nothing will ever stop you from submitting just one string. They don't parse to see if you're passing something that looks like a value and insist you parameterize it. This means that, if someone either doesn't know or doesn't think to parameterize, they can still build an expression as a string and that expression is still vulnerable. Most likely, you're just not seeing as much of it because the number of databases out there is massive and a lot of programmers were told not to build expressions that way and remembered it. Sadly, that doesn't mean everyone was taught that, so it still happens year after year.

Chrome for Windows-Arm laptops officially lands in time for Snapdragon X Elite kit

Re: Microsoft only dropped Alpha support

I'm not really sure what that proves other than that Microsoft is quicker to drop support. The hypothetical of what would have happened had Alpha remained in production and being purchased is the better one, but we don't know whether Microsoft would have kept it, whether people would have bought it, or any of the questions relevant to the ARM situation today. Windows on Alpha and Itanium were already weak because people weren't buying the machines with those chips in them. You can't really blame Windows for Itanium's failure when Linux shops weren't buying Itanium boxes in droves either.

Re: The x86 layer hasn't skipped [a] beat

It depends how often you have to use it. If most of your tools are compiled for ARM, then you will be efficient most of the time and the emulation is there when you need to run something that wasn't compiled for it. The trouble comes if most of what you want to do hasn't been compiled over and you spend most of your days in emulation. For people who use niche tools, it's probably not ready. For the average office computer where a word processor, email client, and browser are needed, you can likely find ARM versions of all those things. Definitely if you're using Office for those, but Firefox and LibreOffice have Windows on ARM ports as well. I don't have one, but I think it has avoided the reasons why I told people not to consider earlier attempts. The Windows RT devices may have looked like Windows, and there was some Windows source code in there, but they didn't have compatibility with anything Windows had. The current version does have that, and from what I've heard from people who use it, it works pretty well.

As AI booms, land near nuclear power plants becomes hot real estate

Re: Anticipating grid failure is more like it..

I haven't worked in the electric power industry, but I would guess that they get two advantages by being close. First, they get to avoid paying transmission costs, including any cost for adding more grid capacity for their large set of usage. If the existing grid couldn't handle their relatively large load being added, they'd probably have to pay most or all of the costs to upgrade it. Second, if there is a grid problem, their datacenter would continue operating. That failure doesn't have to be long-lasting. If they've sold their capacity on an SLA that becomes costly if the systems lose power, then they might want to avoid what, to a residential user, might be an annoying but acceptable outage. By locating close to a plant, they can probably get away with a lot less generator capacity than a normal grid-fed DC.

Over 170K users caught up in poisoned Python package ruse

Re: Python, eh?

In this example, it wasn't PyPi that had a problem. It was the package that was instructed to retrieve code from somewhere else, download it, and run it. Nobody broke into PyPi to submit a poisoned package; they broke into someone's GitHub to make a real package poisoned. The important part is that, unlike previous attacks which have indeed used PyPi, this could have been done to any project using any language as long as somewhere in the build system accepted a dependency's URL. They picked a Python package in this case, but that wasn't required for this to work.

That Asian meal you eat on holidays could launder money for North Korea

I can't back which claims with evidence? That they threaten anyone they let out of the country? Does testimony from escaped ambassadors and tech workers count? You can find that. But if you will dismiss this all as state department propaganda, then there's nothing I can do. Do you want to try convincing us with evidence of your own? If I can't back up anything I say with evidence, then surely that means you can? You could, for example, find me an interview with a North Korean who didn't either escape their country which wants to imprison them or is working for them right now? I can find you interviews with plenty of migrants, with legal documentation or not, from almost every country, but you tend not to find North Koreans who voluntarily left their country, were allowed to do so, and are willing to talk about it.

Re: Wait, who sells them the weapons?

True, and it already works that way. However, if most countries and companies will not sell you the parts, it means the markup on those parts is pretty high, which means that there is an incentive for the person who is willing to break those sanctions and find the parts anyway. If I make chips that could be used in missiles for $10 apiece but refuse to sell them, and North Korea is willing to buy them for $60 each, then a company has a $50 per unit ability to cover any costs involved in getting them out of my control and into North Korea's. If they are general purpose chips, this can be pretty easy. If they're restricted technology that has to be obtained from one of a few people I'm willing to sell to, then it's harder, which increases the price even further.

The more cash North Korea has on them, the more their ability to pay those increased margins. You'd hope that, at some point, they would decide that more nuclear weapons they don't really need isn't worth the price, but if they thought that way, they probably would have stopped making them at least a decade ago. For other weapons systems, they have plenty of people who want to pay them to manufacture them. North Korea has been making and selling weapons as one of their major export industries for decades, and they've been making some advancements. Russia wants a bunch of cheap and modern missiles, and North Korea has a bunch of really cheap labor and factories built for missile manufacture, so if they can connect Russia's money and modern missile components, they can get them.

Woz calls out US lawmakers for TikTok ban: 'I don’t like the hypocrisy'

That is not what I said. What I said was that, in my limited experience, I don't know people who would. It is like asking "Why do people complain about others eating meat but then go hunting?". I know some people who do happily kill and eat animals, and I know some people that disapprove of people eating meat and will complain about it to anyone who does, but those are not the same people. In order to demonstrate hypocrisy, they have to be the same people. Otherwise, it's just different people doing different things. In my experience, the people who complain about any access by the government are not the same people who will post anything on social media. Maybe your experience differs from mine, but what I am saying is more complex than "I wouldn't post that, so they don't".

Re: Risk/Reward.

Thank you. I think I better understand what you're saying now. The reason why I was talking about the ease or difficulty in looking up a phone number is that it affects how I feel about having to give it to somebody. For example, I don't have a problem giving my phone number on a government form, nor do I know many who would. I was trying to find out a type of data that someone would provide easily but would complain a lot about providing to the government, which is central to the question you brought up. In my experience, people who readily give that information don't have a problem readily giving it to the government, and those who complain most vociferously when it's the government asking tend to complain when others ask for it as well, but this appears not to match your experience. Yes, there are people who are ridiculously conspiracy-minded whenever the government does anything and people who will give away any private information, but they tend to be different people, not one person doing both of them.

I have, and I've seen two categories that fit with the idea, but don't work with the question:

Group 1: Are happy to give out any piece of personal information, no matter how much I wince when they've done it. These are people who would post a live view out of their doorbell camera and, if I ask why, they will say something stupid like "it'll help make sure my house is safe". These people will definitely put lots of personal information on social media, but they'll also give it to the government. Point out that the police have extra access to that camera and they'll say "I have nothing to hide".

Group 2: Paranoid, kind of like me or even worse. They'll keep lots of data private. If they're asked for it, even when it has a purpose, they'll think for a while about whether they have to or if they can find a way around providing it. This applies to the government, but it also applies to social media.

What I don't see too much of is group 3, the one that happily puts data on social media but refuses to give it to the government. Now I have seen a similar group of people who are avid users of social media and weirdly panicky about the government doing ... something (if they explain it, it sounds crazy, so often they go for vague). But those people don't tend to dump tons of data up there, at least not intentionally, because they think the NSA is collecting it (which they probably are because hard drives are cheap) and using it against them (which they're definitely not doing because these people are not interesting). The question asked in the original comment relies on people being angry about giving a certain piece of information to the government but accepting giving the same piece to social media. General attitudes being more positive to social media than the government don't fit that question unless the information being provided is the same.

Re: Risk/Reward.

You're eventually going to have to explain the things instead of saying "whoosh". Because one of two things are going on here:

1. I'm an idiot, and I'm going to continue being annoying until you explain your meaning in simple words that my walnut-sized brain can understand, even though your original comment was rather clear already.

2. We actually do understand what you're saying, but our responses are not to your liking and you choose not to make meaningful response.

In many cases where I see "whoosh", it means that the original comment was sarcastic, and someone missed it. So If I try to interpret your comment in that way, then maybe you were saying that a phone number isn't sensitive information because phone directories exist, so it doesn't matter that people willingly post it on social media? That doesn't sound like what you were saying, but your comment didn't seem that sarcastic. Otherwise, their point about how public a phone number is is relevant to the discussion. You can tell us what you meant. My walnut is ready.

Sorry, but I'm not sure you read or understood my comment. For example, the "muh freedumb" thing you talked about: I didn't say anything about freedoms, lack of freedoms, or governmental overreach. Not one single thing. What I said was that I don't know what information people would be angry about giving to the government but happy about giving to Facebook. If you see an argument about freedoms in my comment, I'd be very curious to see what led you there, because I didn't intend it.

I asked for examples, and you've provided one. Let's consider it. I don't know people who would be angry to put their phone number on a government form, assuming they're not already angry about having to fill out the form itself. I know a lot of people who would not put it on social media, exactly for the reasons you say: it's public when they have it, it's not when the government has it, and the government already knows it. However, as data goes, this is one of the less sensitive pieces of it. I've had my phone number for many years now, and since I'm able to port it around to different providers, it's likely to be mine for the rest of my life. I've had plenty of places who I've given it to, either because they actually needed it to contact me or because they demanded it and I couldn't do what I wanted or needed to do without them having it. This includes various government services, and I didn't mind them having it. This means that, almost certainly, my phone number and name are associated in nearly any dataset that can be purchased and likely in plenty of free ones to be found online. I have little hope of my phone number remaining truly anonymous, so I must factor that into how sensitively I'm going to protect it. I still wouldn't hand it out to anyone who asks, but I don't protect it the way I do more sensitive pieces of information.

The kind of thing that I don't want to give to governments are things like passwords to online accounts, private keys, and the like. Mostly, they are things I don't have to, although various ones suggest collecting them from time to time. I would not give any of those to social media either, and I think that, although there are a few people who would be stupid enough to fill in the form "The password to your email account here", it's a rather small set compared to those who are willing to give their phone number except for authentication and communication, which is a small set compared to those who use the services at all. Maybe you think of phone numbers differently than I do, but if you agree about its sensitivity, is that your only example?

Twitter's lawsuit against anti-hate-speech crusaders gets SLAPPed out of court

Re: Careful here.

They don't have a master control panel that can shut off ad revenue, not that I have any ad revenue to be cut off anyway. Still, they can only cut it off by going to advertisers and telling them things that make them want to cut it off voluntarily, and they individually have to be convinced. Twitter still has some advertisers. The important part here is that, if they don't have anything convincing to tell them, then the advertisers don't have any reason to stop advertising. It only worked because what they were able to show advertisers is something the advertisers didn't want to see enough that they choose to stop buying advertising space. The organization may have helped to shine a light on that, but without that light, it would still have been going on, and advertisers were already leaving as a result anyway.

Debate is not stifled by someone pointing out facts. If you want to accuse someone, accuse the advertisers; they made the actual decision not to spend when they were free to ignore any reports written, and if they had, nobody would notice much. Those advertisers have free speech, including the right not to advertise. No debate stifled, nothing untoward happening. There are some forms of harassment that do occur and are dangerous. This isn't it.