Posts by doublelayer 9408 publicly visible posts • joined 22 Feb 2018
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.
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.
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.
"Does anyone win? I thought they just went on and on until everyone lost interest."
Or one player (you know who you are) is so relentlessly annoying and competitive that the others don't care what happens just so long as that player goes bankrupt. Queue a formation of a cartel of the other players. I'll give you the property which completes your monopoly and you give me the same. Build a bunch of houses on each one and by the way, rent is cancelled if you show up.
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.
Wishful thinking, I'm afraid. Several ransomware attacks were known not to return decryption keys, yet received payments. Probably not as much as they would have if decryption worked, but they got sent money by people who didn't investigate them before deciding to pay up.
Please stop. There are lots of people who want to stop crime by completely eliminating privacy, but that doesn't make that right, practical, or even functional. If person A doesn't buy gift cards, but instead buys other items and sells them onto others, the problem is the same. Let me guess, we now need to present ID to buy anything that looks easy to resell?
There is already a method of doing what you want. Proceeds of a crime can be ordered seized from someone who knowingly received them, someone who didn't knowingly receive them but was contacted fast enough, or someone who has the ability to obtain them from the criminals involved.
It's an attempt to encourage caution about external resources which could host malware, request information, or try to steal SSO tokens. Clicking on the link versus pasting it doesn't really make much difference. Sure, there's a chance that someone will recognize a URL as malicious but not bother to check the URL on a link, but I don't think it's a large subset. Most users I've seen will either check where the link goes before clicking it or cheerfully copy and paste a link to iamactivelyevil.com.
"Still scratching my head how in the world it is possible someone manages to design, produce and make truckloads of money of an Operating System that allows its kernel, device drivers and boot code to be changed by a webpage, email or a pdf."
Simple answer: they didn't. Your OS's core components can't be infected by opening those things unless they've found one massive vulnerability, and they probably haven't. In most malware attacks, the powerful application is a binary, executed on the machine. The user may be prompted to download the binary by a website, but the website didn't do it. Or the binary might get installed by modifying something they already have installed. Or a password is guessed and someone manually executes it. These are the very common things.
Yes, there are vulnerabilities allowing an attacker to do drive-by attacks without the user or someone with user-level access executing something. They are somewhat rare. They're also found in all OSes. Linux, Mac OS, Windows, Android, IOS, you name it. That's basically impossible to prevent because there is so much going on. Implying that Windows has a lot of those and they are the cause of lots of malware infections is incorrect. For many attacks, the people to blame are the users who executed it and the administrators who didn't protect the method used to attack. Some of the time, the blame is squarely on one of those. The original developers deserve blame too at times, but not as much as you may think.
"What was once a perfectly safe conduit for plain text, is now a funnel for all manner of shite, because "we" yearned for increased functionality, or rather, developers thrust it upon us, in the war for market share."
I'm sorry, but in most important respects, this is just wrong. HTML email does allow a few exploits, such as embedding an image to check when somebody is opening the message, but that's not a major security risk and the privacy risk that does exist is mitigated by most modern mail clients and some mail servers. Opening an HTML email doesn't in itself give the attacker access to run code.
The exploits which have worked so well over email are all hacking the human. Open this attachment which is an executable but looks like a document because the OS doesn't show extensions. Open this document which is actually a document but contains macros. Go to this website and enter the information on it (if the user copies a URL or clicks a link, they're ending up in the same place). All of this was as possible with text-based email as it is today. A few of the risks that make it more dangerous, including the structure of the protocol meaning it's possible to impersonate anyone and a lot of servers will just trust you, are leftovers from that old text-based conduit which was never secure and still isn't today.
Back in those good old days, it wasn't that email was more secure. In fact, it was almost certainly less secure because we have found some things that could easily be fixed. The reason it felt better is that there were fewer attackers and fewer users who were biased toward more familiarity with the technology and its risks.
Of course they do. Yet their interests are not a reason I should have to sacrifice my privacy. If they want to track conversions, they can without having to create their own domain. If they want to know about their customers, they can send out a survey and see how many of the customers will fill it out for free, or they can have a prize to increase participation rates. If they want to track me elsewhere along with a massive company, too bad for them. I'm not going to let them do it if I can help it. Just because they're not making enough money to pay for ethical market research is not an excuse to let them violate others.
"For months, developers at Facebook and Apple have been trying to figure out a way to continue to allow advertisers to track ad conversions – to understand which ads people click on – in the web's increasingly complicated technical environment."
No, they're not. It is easy to determine which ads people are clicking on. Let's say a company is running five different ads for the same thing and they want to measure whether there is a difference in effectiveness between the presentations. Here's how you do that:
Ad 1: links to https://ispamyou.adnetwork/ad/1
Ad 2: links to https://ispamyou.adnetwork/ad/2
And so on. Or, because the short numbers will get reused:
Ad 1: links to https://ispamyou.adnetwork/ad/aei6zln2
Ad 2: links to https://ispamyou.adnetwork/ad/fl2ozvnp
If you're on something which doesn't do custom paths, you can do the same thing with query parameters. Then you just dump the request in a database to look at later and redirect the user. Facebook could build a server to collect that if there is a user who lacks the technical knowledge to do it themselves. I wouldn't be surprised to hear they already have that. The privacy protection thing doesn't make that harder.
What it does make harder and what Facebook wants to make easy again isn't figuring out what ads people are clicking on, but to figure out who the people are who click on the ads. Or do anything else online. That's what Apple's privacy measure is intended to protect. Facebook and its advertisers are angry about that and I understand why, but that's just too bad. They never asked my permission for invading my privacy. I will neither ask their permission nor care when they object to my blocking and impeding them.
Yes, and the methods of oppression used by the so-called Islamic State which are undoubtedly terrorism were considered by them to be lawful. Just because the terrorists consider themselves to have political power and their motives and actions to be justified doesn't stop it from being terrorism. Was the action generating terror in the population? Yes. Was it done deliberately? Yes. Was it done for reasons connected to Christianity? Yes. It is possible for enforcement of a law to meet the definition of terrorism.
Sadly, it also shows the number of people who don't have multizone setups and don't have the ability to recover quickly. There's a site I wanted to visit on March 25th which didn't work. Turns out it went down on March 10th and is run by a French company. It's still down today. I would expect that they would have the necessary backups to get a webserver back in operation in a month. One datacenter can be very important to small operations, though with cloud it shouldn't be.
These are points "futurists" should really keep in mind. They always come up with technology ideas without even thinking about whether people would want them if they became feasible. Science fiction writers do the same thing, but at least they're not necessarily saying that we're going to have those technologies. A lot of futurists appear to have the kind of technology experience which comes from reading about but never actually developing things, and perhaps this explains why they think, for instance, it is easy to make a computer converse with a human on general topics.
True, but that's just more data. We can store the instructions to decode data and people can find it. Consider the Arctic code archive Github did last year. Included in that is the source code for a lot of things you can use to read files of various rare types. There's undoubtedly a Fortran compiler up there. Even if they can't figure out the instruction set to which the compiler will compile it, they should be able to work out the syntax and reverse-engineer your code if they care enough. The source for FFMPEG isn't on Github (or maybe someone cloned it), but that's likely stored on lots of disks. That's a really useful way of accessing video or audio data once they find it.
Archaeology is difficult. They have to figure out a lot of details that the creators of the artifacts didn't specify. It won't miraculously be fixed by our ability to create copies of stuff, because they'll still have to work out things like the languages we use and how our stuff worked. It will be made easier though because we have a lot more information for them to find and that information is harder to lose or destroy.
I'm not sure that's as problematic as it sounds. The pyramids are still here, but I'm sure there are various things we have built which could also remain here if we didn't do anything to it. There are artistic constructions which we aren't going to take down and won't just decompose on their own. Unless we have a war which destroys them or somebody comes along and really hates them, they will remain there. Remember that we don't have a ton of ancient Egyptian office buildings to investigate; we have the constructions which had an ornamental purpose and were preserved to retain it. We will do the same.
On data, we have a lot more power to preserve it than our ancestors did. A thousand years ago, there weren't many copies of documents, they were stored on stuff that is really easy to destroy, and copying them took a very long time. A fire or flood in a library would destroy a lot. Just to make it worse, the library was made of wood, people used fire to heat it and see, and it was next to a river so the inhabitants could get something to drink. Lots of information died then and there. Meanwhile, individual data storage devices degrade, but we have the ability to copy information without error and reproduce it on multiple continents in minutes. Also, libraries today have started to buy out Cold War bunkers to store their material. I think those are a bit more resilient.
Not only digital things. There are millions of paper copies of the same books where our ancestors wouldn't have them. Even with a global catastrophe, the chances of one of those surviving for archaeologists to find it is a lot higher. This also applies to documents which wouldn't have been kept. In centuries past, routine business documents, if they were created, were erased so as to reuse the paper. Eventually, they were just burned or trashed because they weren't needed but the space was. Nowadays, they're just archived because it's cheap to keep a year's records on a tape. Some places will eventually decide they don't need to keep that after all, but some others will keep it out of laziness alone. It's so cheap to store data that I have copies of Wikipedia and a few other encyclopedias on my own media, along with a bunch of nonfiction books and other documents that would be rather nice sources for life today if you needed that. And that's just data I intend to use myself. There are projects to archive all sorts of data with the goal of future availability firmly in mind.
If you're referring to price elasticity, there is but it doesn't change the answer. It allows more granular discussion of exactly what will [probably] happen if suppliers change the prices. Some products are inelastic, so if the price goes up the company just gets more money. Some are elastic, meaning the companies are taking a large risk by increasing the price. There are equations and theories giving more information about how to test this and use the results.
Either way, companies change the prices based on their own calculations. If the tax rate goes up by 5 percentage points but the company expects that increasing the price will cause demand to fall, they will bring out the calculators to figure out whether that's a good idea. Some companies will decide that increasing the price will cause demand to go down too much, so they'll have to absorb the tax increase. Unhappy execs and shareholders ensue. Other companies will decide that they can handle the increase and prices go up. However, if the tax rates didn't increase, the companies may have done the calculation (they do that all the time as part of routine work) and increase the price anyway. So it is true to say that tax increases may increase prices, but incorrect to state it as a certainty.
And, using that argument, technically you as an individual also pay no tax, because you pass it all onto your employer. It is included in your income. Also, you pay no tax on your investments or property or anything else for which you get a tax bill and pay money if you consider it as ingrained in the cost.
It's not in the cost. It is a separate cost. How a change in taxes is handled depends on the actions of the person or company. If the tax rate goes up, companies may increase prices, decrease expenses, or report less profit. These are all options and are all used. If tax rates don't go up, companies may also increase prices and give the money to somebody else. It's a decision they and not the tax authorities make. It's not correct to assume that any increase in corporate taxes takes the form of price increases.
Yes, in the pursuit of maximum utility for you and nobody else, the optimal tax rate is 0%. That applies to corporate taxes and personal taxes. Which is just fine if you live in a world where you never need governments to provide services. However, economic theory doesn't agree what the best rates are when you do need those things and, as it's a subjective thing, may never be able to do so. In fact, as economic theory goes, there's not much difference between a corporation and an individual. It's best not to say that economic theory thinks X is a certainty because A) it isn't one person and frequently some economists think X and some think Y, and B) there are lots of questions that economic theory says it either doesn't or can't address.
Python doesn't let you chain too many expressions on one line because they don't use punctuation to delimit expressions and blocks, so there's no workaround there. Java, on the other hand, does have that punctuation so I wonder what happens if all the newline characters are dropped before running the scan.
"The great "feature" of COBOL is that you virtually never need to provide independent documentation of the code functions - it's so totally readable."
Has this ever been true? About anything? I doubt it.
No matter how nice the language looks, someone can find a way to make it unreadable. The easiest way that I've found is to split every function across multiple files, ideally containing split parts of unrelated functions. If multiple files are not available, just split up all the function parts and disperse them across one big file. If you use easy unclear names, lose single points of truth, always avoid abstracting out functions, always abstract out everything you can do, or write in JavaScript, your code can become unreadable really fast.
"The unbeatable feature of COBOL is its support for binary-coded-decimal arithmetic, in which you can represent a billion dollars, or a billion anything, to the nearest cent."
Er... That's pretty easy. That's an integer divided by a constant, and a pretty small constant. What's more complex is storing values to a lot more precision when they're not rational numbers, but we also can do that today too.
"with the more "modern" (don't make me laught) programming languages, and the lost appreciation for cpu power and memory being limited ressources. Guess what, when you need to do a lot of these calculations concurrently these things do matter."
Absolutely, but I have to wonder about a few things:
1. The computers you're using to run the old assembly and COBOL probably cost more than cheaper modern computers. Have you calculated the various resource costs of using those modern computers? I can run an inefficient program on a modern computer and have it complete faster and cheaper than running an optimized program on an old computer. I can also produce an optimized program that will be even better on the modern computer.
2. So your calculations are going slowly with some modern language you don't like. Have you tried multiple languages? There aren't a lot of COBOL systems running on modern hardware but there are a ton of C ones and C is also pretty fast. If C doesn't work, there are other low-level languages available which have execution speed as an important factor. If you're comparing assembly to Python, it's not a fair comparison.
3. So you can't write it to run on modern computers, even in C. The assembly that was written decades ago was probably quite well-tuned. Have you considered writing well-tuned assembly again today if you need performance so badly? The people who write compilers know how to do it. Maybe it's not modern developers causing the problem, but comparing two very different approaches: one where people worked hard to speed it up and one where a straw replacement was created quickly and judged even faster.
A battery that runs a car can provide backup power for some things in a house. For the big hospital machines, no. For the server rooms, no. They are unsuitable because those systems need to stay up reliably, which is not assisted by batteries you don't own whose owners can easily move them. Also, you would need a lot of cars to keep a server room running, and they won't last forever.
Battery backup is certainly an option, but it is currently a very expensive option. Even ignoring that fact, the operators would use batteries they own. I don't think there's reason to worry about difficulties obtaining generators. They're common enough that people will keep making them until there is an economical alternative available.
Big open spaces are subject to a variety of extreme weather events. You are correct that it gets really hot there, but because it has no shielding from winds, it can turn cold fast. You are implying that this type of weather is completely unexpected in Texas. That's not true. The state receives cold weather and snow with some frequency. Unfortunately for them, they live in a place where you can get very hot and somewhat cold weather in the same place and they have to prepare for that. They could prepare by having generation equipment which could withstand those conditions or they could prepare by importing energy from elsewhere, but they chose to do neither of those things.
"I sometimes wonder whether cloud-only is even worth it for anything bigger than SME."
This is not a good example to make that point. The location here is a lot more like what local servers are like than what cloud is like. The large cloud providers operate so many datacenters that they can afford to do lots of expensive things that local or colocated servers don't do for the expense. DR is often one of those things. Large cloud providers also have built-in features for redundancy across datacenters or regions. Meanwhile, a lot of companies will either colocate their servers in a datacenter not unlike the one in this article or will run a facility of their own which isn't much different. This obviously doesn't apply to companies which spend a lot of time and effort on their servers, including really big places or ones with a lot of technical knowledge available, but it does for many others.
Cloud has a lot of downsides. You pay for lots of things you don't have to when running locally, the prices may be higher which you can only figure out by spending time on a boring effort to calculate them, you have another supplier on which you're relying, all that. However, if you're concerned about disasters, it is a lot cheaper to run redundant systems on cloud than to run them yourself unless you have a lot of servers. Now that's not necessarily a reason to go all cloud. You could run redundant systems in colocation datacenters or even run some locally with cloud backup. For a lot of businesses who don't bother with geographic redundancy at the moment, the extra cost of multiple servers to perform one task may not be judged worth it.
"Anyone with even a passing familiarity of Java will tell you the value of a library lies in its interface rather than its implementation,"
Well, I have a familiarity with Java and several other languages, and I don't agree. The value of a library lies in both of those things, biased toward the implementation. A nice set of functions is an asset, but it will not rescue a library which is inefficient. Meanwhile, there are libraries in use which have terrible interfaces because their function is still too important to give up. Work to improve the interfaces of such libraries is greatly appreciated because it connects good interface with good implementation.
"and likewise will tell you there are many ways to write the same interface in functionally-compatible ways. Google didn't have to copy the interface"
If they hadn't copied the lines specifying the function names, they would have rewritten files containing the function names. They could bash the names around so they're technically different, but most of the stuff has to stay the same so the interface is functionally compatible. If they did that instead of copying, Oracle would claim that they did the same thing because the functions are all here and named the same.
I don't think that's what I'm doing. The court case has been decided on fair use grounds. In the way I like, but using arguments that aren't the ones I would use. That's not at issue. I'm merely disagreeing with the quote "Google did not implement the code in question based on the published API specifications, they copied the 11k LOC directly.". It's not central to the decisions, but it is central to the argument being made by the original post. I think that statement is incorrect in the extreme, and that statement is what I'm arguing against.
"Google did not implement the code in question based on the published API specifications, they copied the 11k LOC directly."
The lines concerned were the API specifications and didn't do anything because they just listed functions. They required separate implementations, which Google wrote without copying. If you compiled those lines of code and tried to do anything with them, you couldn't. Not a single one of them ran. This was just a list of names. You are implying otherwise, but we and you know what they were.
"Google blatantly copied Java,"
No. Google blatantly copied a list of Java function names. They didn't copy the JVM. They didn't copy the implementations of those functions. They also skipped some of the functions available. The question is whether those names are as protected as all the important code that actually runs is. The answer appears to be no.
Microsoft filed a brief supporting Google's argument, as did IBM, Mozilla, and a bunch of others. They're probably quite happy today.
"Surwe, as if you would proudly announce a chip that would be less flexible and performant than what was made before. Hurray!"
You might, though. They can sell chips on other benefits. It could be similarly performant as the old one but a lot more energy-efficient. Or as performant per core but capable of more parallelism. Or as performant on standard tasks but with extra acceleration for particular operations. Those are at least possible alternatives, albeit ones that don't often make the headline announcement.
If that's the case, they're not very good at their job. Most of the economics studies involving meaningless money contradict many other theories. Behavioral economics really likes these. Whether that's because the previous theories were wrong (probably), because people act different when they actually care about incentives (probably) or because the researcher is deliberately messing with the results (probably not), they don't tend to be blatantly confirmatory.
It's unclear. People like to hold Turing test challenges, and programs in those challenges have been ruled human before. That might not be a great basis to declare the test passed, but it is what the test specifies. It also depends a lot on what we want them to do. The original Turing test didn't include sending images to the other party, therefore not requiring the AIs to see. Also, a program trying to pass the Turing test, because it sends back text, has the ability to say "both" where the programs here which are just identifying things have to pick a single one.
In my opinion, the Turing test is a rough test that is likely to have too much uncertainty to prove intelligence. There were probably a lot of people who liked to talk about it back when it seemed impossible, but now they're pointing out defficiencies in the concept. The only problem is that a lot of people attack anything termed AI without even trying to define what they think AI is, or provide an unrealistic explanation which means something is only AI if it acts entirely human and attained sapience itself without ever being programmed.
I think that approach is too limited.
"So why isn't there an AI program somewhere that can actually label the photograph itself? 'Cos AI isn't AI really, it's what the programmers tell it to do."
Whatever our definition of intelligence ends up being, it's got to do what the programmers tell it to do at a low level otherwise it's no longer artificial. We could probably argue about what intelligence is all day, but if AI is possible at all, it has to be implemented with code and machinery which means its instructions are created by another intelligence.
"As stated above, GIGO and it always will be until a 'machine' is actually cognitive."
Now this doesn't sound fair. GIGO applies to anything. If you take a human child and prime them with a bunch of false data without giving them the ability to learn that you're lying, they'll believe you. If everybody the child meets insists that the tall wood things that grow outside are called squirrels, they will believe that those are squirrels until they meet some other people who correct the misconception. If you're going to define intelligence as "the ability to figure out that everything people tell you is wrong even though you have no other source of information", that's a high bar. Computers don't get to meet random people and learn from them or even experiment with actions to see consequences. In life, we have a lot more input than any of these programs ever have, and yet there are a lot of humans who get incorrect concepts of how the world is.
With automatic translation software, it either just looks at the words and tries to do them literally or it finds an idiom in a big dictionary. When I did some translation, I would always replace them with factual statements. It had less flavor, but at least I knew the reader would understand it without taking the risk that the closest idiom I could come up with was regional. Then again, I was not a professional translator, just a person who spoke multiple languages and hadfriends who didn't.
Yes, just turning off the phone is probably good enough to drop you off the grid. If you're paranoid, you might not trust that and want to go further and remove the battery. The logging could show that you did that, indicating that you had taken a suspicious step, depending on how much analysis they wanted to perform on your data history.
Most of the time, it's just criminals being stupid. A lot of people who commit basic crimes just don't know very much about the risks they're taking. Some people still get caught with fingerprint evidence even though everybody has known for a century that they are left everywhere and police know how to use them. Given that there are criminals who don't bother to put on some gloves, it's probably not surprising that there are criminals who don't bother to leave the phone at home.
Very little. The OS itself has cut the packages from Google which phone home to them. If you log DNS requests, for example, you'll find there are orders of magnitude fewer while the phone is in standby. Flashing it also wipes out the manufacturer's installations, some of which likely send telemetry as well. The comparison between the two is striking. While there are ways for tracking to persist even after Lineage has been flashed, that's a possible mechanism where you already have several guaranteed ones.
In all cases, it's a significant improvement. Of course, if you flash Lineage OS and then install Google's APKs so apps requiring Google Play Services work, they'll start to collect again. Also, you'll lose some of the Google-provided services. I value that in the pursuit of privacy, but it annoys people sometimes.
You mean like the one Pine64 is working on? They've gotten their phone's communications chip to run mainline and a few parts of the system work already. If you're willing to live with the blob on the chip, their device also isolates it so it can't access anything in system memory unless the main system sends it. But as said above, the information the GSM standard gives away is really tiny compared to what the phone manufacturers are getting. Also, the information the GSM standard requires is used to provide a service to me, I understand what it is, and most of it is actually required for the service to work. The data collected by manufacturers doesn't meet any of those requirements.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
