Posts by doublelayer 11536 publicly visible posts • joined 22 Feb 2018
Because the law that already exists makes not talking to the police and giving them what they want punishable with an extra prison sentence. Yes, it's obviously a massive abuse of the suspect's rights, but when the average citizen finds out that being silent can land them in prison for longer or in prison at all if they can't be convicted on another crime, they'll probably choose to speak up. That's why the law itself needs to be eliminated.
Does not work for most situations where the data they're looking for isn't just received messages, such as encryption private keys used by some apps, contacts, notes or recordings, photos or videos, metadata that can't easily be wiped, metadata that can be easily deleted but you didn't in time, access tokens or passwords letting them into other things, and the like.
"However, I don't still get what "downloader hosted on WhatsApp’s media server" should mean. They are just describing the infected payload crafted into the videofile ? It is a bit misleading to me"
In itself, it doesn't mean much; they're just stating where the file came from. It does indicate that it was not retrieved from an attacker-controlled location, and therefore that it is not possible to track that location to identify the attacker. Not much more detail comes from this one observation, but it is relevant information to understanding what happened.
"Facebook recently sued NGO Group over its Pegasus software"
I'm assuming this was the spell checker? It's NSO group. Incidentally, as they aren't exactly hiding that they have this malware, I'm surprised and displeased their company hasn't been raided by law enforcement with a raft of computer abuse charges.
Mostly, you're right to argue for less bloat in software's resource usage. It can be really weird to muse on what someone from a few decades ago would think of the cheapest computer we could find today. However, not all of the increase in usage is a bad thing. Some stems from techniques that actually improve the experience, either for users or for future developers.
An example might help prove the point: I used to use an audio editor which was written in the late 1990s, and ran for a very long time despite not getting updated. It had several useful features I liked, a nice interface, it was just perfect. Well, not entirely. Since this was intended to run on computers of the Windows 98 era, the developers didn't plan on having very much memory available to them. They dealt with this nicely, using only about six megabytes, no matter how much audio you wanted to work with. All the audio would be streamed from disk, with temporary files holding processed data before it was saved. This meant that, although I had gigabytes of memory, if I wanted to do any processing that required modifying many parts of the data, it would read in a chunk from disk, process that chunk, write it back out to disk, and continue. It would have been faster had it been possible to inform it that it could cache a lot more. I ran a benchmark between this program and a more traditional editor with memory caching, and found that then (around 2009 I think) having audio data in memory made compression operations take about eight times less time than it took for the program reading from disk.
And the risks of confusing names. And the pressures on people to register multiple versions of their domain if only to prevent scammers. And the sheer pointlessness of having thousands of categories in which to place things. If you're arguing for radical changes to how TLDs get assigned, having only one makes a lot more sense than having a functionally infinite supply.
I'm not sure whether your past post had specifics, but you need a better reason than that if you intend to prove we need to uproot something that works. As far as I'm concerned, neither group needs .amazon and I am content to let them fight about it. Meanwhile, our other DNS systems continue to work well nearly everywhere on the planet and on nearly every device in use. Based on this and other things, I'd be happy if we replaced ICANN with something a little nicer and a lot fairer, but I see no reason we need to replace our current version of DNS.
Balkanization produces few benefits and many problems. Instead of one corrupt organization which can't figure out what it's doing, we have a hundred or so. That's assuming the governments mandate it. If balkanization happens at the ISP level, then we have a thousand which, even if they intend to be compatible, won't be merely because they can't coordinate in time. We could try to freeze the system, establishing an acceptable state and saying that no changes to that framework will be accepted without unanimity (or close to it), but have fun trying to get people to agree on the acceptable state.
Enough to do what? But almost certainly, the answer is no. All you can accomplish by switching out a SIM is to change the number and provider you're using. Some phones can store a contact list on a SIM as well, but that's an abridged version of what it already has on the device itself. Furthermore, that only affects traditional phone services such as voice and SMS text messages. This involved a message application that runs without using information stored on a SIM.
Well, your experience is not like mine. I've seen exactly this in many closed source projects. People want the project to do what it does with a completely different interface. They're willing to commit a readme that lays out that interface if I could just fill in the gaps. Or they'd like their project and my project to merge because our functionality compliments one another. They'd be happy to modify the code to do that as long as I deal with all the bugs because they haven't read the code to my project before making the suggestion. Some times, these people are making constructive suggestions and my team should consider what they're asking for. Sometimes, they are very skilled and dedicated and they'll be valuable assets to our team; at least one person I respect quite a bit joined us in that very manner. Sometimes they have no clue what they're talking about and should be ignored, and if we didn't figure out this we'll be cleaning up after the disaster for quite a while.
And hence we have the problem. I don't think the IEEE have a good claim to it, but the IETF does. It'll be a pain to find people to agree with me, and another one to get the IETF to agree to take it. The real problem will happen when someone manages to take over the IETF and use it to make money from their lucrative new property, though. After all, ICANN didn't start out like this. Nor did many of the other players with a lot of power in the mechanics of the web. They became this after the people who started them with the best of intentions stepped down and some enterprising people figured out how to be placed in power. At least with an independent thing we have a little hope that it could be taken from them. The United Nations does not have that option unless a large chunk of the world's governments agree (and how often is that).
That's exactly the point. I trust my police only some of the time. The best way to ensure that I can trust them is to keep them honest. That means limiting the powers, because I and everyone else knows that power corrupts.
Take an extreme example: if we allow police to search places without a warrant, what would happen? In many cases in democratic countries, they'd use it when they have to and keep things limited. They would improve their rates of successfully preventing crimes and bringing criminals to justice. But it takes only one corrupt officer with a grudge, a bias, or an interest in what someone's doing to start abusing that system, and once that happens, more people will start to do it. Then some people who run policing organizations will start to set up more organized methods of using that new power for the benefit of themselves or some political belief they think is important enough. Within a few years, the country has turned into a police state. That's why we don't let them do that; not because we distrust them now, but because we need to limit their powers now and for the future.
Reasonable, yes. I agree that, from everything they've said, they have a good reason to ask for the data, are handling it responsibly, and there isn't much capacity for abuse. However, when you look into the details, there's little but bad possibilities in future.
There are some obvious ones, such as requesting a much larger radius. For example, asking for the IDs of every device in a neighborhood and cross-listing that against historical data. Or requesting the full histories of certain IDs, with or without a warrant. There are some subtler possibilities though. If any of this data is wrong, it could result in people being wrongly pursued or people being ignored by the system. If a person involved in this crime were inaccurately placed by their device, they could go unnoticed. For reasons such as this, location data cannot be used as the primary tactic to catch criminals. It is far too unreliable and prone to tampering.
Perhaps the worst possibility though is legitimization of the collection of this data and its availability to law enforcement. The companies shouldn't have it, and in most cases nobody should have access to any collection their may be. If this warrant is used as a reason not to ban the companies from collecting the data, or if it allows other less trustworthy law enforcement (China's, for example) to access it, it may be incredibly harmful.
If they think you were in another country, not just somewhere you were near, it's possible someone else has access to your account. You might want to check the recent account accesses. While your there, close the account because they're trying to figure out where you are.
I wonder if that's really true. The majority of sites need to run code for one of three reasons:
1. To manipulate the content already on the page. This includes input verification, changing whether a section is hidden or not, moving content around for better presentation, and the like. I at least am completely fine with that running.
2. To pull content from a remote source to keep it updated without needing a refresh. I'll admit we use and like this, and we might need a solution to that. We have some capabilities outside of JS to do this already, which might need some improvement.
3. To pull data from the user's system, send it to a remote server, and pull new data back. This is often done for advertising, and it also is the source of innumerable security vulnerabilities. However, as already pointed out above, a site can still perform advertising by sending the ads when the page is initially loaded. While there are possible legitimate uses for that, I cannot think of many pages that are doing so.
If we limited JS to only be capable of the first two purposes, I don't think many sites would look any different. Of course it's simply a dream that has no chance of happening, but I think it would work if you managed to get it started.
Admittedly, an expanded version of HTML could implement some of the more common functionality without requiring JS to do it for you. For example, for table sorting, imagine if you could write this and the browser would handle it: (I'm trying to do this so the comment HTML checker will leave it alone. Note to self: the system will not auto-expand < and > into angle brackets. Apologies if it doesn't work)
<table>
<tr><th sortable>Name</th>th sortable>Value</th></tr>
That could be customized in various ways, and you'd no longer need to download a sorting function over and over. HTML5 already has a "sorted" property which allows specifying some details about sorting, but it is limited where this wouldn't be. Of course, you'd have many small details to handle, such as sorting on rows instead of columns, but it could be quite nice.
I don't think people would mind if a web processing engine only did things to and with the page it came with. It's when it starts collecting data and sending it somewhere else that we get annoyed or worried. As specified, Wasm is restricted enough that it only does processing. Which we all know is not ever the way it'll be used.
Except those never worked as well as it sounded like they would. Many programs written in something that was supposed to be platform-independent but originally written for and on a specific platform ended up running correctly only on that original platform. Take, for example, a program I ended up reimplementing. The original was written in Java. Nice, clean, write once run anywhere Java, without calling anything OS-specific. So it should work great, right?
Well, it was designed for Windows, and it needed to identify and write to external media (or simulated external media). And since it was checking the volumes by enumerating drive letters, it couldn't find them on anything using a unix-style volume mount system. It would run properly until it wanted to read or write to one, then keel over. There was a similar bug that happened when you tried to run the tool on Windows 10, which was a bit more complex and had to do with the way the OS's SSL/TLS implementation worked. Once again, the program failed badly.
In both cases, the version of the JVM running it was the same. While it didn't call OS-specific APIs, it was written in a way that called universal APIs with platform-specific parameters. It was clear that the original devs hadn't planned for anyone to run it on something other than Windows. It's unlikely that Wasm will go that way, but as there were platform-specific parameters that could cause that Java program to crash, there will likely be platform-specific bugs or ambiguities that allow a Wasm program extra functionality or alter its state. The majority of those will cause an annoying glitch seen only by the user. The minority will be developed into methods of accessing the users' systems to their detriment.
That depends which laptop you get. Many of the slightly larger ones (still at that price) do have upgradeable memory and storage. The smaller and thinner ones probably won't, but they'll weigh much less than this will (and won't have any wires hanging off). You have no guarantee when the next pi will come out, what its specs will be, or whether the ports will have changed by that time. With those provisos in mind, it's at least worth considering whether this has many advantages for you particularly.
In that case, this is not the most efficient option. Running a screen from the battery will run it down very fast. You could get a portable USB battery that will run the phone for a week. Sure, there's no big screen now, but the battery will be cheaper and smaller. Meanwhile, if you need the larger screen and keyboard, this probably won't run with any less power than a standard laptop.
For ... what? If you have dozens of pi projects in your house (I may not have dozens but I have a few), they're probably running headless with SSH access from your main computer. If you want this to use a pi as your main computer, why not just use a pi with existing hardware--you probably already have keyboards and monitors available. What is the advantage of this one unless you want to move it around, and if you're moving it around, why not use a standard laptop? The suggestion above of a portable interface to servers makes sense, but otherwise, I can't think of a good use case.
There are two types of protection for code, and they apply differently.
Copyright: You can't copy the code or substantial parts thereof directly unless you have permission.
Patent: If the process established in the code is new and its creator has a patent, you can't reimplement it without permission.
Hence, no, you can't copyright an algorithm, process, or system. You can patent those things if you've invented them, and you can copyright the code used to implement them. If you make a method of doing some task, but it's not original enough to earn you a patent, I'm perfectly allowed to make a program that does exactly what yours does. I should also be allowed to let my program take the same command line flags as yours if I want to.
That would mean that they have to completely reimplement someone else's codebase. That takes a lot of effort. So far, they've shown no interest in doing that because they can instead just sell people resources to run the original thing on. They still get all the money, and they don't have to reimplement a thing. I have to ask if that's all that bad an outcome anyway. It means more people familiar with an open source codebase, hence more potential customers for any commercial system the original author has and more possible donations from users who want more updates.
"If API come under unrestricted usage, then Google should stop whining how others use Google Maps and Other google products via API"
You've gotten that one wrong. The two are not at all similar. Google has restrictions on what you can do with their system, and the API is the path you take to use that system. Oracle aren't running a system, and intend to copyright the names and structure of their API. Google would not mind if I wrote up a program that used the same function names as one of their APIs. In fact, they'd probably be happy because it's now easier for someone else to modify my program to use their services.
In your example, Google want to keep you from acting nasty inside their house, which you got to by reading the address on the front. Oracle wants to copyright the address so you can't have any other houses with those numbers on them.
Oracle's point of view is that everything to do with the API is copyrightable, including the function names and the parameters they take. Whether you copy their header files and reimplement or look at the page and write a header too, they consider you equally culpable for infringement. If they win, that means the following:
"clean-room reimplementation": Have you seen the originals? And yours is similar (let alone compatible)? You infringe. Pay up.
"choose one of the many that are freely licenced": Did they copy? Did they see ours before they made theirs? They infringe. They need to pay up, and you need to stop using it or you will infringe shortly.
. "write your own": Is it similar? Do you use the same names and function contracts? Any of them? You infringe. Etc.
If that happens, I'm afraid it doesn't work quite as you specify. You've suggested that "The APIs that are locked up get ignored." That's possible, but what will happen is what happened with Java. It will get released under something that makes it look open until people use it. Then, the hidden loophole allowing changing the terms gets activated.
The only way to avoid it is to only ever use something that is and always was under a very clearly open license. We can do this now, and that's a great thing. But the only reason we can do that is because interfaces weren't copyrighted earlier. We have open implementations of C because AT&T didn't get to charge us. We have most of our OS and more complex language APIs because we had C. It didn't have to be C, but it did have to be something we could use freely. Without that, we wouldn't have very much, as each group trying to innovate would have to stay stubbornly in their own company or research group and not look at or use anyone else's stuff.
It's not an infallible solution, but a perfectly unbeatable solution would likely require far too much effort on the part of the user. If we require an ID check, then a criminal needs to make a fake ID and physically go to a store. That increases the costs to them such that they can no longer outsource it or do several in a day. If the target is high-value enough, they can still succeed, but it will take more effort and there will be many more possibilities for them to mess up and trigger an alert. In addition, if they do try, they have now committed forgery and fraud and I think the police will be more interested in stopping them.
In the U.S., there are many places where you aren't so close. They have to balance the security of requiring people to go there with the convenience of not requiring people who don't live in an urban area to travel well out of their way. I think that they could handle this by sending a replacement card to the address of the user, which would work for a legitimate request (almost always) and wouldn't require the user to go to the store. Letting someone at a call center change the card without security controls is a very bad decision. The two of those physical methods would work reasonably well for any account with an address or ID attached. Prepaid accounts set up without identification might be different, but I believe they are becoming rarer and rarer.
That's exactly the problem. If the FBI only existed to do things like this, the U.S. could figure that out and get rid of it. But most of the stuff they do is actively helpful to the average citizen, from investigations of major crimes to coordination among smaller crime-fighting organizations. And then they turn around and demand things they have no business having and access communications data without warrants. The institution needs a thorough cleaning and some parts should be jettisoned entirely, but on the whole they're still needed and mostly honest. If only it was easy to assign organizations to a good or bad pile, the efforts to improve would be so much simpler.
That was reported. We assume it's correct, but it might not be. However, I believe that that did happen.
That was four years ago, years which Apple has spent improving security. It's quite likely they've patched the vulnerability used back then and the various people who want access now need to find another one. It would be easier if Apple put one in, so they'll ask for that for a long time. If it was really very important, they'd have another group find it. That they haven't suggests that they don't care all that much about these specific devices and just want access, you know, for next time whenever that might be don't question us we're the law.
Go to that article. See what we said. We weren't happy with Apple's decision in Hong Kong, and we were pretty clear about that. Yes, I see some people there who made such arguments as "It's legal under Chinese law", but they seem to have received quite a few dissenting replies. I'm still not happy about that.
That said, show me a good company that protects people everywhere, rejecting requests for censorship and surveillance no matter who submitted them. I can't think of any. Apple is helping slide closer to that end of the scale, but they're not on it. I'm happy to be angry at Apple whenever they do something dishonest. This time, they haven't.
You don't need DoH for that, just get the typical DNS providers to set up a different set of servers to handle .org and reject what ICANN has said to do. Doing that is easy. Getting it adopted by anyone else is difficult. Doing that without breaking things is impossible, and it only remains to be seen whether someone gets worried enough to do so anyway and risk the breakage.
Profit is fine. You are missing two major points, or intentionally ignoring them.
1. None of the places involved in this at the beginning were for profit. ICANN as well as the places responsible for .org were nonprofits; in fact they still are.
2. None of the money they're getting is due to work they did. They were entrusted with something, and they're selling that thing. As if I put someone in charge of an art museum and that person started selling off the artworks. They didn't produce anything special, and the thing they manage doesn't have value because of their efforts, but because it had value before. They're entitled to being paid for the work they do, as the museum director should be paid for organizing the museum properly and managing security, but neither .org nor the masterpieces of someone else's efforts belong to them.
Just because some phones can be rooted or install a custom ROM, that doesn't mean it applies to all, or a "majority". It just doesn't, plain and simple. Many of the devices on the market are locked down to prevent you from doing that. Even those that can be rooted make it clear to you that you aren't supposed to be poking around there, marking the device as insecure which can make some apps decide not to work.
Compared to every desktop operating system in common use, this is crazy. No matter whose Windows machine you buy, you have the right to be an administrator. You have the ability to boot to an external disk. The same applies to Macs, Linux machines, BSD machines, and pretty much everything except some Chromebooks. And yet, people wishing to root their Android device usually check for that before they buy it because they know most out there won't make it easy if they let it happen at all.
And as we know, to root any phone running Android 5.0 or above, you click settings, scroll to the bottom, click "Root this device", and agree to the prompt. You might have to enter your passcode as well, and the process should take ten minutes or less, ending in a reboot. Oh, wait a minute. I drifted off and was dreaming. What were we talking about again?
It would be anticompetitive to deny them the ability to preinstall their apps. However, I did not suggest that. I suggested that the preinstalled apps would have to be uninstallable and would be subject to the same permission restrictions as any other apps. Google doesn't want to do that for a few reasons. First, they don't want any of that to apply to their own apps, and if they restricted manufacturers but not themselves, that would indeed be anticompetitive. Second, they get paid by the manufacturers, and they wouldn't want to anger any of them. Third, they know that not many people are using the manufacturer-provided apps when the Google apps are also preinstalled, so they get the data anyway.
You misunderstand the trust issue. If you build it yourself, we would trust it. If you got it from someone reputable, from Google to the Lineage OS people to someone who has earned our trust in building images, we'd trust it. If the image comes from a user on a webforum, that's a much less trustworthy origin because you don't know what that user built or whether anything else was done to it. The discussion was about ease in building and flashing. It's not a simple task to build Android to run on something, nor is it simple to figure out how to flash it unless the bootloader is very accommodating. Technically aware people such as the ones who read and comment here can do it, probably, but it would take much longer than downloading a Linux image and putting it on a disk. People who are less technical would not find it straightforward at all.
If they cared, the Google-enforced solution looks like this:
1. If you manufacture a device with extra software that can't be uninstalled, you can't be part of our Play Services community on any newly manufactured devices until you update your older devices. If you manufacture devices without Google Play, you must make these modifications on them if you ever intend to run Play Services on them.
2. We have modified the Android kernel not to allow an app to bypass certain permissions, and if you modify the kernel back we will flag your installed apps as malicious through Play Protect.
But none of that is going to happen. Google has no incentive to want this, no reason to spend any time on this, and no interest in taking any user-oriented actions such as this. If they did, their own apps would look very different, and they would have a better system for making sure people got security updates at the very least.
There are lots of laptop users, and for each, a different kind of laptop is useful. I carry mine around quite frequently, so being somewhat light is important, but I don't need it to be unusually thin. Neither do I need one with a desktop's worth of processing inside it; sixteen gigabytes is enough memory for everything I need it to do, and if I need more, I have no problem offloading the task to a server. Those characteristics don't apply to everybody. Similarly, I would be interested in a revival of the netbook, specifically in the sense of a device with a very small screen, keyboard, and asking price. While there are others who might want that as well, the concept doesn't seem particularly popular with the general public. Some people want a laptop with the power of a workstation and others want it to be as thick as a sheet of cardboard. Fortunately, there is something around for both of those people, just not the same thing.
Two reasons come to mind. First, there might not be ruggedized cases for every phone on the market. I am certain there are some for the devices that sell very well, such as the latest iPhones and Samsungs, but there won't be for the low-priced phones which get changed out from month to month, and for everything in between there's no certainty at all. Therefore, one can't choose a phone they like and be guaranteed to find a case that fits it.
Second, a ruggedized case might not give you as much protection as a ruggedized phone. The case manufacturer probably has tried their best. Still, there's less profit margin for them to buy a bunch of another company's phones and try to break them than there is for the original manufacturer to try to damage their own. Finally, if the unit you're using turns out not to have been ruggedized sufficiently, the manufacturer of a phone that claims to be able to handle it is probably more likely to replace it for you than the case manufacturer.
"Are you aware that is almost entirely for beef/cattle farming - which is almost entirely exported, in particular to the US?"
Yes, I was aware of that. Are you aware that the people doing the farming are Brazilian businesses, not some international group? And that this applies to myriad other areas where other things are being produced? See how it's still a problem? If it's shipped to the U.S. or eaten there, the forest has still been burned. This isn't necessarily the fault of increasing populations, but nor is it the fault of an eventual consumer. The people making the active decision to take an action that harms the environment are responsible.
You cannot limit yourself to taking only one action or declaring only one perpetrator. It's as if your house was on fire and I came to deal with the problem by pouring water on one corner of the house. I wouldn't be helping anything because the rest would continue burning, and when I ran out of water that corner would also go up in smoke. If you want this problem fixed, you need to evaluate all of the contributing factors and make plans for dealing with any that are large enough to have an effect. You can't focus on only one country or region, whether that's a developed or developing one, because the problem is global.
I didn't vote either way, but I think your view is limited. Not wrong, as consumption is a problem too, but limited. Increasing populations also put pressures on the environment, and in different ways. For example, growing populations in areas almost always leads to deforestation of those areas for extra places to live or to grow food. When that happens, even more of the trees that sequester carbon are taken out of commission, and the typical way of doing that is burning them which exacerbates the problem. A good example of this was last year's fires in Brazil which the Brazilian authorities weren't particularly interested in stopping.
You can't treat the issue as only having one primary cause, because you'll end up playing a game of whack-a-mole. If something contributes, it should be considered as important. The single reason I provided wasn't it, either; that was just one example. There are lots of moving parts in this system, and you can't just point at the big, obvious one and think that you can simply make it stop or that making it stop will stop the system.
I don't think the innovations have been very important, but until 2015 or so, you could at least notice them. The new phone would have a better screen than the last one, would load apps faster, maybe last a bit longer on battery*. The same being true of communications--data over 2G was nearly unusable, 3G was good, 4G was great. Now, although processors in phones get faster and faster, I don't really see any effects on my general usage. I'm sure some people use more processing and have noticed the changes, but I doubt it's their major consideration. A logical response from the manufacturers would be to try to experiment with new things or to compete on price. They've made a couple attempts at the former, but their treatment of the latter is strange and doesn't seem to be helping them all that much.
*New phones running for longer on a battery: I am only comparing like for like here. I know that non-smartphones ran for longer, and that a new phone with a larger screen will run shorter. For a while, phones using new chips and the same quality screen would improve their battery life. Now, every saving in battery is used to allow an even bigger or higher resolution screen.
Yes, the majority does. But the companies want to sell to everybody, including the minority. In addition, the majority who live in cities sometimes tend to leave their cities. They may go drive or take other transport to another city, or go away from the city for recreation, or move into a suburb, which might be in an area with obstructions to easy coverage. These conditions increase the size of that minority, and depending on the area, they may make it a majority.
Attribution is hard. It's. possible that someone's been framing North Korea for an unspecified length of time, and they either are responsible for everything attributed to that country or are very good at mimicking characteristics of their malware to do the framing. If so, they're really good at fooling everybody. However, we've seen what it's like when people try to blame North Korea--someone who is probably Russia but theoretically could be someone else tried to do that a couple years ago, and they didn't stay hidden for very long.
As for solid proof, there are several types. The basic type of having found assets in the malware relating in some way to North Korea applies to most of them, but could obviously be faked given some effort. This runs from the simple string frequently used there to a network address that has been operated by Pyongyang interests at some point. There is also the tactic of code comparison. If a group uses a similar module (similar in the sense of similar compiled code) that was previously reliably attributed to North Korea, then it's probably North Korea doing it again. They're the only ones with the source, so it's extremely unlikely that someone went to the effort of reverse engineering their codebase just so they'd produce similar binaries. And finally, we can have extra confidence in some of these tactics because there are some pieces of malware to which the North Korean government has admitted. Using these tactics, researchers who have spent years looking at malware from different groups can do a reasonably good job of telling when one of those groups spins up again. Nothing is guaranteed, and attribution is very tricky, but don't presume they don't know what they're talking about.
The problem is that you can apply that logic to anything at all. If a parent installs a desktop that has a camera on it, for example an all-in-one machine, they have now recreated the same environment. A malicious actor who gained access to that machine would have the same capabilities as one who gained access to this IoT device. They can't easily keep moving that desktop around with them.
I don't think we'd believe them totally blameworthy if that computer got infected with malware to their detriment. Yet if it did, they're likely much more responsible for the problem than someone who installed this IoT device. From the sound of it, the cameras could be accessed with relative ease online by guessing a password, while getting malware onto a desktop usually requires the user to fall for a fake download or phishing email. On this basis, attempting to blame the parent for something the manufacturer could prevent seems limited at best.
I'm considering the statement "Joke icon yes, but part of me actually wonders if this would be justified in some odd way." as cancelling the sarcasm. That's a terrible idea. There are cameras, microphones, and speakers on lots of things, including laptops, phones, some desktops, and various other devices. If you include those devices that lack a camera but do have a microphone and speaker, that's almost every consumer electronic device.. And somehow, it's the users' fault when that device gets hacked? Instead of the manufacturer who could have made the device more secure? When it's already been pointed out that no matter how much the users might want to spend time and effort on a more secure configuration, they don't have the option?
That presumes several things:
1. There are ranks.
2. The managers want to move this employee up the ranks.
3. This employee wants to move up the ranks.
However, in most cases, one or more of those things won't be true. For example, I don't want to move up the ranks of most employers, because my job is software development. Some places will have a "senior developer" role, which is effectively the same as my current position but they're paid more and have a bit more independence. Others don't bother with that; there is one rank and you just get pay raises if you've done well. Many of those places also have the concept of going up the ranks, and if you do so, you stop writing code all day and start managing others who do that. I don't want to manage, and therefore I don't want to go up.
In this case, however, the problem is that the employer wouldn't want to move the employee up the ranks. Doing that wouldn't help them at all; they'd still be paid a higher amount, in fact they might deserve another raise which a discriminatory company wouldn't want to provide. In addition, a good helpdesk worker elevated to a new position wouldn't even be doing the helpdesk job they were so good at, and their superiors might now have to deal with their management, which is untested. Do you think a company that is already willing to discriminate based on age is going to take that risk, or will they try to get rid of the risk and hire a replacement at much less cost to them?
You can age discriminate either way. The article talks about discrimination against older people, which is certainly seen and quite a bit in tech specifically, but there are also examples of discrimination against young people, usually in different fields. It's often because the young are believed not to have sufficient experience or to be unreliable. Either way it's done, it's a very limited generalization. It's wrong to do, and it's usually not at all productive anyway.
They say what jobs they were talking about, and they never claimed that the percentage was representative of anything else, only that it was significant. All this says is that age discrimination happened in the dataset they used at a high enough level that it's worth considering doing something about it. It doesn't necessarily mean that it happens everywhere, but when you combine this research with the many other times age discrimination has come up with varying levels of proof, it seems pretty obvious that it's pervasive and needs extra looking into.
As with the last license, after having read the one you mention, I have little objection to its content. However, I see no particular merits to this license and a few annoying aspects. The first is that this license includes many phrases that sound like this: "Nothing in this Licence is intended to deprive the Licensee of the benefits from any exception or limitation to the exclusive rights of the rights owners in the Work, of the exhaustion of those rights or of other applicable limitations thereto." It's reasonably clear what this sentence means, but it is by no means the clearest way to say that and the whole thing is written like this. Compared to the clarity and terseness in many other licenses, this is worse.
Second, I note the geographic limitation to where this license can be argued; if I produce a work licensed under this in Canada and someone in India violates that license, I can only pursue some types of actions in Canadian or Indian courts, and must pursue some types in Belgian courts. That might never be a major problem, but I see no benefit to the restriction.
It's not only Python that does this. Perl and PHP both have made breaking changes between versions, in fact quite a bit more frequently than Python did. Nobody likes breaking changes, and I'm sure the PSF would have chosen not to if they could get around it. However, by forcing the tricky unicode handling parts to be made clear, they unearthed many potential future bugs, which would have been found later on in less pleasant circumstances had they not broken that. For the same reason, if you designed a C-like language today, you could probably suggest some improvements to it that can't be implemented in C itself to preserve backward compatibility. Not everything about the update was necessarily a good thing, but I think there is sufficient merit that the language shouldn't be counted out.
