Posts by doublelayer 10333 publicly visible posts • joined 22 Feb 2018
You know that a lot of instructions are burned waiting for data to get to the CPU just from RAM, and that you have to put a lot of data into RAM from the disk which takes even more instructions, and that read speeds are reported for large, continuous reads, not reads of small files? I don't want to state the obvious if I'm missing a rhetorical question here.
"This removes a reliable, in situ communications network that could easily have been developed and repurposed - perhaps as an internet for kids with whitelisted content."
I can't say I like that idea. You want an internet for kids, you build one, but you don't need your own wires for it. What would be the point of that? Just to make your new internet tremendously more expensive and unavailable than using the same wires the normal internet uses? Don't expect me to embrace any part of the idea, either. I don't see trying to slice the network into pieces as going anywhere useful.
"If CPU's are so fast why does it take 10 mins to log into windows 10? What is it doing? Nothing useful, trust me I've looked into it."
Probably nothing useful, because my computer can manage it in about two seconds. My really cheap computer can manage it in about two seconds. My old computer that shouldn't be running Windows 11 according to Microsoft can manage it in about...2.5 seconds. So if your computer takes ten minutes, one of two things is the case:
1. It's not Windows. It's something that's starting at login and doing so badly, which might be something you intend to start or a big stack of malware.
2. Your computer has a problem, probably a disk problem.
Look into those.
Of course they do. At a basic level, who you're supposed to pray to and what kinds of praying are really bad. The Greek gods said that killing a cow in their name was a great thing to do. Hindu gods take that very differently. If you're going to interact with cattle, figure out which if either of those sets you're dealing with, or more likely which set of believers are watching you, because if either set of gods exist, they don't seem to be doing anything about the issue.
I don't think those advertisements were about buying things. For example, this paper and others have frequently described how they intentionally put in ads claiming to offer services they oppose so that people seeking those services get confused and go to them. What happens after that may depend on the group, but at the very least, they have the name of the person and they've wasted the person's time. There are worse options available.
The advertisers probably don't care that 3% of the visitors don't see their ads because they won't end up paying much if anything for those people, so it's all the same to them. The publisher sees 3% of the people using their service with the costs associated with delivering it and would like to try getting that revenue back, because what do they care if none of those people buy the advertised stuff? From the publisher's perspective, either that person starts earning them some revenue or that person goes away and they no longer have the costs of providing the service to them. This makes more sense when it's something like YouTube because it's a lot more expensive to send videos to people than to send a text article. That's from the perspective of a person who has done neither, but I'm pretty sure that is what they're thinking.
The question is how large the group of advert-antagonistic are and how strong their antagonistic reaction is. I am probably in the group, but through a combination of blocking most ads and being able to ignore them more than some people I know, an ad really has to work at it to annoy me enough to get me to dislike its origin. I doubt you're keeping a full list of all the ads you've seen so you can avoid the businesses, especially as many of those would probably either be something you were never going to buy or something you have no choice about because it's the only supplier that offers an acceptable choice when you need the thing they're selling. So if the group is relatively small, those who push the adverts may view it as unimportant, and if the group is small enough, they could even be right that annoying those people and losing their business is cheaper than figuring out who they are and leaving them alone.
And, with a protocol like TOTP, you don't have to. Do you think Google and Microsoft are doing something nefarious in their apps? Okay, use a different one. It even works to use a non-Microsoft authenticator on your Microsoft accounts and a non-Google one on your Google accounts. The recommendations of these are because they're available, likely to be supported for some time, known to come from secure sources, and believed to be trustworthy. You are free to disagree with these assumptions, although I don't, and having an open protocol means you can manage with that easily.
The law does not say "using phone numbers for login is forbidden". You probably have a point if, as I understand your report, the phone number alone can reset all other factors and allow taking over the account. However, you're going a lot further than that by claiming that the law forbids them using phone numbers as an identifier or security method at all, and it clearly doesn't. Lots of services use a phone number as a true second factor, where it AND something else are required to make changes, and that has never been the subject of any GDPR penalty. Nor is there necessarily a reason why it should. Using a phone for MFA isn't great, but it is more secure than not using it, and GDPR does not say that not having MFA is forbidden either. I'm not sure the valid point is going to be accepted, but your other one certainly will not.
That's why most services offering TOTP either built their own app to issue the codes or recommend one specific, reputable authenticator app, usually either Microsoft's or Google's. The benefit of something like it is that it is open. While email may have gotten some "value reduction" as you call it by being an open standard, it is still better than alternatives because it can be used nearly anywhere. I prefer TOTP to a mandated single provider because I get to decide where the authenticator is. I don't need to install their app on my phone if I'm not using the service there and I can move keys to a different one as I choose. If I want to use an authenticator that has more security precautions, I can do it without begging them to support it.
I'm not really sure why this is relevant, but I'm willing to discuss it anyway. Mobile providers don't have to allow it; they offer a network and this is a thing you can use on a network. They don't really get a choice to permit or forbid such things. If they took actions to block communications methods like this, they would likely be punished by the law because it would be considered an anticompetitive action, an abuse of monopoly powers, and, where common carrier status is part of the law, it would violate the regulations on them and risk stripping them of that status.
They also have no reason to do so. Users of such applications are still using the mobile providers to send their traffic. When they choose to do so, they must pay the mobile providers for the network traffic they send. It doesn't matter that the providers can no longer read the messages because they agreed to provide a service delivering bytes and the user has purchased and used that service. Your analogies are mostly if not entirely flawed; the sender and recipient know well that SMS and WhatsApp messages are not the same, the deliveries use the same network rather than an alternative, and there is no cost to whatever telegraph forms were supposed to be (they both construct their own message packets and making packets is effectively free and the costs are borne by the user's device anyway).
The latter is a valid concern and Facebook should have to change their system so that just having the second factor is not sufficient to gain access to the account. I'm not entirely sure how this process works as I do not have any accounts at Meta, but it sounds like there is a significant design fault in it if just having a phone is enough to reset the password (that's where you make someone use all the factors).
The former is the user's problem: if you change your phone number voluntarily, you remove it from accounts before relinquishing it, not hoping to do so afterward. The same applies to literally any other contact mechanism. If you stop using an email address, physical address, domain name, private key, or any other thing that is used to identify or authenticate you, you should activate the new one before deactivating the old one or risk getting locked out and you should deactivate the old one so it can't be used to compromise the account.
You might want to reconsider this site then. This is for profit, after all. Not all sites intended to make money are the same. I block ads as well, but I don't object to sites that exist to make money for their writers, including ones that require payment to use them. I only pay if I know I value the site that much, but it's a perfectly normal way to run a business.
The protocol isn't as simple as load page, send money automatically. There are manual controls on this and it's being run in the browser, meaning there will be even more settings. Most of it is probably manually pressing a button, so loading a hundred times will do nothing. The people writing this aren't complete idiots, so they'll also know to put some kind of cap on it to prevent the headlines of a massive macropayment. That won't prevent there being other problems with it, but it won't be something that basic.
Books are one of the main things I think of, not because Amazon's still mostly books, but that's one of the things I used it for. When I was a student and needed textbooks, I could buy them new from my university for way too much or buy used copies, and those copies were usually easiest to find on Amazon. A typical book shop wouldn't have them, other online sites would make it hard to determine whether I was getting the right thing and wouldn't necessarily have what I was looking for. Amazon was a reliable source. And when I was done with them and the new ones I had to purchase, I could sell them back on Amazon to next year's students. I'm not sure either works well anymore, but this was well after they expanded into a market with things other than books. Amazon still recommends textbooks to me on occasion, so you can see how much I used that.
The theory of micropayments is not a method of charging people for subscriptions, but quite literally "people being nice and tossing a few pennies to sites they like". That's why it doesn't work. Still, if that's what they're building, then it will be the not working version rather than the empty your wallet automatically version.
I agree on the first, disagree on the second. I have a few places on YouTube which I enjoy, although not very frequently, but most other times I end up there or get links to it, I'm disappointed. Whenever I do a search for something and get YouTube links, I mentally sigh because I know the chances are high that this video will take five minutes, even at the fastest speed, for me to realize that they know nothing more than I did before I did the web search. I've been recommended videos when watching one that was interesting to me, but those recommendations have rarely if ever proven even slightly as interesting. So I agree that there's plenty to like, but I don't think it's that easy to avoid the rest.
Except if it's seven years old, it's got POPCNT. It's going to have to be about fifteen if it lacks it. I'd prefer if they hadn't done it as well, but while the restriction on 7th-gen Intel parts is a problem, restrictions affecting Core 2s are less concerning to me. In my experience, people with hardware that old have to be dragged to update their operating system anyway, and they're going to need a new computer when something breaks in their old one and isn't economical to bother repairing.
I'm not sure what this was meant to tell me. Its number is similar to mine if we let them use the generalizations that don't fit the situation: their algorithm assumes one iteration per bit, and their loop will need more instructions. If the loop is not unrolled, there will be jumping. Even if it is unrolled, they need two instructions per cycle. One to shift and one to add. That comes to 128 instructions for a 64-bit register or 64 for a 32-bit one, which is close to the 70 I estimated. I'll stick to 64-bit ones for the other approaches.
Their alternatives aren't necessarily better. The lookup table cuts it to eight cycles containing three instructions (assuming my mental compiler isn't as rusty as it probably is) but it uses 256 bytes of memory which will need to be cached and originally calculated.
The third method loops through each set bit and performs three operations (subtract, and, add). So for a value that's mostly zeros, it's great, but for all 1s, it's 192 instructions.
All of these are also destructive to v (the value being checked), so budget in time to replace the original value from cache. Of course, actually telling how fast these are will require figuring out how fast the instructions are and how fast POPCNT in hardware is. I only estimated instruction count, not running time, but I'm guessing the hardware one is faster or they wouldn't have added it.
Not at all. You can implement POPCNT using some shifting and adding. It doesn't rely on any peculiar aspect of the processor. Yet, if you do implement it in software, it will turn one instruction into about seventy, so if you find yourself wanting to do that frequently, you might benefit from the CPU doing it for you.
It depends what VM software you use, but usually it doesn't if you're already running on X64. However, I really doubt you're trying to run modern VMs on a computer with an X86 processor that's old enough to lack this instruction. While there are boxes with older CPUs in production out there, they usually don't run the latest software versions whether Windows, Linux, or something else, so this doesn't affect you. If you are trying to run latest OSes on a computer that old, there are emulation options that will run those instructions, though expect there to be slower performance if you run those instructions a lot.
Having more addresses than we could use up sounds like a bad thing to you? The problem we have now is that we're running out, and if we made it a bit larger so that we wouldn't run out for a while, that would be more fragile than just doing it right and pushing the limit far, far away. It's what we've done with most of the limits in our systems when we increase them.
When you're using someone else's network, you can't guarantee they'll all be 192.168.1.1. I've frequently seen 192.168.0.1, 172.16.0.1, 10.0.0.1, and various other /24s in those ranges. It doesn't matter, because if I want to access their gateway, I query my network to get the gateway address and it tells me. I do not need to try any of these when my computer already knows the address. It knows the V6 one too. Open that, copy it into your browser, and pull it up. The same steps you probably already use will still work here.
As for wasting bits in a packet, there are a ton of bytes in many protocols already, but I'm guessing you don't consider them wasted. If you're using WiFi or Ethernet, your network controller is already using and storing plenty of extra data in order to work with them. If storing 128 bits instead of 32 is really causing a problem for your hardware, you likely need to spend a couple pennies on better hardware, because we no longer work in dates where 512 bytes on chip is expected. There are embedded controllers that have small amounts, but they usually aren't running full network stacks and trying to communicate that way.
The RFCs do not say that you must drop it, but neither do they say that you must pass it. It says "reserved". How you implement that is up to you, but there is a difference between using it as normal space in your own network and assuming that sending traffic to the internet should also work. For example, we could also free up lots of space in the 127/8 block because nobody needs that many loopback addresses, but it would not be acceptable for me, as your ISP, to decide that I'll take all those addresses and send traffic you send to them out to whatever boxes I put there. It would not be acceptable because the protocol specifies that I should not, and the protocol also specifies that those addresses are reserved, not for definitely using on the public internet but not right now, but for some unspecified future use which might not be standard.
Reserving something for future use kind of implies that you have a reason. Not just "so far unassigned". For example, phone systems often have certain codes that are reserved for future use. When those get removed from that list and put to real use, that tends to happen when something has changed, and the numbers look different. For example, the length of a phone number in a system that uses variable lengths is usually decided when the prefix is put in production, not before. As it happens, we didn't make any changes that would make use of the numbers in a different way, but they easily could have put those addresses on a list and would have if they hadn't imagined that something could change in a way that required a contiguous address block that wasn't in use.
Actually, you might want to, in case the future use is eventually defined as something that's incompatible with the protocol you've supported. For example, there are a lot of file formats with a version field. Version 1 is already defined, and my program supports it. I should not treat version 2, currently reserved for future use, as a flag that anyone can use for whatever purpose they like and treat it identically as version 1. I should not do that because, if version 2 does come out, my program will be treating it incorrectly rather than just telling people to install the update that handles it properly. An update to set version 2 as equivalent to version 1, should that prove to be how version 2 works, doesn't break things in any other situation. I think the 240/4 handling should have been a configurable option, but it absolutely should have been blocked by default.
Not that unusual. Lots of scarce things are cheap if you look at small quantities. How much does it cost to get twenty liters of water in a desert? Not that much. How much does it cost to have enough water for drinking, cleaning, and agriculture for everyone in a desert? A lot.
You usually can't buy one IP address for your use. You can rent them easily enough, and often it will be difficult to know how much of what you're paying is for the address as opposed to the server or network you're renting with it. When you're buying addresses, the smallest chunk you can usually buy is a /24, or 256 addresses, and that makes a price of $7,640. That's conservative. Current auctions for /24s are showing prices between $10k and $15k. Yes, I could do that, but it's not a small purchase. And yet, 256 addresses is not very many addresses when doing something at scale.
And every piece of software attached to a 255.* address would have to handle that protocol. If you connect to software running on my computer which creates its own streams, it can use a variety of libraries to create the packets it is sending. Not all of them support your arbitrary protocol, and at least some of them are going to need to. You can't abstract that out into one implementation of TCP, for example, because the existing functions for making TCP connections don't have a variable-length address parameter so anything calling them has no way to create a connection to a longer address. The 240/4 address space is theoretically easier because it looks like any other IPV4 address, so most libraries have not bothered to treat it differently, but even that has a lot of systems that need software changes to handle it.
Whenever you replace a network standard, you have to change almost everything that interacts with it. It's not just the routers in the middle that may be older, but software at the edges as well. No matter where you add extra data into the IPV4 address, that is changing the protocol. Software can't handle it. You are more than welcome to build your own proxies which route traffic sent to one IP address to multiple subaddresses on your network, then write software to understand that protocol, but if you think that it can be done to the entire world more conveniently than adopting an existing and mostly supported alternative like IPV6, you're probably misunderstanding something.
The risk that someone treats "unused for now" as "I can do whatever I want with it", it gets switched to "used for something different" and all the traffic breaks something. When the block was first reserved, "future use" might have meant that you send traffic to those addresses that might not be compatible with the existing specification; it was not stated which of the details would stay the same when they were eventually put to use. For example, we had a discussion a couple weeks back of companies who used a domain name they do not control for internal company stuff. If you never make a mistake, that's not going to cause any problems. If you have any misconfiguration, you will start to, at the very least, leak your internal names to an external DNS server, and possibly route to someone else's servers which could be quite dangerous.
Ideally, routers would configure such things in software. It would, by default, treat 240/4 as a range that might not act like normal ones and therefore wouldn't pass traffic intended for them, but there would be a table of addresses that were handled like that and people could remove the block. However, if you're going for speed, you might implement that logic in hardware and not bother to make it configurable. The same is true if the people building the hardware assume that the address space won't be used before this hardware is obsolete, and when it is used it will need custom software to handle which won't be written for obsolete hardware, so they shouldn't add it in. So, unfortunately, most equipment was not built to make it simple to disable that behavior.
Not quite. Diffie-Hellman allows you to exchange keys with someone in a public channel, but does not let you prove while doing so that the person you're exchanging keys with is the person you want to. The benefit of it if it's done well, which is not easy but possible, is that if I am watching your communications, I should find it hard to determine your shared key. If I can successfully interpose myself in your conversation, providing my own keys and preventing the person to whom you think you're talking from providing theirs, then I can still impersonate them. If I can simultaneously do that to both of you, then I can impersonate each of you to one another and both eavesdrop on the communication and modify it as desired. An electronic device physically between the chips is capable of doing that, so if they don't start out encrypted, the communication is weak.
Very good points. The first one is not very concerning to me, as it's pretty easy to set your key when you first encrypt the drive, and since you're the one doing it, you can be pretty sure that nobody has your computer open at the time. It's not perfect, but you only have to do it once. The replacement of a TPM doesn't concern me much, as it would already require setting a new key even without secure communication.
However, I start to wonder whether implementing this encrypted communication path is worth doing. Using TPM alone to store keys is giving a piece of hardware the ability to unlock the drive in the same box. People should know what that does (protect against access to data on the drive if you only have the drive), what it doesn't (secure things against someone who has the entire machine) and that they have other options and act accordingly. For example, whether this interchip communication is encrypted or not, the attacker can still turn on the computer, boot the operating system on the encrypted drive, and try to do something at the login screen. If they found a vulnerability at this stage, encryption would not matter and they could gain access that way. If they intercepted communication between the CPU and the RAM, they could do something similar. Hardening one path will not prevent the combination of physical access and all keys stored inside this box and not the user's brain from being less secure than the alternatives that involve getting part of or the entire key from an external input so that physical access to the computer is insufficient to decrypt it.
You clearly haven't bothered to read the numerous comments here that explain why:
1. Bitlocker, even in this insecure configuration, is significantly more secure than a simple password on an unencrypted drive.
2. This is only one configuration, and any of the others would prevent this attack.
3. Exploiting this attack is only possible on a subset of hardware, and there are large classes of devices where it would not work.
That is not why we have asymmetric encryption. We have asymmetric encryption to securely identify people, but you can't do that if you've never seen them before.
Say that we decide to exchange some encrypted communications and I send you my public key in the mail. When you receive an envelope containing a public key, how do you know it is mine? If someone intercepted the message and sent you a different key, how do you know that it wasn't mine? You don't. All you know right now is that you have a public key. If whoever intercepted our mail can't also intercept our other communication path, then you'll figure out that it doesn't match me when I can't read any of your messages. If they can, though, you encrypt something with their public key and they intercept it. They can decode that, know what you said, then encrypt it with my real public key which they got from my letter. They send it on to me, and I assume it's you doing it because they used the public key I gave you (or they intercepted your letter as well, either way works). I therefore use their key as well, and they've effectively obtained access to all our communications even though we think we're being secure.
There are two ways to get around this. One is to have an external method of validating that the keys belong to. That can be manual key signing or certificates, but either way, you have to have an external chain of trust. That's why HTTPS can use keys you've never seen before, because you can check them against the certificate authorities and you have seen their keys before. Drive encryption can't do that because it doesn't have an internet connection and because it would be too easy to generate a key that gets signed by some authority as being permitted to access anything. The other method is to keep a key stored from the first time, I.E. instead of getting mine in the mail, we meet in person and test each other until we're confident that the keys we're exchanging belong to the right person, then exchange keys physically. That's your best bet here, but it would require the TPM to have a secure storage location for keys which can neither be read or written except when the TPM is configured.
When a system is broken because incentives are bad, you usually can't fix it by flipping the bad incentives to go the other way. If you made fees higher for rejecting patents than accepting them, the incentive is now to reject them. Prior art involves citing something, so it's a little harder, but the patent office has other reasons to reject a patent application, including the obvious idea standard. It would be easy for them to simply stamp every application obvious and wait for someone to challenge them. They won't have a major budget for dealing with challenges, so they'll probably settle with anyone who challenges meaning that your patent is now accepted if you are willing and able to pay a lawyer to file a challenge and rejected otherwise.
That's going to give you no useful patents until you try to patch another bad incentive on top to get rid of that. Usually, something that ends up being a stack of patches to fix the problems of the last patch is not a great option and, if we can redesign it from scratch, we'll get a better result.
There are various levels of this, and it doesn't always sail under that exact flag. For example, though I've managed to avoid the worst of it (see the comment below this thread for an example of that, I have had to work in a place like this. The way it worked there: the people who wrote the tasks would write a summary of what they intended which would usually be one to four sentences. It was assumed that the design summarized, if I'm being very charitable, there was what needed to be written, and it was then assigned to someone. If it was the original creator of the idea, no problem, as they already knew what and why. If that person was busy and it landed on you, who knows. You were permitted two hours to ask questions and encouraged to do so, but sometimes those questions would be directed to a different team and would sound too much like "I see you'd like to do X. Why do you want that" and the answers sometimes started with "I didn't suggest it and I don't know why". If you were still trying to figure this out later, then you would get questions about why you hadn't just written it yet.
"To a real software developer, coding is the least difficult part of the job, a trivial translation of their understanding of the problem into instructions for moving bits around inside the machine."
Exactly right. The coding part can take a while, but usually because something went wrong in the conceptualizing part or because some system interaction doesn't work the way that was assumed or would be best. A good programming group probably spends longer figuring out what they're going to write than writing it.
Similar to your observation about writing simple functions, another red flag in programming jobs I've seen is when people are expected to start writing code as soon as they get a task. A good programmer is told to figure out the problem and design a solution first. That design doesn't necessarily have to get reviewed, but if you just start writing, the first version that works will have something wrong with them which will either need replacement or will get released and cause a problem in a few months.
I am not a web developer, but I am a developer and I need something slightly between not guilty and guilty for me to plead. I have repeatedly been responsible for new features, which are probably unwanted new features to someone. Sometimes it was someone else's idea, I thought it was rubbish, but they told me to do it anyway. At least in those cases, I can comfortably blame that guy. However, there are times where I think the feature will be useful to someone and I might even know one to whom that applies.
Unfortunately, many new features require changes that start to break things for others. I think one of the principles of good design is that those changes should be minimized when possible, but sometimes it really isn't possible. I've recently had to make significant changes to a command line program in order to add a new feature. My changes are, in my opinion, a good thing because it will make it much easier to add more similar functionality later and I'm planning for that to happen. However, it will require users of the old version to change the way they use it at least a bit and the work involved in providing an old and new interface is probably unwarranted. So yes, sometimes it's our fault, but sometimes it is not and we're usually trying to minimize the annoyance when we can.
Useful to who? Some people have performed a computation on them that they think is useful. I may not agree, but I might not think that what you do with your computers is useful and that doesn't stop it actually being useful. Worth the resources expended and the collateral damage, probably not. Useful to someone, yes, I'm afraid it has been.
You are asking them to prove a hypothetical and refusing to prove your own. Neither is going to be possible. They cannot prove that a computer can think by going and building you one, and even if they could manage it, you probably wouldn't accept that they had. Similarly, from what you've said, you don't have any reason to think that such a thing is impossible, you just state it as an axiom. I agree that nobody has built one, and the way we are going, nobody will, but that is not sufficient evidence to prove that it can't exist.
If you think you have a proof that machines could never be made to think, you could post it, but simply saying to show you is not a valid argument. For example, if I told you that it is impossible for a rock to exist on the ocean floor at 3 km, you would be correct to tell me that my statement is incorrect, but you probably don't have a machine capable of retrieving one of the rocks that are down there to show me that it really is a rock. I cannot take your inability to retrieve a rock from a location as proof that no rock can exist in that location, and you can't treat someone's inability to produce a thinking computer on command as proof that one can never exist.
Unfortunately, this ends up being similar to a "my computer is slow" problem*. I don't doubt that you're having these issues, but I can't say I've had any. My known Firefox issues affect only two sites, and one of them just has a button that doesn't expand so I had to bookmark the subpage to get there. Since I haven't experienced the problems you have, it's hard for either of us to figure out which one of our experiences is more common.
* I assume nearly everyone here has had the experience of someone who says their computer is running slowly. Usually, they're not wrong, but the cause could be so many things and the symptom is so vague unless personally tested that it is difficult to know exactly why and how to fix it without checking the machine concerned.
I think part of the problem is that your opinion isn't very clear. You've mentioned several problems that Mozilla and Firefox have, said that the user numbers are low, which we all know, but you didn't really express much of an opinion on anything going forward. You didn't say what we should do, nor what Mozilla should do, nor really what you expect to happen in the future though I can guess that "Firefox ceases to exist" isn't extrapolating too far. Nor even how you feel about the decline. It doesn't help me make an opinion on anything particularly important, other than "The Mozilla CEO is paid too much", but that isn't an opinion I can do anything about.
They already have Tor Browser. It's Firefox with modifications, so it'll look similar and already supports it. Is there a situation where that's not an option but normal Firefox is? I have a feeling that the Tor node operators are happy this hasn't happened, because it will rapidly increase the traffic through the network from people who don't need it. That will add some more noise for those who need it to hide in, but it will also increase the bandwidth requirements and those are mostly being covered by volunteer node operators who don't have unlimited budgets.
I don't know. I've seen and participated in many arguments with other Linux users who think sudo is a bad idea and it should only be su. I disagree with that, but it's not just one person who thinks that. That's effectively what Windows had before, and it was pretty easy for a program that needed administrator to ask to elevate itself, effectively allowing them to act like there was a sudo option. Maybe Microsoft thought that was enough for a while, and while I prefer the functionality that sudo provides, it's not a necessity.
Lots of people have implemented bash for Windows. It's not hard to use one of those. Of course, bash doesn't include sudo, it runs the sudo you already have, so you'd need someone to make sudo for Windows. Fortunately, Microsoft appear to have done that, so if they implemented it as a program and not a shell command, bash for Windows can use sudo too.
As for PowerShell, I don't like it very much, but I can't pretend that bash is somehow perfect. Its peculiarities are mostly just things that I've had more experience getting around. PowerShell, while ugly, has more support for handling complex data types and objects that can be treated as objects instead of serializing and deserializing them in turns so you can pass them around. Sometimes, this can be helpful.
Oh, no, you should keep using a per user charge because everyone who buys it will think they're getting a great deal. We pay for 200 users this month, then next month we only have to pay for 180. Then they realize that the software doesn't actually let them cut staffing as they thought and they still end up paying for 200 users.
It depends what you were doing with them, but probably not. Banking apps are rarely the targets of the attackers because there are a bunch of apps and each user probably only has one or two of them installed. Finding a bug in banking app A doesn't let you attack anyone who doesn't have an account at bank A and anyone who doesn't need access to it on their phone. Nor do they usually attack by having someone install a dodgy app. Malware of that kind exists, but targeted attacks like this can't rely on someone installing something for them. Mostly, they look for vulnerabilities in the OS itself or in particularly common apps, often communication ones like WhatsApp which are popular and have an easy way to deliver a payload to them by sending a message to the victim's number.
Nor are financial details the target of something like this. They're paying millions for the right to infect someone; they have enough money as it is. Usually, they want information. Your calls, your messages, your emails, and the ability to track your location and turn on your microphone. A flip phone has all the hardware needed to do that, and the only possible difference is that you might not sync your email to it because the interface makes it annoying to use. Flip phones have been able to read email for fifteen years, though, so nothing would prevent it from being an interesting target to users of stuff like this.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
