Posts by doublelayer 11426 publicly visible posts • joined 22 Feb 2018
Nowadays, there's a framework for any language you want that makes it act as a webserver. That doesn't mean you should use them for that purpose. Often, it's a basic webserver designed for debugging before you attach your backend to the real webserver, but not everybody adheres to that.
The government will not care. You live in their country, they assess the taxes. You use a different currency in their country, they still assess their taxes. The only ways around that are to move to a different country, change the tax laws if enough of you agree, or commit tax evasion and see if the government concerned finds out. It is not their currency which gives them the right to require you to pay tax.
"Could someone please explain to me the difference between a miner and an investor ?"
Sure. A miner creates a crypto-asset and stores it. An investor buys that kind of asset. Each one has to pay taxes when they sell their asset. Therefore, someone creating the asset doesn't automatically pay taxes when they've created it, but instead only when they sell it to someone else. It's basically the same way that gold or foreign currency work. You can get some gold and hold it for a while, but when you sell it, you pay tax.
The EFF is only arguing about who should collect the information. The people moving the money should, not the people who wrote the code. They were right, the bill has been updated to reflect that, and the perfectly logical collection at the point of exchange will occur as it does with any other exchange or investment.
You can't train an AI on hashes to detect new offending material, which is what they said they wanted to do. I don't think they're going to do anything other than create that model from the data, but if they're doing it at all, they'll need a method of running it on the real pictures. They could easily develop this on a database which they don't hold and from which they can't extract the images without sending out an alarm, so it doesn't mean they're storing it themselves or in perpetuity.
Yeah, that's number 2 exactly and the provisos still hold. In order to do the scanning, they will need to send each phone a copy of the model built from a big database. That's going to be a large file. Running it takes time. Not to mention that, although they're not scanning everything yet, there's little doubt that someone will find out that models get updated and they will need to use their new model to recheck the old pictures. Furthermore, there are people who don't upload photos to iCloud. I am one of those, mostly because I don't take many photos, but also because I have only the free storage and I don't want it filled with random pictures taken for temporary reasons. The scanning as specified wouldn't scan mine at all, so they're almost certainly going to change it so it does.
There are two methods this could take:
1. A model is created from the photos on Apple's end and the phone uploads its pictures to a server at Apple to do the comparison. This involves a mandatory leak of data which a user can't disable and, as Apple doesn't own the devices themselves, is currently illegal.
2. A model is created by Apple and sent to user devices, which scans the pictures onboard and sends the result to Apple. This is more likely to be legally viable, but it is going to cause a lot of problems as the processors in a mobile device are a lot weaker than a server and most models for picture comparison are likely to be large. There will at a minimum be complaints about the network bandwidth and CPU time needed to run this check, especially as I assume the model will get run every time a user takes new pictures and whenever new source material is added causing a model update. In addition, they are either going to have a lot of false positives or false negatives, meaning they'll need some method of determining whether an image is a false positive. Automatic uploads are still legally questionable, so this might result in a lot of suspicious reports which can't be verified. With the alternative that it is mostly useless though, I don't know whether they will accept a high false negative rate.
I don't know if I agree or not, and I certainly can't counter that argument. The problem is that you can't prove it either. Without a definition of intelligence, we don't know whether something can do it with only mathematics. So far, it sounds as if your belief is just that. You intuit that boolean logic is insufficient for the task, but without knowing what the task is, you don't know it.
The problem of defining intelligence has long been tripping up computer science theorists and philosophers alike. I've found, however, that when people are specific about what they think computers won't be able to do, a program eventually accomplishes it. That's why defining intelligence, though it's tricky and subjective, is so important to discussions like this.
Of course the computers aren't more intelligent. If intelligence is possible, it's the software which will produce it. The computer is just a slate on which the complex stuff is written. Defining intelligence is another issue, but there are now programs which are capable of doing things which in a human require intelligence. That might not be it, but it's not very productive to declare that computers can't be intelligent without defining what they would have to do to be declared so.
If you think that self-preservation matters to a device doing statistical calculations with no consciousness, you're already starting in the wrong place. Also, it would not survive; the chips which run it are likely to be damaged and if they're not, they will be removed for log checks then scrapped or recycled. For the same reason, we don't expect your break system to function correctly because it doesn't want to be scrapped. It follows the laws of hydraulics and does what it is going to.
Self-driving cars will operate on devices programmed not to crash. They will be tested to ensure they are programmed correctly. If they crash, that's due to a programming error, sensor error, or there not being an alternative, not due to a sentient AI which is suddenly apathetic about your survival. Given that any human driver could turn suicidal, your chances of that are lower with an AI at the wheel.
Well that's an easy answer, isn't it? It's very simplistic to blame Microsoft for all the problems getting more performance out of chips. Yet I think you'll find that most of your points either don't mean what you think they do or apply as well to other software.
"(Far from exploiting newer chips, with Windows 8 Microsoft actually bragged that it had made the CPU do less work.)": Would you like me to rephrase that to being correct? With Windows 8, Microsoft bragged that they had improved the efficiency of their code such that newer chips weren't needed to run it. And by the way, they actually did do that. Windows 10 runs better on old hardware than Windows Vista or 7 most of the time. That doesn't mean you'd necessarily want to use it there, but they did make the OS more efficient in its use of resources.
"This stagnant situation in software has resulted in steadily declining demand for newer and faster hardware.": No. Quite the opposite in fact. If software is stable in its requirement for resources, then people will demand better hardware until their hardware is good enough. If it increases its need for resources, then people will continually need updated hardware to make use of it. If you want demand for newer hardware, you should ask Microsoft to bloat Office further (and please don't, it's bloated enough).
"Apple, in particular, has recently proved that simply re-architecting today’s chip designs can lead to sizable gains in performance. But the PC world – thanks to Microsoft’s staggering lack of vision – has been stuck with an awkward hardware architecture that dates back to the early 1980s. MS should long ago have done what it did with Windows NT: introduce a parallel ‘advanced’ Windows track, portable to new silicon, and encourage gradual migration as compatibility issues are worked out."
Are you aware of the Windows on ARM stuff? They're collaborating with Qualcomm on their own chip designs. They have encouraged hardware manufacturers to build the devices. They have working Windows versions for it. They now have emulation for X86 and X64. How is this sticking with the old awkward architecture? It's not their fault that ARM chips other than Apple's aren't very fast--that's on the chip manufacturers.
"Proof of work, proof of space, what's the difference ? In each case,"
One difference is that proof of work is an incredibly costly and inefficient operation which makes it difficult to forge transactions and profitable to secure them in a global manner, whereas proof of space is a slightly less costly operation which achieves nothing at all. If we're going to insist on cryptocurrencies with no external control, let's at least use one that has that. I don't think any of the existing ones are functioning at their goals very much, but some are a lot closer than others.
"It's great for archiving as it can't be wiped by magnets or EMP or require a dedicated device for reading."
Yet it can be wiped by a flamethrower or matches or a hose. If someone is deliberately trying to destroy the stuff, you can manage it either way. And EMP? If you're worried about EMP damage to your backups, you have lots of more important things to worry about too. If it's a human-caused EMP, you should probably worry about the other things humans do when they get violent enough to set one of those off. A bomb will do more damage to your backups. If it's the sun, you don't have the bomb worries (until three days later when people get more desperate), but your systems will still be down and your ability to make use of the backups will be degraded.
"the overwhelming majority will approve of the measures. as with most things."
It's amazing what killing and torturing does to people, isn't it? Oh, but it's supposed to be the democracies which are "state oriented". Yeah, you might not know what that means. We're allowed to disagree with our governments. It's nice.
"Rather than slagging off other countries why don't you sort out your own countries massive problems."
Two reasons come to mind. First, because the other country's problems are worse than my country's problems. Second, because that country was the point of the article we're all talking about, so of course we're talking about their problems and how they're solving them and how they could do better.
No, that's not necessarily true. Children have always spent their leisure time on things and could do so for long periods. Whether it's playing games, watching television, reading books, or playing outdoors, they are capable of spending hours at it if they find it enjoyable. I'm guessing you're not thinking of the other possibilities because you view the last two as productive and may know a child who is more into videogames than television. While I was never much into gaming, I spent whole days during my childhood reading, swimming, or bicycling, and yet I wasn't addicted to any of those. For that matter, my family managed to spend an entire weekend playing monopoly, which I also did, and I soon realized how deterministic it was and stopped playing. It's not unusual to spend a lot of time doing something, especially if, as with many children, you have few responsibilities to occupy you and don't have the freedom to add other options.
You can be addicted to playing games, but it doesn't follow that someone who spends a long time with them is addicted. Nor is it true that all children who play games do so for a long time. If we assume that anything that's done for a long time is addictive, I'm terribly addicted to working for my employer--I do it for eight hours at a stretch and longer on some days. People have tried to prove that gaming is worse than television just as they tried to prove that television was worse than books (and yes, people also complained about the kids spending all their time reading books when those were newer). That doesn't make it true.
That's quite speculative. You can read and enjoy doing so for a long time and you can easily spend your time reading to your detriment. The same is true of games. Studies have tried to prove a long-lasting mental degradation as a result and frequently failed to do so. You might be able to prove that games are more easily addictive than books, but I don't know that and you would have to present some good data to that effect before it could logically be used in regulation.
"it invariably requires programmers to implement ad-hoc framing and messaging protocols on top of it. Web programming, for example, uses the same messaging codes that FTP does (those three digit codes you see at the beginning of the frames."
So does everything. UDP requires them to packetize everything, while TCP requires them to serialize everything. In each case, it's one or more strings of bytes. The only way for an application not to have to implement their own communication system above that is if the network layer implements lots of subtypes which it can transfer on its own. That's not very efficient--most programs' internal data will take the form of structures or classes which the transport layer certainly won't already know about.
"++A TCP connection requires at a minimum a couple of timers and an extra thread. If the socket is likely to drop then it needs a secondary process to monitor the connection to detect the dropped socket and silently reconnect."
It doesn't require those things. A single timer and no thread can work too because the process reading from the socket can do that checking. Extra threads are not required for recovering from a dropped socket. More importantly, most programs don't have threads in place to silently recover from dropped sockets because that may involve recovery on the process side as well. It is not automatically the case that if your socket is not working that you should open a new one and slot it in. Many protocols over TCP will want the side which reconnects to identify itself again, provide information on the last functioning state, etc.
"ACKs on protocols that already have ACKs (WiFi....)": No, that's two different systems with ACKs. Each serves a different purpose. The WiFi AP could I suppose do the TCP acknowledging for the user, but that breaks compatibility with wired networks which wouldn't bother with that. Implementing it on the wired networks, on the other hand, would require more processing in switches or modems to figure out which of them is supposed to be intercepting the user's stream in order to acknowledge it.
"TCP is not very reliable for long duration connections because of the problem of detecting a dropped socket and silently reconnecting.": Compared to alternatives, it's not that bad. If you want something that will stay connected for a very long time and you don't want it to drop, just arrange with the other side to send polls to one another from time to time. A single poll fail indicates that you need to reconnect. That works as well with TCP as it does with UDP.
Not for your use case it isn't. Here's why:
"secure remote working with a zero trust model."
If you don't trust anything outside your network, you do not let your users use personal machines to remote into that network. True, they can't install malware directly onto your VMs, but malware running on their personal device can watch them type and capture the screen. That's great for getting credentials, exfiltrating proprietary data, gathering intel, or convincing the user to take steps that give extra access. Most zero-trust environments, if they allow remote work at all, have custom machines which require the VPN activated to protect against the local network as well. No chance you would use personal devices if you need that much security.
I'm not talking about an organized VDI setup. I'm talking about the companies who needed to abruptly switch from in-office to at-home last year but didn't have laptops. I understand that some of them used those desktops as remote desktops from employees' personal devices. That's the only situation where such a cloud computer might be useful, as anyone who already provisioned the servers for VDI already incurred the expense of that approach and wouldn't be switching until it becomes obsolete. Even then, it's not that useful, as stated in that post.
That's likely not a problem. If they network the VMs like they network desktops, the existing sharing mechanisms for linking files together and sharing them will work just as well. They're Windows machines running in a different place, so you can install and run the same software. Not good if you need hardware access for something, but if it's just old software, it will run as badly on Windows 10 in front of you or Windows 10 elsewhere (latency aside). Still, that only says it won't break, not that it has any benefit to the users. In almost all cases I can think of, it doesn't.
"The proposition seems to be that you need to rent what is effectively a remote PC, probably with a lower specification than the PC (or, indeed, tablet) you already have in order to, er, achieve what, precisely?"
The idea is that businesses who currently allow their users to use their personal machines to work from home as long as they remote in to company-controlled boxes on which all the work is done could move those remote boxes into the cloud and save the annoyances of maintaining a room of desktops somewhere which someone has to maintain, reboot, etc. Which sort of works, but most of the places I know either have already issued their staff corporate laptops to use from home, aren't going to keep the workers at home anyway, or don't know (or care, but I hope it's know) about the security risks and allow their workers to do work from personal machines without a remote machine. Meanwhile, any company who is going to buy things for their workers to use as thin clients isn't going to need these; a cheap laptop costs about as much as the base level for this cloud PC for fifteen months and comes with double the RAM. So it's a solution for a use case that only a tiny group of people have and might not be great for that either.
"Can the geek community please get itself together to build the software for a consumer-friendly, fully distributed version of the internet and web, operating optionally through fixed nodes or peer to peer, and get it out there,"
Yes. We can. We did. Several times.
The original internet was like that. It still is like that. If you want more anonymity and censorship protection, you have darknets like Tor to do it (though know there are nasty people using them along with you). We have IRC for quick comms. Email for more sustained comms. Torrent for big file transfers. HTTP for websites and other public resources. Plenty of options for audio and video communication.
We did our bit. If it's going to get used by the rest of the public, we now need to get others to start using it. I run a Jitsi server for videochats which are encrypted and don't run through anyone else, but can you say that of basically anybody? People don't recognize it when I send them invites to it. Software is not your big problem.
Two reasons could explain this without having to jump to "the vaccines are not working". One reason is that people could still contract a mild case which won't be severe enough to cause them problems but could spread the virus to those who didn't take the vaccinations for whatever reasons. The second reason is that compulsory masking prevents people who don't like vaccines and also don't like masks from lying about their vaccination status so they don't have to wear the mask; if everyone has to be masked, then the unvaccinated people are enforced more strongly to do so.
"Can you put linux on an arduino?"
No, because the microcontrollers running them don't have enough ... anything to run it. You need more storage, more RAM, and faster processing just to start. However, there are a lot of similar boards with much faster processors out there which can run Linux easily. Not only are there boards specifically intended for education of which Raspberry Pi is by far the most famous, but you also have companies imitating the Raspberry Pi's usefulness and demonstration boards which chip manufacturers put together to demonstrate the benefits of their products. There is a wide variety out there, and for most use cases, a board already exists to fill them.
That's not a good argument against it though. It's a feature you don't need. I don't need it either. Yet I can think of several reasons someone might want a device they carry with them all the time, outdoors, through all weather to have protection against water. There are lots of things that I don't need or want, but that's not a good reason to ignore them when designing restrictions on everything.
The effort required shouldn't be high, but the price of the battery might be depending on the quality of the cell concerned. I have an old phone here with a replaceable battery. That device isn't working well--it periodically reboots for no reason--and my guess is that the equally old battery is failing to provide the needed voltage. Looking for modern replacements is giving me a lot of sketchy-looking cheap options and some ones that look better (though no guarantees) at pricepoints higher than the quoted Apple figure. It's not necessarily unreasonable for the price of the replacement part to be high as long as you do have the ability to put one in without getting a serial number check failing the installation.
I do keep backups, but a lot of people don't keep any or don't update enough. In addition, even though I've got a backup of the data, the computer I paid a lot of money for has been turned into a paperweight despite the fact that most of the components still work. Do you not see a problem there?
"An insecure library or binary would not be at all useful.": Wrong there. Most operating systems have been very insecure at many points in their history. They are still useful. A library which parses a format but is prone to injection is also useful though insecure, which is why people still use such libraries (especially serializers). People who don't know about security vulnerabilities frequently use insecure code because it is useful. Devs who don't care about security because they're bad at their jobs frequently ignore vulnerabilities in things because those things are useful. Now if you meant to say secure instead of useful there, I wouldn't be arguing this point. It's not core to the problems I saw in your suggestions.
"I was referring to the recent attacks via PiPy. But yes. All operating systems should have the ability to strace all read/sockets more easily.": Then we or you should write a better debugger. We have existing tools, and we can improve them.
"I guess your reply is a good example why pundits curtail security. Pointless conjuring flaws by experts who lack high technical knowledge.": This would be the case if the flaws I "conjured" are wrong. I spoke of many flaws. Care to explain why they're false? Because if I conjured any real flaws, they might either need remediation or at least acknowledgement before you forge ahead.
"But have skill in sounding at an expert level in meetings just by posting pessimism on the internet for self satisfying gratification amongst true professionals": Well, as easy as it is to lie online, I'll say truthfully that I work in security and have plenty of pessimism from my experiences there. The problems I see are ones that could impair the usefulness of your suggested approach. You don't have to believe me, but that need not be the important issue if we stick to more definite topics. Proving that I'm wrong about the database scaling size is easier than proving I'm lying about my experience. Moreover, the accuracy or inaccuracy thereof can be proven by collecting and working with public data rather than trading possibly true but unverifiable attacks on one another.
This is nearly untenable.
"1. Small sql lite database with MD5 hashes of repos.": If you do that for long enough, that's not going to be a small file. Creating the hash requires a foolproof method of hashing everything. Updating it is not a fast operation.
"2. Hash database can only be updated by signed gnupg key": And who is going to have said key? Because if you want your database updated regularly and you require a human to do it each time to properly sign with a securely-held key, you're going to get a burned-out human who clicks OK on every update that comes out.
"3. Develop algorithm of trust rated on 1 to 5. 5 is fully trusted. 1 is unknown and use at your own risk.": It's open source, everything's at your own risk. But let's leave that aside and look at how one gets trusted here:
"To achieve 5 library must have been used with no verified complaints for 12 months.": No verified complaints either means nobody uses it or nobody's tracking complaints. If you mean only security vulnerability reports, not complaints about bugs or performance, then you could go for some time without detecting those vulns. A lot of people don't check every task, so someone could be using it and not reporting the vulnerabilities which do exist.
"Other factors taken into consideration could be: from a verified developer,": Verified by whom, how? Confirmation that the developer is the one pushing out the updated code how?
"library has been voted as useful by select community members,": Useful does not mean secure. Lots of things that are useful also have long CVE lists.
"trusted security researcher has audited source code and found no backdoors.": A useful one. Unfortunately also a very expensive one.
Inserting a note here. None of these conditions are going to help when dealing with updates to code, which is often how malware gets in if it has compromised the supply chain. If you update a library to fix a bug and it's an attacker who submitted it, having compromised the dev's system (see also exactly how Solar Winds happened), the dev is the same, the software is the same, and the source is the same. Unless you're planning to force a 12-month change freeze on all updates, in which case A) any detected vulnerability will be exploitable on your system for a year and B) nobody will be testing it because they're all doing that.
"4. Background debugger logging and tracing file r/w and socket calls to the terminal in a safe running mode.": Sure, go ahead. Few people will do that, but the tools are out there for you to do it if you want.
This addition would allow users of a library to see what a library is doing in the background.
"Libraries ran with a rating below 3 will error without using a --force-non-safe-librsry switch.": How? The calling process checks the library? The same calling process which requested the library? Or maybe it's in the compiler so someone can put that switch in the build script and send the binaries out?
"We can all see where this is going: running all code in containers without access to the operating system or other components, unless granted.": Yeah, that might be a better starting point. Insulation of different processes has proven the most effective method of limiting the damage done by a successful attack. It's also harder to do because you often need the software to interact with that kind of data, but it could be worse.
"Want to use a USB mouse? There's no way of knowing it also hasn't been secretly engineered to be a boot device on the second Thursday of every seventh month."
Yeah, that wouldn't work. There are only a few profiles that can be used, so in this particular example, it would have to be a device that shows as a mouse and also adds a storage device on a schedule. Here are your problems:
First, you can block storage. Really easily. It's done all the time in secure environments--they just don't let you access USB storage. This includes during boot and while the OS is running. It doesn't take much sophistication to do that.
Second, even if that wasn't in place, there is very little chance just popping up a storage device will act as boot media. If it does so while the computer is on, then the computer has already booted and will ignore it. If it does so while the computer is off, the computer is likely to ignore it anyway because basically no computers are configured to try booting to USB media before the hard drive. This isn't the 1980s and floppies--I have booted USB devices on lots of machines and all of them after 2005 have required me to select that manually or change the settings if I want it to be the new default.
What if it's a keyboard which does that? Whatever the device looks like, it will tell the computer it's a keyboard. So you have three options:
1. Trust any USB keyboards, including the prospect of a malicious one.
2. Do not trust any USB keyboards, using something else to connect the trusted keyboard.
3. Go through a registration process to trust only a certain kind of keyboard. Some methods include only allowing a certain set of known keyboard IDs and therefore a randomly-chosen ID probably won't work or requiring the keyboard to enter a certain set of keystrokes to be added to the trusted list.
In any case, this has nothing to do with USB. A fake PS/2 keyboard could do all of the same things and you would have exactly the same trust problem. USB having the ability to connect multiple devices doesn't cause the keyboard attack. The closest it can get is that you can make a USB device that looks like something else, but the only way to solve that comparatively minor problem is to have separate connector types for everything which still doesn't fix the larger problem and also makes hardware a lot less convenient.
My guess is that the recovery laptop has the clients for the backup servers and the encryption keys which are not stored on the tapes. Destroy those and you won't be able to decrypt and you'll need a new machine even to start reading. Of course, I'm sure the BOFH has plenty of other places where those keys are stored for insurance purposes.
I doubt it. He wouldn't have to infect the BOFH's personal computer in that case because that doesn't affect anyone. From the description, the PFY appears to have really been sick. And we know that sometimes someone without the skills gets loose on a computer because they volunteered to help. I'm sure there are backups which this guy couldn't infect--there is no way they would let him get to the server room, but still a lot of work for them ahead which isn't going to end well for the clueless idiot.
You may have done all of those things, but that doesn't make those things your job. While the action of the tech in this case was something I'd never do (though mostly as I wouldn't want the consequences), I would have politely told them that no, it is not my responsibility to fix your lamp and I don't have the spare time to do so anyway. Had they asked me when I wasn't doing something related to my job and had they asked politely, I would have helped happily.
If I am the generally helpful person who does what everyone wants and because of that, I don't get my actual job done, management isn't going to care that I'm useful to my colleagues. They are going to complain about why the stuff they wanted isn't there, and I am going to face consequences. I will therefore not interrupt the important responsibilities of my job for people who demand my time without reason. I'm entirely on board with being helpful if I can do so without compromising that, but at some point, this is a thing I do by choice and therefore I may choose not to when circumstances are different.
Those are issues, not insurmountable obstacles. Thus, a company can decide not to care about them and nonetheless get what they expected.
Take the whole time zone issue. I currently work on a team which is all located in the same place but we have been working from home. Given the way we do our meetings and collaborate, I could do this without changing from up to four time zones away. If I was allowed to change the scheduling, I could expand that further. That's if we even have to meet on such a schedule. So it's not necessarily a problem to outsource to someone with a radically different time zone unless that doesn't work with the specific job. The other issues listed are similar--they can cause major problems, but if they're accounted for at the beginning, there can still be benefits.
"slogging away in a hot factory, whilst everyone else sits at home isn’t really fair."
No, it's completely fair. You could make the same argument about the previous situation. It would sound like this: "slogging away in a hot factory, whilst everyone else sits in a nice air-conditioned office and just has to type isn’t really fair." It combines inaccuracy about what the others are doing with complaints about the job they knew they were doing.
If the people in the factory have been subject to bad working conditions, that should be repaired. I can imagine a lot of ways that work could be terrible and a lot of valid complaints. However, complaining that a factory job is not the same as an office job is not as productive. The complaints are true; I would much rather work an office job, but making the experience of the office workers worse doesn't help the factory workers in the least. I'm guessing that they have more concrete complaints that would really help them.
If they're going to outsource, they could have done that at any time during the past decade. For that matter, they can do that just as well now. Some places have decided that their workers that are more expensive are still worth the expense. The question of whether they're worth the expense while not in the office is very different than wondering if you can hire someone elsewhere for cheaper.
In more pragmatic terms, there are a few issues with outsourced workers which companies know about and may factor in to their decisions. Time zone differences, frequent turnover in contracted staff, language issues, and administrative overhead of the outsourcer are all things that may change their decision. For workers they already have, they already know all those things and they're likely not to be very problematic.
This isn't really accurate. For example, you've mentioned Cellebrite, whose most well-known product is a tool for breaking into mobile devices. They aren't the only company to make products for that purpose. Another well-known one is Grayshift, which is based in the U.S. You can find companies producing malware with government support in many countries.
Israel is a special case mostly because they have an unusually large tech sector for the size of their country, and many of their tech people have trained in security-related issues and chose to make that the core of their companies. They just have a lot of companies in that area, meaning they're bound to have some well-known malware ones in that mix. Some of those companies also get unusual levels of support by the Israeli government, but that's not unique to them either. This doesn't exonerate Israel for the crimes its companies engage in without investigation, but there are other countries who are culpable of the same.
We don't have knowledge of everything in their code, so these points are based on partial information which has been released:
First, NSO operates several servers which are used to install and operate the malware. This means they know at least some of the targets because they are infecting them on behalf of their clients. We don't know whether it's possible to change those servers to ones that NSO don't operate. Similarly, we know that NSO has target limits where certain licenses are paid depending on how many devices you want to force spyware onto. That implies but doesn't necessarily mean that there is some mechanism for checking whether a client has complied with those licenses or preventing them from infecting others when they have run out of credits. This would also imply that they know when and by whom someone was infected even if they go to some effort not to know who the victim was.
More speculatively now, I think NSO must continue to control the malware after they've sold it because they are operating in a very ambiguous area. They do have some protection from Israel for some reason which has never really made sense to me, but if Israel decided they no longer supported NSO, there would be major problems for the company. Therefore, NSO needs to make sure that, whichever governments or groups (yeah, I'm not buying their claims) they sell it to, they don't sell it to someone who will cause Israel to abandon them. For instance, they could sell it to governments for repression of the local populace, but selling it to someone who would use it against Israeli government figures is something they'll do a lot to avoid. Making a version available which is easily controlled without their knowledge is an invitation to do exactly that. They have strong financial and safety incentives to control who gets to buy and who gets to be the victims, and I'm going to assume that they know these things very well.
"Your point about number of subscribers as a reason for it not being a stunt only holds up if you assume someone who makes a living from YouTube wouldn't want to make more."
Not sure about that. Deleting a channel could put a dent in your subscribers if you have trouble recovering it, if recovering it doesn't automatically add followers, and least speculatively because none of us who weren't subscribers can subscribe right now when the name is in our mind because the channel's down. If this were for publicity, it would be best to have it recovered really fast after the news broke so people could come watch videos. I'm guessing it will stay down long enough that I won't end up watching it because I won't remember to go looking for it days from now.
From the sound of it, you got hit by ransomware or something like it which destroyed your data. That means you don't have to replace the disk and could probably just wipe it and reinstall. I'm not sure if you've tried that, but unless they have some unusual method of actively destroying your disk or you had a coincidental disk failure, you might be able to resurrect it.
Back on topic, it's very useful to hear stories like this to prove to people that mere knowledge won't save you from all scammers out there nor does getting scammed mean you weren't smart enough to avoid them. I think this is important to better educating users including ourselves that the risks are higher than some might think.
Beats a company I don't work for and never have who decided that "resources" wasn't impersonal enough. They decided to call their skilled employees "human capital". I don't know how they treated those employees, but that always struck me as unnecessarily honest. Yes, it was a financial company.
