Re: Did we have this problem with telegraph poles?
It's Intercity Express, a series of trains operating in Germany which includes the infrastructure needed to run them, hence the overhead utilities.
11394 publicly visible posts • joined 22 Feb 2018
It's Intercity Express, a series of trains operating in Germany which includes the infrastructure needed to run them, hence the overhead utilities.
"A Baofeng UV-5r hand-held is quite adequate for free bi-directional multi-channel Satellite Communications."
Really? Because I just looked that up and it doesn't seem like it does that. It's a terrestrial radio which can transmit on two or three bands using a relatively low power limit. Assuming you have the proper license to use it, you should be able to communicate over a few kilometers to people using radios on the same frequencies. Satellites, not so much. There are a few satellites used by hobbyists which receive such signals, but they aren't permanently available--the site I found that discussed them told people to look up the availability times--and they don't relay your signal elsewhere, so no internet. I also doubt that it's easy to send your signal to such satellites with such a weak transmission. Am I wrong, or is this a completely different device with completely different use cases?
You are the one with the logic problems. The conversation into which you've inserted your comment surrounds a particular quote. You might have seen it in the original post as well as quoted in most replies. For all I know, you might have written it. It has a similar tone to the rest of your writing, though you're both ACs. Here it is, in case you didn't:
"And just how long will I be refused entry to locations because I don't want to get vaccinated?"
The key words are "don't want to get vaccinated". That's quite different to "got vaccinated and have privacy concerns". So do I. It doesn't change the fact that people who don't want to get vaccinated are putting others at risk. Your response doesn't even try to argue against that. So, I see three options:
1. You wrote the original quote, but you don't have any good arguments for it so you've switched your argument from "don't want" to "privacy concerns".
2. You didn't write the original quote, but you wanted to support it but don't have any good arguments for it, etc.
3. You didn't read the quote, decided to argue against a point without paying attention to what they said or what the person who they're arguing with said, and ended up out of context.
"I genuinely do not understand the opposition to being able to prove that you've had the vaccination."
I don't oppose that. What I oppose is a centrally-controlled register of identification to which data can be added. If they produced a card which had my picture and said I was vaccinated, and people looked at it and thought it was probably me, then handed it back, that would be ... well not great but we could talk. They're more likely to have a card with some codes on it which get scanned by a device which promptly uploads it to the internet where a server records where I've been. Why does the government care where I've been enough to store a history of it? They probably have no reason to want it. They probably won't do anything malicious with it. They'll let the person who breaks in and steals the data figure out the malicious use for it. Unless there's someone specific with access who wants to be malicious to a specific person, in which case they now can.
Meanwhile, having that card as a requirement to enter places has problems other than privacy. It makes any type of interaction less efficient while people scan the cards. It means that, should someone lose the card or forget to take it with them, they can't do anything. And perhaps most importantly, it isn't very useful right now. Just taking the time to issue cards to all those with a vaccination will take a long time. Eventually, the vaccination rates will increase such that pretty much everyone has one. If time B is less than time A, then the entire project is a waste of resources. Even if it's the other way around, it's not really that valuable when we already have a mechanism to protect ourselves when in public. When you also consider that the resources being spent on the massive checkpoint database could be spent on getting vaccinations to people faster, that seems like the better use of the resources.
I read the headline and assumed this would be an access point which allows devices to connect, then uses them to mine crypto. I had my "That's a security disaster and nobody will use it" comment all ready to go. Then I read the article. Now I have no clue what the device actually does.
It still sounds like the number of devices connected is important to how much crypto you mine, given that the article says "We expect that people living in highly trafficked, urban areas (like cities) should be able to make about 50 cents for every 1Gb of cellular data they transfer." Given that mining efficiency is based on processing power, this implies that having connections means you are using some of theirs. In which case, it's a security disaster and nobody will use it.
Except the article never expressly says that the client devices do the mining. It does say "FreedomFi yesterday announced it has buddied up with Helium Network to mine the latter's native crypto-coin on Magma-based 5G gateway devices in return for dispensing signal." Also, I'm not even sure how they would plan to make the clients mine for them unless they had previously installed software, which would dramatically limit the number of clients available. But in that case, why does it matter how many clients you have--the CPU in the access point can mine as fast as before.
So maybe I'm just not reading this right. If what is going on is obvious, I didn't get enough sleep and I'll stick to that story.
"Imagine what computers would be like if "ease of ownership" had kept pace with memory, CPU power, or network bandwidth."
It did. However, computers also gained extra functionality. You can have a really simple computer if you only want it to do a few things. If you're interested in it doing lots of different ones, things get more complicated. Just like you can have a car which is easy to drive, but if they made one that could also fly and sail on water, you'd expect some more buttons on the dashboard and items sticking out the sides.
"Of course, if that happened, we wouldn't have "dumb users" to kick around, and where would the fun be in that? And I know all you IT admins, jealously hoarding your hard-won knowledge like dragons sitting on your treasure,"
Now really? I'm not in IT (programmer), but I have done my share of admin and support and I don't want to guard my knowledge. If people stopped coming to me and asking me to fix their broken stuff, that would be great. If there was a miraculous way to never have problems so I could just write my code, I would really like that. There isn't. There won't ever be, because when people try too hard to get it, they break things silently and then the users come to the technical to fix it. For example, Apple really likes hiding information from users to make things easier. This meant that, when they changed the filesystem they wanted to use and their computers didn't complete the change correctly, the users had no clue what had happened or why. They brought them all to me for me to fix the partition disaster and perform reinstallations as needed. By the way, I would be very happy if Apple didn't make any mistakes and I didn't have to do that.
"ultimately wouldn't you rather live in a world where you didn't have to deal with all that crap and could focus on challenging, interesting, and high-value stuff instead (or just have a lot more free time for play, whatever)?"
Yes, I would. And when you have a way to get there, let me know. Until you have that though, there will be a need to keep users from making security holes or operating critical activities on unreliable systems.
"It would be our fault for failing to implement a viable alternative to IPv4 over a decade after its limitations started hobbling the Internet."
Wrong. The Chinese proposal doesn't supplant IPV4. Also, we have a replacement for that: IPV6. Despite some issues with backward compatibility due to more IPV4 design mistakes, it's gaining usage. China's proposal replaces TCP, not IPV4. Try again.
"The big commute is something we've done to ourselves. For excellent and well founded reasons no doubt, but still fundamentally self inflicted."
No, it wasn't. I say this as someone who has a short commute, but still. The big commute is a result of companies putting the offices in a place where people can't live nearby. The companies have their reasons, that they want to have lots of possible workers and clients in close proximity. The people who live far away have their reasons, usually that they can't afford to live closer. If you don't have in-demand skills that make your wages relatively high, then you will have to choose a place to live where you can afford it. That's unlikely to be in the big city.
Meanwhile, the company is the one making most of these decisions. It's not exactly their fault, because they also have to do that in order to work well. If a company requires a hundred workers with a certain skill to come to the office, they're unlikely to put that office in a small town where they would have trouble finding those hundred or replacing someone who leaves. Still, they're choosing the predictable expense of expensive real estate rather than the unpredictable one of having trouble finding workers, meaning the workers have to choose the long commute. Rarely is it the employee's choice.
"Which? said: The biggest reason for not reporting adverts that caused a scam to Facebook was that victims didn't think the platform would do anything about it or take it down – this was the response from nearly a third (31 per cent) of victims."
Most online platforms don't bother doing much about fraud or abuse on their platform, to the extent that it's basically pointless trying to point out problems. Take a recent attempt I made to take down a phishing site. It used an obviously malicious domain name purchased from a registrar and also hosted the server on resources from that registrar. I sent a message to their abuse system notifying them of this. After two days of silence, I received a message informing me that the server they hosted with the registrar redirected the link to a server run elsewhere, so they could do nothing. Yes, the company which could revoke the domain name and thus disable all links going to it or revoke the server doing the redirection and obtain the same outcome could do nothing. If they don't want to do anything to save their income stream, why do they bother spending money on people to come up with excuses for why they're not going to take down fraudulent things? A bot which just says "We reviewed and think it is legitimate" is much cheaper.
That helps, but it isn't sufficient to make the astronomers concede that it's fine now. Everyone has a different opinion as to how they value each group who wants to do something. You could easily argue that you don't care about the astronomers' complaints. Arguing that the astronomers have dropped their complaints, however, is not going to work.
"The M1 has a dedicated x86 interpretation chip, so the performance should be pretty much there except for higher-end applications which are utilising the more powerful assembler instruction sets for x86/64 chips."
Misleading or wrong. The M1 has extra functionality to improve the process, but it doesn't have a separate chip for X64 operations. That would essentially be a dual-processor system. It doesn't have that.
"Unsure what you mean by the Samsung A11 comment, Samsung do not make CPUs."
Now here I'm torn. I also don't know what they mean, but you're wrong here. Samsung do make CPUs. The Exynos range of ARM SoCs. They aren't the fastest out there, but they're still making them. So probably the original comment about them "throwing in the towel" is wrong too unless it was referring to something minor I don't know about.
I generally agree, but I suppose we all have different requirements. For example, I don't want an optical drive. I'm not sure what you're doing that requires one so often, but I have only used one occasionally and the cheap USB one I have is sufficient for the task. I don't find disks around so often these days. I would like some USB-A ports for flash drives, but I'm sure there are people who rarely use those too. I'm entirely with you on the desire for a large and replaceable battery.
"Customers would know when a new product was going to be announced because a successful product would be nearing its mandated end of life, so would hold off buying the latest version of fondleslablet* knowing that a new release would basically have to be around by a certain date."
I don't think that's a problem. If the guaranteed support lifespan was five years, that's already much longer than the typical cycle. IPhones are good examples of this--they already have about 5-7 years of support, yet they make a new one every year. People tend to buy new ones for the features or because their previous one broke. Most people either buy one when they decide it's good enough or keep their old one until it doesn't work anymore. They do tend to wait until October to see whether the new one is interesting, but they won't wait the full five if they're considering a purchase already.
This is exactly correct. It's a deliberate antitheft measure. Sure, it can be annoying if you don't know the details to unlock something, but I think most nontechnical and some technical people would prefer the +-
protection against theft given that someone with the proper details can erase and reuse the device. Android with Google's services does the same thing.
The law shouldn't ban publishing the default passwords. It should ban having a default password. Out of the box, it has no password. When someone wants to use it, they have to set the password. If they forget the password, they use the physical reset and it loads the factory firmware, allowing the user to set the password and reconfigure.
Now for things given to less technical people, this can be annoying. I know for a fact that my family does not know the passwords to their internet equipment because I set it up. However, they need to balance the risk of annoyance for people who have to set a device up from scratch versus the security nightmare of having lots of things with default passwords. If the default password is "password", "admin", or the product name, not publishing that is not going to stop people figuring it out.
Not really. Sometimes that's a problem, but most of the time, the stumbling block to third-party support is that the manufacturer has locked down all the things that you need. Custom versions of Android can run on phones with most kinds of SOCs. Certain ones are harder, for example because Mediatek doesn't release information about some of their chips, but the developers can get around some of that. Manufacturers have even less excuse, because they have access to documentation that we don't. They could update things but choose not to. Third-party developers can too as long as they have access.
"I’ve worked for organisations with “secure facilities” in rural areas miles off main roads and have procured diverse data circuits along with diverse power to ensure their ongoing operations,"
Very nice. Not very useful though. You can do lots of things to improve a network connection. All are expensive and in this case, none are needed. The server concerned is required for operations inside the building. It is not required for operations outside the building. Why should they spend on lots of network links just to show they can put the machine outside the building anyway?
If you want, you can buy a refrigerated vehicle and hire a full-time driver for it, just so they can go retrieve chilled food and bring it back to you. Or, you can have a refrigerator in the kitchen. If the only person eating the food is you, it's a lot cheaper and faster to chill the food in the kitchen. That doesn't make the vehicle idea bad in all cases--you might operate a business where you have to bring chilled food to lots of different people. Still, you probably don't own such a vehicle and you have a good reason not to.
"If big tech or media doesn't like your message - there is no debate of ideas, you just get canceled."
Not true in most cases, and not true this time either.
He was being paid (in Azure credits evidently) to post advertising about Azure. I don't know why; it doesn't seem like a good business decision in the first place. He didn't like that. I'm with him--I would only be willing to post approving comments had I actually compared two options and thought one was significantly better. While I wouldn't mind getting money from the better one for the post, I would probably not take it because it would weaken my credibility by implying I was biased toward them. He complained about the program he was in. Is it that surprising that the people running the program figured he wasn't a good person to have in it? He didn't want to do what they wanted him to do.
"you could just add more internet connections."
Oh come on. The stated use case is about as clear a don't-use-cloud situation as you could imagine short of an airgapped environment. It's not cheap to run extra internet connections which you intend to be redundant. Cable connections may use common infrastructure, so you either have to pay for installation of alternate paths or hope that an issue with one won't bring down the other. Fixed wireless connections may not be available depending on the size of the factory, are prone to congestion, and may use common infrastructure as well. Satellite might be the best alternative to avoid those problems, but that also depends on the weather and available satellites. Meanwhile, from the sound of it, the server doesn't do anything for people outside the factory, so it's a lot more important that it is available to the other things in the factory than to the outside world.
There are at times advantages, sometimes significant ones, to using the cloud. However, even if the cloud providers manage to improve their uptime to 100% and reduce their prices by an order of magnitude, there will be some cases where it's still not the right decision. A situation where the users and the cloud are separated by unreliable or limited network connections is one of those.
Exactly. The question is not detecting a single malicious commit, but instead identifying how bugs happen. Whether deliberate or accidental, the goal is not to have them. So look at how they came to be and see what patterns there are. Is there a type of bug that doesn't get caught often? If so, can testing or review be improved to detect it? Is there something that reviewers consistently fail to catch? What is it and can something be done to draw their attention to it? That's real effective research.
"Isn't there now a risk of a Streisand effect, where lots of other people will try & sneak code in 'for fun", since it's been proved to be possible."
I doubt it. It's not very easy to introduce something just for fun. Submitting a basic patch allows people to say they did something and not have someone angry at them.
"Might have been better for the kernel folks to have just had a quiet word with the Uni, while improving the processes which allowed this to happen."
Oh no it wouldn't. If people were going to tamper with the code, the research paper itself made that idea public. Keeping this quiet would have left that paper as the last word. What the Linux kernel community has done now is to demonstrate that maybe you can insert useless or dangerous code into the kernel, but if you get caught, they will target you with all the power they have. They have established a deterrent to people contemplating pulling the same kind of stunt.
It works all the time. If you're going to penetration test someone who asked for it, you coordinate with the person who hired you that you're going to do it. You don't tell them all the details, but they need to know who you are and at least a range of time you might do the penetration. That's so that, if you fail to penetrate and end up in the security office or the police station, they know to vouch for you.
I think that comment is missing the point.
"Still, one should question whether the policy of "Don't probe possible vulnerabilities because it might upset us" is such a great idea in today's infosec security targeting world."
Probing vulnerabilities in the code is important, and the Linux community doesn't have a problem with people doing that. Nor is there a problem looking at the ways people operate and suggesting that such ways lead to security problems. The key is that observation of others is good and probing of your own systems running others' code is good. Probing others' systems without permission is a very different story.
Consider a parallel. Penetration testing is important to ensure that security procedures are sufficient and followed. Hiring a penetration tester is a good idea. However, being a penetration tester of someone who didn't agree to it is not. At best, you have people angry at you though fixing problems you've demonstrated. At worst, you end up in jail. If these researchers had gained the agreement of someone in authority on the team that they would run the experiment, the community would probably be reacting very differently. They didn't even try to get permission.
Because collectors are weird. They will find something you can possess and that there aren't many of, and they will decide that it holds a ton of value. Because there are multiple people doing this, they end up looking sort of right as they exchange their useless items with each other and sometimes make money doing it. Meanwhile, I, and probably you, look at them and think their items are nearly worthless. Especially true when the items concerned have some purpose because the collectors will frequently not use them to preserve the condition.
What we should do is look through our junk and see if there's anything in there which has now become rare. For example, I have a sort of PDA thing that's about twelve years old. It was pretty rare even when it was manufactured, the company made a small batch, they went out of business in 2012, and the internet doesn't even find anything about it unless you really know what to search for. Of course the device isn't very useful now--it's got an ancient Linux kernel and no package manager. The update server is long dead, and the OpenSSL library doesn't support very much so it can't do much with the browser or email client. That's a great thing--that means most of the people who bought one have probably thrown it away by now where I just put it in the closet. So all collectors, call out offers.
The hardware designers certainly do attempt to construct the phones well. They want it to not bend, not overheat, and be thin and stylish. They don't spend so much time on not gaining scratches, not shattering, and being easy to hold. I have never broken a phone screen, but I know people who have. I also know that the glass on the back is easier to shatter than the glass on the screen, which makes things worse. They have also managed to reduce the phone's friction coefficient so low that they are almost ready for first-level physics class. The result is that people put them in cases so they are less likely to be dropped and more likely to survive if that does happen.
Connecting an Arduino to WiFi is a pain. It can control the light bulb or whatever other thing you want automated, but if you want to control that thing remotely, you need some communication mechanism. WiFi or Bluetooth are commonly available, but neither runs on an Arduino unless you attach something else to do it for you. That's another set of chips you have to buy, power, and maintain just so the original controller can be contacted. What's even more pathetic is that the controller for the communication is usually an order of magnitude more powerful than the controller the main task is running on. If you don't want remote access to the device, then an Arduino is probably fine. If you do, it makes sense to use the processor which does that communication to do the automation task as well. Unless you can't work out the low-power modes or you need custom control pins the comms chip doesn't have, that will be the simpler and more efficient solution.
I think it might be possible to allow interventions like this, where the systems themselves aren't directly entered but the malware's control system is compromised. The major restrictions that are needed are A) they shouldn't be allowed to extract data from the system including telemetry about their removal, B) they must not push any binaries or scripts other than a removal, and C) they must publicize what they have done. If those restrictions were clear, I wouldn't mind actions to cauterize malware by invoking its self-destruct mechanisms.
If the organizations concerned intend to spy on the operators of infected servers, they already know how to do it and they won't ask permission. This is a separate issue, but just banning something like this won't fix the problem because those agencies have already made it clear they're willing to break the laws. Meanwhile, if the agencies are investigating the operators for crimes, they can get legal warrants allowing them to collect information. So what is made possible by allowing this which wasn't already possible and frequently used?
Really, why not? Each of those countries, though small and economically troubled, has managed to set up the resources to build nuclear weapons. That's expensive and difficult, but they wanted it badly enough that they have done it (well, giving Iran a bit more credit given we don't know how far along they are). Building a few teams of smart people capable of breaking into stuff isn't that expensive in comparison; you need some computers, some smart people, and for those people not to have great alternatives like working for a tech company. Why couldn't North Korea or Iran manage those requirements?
"(yet, my instincts tell me that there is more to this - how far down DOES that rabbit hole go?)"
Then go digging. You have the freedom to do it. Just don't complain if you find the security researchers know more about it, having researched it for months, than you can find out. I've seen nothing which suggests Russia couldn't or wouldn't have done it. Nor do I find any major flaws in what I've read so far attributing it to them. The opportunity's always there if you can prove them wrong.
But that's not trying to mimic Windows. MATE may have similarities to Windows, but it wasn't designed to make transferring people easier. The desktop environments which were designed to look as much like Windows as possible are just getting tiny details the same while ignoring the large chunks which won't be. MATE clearly isn't Windows but uses enough of the same concepts that people can figure it out quickly.
"I would be VERY interested in seeing what the political spectrum of Micros~1 employees are, how many voted for Trump in 2020, how many are registered Republicans, and so on. Was THIS (or anything related to it) in the survey?"
As you can imagine, a survey about what the employees think about the corporation doesn't include extra useless questions like that. A good thing too. If my employer ever asked me something like that, they would get A) no answer to that question, B) no answers to most of the following questions because my focus is no longer on their survey, C) a cold statement that the question serves no purpose and is inappropriate if the survey contains an "anything you'd like to comment on" question, and D) reduced performance from me while I consider whether that's actually where I want to work.
Not just that--the second SE is half the price of the mini. If we assume that people who want small phones don't need 5G and are fine with recently-the-fastest-but-now-the-second-fastest processor, it makes a lot of sense that they wouldn't really see those improvements as deserving a doubling of the price. I hope there is a market for small phones as I am certainly in it, but my needs are small. I don't need a large screen, and I don't need a fast processor, many cameras, or 5G (though I don't mind that one). I am not interested in a small flagship phone. I'm interested in a small low-to-mid range phone.
"I also wish people would stop calling GNU\Linux background drivers daemons. That REALLY bothers me. Please stop it."
Why? Daemon is a term that's been used to describe exactly that sort of thing for a while. In fact, not only do I have no problem with daemon, I wouldn't like to call them "background drivers". I view drivers as controlling something else, especially hardware, for a separate process or the OS as a whole. Lots of daemons or whatever they are don't do that. So I'm going to prefer daemon for that type of program unless you have an argument for it.
Also, what's wrong with Python as a name for a language? Language names are pretty much all arbitrary words or letters. You don't seem to have a problem with Perl as the name of a language, and that's not even spelled right (it was going to be named Pearl, but there already was something called that, so they just chopped out the A and went with it). Why is Perl fine and Python not?
That's fine, but not really complete. There are lots of subjective elements. What should the assumed environment be? Does the user use a single laptop screen or two large desktop screens? If there is a possibility of a mobile user, two interfaces or one interface? Should the desktop interface look like the mobile interface with additions so users who use both are familiar with it or should they be made to look like the interfaces of the devices they're running on so that actions are fast on each one? What are the key actions to be taken? Should the action be made fast or have lots of options? Should there be two choices for the same action just so one is fast? What about aesthetics?
As I've stated, I am not an expert on this and I don't want to be one. Still, there is a lot of subjective stuff when designing UIs. I subjectively think the Office ribbon is bad. I know a lot of others who also think the Office ribbon is bad. Microsoft stated at the time that it was better for feature discoverability. I'm sure they've done some tests on it. I've also heard people who don't think it's a problem. Similarly, I've seen such discussions about the window systems on Windows, Mac OS, and various desktop environments for Linux/BSD. Each group has some statistic they'll bring out for why their desktop is better. Each looks nice and numbery, and probably has some validity to it. Yet there is no agreement about which is best. Because it's subjective. That doesn't stop a bad interface from being bad for pretty much everybody, but it does eliminate the ability to find the epitome of excellence in UI design.
The developers could be doing that, but they could also have a point. UI is very subjective. There are lots of UI changes that some people think are better. Others will hate them vociferously. Also, changing the UI is a guarantee of annoying most people. So it does to some extent depend on what change was suggested and how many people were familiar with the previous one. After all, if you maintained an office program and someone suggested you throw out all your menus for an ribbon of buttons which always seem to move when you're not looking, would you do so immediately?
In my experience, I try to minimize UI changes after the first non-beta release. Suggestions for redesigns only get through if the change is small (and I think it makes sense) or they've written a long, detailed description of why this improves the system and how users can be made familiar with the change. Improving the UI because "I know more about usability than you do and this approach is superior to yours" won't happen; both of those points may be true, but that's not enough for me to start from scratch with no support. Fortunately, I rarely have to deal with this because I don't like working on UI stuff and try to either stay to the backend or keep it simple.
"if your project has non-developer users and some sort of feedback mechanism then I think you should expect feature or usability requests."
You should, and you should take some of them. I do wonder if some of the negativity with which feature requests are received is due to users who ask for the impractical all the time. I'm on a couple of mailing lists for open source projects, some of which have quite a few non-developer users. I've seen plenty of normal feature requests which should get real consideration. Sadly, I've also seen people asking ridiculous things and not stopping when it's explained why that's not feasible.
One person wanted us (well, in that case I was not a core contributor, so them) to add a proprietary component because they preferred it. We pointed out that A) the software was GPL and the component wasn't, B) the component wasn't free, so in addition to changing the license we'd have to buy licenses for it, C) the software we produced was free to users so we'd just be losing our own money trying to do it, and D) nobody but this guy seemed to think this component was any good anyway. This was not the end of the bombardment with emails asking why we weren't going to do it. For another example, there was one person who wanted the project's resources translated into Slovenian. That's fine; the work had already been done to make things localizable and there are existing translations. No, that's not what the user wanted. They wanted us to find Slovenian translators and have them translate the resources even though none of us spoke it. I volunteered to simplify the process of creating the localization files so they could produce a translation. This was not the right move. This particular episode included some angry missives from the requester.
I wonder if the treatment afforded proper feature requests is due to things like this. If I as a developer think people will ignore me when I state reasons why I can't or won't implement something, I might be more likely just to ignore most people and only pick those feature requests which struck me as the most interesting. That doesn't make that the right approach, but it might go some way to explaining it.
That is possible. The traditional ways to type in Chinese are drawing the character or typing a romanized equivalent and selecting the correct option from a list. Each spoken character is pretty fast. Depending on the user's speed at handwriting, speech recognition could be very helpful if it's effective.
My suggestion for those people requiring anonymous contact is to continue to allow sending no number to caller ID. An unknown number can't be identified and can't be called back. That's better than faking someone else's real number. If scammers use the unknown value and people start ignoring it, that's their choice.
This isn't feasible and doesn't solve the problem. It's kind of like the people who block IP blocks from cloud providers or various countries--if you can do it, it only blocks them for a few days before they move but it does negatively impact others. In this case, the scammers already appear to be coming from the U.S. because they use companies which are based in the country who in turn don't tell you where they got the line from. If this was prevented, the scammers would find new ways to route onto the U.S. network and lie about it with the assistance of the same kind of companies. Meanwhile, if you ever did get contacted by a call center, likely a callback you requested from some company which outsourced it, the call would be dropped.
One thing that would make a much larger dent in their operations is a caller ID system which does not allow forged numbers. If they couldn't keep changing their number, they would be easier to block, since phone numbers aren't completely free, but they would also be easier to track. A complaint against a fake number gets automatically discarded today. A complaint against a real trackable number can identify a caller or at the very least the unethical company willing to front for them. That can lead to much faster action.
This research only covers people convicted under the Computer Misuse Act. As stated, people who commit larger crimes will likely be charged and convicted under something else, like the laws against theft, because they are easier to use in court and lead to more definite sentences. It also only includes those people who operated on a large-enough scale to get the attention of the police, who didn't do enough to cover their tracks, and who didn't do so much that the really determined and skilled investigators got brought in.
That doesn't make it work. If you play with a sufficiently large group, the chances are incredibly high that one of these things happens:
1. Everybody lands on properties and buys them immediately because they have the money to do so. They thereby block everybody's chances at a monopoly. People then circle the board paying low rent payments to each other and hitting the random squares from time to time. Often, there's one property unclaimed which could give someone a monopoly except nobody has landed on it all game.
2. The same thing happens but someone manages to get a monopoly. They have one and nobody else does, so they are going to win. Unless the other players concede then, there will be a long death spiral as people don't happen to land there this time around or the player with the monopoly gradually builds up the capital to build more houses.
The more rare options just result in the game ending faster, not the game being any more interesting.
I think most of those features should probably be limited to their pro plan. Then again, a business can usually have a protected internal network through which files can be transferred. Still, individuals probably don't want most of those features and implementing them will take more resources. Since those are mostly for business users, it makes sense not to give them away.
It's not scanning the whole internet. At most, it just has to advertise its availability to the server which can connect it to the other machine. Machines which have not contacted the server need not be scanned. Machines which don't have a connection established also need not be scanned. That cuts out nearly all of the internet, and it is only necessary to check on the computers involved in the transfer, so that's probably 2 though could be 3-8 theoretically. That doesn't explain the CPU usage.
We can do both of those things. The problem is that doing so takes some effort. Some people want it to be doable with a click of a button. If it is that easy, then every transaction will receive a button press and the data will be on file. On the file of the police for easy tracking of criminal activity. On the file of the police enforcing a dictatorial regime. On the file of a police officer who doesn't mind using it to stalk someone. On the file of an advertiser who thinks they can use it to sell stuff better. On the file of an abusive family member. On the file of an unethical journalist. On the file of your boss.
Sometimes, we have to concede something which makes it easier to commit crimes because it supports others' ability to live a life without oppression. If we didn't have to, we could eliminate all crime, or functionally so. 95% of crime would be impossible, 4.99% of crime would be possible but nobody would do it, and 0.01% of crime would be detected immediately. You would not want to live in that world, especially if you ever disagreed with the people who decided what crime was.