Posts by doublelayer

Raspberry Pi Pico cracks BitLocker in under a minute

Re: Deliberate

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.

Re: Deliberate

Are you a cryptologist? You are aware that generating new keys each time you need to communicate opens you to an attacker intercepting your communication before you've sent the key, substituting their own key, and MITMing all your traffic. The hardware used to read communications along this path can also write them. The way to get around this is to prearrange keys. If the TPM had a bit of memory to store the key, then you'd only need to exchange keys once, although either side losing or compromising the stored key would break it.

Generating keys on the fly is no more secure than this method when your risk is external access to the communication path.

Re: A brilliant testament to analysis

That method already works with this vulnerability. If there is an additional passphrase, then the overheard component from the TPM is insufficient to decrypt and you're already secure, no need to add additional cryptography to the communication. And any user can set that up with Bitlocker. This happens when they have selected not to do so.

The spyware business is booming despite government crackdowns

Re: How much are we doing this to ourselves for convenience?

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.

Re: $860K per target?

Not exactly. It's $860k per concurrent target. If they target you, gather information from your phone from an hour, then stop, they pay nothing other than that they have to take their eyes off someone else for an hour. If they're targeting lots of people, adding you can be pretty cheap.

This is also not necessarily the only price. I think it's likely they may have multiple prices. For the wealthy dictatorships, they have the inflated government price. For many other governments, they have the less inflated government price. For the keen business who wants some surveillance, they have their special discount based on how much money the company has available and how badly they seem to want it. Why not sell to the low end at a lower price when adding more victims is almost free? You might get some customer loyalty.

IPv4 address rentals to mint millions of dollars for AWS

Re: Re. There are now more devices than IPv4 addresses

I'm not saying that private addresses are bad, but that public addresses shouldn't be limited unless there's a very good technical reason. Because we don't want to use IPV6 is not a good technical reason. By all means use the private address space for things that don't need public addresses. However, the mindset of many ISPs is that nobody needs public addresses and nobody will get them unless they request them and pay, usually per address, for the privilege. It should work in such a way that you can choose private or public as you like. IPV6 allows that. IPV4 would allow it, but because of address scarcity, it generally does not.

No, all these downvotes because the ones they're talking about are reserved addresses for other types of networking. In hindsight, lots of those reserved addresses are not doing much of use being reserved and could have been used as normal addresses, but it's too late to change that now. If we could retroactively change the protocol to remove those blocks, and maybe while we're at it take back most of 127.0.0.0/8 and 0.0.0.0/8, we could gain maybe 600 million addresses if we're lucky. That would help push the problem back a bit more, but it would not fix any of the other reasons why IPV6 was adopted, nor would it prevent IPV4 from running out of addresses.

We could go to more lengths to take addresses away from organizations that don't need them. Lots of addresses are stuck there, but at the end, we will still have a cap near 4B addresses, and the internet is growing to the extent that it is not enough addresses. The truth is that your equipment can already handle this unless it's really ancient, that the addresses may be harder to read, but they're not really that difficult, and that you sometimes have to do something moderately tricky when tech changes. Trying to reclaim multicast will require as much work on your part to implement as adopting IPV6, but it also requires a bunch of code changes which have already been completed for most IPV6 systems. We should not have to go to the effort of forcing every internet user in Asia , Africa, and South America through multi-layer CGNAT and an annoying process where we try to convince the US military to give up some of their /8s because they always take suggestions from the public so you don't have to beta test a new network.

Sure, they could have made an IPV6 that looks more like IPV4 and has longer address fields, but that would still require people to implement the new protocol, exactly like they do with IPV6. The other changes introduced when they made IPV6 have some problems, but that's not the reason it hasn't been adopted. Most places that haven't implemented it aren't saying that "If only IPV6 didn't have [insert change here], we would just use that". Either way, the change requirement would be the same and the work would only be done when it was almost too late.

That estimate is just wrong. I don't know how many addresses are in use, but there are three categories to consider:

1. Machines that are online now and respond to pings. About 6 million, evidently.

2. Machines that are online and do not respond to pings. This is the default for most machine images and firewalls. You have to take two manual steps to change your configuration to allow pings. I'm not sure why this guy assumed that 50% of users would have done that.

3. Machines that allowlist IPs and won't respond to your script no matter what their ICMP settings are. There are a lot of these out there for private networks that use the public internet to connect them.

I don't know how many are in use, but it's a lot more than 12 million.

Re: Re. There are now more devices than IPv4 addresses

The problem being that, if you want to have two servers but you only have one IPV4 address, you have to put another box in the middle to filter and direct traffic to the right one, and if you want to have twenty, that box ends up having to be a lot bigger to do work you wouldn't need if you could just give each server an address. The problem being that, when someone wants to build a point-to-point network from their own devices, they can't do it without some central server coordinating things because their ISP has multiple layers of NAT in the way. Let me guess, you don't see a problem with it because you either don't run many or any servers on the public internet or because you already have your own IP addresses? A lot of people do not have assigned IP blocks, and many countries were assigned so few that you'll virtually never get them. It's another reason that people start to use cloud providers, because there isn't much work involved getting a new instance publicly available, even though it produces a worse maintenance requirement later.

AI models just love escalating conflict to all-out nuclear war

Re: FOX to blame?

While those probably contain a lot of crazy, you don't have to go that far. On this site, go to any news article about ransomware and look at the comments. You'll see lots of calls for ransomware operators to be killed by our military without trial, assassinated, tortured to death, targeted by airstrikes, and on a few occasions, threats of or actual delivery of nuclear attack on countries that aid their actions by not enforcing laws. Probably a lot of this is hyperbole trying to express the statement "anyone willing to infect a hospital with ransomware is evil, they're not getting punished right now, and I would be happy if bad things happened to them", and they aren't serious about getting that severe with the response. A chatbot does not know that. If nuclear bombing of Moscow is an appropriate response to a ransomware attack from a group with a Russian director who didn't get arrested, then why not use them for everything you don't like?

Chatbots are not trained exclusively on writings of sane people talking realistically about important issues. It probably wouldn't be that much more useful if it were, but it would look different. It's mashing up writing about topics the writers may be incompetent to comment on and then applying that wisdom to situations the original comments weren't even talking about.

Re: Unsurprising....

"So here's a thought. Program AI to play these war games with their goal being to not lose a single 'life': To retain the numbers they start with."

No problem. In order to preserve as many lives, ideally 100% of lives, present on our side, the necessary act is to destroy the ability for potential adversaries to harm any lives on our side. We therefore propose an immediate strike at all military and civilian assets of all potential adversaries.

Or alternatively, to retain the numbers we start with, we will need to ensure that the lives destroyed are replaced by new lives from our side, so in addition to destroying the adversaries' ability to harm our lives, we must begin a project of life creation to get the lives budget balanced.

You can program any goals you want in. The output is still not going to be very useful. Decisions about whether to attack aren't made by logical machines, not that we have such anyway, but a small set of people. Knowing what they will do and talking them into a different plan won't be accomplished by bots trying to solve a mathematical problem about what kind of military advice would appear in a web page it's scraped.

Survey: Over half of undergrads in UK are using AI in university assignments

Re: Plus ça change, plus c'est la même chose

I think you may overestimate what you're getting. It may look nicer, but if it's inaccurate or lacking in detail, it's still not good. Judging from your responses, I'm worried that you might not care.

Re: Plus ça change, plus c'est la même chose

Job tasks and education tasks are not identical and shouldn't be. Let's stick with painting. There are some painting jobs that can be done with a big sprayer. A certain kind of paint, a certain level of acceptable quality, and the sprayer becomes an option. It's an easy and cheap option when it's acceptable. Yet if we're teaching someone to paint, we can't just let them do every job with the sprayer, because at some point they may be called on to do a job with something else. If you want a painting job that can't be done with the sprayer, you expect that your painter has learned to use other tools. That means that, if the painting teacher says that you have to paint this wall with a brush to demonstrate you know what you're doing, it would not be acceptable to use the sprayer and say "look, the wall got painted, why should I do it the way you said to". The test restricted the available tools for a reason, and the reason is directly applicable to the use of the skills later.

The same applied to my example of programming languages. They weren't asking me to write a program because they needed the program for something. They were asking me to write it so I would learn something. That means using a language I'm less familiar with, one where it's harder to write, one where it's more likely there are bugs in the result, but the choice that means I learn a skill because there are times when I will need to apply that skill. If people frequently had to use punch cards in modern industry, and they decided to take a course that taught how to do it, then yes they absolutely should be required to use punch cards and doing the punch card homework using a modern compiler would not be acceptable. We don't teach that because it is not considered useful, but if we did, the students who chose the course would have to do it.

Re: Plus ça change, plus c'est la même chose

No matter how good LLMs get, you will still have to write things. If you need to describe something to someone that doesn't already exist on the internet, you have to actually write down the details. The LLM does not know any of the things that just happened, so at the very least, you need to accurately provide all that information to it for it to rewrite into something that looks nice enough. This is the same reason that calculators don't make mathematics obsolete. They're great at figuring out what the answer is, but they're completely incapable of determining what the question was, so you still have to do that part. I think you already know this.

Re: Plus ça change, plus c'est la même chose

If you're being tested on how to write an essay, you need to demonstrate that you can write it. If you're being taught to use a brush, you need to demonstrate that you can use a brush. That is different from later applications of the same. If you're being tested on painting something in general, you may get to choose a tool from a set of different ones to do the job, but if they're specifically testing your ability to use a basic brush, you may not get to use a different tool, even if you otherwise would want to.

For example, there were a couple occasions in my schooling where I was permitted to select the language in which I'd write a project, but mostly I did not. If I had asked to do so, I'd have likely gotten a response like "Of course you can write this string manipulation program faster and easier in Python than in C, but this class is taught in C and we want to give you something easy so you learn how to use C". It doesn't matter that, if I had a similar task in the workplace, I would almost certainly not use C unless performance was critical, because the point was not to have the program written, but for me to learn something.

Re: Plus ça change, plus c'est la même chose

The calculator does a specific task and it is easy to decide whether having that task delegated is acceptable. If it's a child doing arithmetic tests, it is not. If it's a university student doing calculus, a calculator that can automate the insertion of terms into a formula the student derived is fine, but a program that automatically derives it is not. In the workplace, that program is probably fine as well.

An LLM is sufficiently capable that it could do a number of tasks, nearly all of which are not acceptable. The comparison to an assistant is valuable here: in school, you don't get to have an assistant. I did not get to write my code, then pay someone to write the documentation for me because I couldn't be bothered to do it myself and the graders didn't look too hard at it; I had to write that myself because that's what the assignment was.

Some of them have to realize that the homework answers generated by an LMM have a decent chance of being wrong. If you're going to cheat, there are ways to cheat that aren't as much of a throw of the dice. Sure, they take longer and may be more difficult, but if you're bothering to cheat, presumably you want to get something out of it and LMM cheating isn't guaranteed to get you anything.

Critical vulnerability in Mastodon is pounced upon by fast-acting admins

Re: Trust Mastodon

You have it wrong. Other server admins can block you, not the devs*. That causes a problem, but it's not what you're implying. Since I don't use the system, I don't know how frequent that is, but at least describe it accurately.

* Technically, the devs could write the code to exclude you, but that's not what has happened.

Windows 11 24H2 is coming so we can all shut up about Windows 12 for another year

Re: 12

To be fair, they haven't said they're releasing Windows 12 any time soon. It's all been speculation about when they might do that and what might be in it. I don't expect it will be soon. While I'm sure it will happen at some point, it has only been 2.5 years since they pushed out Windows 11. That would already have been a relatively short gap between releases in the earlier versions of Windows (everything after XP, anyway), but compared to the seven years between Windows 10 and 11, I'm guessing the gap will be longer than average this time. Maybe 2026. That's also just speculation; while I think it would be a bad idea to release a new named version before then, Microsoft has done things that I consider bad ideas before.

Is critical infrastructure prepared for OT ransomware?

Re: Only a few percent of your military budget

That is probably true in the short term, but what you accurately describe as "drawing fire from the ransomware gangs" can also be viewed as training their abilities. If they didn't have plans to attack OT, as the article calls it, then Ukraine has given them a reason to learn how, possibly some incentives to do just that, and plenty of acceptable testing targets. If the war drags on long enough, they may have more of those skills and fewer targets in Ukraine on which to use them, which cannot be a good thing. Unless we're willing to hold the Russian government accountable whenever we're pretty sure that the attack came from a group Russia could break up, which I don't think our governments or, unfortunately, our fellow citizens are willing to do, we will want to reduce their skills and their ability to use them to make money.

Linus Torvalds flames Google kernel contributor over filesystem suggestion

Re: A better long-term approach...

You have misread it. The discussion there is about ways to replace open source with something else that would be easier to weaponize. Current open source is really quite difficult to treat that way; while Linus himself could probably prevent Red Hat from contributing to Linux, few others could do so unilaterally, and it would take a large group to do it without Linus's support. Should this happen, it would be possible for some group to fork the code and try to make that the canonical (little c) version. They might or might not succeed, but they have the ability and right to do so. There are some who would like more ability to control code to prevent people from doing things they don't like with it, but it is opposed to existing requirements of free/open source as defined by both FSF and OSI definitions and the licenses that implement them.

Techie climbed a mountain only be told not to touch the kit on top

Re: Remote people might be right

If we believe the article, the problem that meant they should do something to this box was happening on a redundant box that was not customer impacting. This means that rebooting it shouldn't have dropped anyone unless the other box was also broken, and that they were doing anything at all suggests that the box concerned might already be in a state where it wasn't dealing with traffic. If the latter is true, then there's no harm in rebooting the box if the redundancy is set up correctly because the worst that can happen is that it still doesn't take any traffic. These are the kind of points that the staff should consider, and when they have, should be willing to explain. If I ask you why I shouldn't take a certain action, I expect some kind of explanation. Not just so I don't leave thinking you might be wrong, but so that I can remember it for the next time something happens.

Re: Had a similar thing happen

I'm assuming you've already tried forcibly closing the app alone, not the entire phone? If so, I'm wondering how badly someone can manage to make an app that can cause a persistent crash that still goes away on a power cycle; the process isolation of Android and IOS is supposed to make that hard to do. Not that they don't manage it, but I've usually not had to power cycle mobile devices to deal with a faulty user-level program whereas desktop programs do it with some frequency.

How not to write about network security – and I'm speaking from experience

Re: Goodbye OSI Layering?

The risk is that having redundant security measures on all levels of the stack means there are lots of ways for it to fail, and when it's working, it is likely significantly less efficient than it would be otherwise. If you, for example, do IP allowlisting on all the levels instead of just one, then when you need to change allowed paths, you need to work with lots of different network hardware. It prevents an attacker from easily adding themselves to the system from one compromised device, but it may make it so difficult to add anything to it that someone decides to turn it off. That's assuming that no device ever loses the configuration and locks out a device that should be listed, which can have even wider effects. Similarly, if you encrypt things at every level, you will probably end up spending a lot more money on networking equipment to perform five layers of encryption and decryption or spend less and get less throughput as cheap processors spend a lot of time on it.

You can do this, and there are some cases where you should consider it, but it strikes me as the opposite problem to the typical bolt-it-on side. The people who don't think about what they need, then try to have someone just take this code and add security usually don't get what they need, and nor do those who try to enclose everything possible in a separate layer of security and then try to make those things work well together. You have to take the more intensive and thorough approach of considering where you can put security measures before building the system that will have the most effect and the least impact on the other goals such as performance and ability to develop it well. You can add redundancy there as well, and in many cases you should.

Re: I would really like a good book on network security

The problem is that many of those questions have really long answers. Checking the settings for UFW, iptables, or Windows firewall is pretty easy. Running nmap over your network is a bit more difficult, but not too hard. Knowing that no software has a sneaky path is so much more difficult, and understanding the full risk profile of every service is a task that cannot be done the same way for any two systems. There are some checklists for blocking the easiest attack methods, and many of those checklists are getting adopted as defaults anyway, but every level of complexity that gets added brings vulnerabilities that are a little harder to exploit and also harder to detect without spending some serious effort on it. The risk of trying to write checklists for those levels is that there are too many things to list and many occasions where applying a preset configuration runs the risk of breaking something else. Even if it doesn't, the risk of giving someone a false sense of security is always present.

LockBit shows no remorse for ransomware attack on children's hospital

The previous extraditions of ransomware operators suggest that they already take them seriously enough to arrest them and send them to the US, which for some reason seems to be more involved in prosecuting them. I don't think changing the charge is going to increase that when the problems are often that they don't know the identities of everyone involved, so the list is pretty short as it is, and that the people on those lists are aware of it and tend to stay in countries where they're less likely to be extradited. It's pretty easy for, for example, a Russian attacker to know that if they've been named, the Cyprus vacations are out (they probably were anyway because of the war, but that used to be a popular destination), but you can still go to Dubai or the Maldives. Unless you think changing the charge will have an effect on those countries, I don't think it will do much.

Re: It's time

I'm not so sure. It's easy to assume that, because they collect all sorts of data, intelligence agencies should know everything about everybody. I'm not convinced that they actually do much with the stuff they collect until after they decide to use it. They probably don't spend their time tracking down criminals, leaving that to normal law enforcement who doesn't have the massive datasets that the intelligence agencies do. I'm sure they know some identities and aren't responding for the reasons you've stated, but I expect there are many who they consider beneath their notice.

I have no problem with adding it, but the major problem is that they're not getting punished with anything. From their perspective, they're not too worried about what they would be charged with because they don't expect they'll be arrested or punished and they've often been right. So, while your logic is flawless, I wouldn't expect making that change to have any real effect on what happens, at least in the short term.

The FCC wants to criminalize AI robocall spam

Re: Some months ago I was downvoted

Benefit in the sense of real broad societal enhancement: nothing. Benefit in the sense that some person manages to make some money: definitely. It doesn't only include people doing illegal or unethical things, either. You could use some of this technology to make certain things more cheaply, for example using modern voice software to perform voice-over work instead of hiring a voice actor or using it to create images instead of hiring a designer. The voice actor and designer probably aren't happy with that option, but it does mean that the costs for whatever involves these will be lower, which may get passed on to you. The harms of unethical and annoying use probably outweigh this, but we don't get to choose not to have it. The technology exists and will be used for all these purposes whether we approve or not. Copyright claims may weaken the one that makes visual art for a bit, but probably not for long, and that's assuming that the side I think is right wins which isn't guaranteed with so much money involved.

Ransomware payment rates drop to new low – now 'only 29% of victims' fork over cash

Re: Time to ban paying!

My point was not that it wouldn't be illegal to do it, but that it would be possible to hide it. If law enforcement doesn't realize you did the illegal thing, they won't come after you. If they figure out that the illegal thing did happen, but you successfully get out of the charges by saying that your contractors did it without your knowledge, it also gets you out. Neither of those would be what the law intends, and, if proof that you did either existed, you would be culpable of a crime, but they are not that hard to do and hide. An audit would not necessarily indicate what actions were taken, just that someone was paid to resolve a situation and that it was resolved. There is no way for an auditor to know, from the payment to an established data recovery company, whether that company broke the law or not. That company, in turn, can run both a legitimate data recovery service and a ransom payment service. I think fewer companies will go through the effort required to do an illegal thing and hide that they have, but I won't pretend that none of them will. This does not change my opinion that a payment ban would probably be helpful on balance.

Re: Time to ban paying!

I agree with you that a ban on payments would be a good idea to pursue, but I think you're underestimating the ability for businesses to get around the rules. I don't think, for example, that "payment to a shady facilitator will look just as obvious in an audit as a payment of the ransom" because it's really easy to hide such a thing. Instead of paying the ransom directly, you pay a company who is going to provide contractors to help you clean up quickly. Those contractors might be helping you restore from backups onto fresh images, or those contractors might be taking part of your payment and paying the ransom with it. Only the contractors need to know which one they picked, and even if you know, you have an excuse for why you might not have known to get around the fraud charges.

However, I think that the number of companies doing that will be less than the number of companies paying ransoms in the clear, so I still think that banning payments would reduce the number of payments made and thus the profit in it. It won't reduce either to zero, but a lower value is still an improvement.

Microsoft's vision for the future of work is you trusting Redmond to get AI right

Re: There are alternatives to Co-Pilot

Because, even with all that annoying crap, people aren't adopting Edge. The market share figures typically have it down near the bottom. While that doesn't technically prevent this from being ruled an anticompetitive action, it's unlikely to be brought up as one because it's clearly failing and thus it is hard to establish harm to anyone.

Re: Doh!

You can disable it entirely so it can't be activated without enabling it again. I'm not exactly sure what "nuke it completely" entails. Do you want Siri to no longer appear in the Settings so it's impossible to turn back on?

Their point appears more general than that, though, since Siri is a frontend to a set of databases that are usually available in other places. Siri's contact information for businesses, for example, is the same ones you can see in Apple Maps as well. The problem is not the voice interface, but the incorrect data it occasionally returns.

Re: US bias

That's what happens when you shove the entire internet into the training set and push the go button. These programs are not looking through the data to find out which things apply to your country, they're just guessing, and if there's more about the US in their training data, it's going to show up when it randomly looks for answers unless you've crafted your prompts to keep reinforcing your country name. Even then, it's not guaranteed to get things right, just more likely to. I'm hoping that people will eventually recognize that this cannot answer specific detail questions when those questions get past simple (I.E. whenever a simple search wouldn't turn up the answer).

It's true, LLMs are better than people – at creating convincing misinformation

Re: 676 sites (!)

"Embed top level domain reputation filters into browsers. Allow low reputation TLDs for experimenting developers, but keep them out of reach unless the filters disabled explicitly."

That won't do anything. to stop people from just putting their junk in an older TLD. I can get a .co.uk for pretty cheap. Sure, the name will be less clear than if I use the word of my choice because someone probably registered all the nice .co.uk domains already, but if you're blocking other TLDs, it can be managed.

Making the registration difficult doesn't help either. It might do something against scammers who like to quickly spin one up, run their scam site for about five days, then try to get a refund from their registrar, but sites intended to have misinformation stick around for a lot longer. It's also pretty easy for operators to just set up a bunch of domains, park them, and bring them online when they've got something for them to say.

Fairberry project brings a hardware keyboard to the Fairphone

Re: The Blackberry Passport...

Which, so far, I oppose for the reasons I stated. I have yet to see anyone explain how any of this is done without breaking most or all of the reasons why multiple messaging protocols exist. I thought that Liam, having expressed interest in the concept and having some technical experience, might have an answer to this. So far, if he does, I don't understand it.

The law as it's currently written basically just calls for this to somehow happen and doesn't explain how or give any criteria. As far as I know, nobody is taking steps to make it happen, and there is a distinct chance that they won't be able to manage it while keeping encryption working. I doubt that was the intended goal when the law was drafted, but I also doubt that the theoretical loss of end-to-end encryption will bother those who passed the law very much. It would bother me, which is why I'd like to see a suggestion on how to keep it and the various other advantages or the requirement reversed. I don't have a good solution myself, so I posted in the hope that someone else had thought of one and could convince me.

Re: The Blackberry Passport...

However, if you're not clear, then both projects fail to meet your standard. Exchange is breaking compatibility by not including the rich message whatever it does, and Thunderbird is failing to be compatible by not supporting it. In this case, I think it's more Thunderbird not supporting it than Exchange not sending it, but I don't know for certain. If you ask for interoperability, I see two ways of doing it:

1. Everything must support the protocol of everything, which either means that I cannot introduce new features because it would break compatibility with anyone else or that, if I do introduce new features, everyone must adopt it. It sounds like neither of us want to do this.

2. Everything must support some standard communication system in addition to whatever protocol they were built for. You can do this, but what's the point? Anyone who uses it is presumably using it for its unusual features, which will be the reason it has a protocol other than the standard. If they just wanted another XMPP client, they have a bunch to choose from. We might as well make that standard email and tell every chat system that they'd better bolt on a mail client. Those systems having the feature won't make anything easier for the users.

Not the way I would do this

I admire the work that goes into something like this, but I have to wonder if the work might not be better spent making a different keyboard rather than using a specific model from an old device. I don't imagine that many Fairphone users happen to have that particular Blackberry around, and they're not cheap and plentiful on the second hand markets. This board will, for most users, provide them the ability to connect something they will never have, and that will only get worse if they do extend this to other phones.

Other open hardware projects have built their own keyboards, and I wonder if it might make more sense to try to do that or find a part that's currently in production. The creator of this hardware may be doing it because they do have such a Blackberry available to cannibalize and might not be focused on the ease for others to adopt it, but they've gone to a lot of effort that I'd like to see pay off.

Re: The Blackberry Passport...

"This is why, incidentally, I want to see all messaging vendors legally compelled to be open to existing open standards and allow connections from 3rd party client apps."

Well that's an interesting request. How do you intend your system to deal with the situation where someone makes a new chat app because they want to offer some feature that's not supported by whatever open standard you've selected? That feature could be a lot of things, from a different format of media to a new encryption strategy. Most of the apps in your list were originally made to add some new feature that previous chat systems lacked. You could deal with a few of these by embedding more and more information in the message, and old clients just dumping unsupported messages out as text. That would work for a few things, although it's not pretty. However, for anything where the architecture is substantially different, for example if they change the routing mechanism to something decentralized or start using asymmetric encryption with user-provided keys, that won't work either. So far, I have opposed similar requests because I don't have a good solution to this problem and I don't want to lose the benefits of new systems. Do you have an alternative?

Elon Musk's brain-computer interface outfit Neuralink tests its tech on a human

Re: Why don't people see the bigger picture?

Their argument was not whether the technology could be significant to someone, but whether it is "the holy grail of human-computer interface design". There are a lot of technologies that are very useful to some people which mean little to others. Acknowledging the lack of general utility does not diminish its transformative effect on those who do require it.

Given that we don't know exactly what software they were using or what actions the monkeys' brains were activating, and that this is a person whose companies have been accused by employees of faking sales videos before, I would take that particular demonstration as perhaps not indicative of the product you get.

Japanese government finally bids sayonara to the 3.5" floppy disk

Re: What you are all celebrating...

You are mistaking two things. The first is that we're not celebrating it. I'm not mourning at all, but there is a middle area between sadness and celebration.

The second is more important. No longer using something obsolete is not erasing, dumping, or losing that thing. We have floppy disks and drives in archives, museums, online shops, all over the place really. We also know how they were manufactured such that, if we decided it was worth going into production again, it could be accomplished. It's not happening because there's no point, not because we can't. There is no benefit and some harm requiring people to use something ancient for a historical purpose. It won't prevent companies from no longer manufacturing floppy disks, but it will increase the cost and inconvenience of anyone who had to submit forms that way. It is also a good thing that you're not required to drive a Model T to get your passport, whether you decide to maintain one or not. There are many old things that we don't consider worth our time to maintain, and that is not automatically a bad thing.

Re: Less "connected" means less likely to be hacked and randsomed.

What makes you think that the system that took in data on floppy disks had no network connection? Lots of systems had networking and floppy drives. Fewer systems had networking, floppy drives, and an application that was written with security in mind. I'd be more worried about how old the software that was used to process the floppy-provided files was, because if they didn't update the hardware requirements, they may not have changed the software. Keeping in mind that the software was probably written in a time when, even if you did use encryption, it was something that can probably be cracked in seconds nowadays, I don't think my concerns are groundless.

Cory Doctorow has a plan to wipe away the enshittification of tech

Re: Does old Cory know what he's talking about?

More that they were ridiculously obvious about it. While I'm sure people here have other companies they'd allege are making money by stealing, it usually takes at least one abstraction and has a contract in the middle. For example, Google makes money by stealing our data, but although I think that's true, they would argue that they have permission to get the data (I don't agree) and that they're only selling advertisements. Napster's business model was based around really obviously allowing people to download music they didn't have a right to download. They were only slightly less obvious about it than if The Pirate Bay decided to try to become big tech. You can't be that obvious about committing crimes if you don't want to get sued out of existence.

ICANN proposes creating .INTERNAL domain to do the same job as 192.168.x.x

$25,000 US per year, $185,000 for each one created, and a per-registration fee for successful domains.

".int sounds okay to me, as it's very unlikely to ever be requested as a new gTLD."

The problem is that .int is already a GTLD, one of the relatively early ones. It's for international organizations, and it's quite strict about it. For example, the official website for the United Nations is un.int. The EU has a few of them, but they usually redirect to something.europa.eu. In practice, it's not as likely to cause a problem as using some other existing domain you don't control just because it's quite difficult to get a .int domain so it's unlikely that any other system will exist and your DNS request will just fail, but still, not the best idea.

Re: "DNS, however, can't prevent internal use of ad hoc TLDs"

Two reasons. Mostly that the land rush has come and gone. When lots of people were buying up names, there was more of a chance that that would happen, but many of those names have not proven to be the commercial blockbusters the investors were hoping for and they're busy hosting cheap domains for scammers and the occasional domain hack, but not even a fun one as was done with two-letter TLDs. Some of them have even been shut down entirely. I don't think people are still hoping to throw money into that.

The second reason is that ICANN already decided that some TLDs were not to be reserved. Back in 2018, they put several TLDs on the never list because some internal systems had used them. If .internal was already used frequently, I would expect ICANN to reject the application should someone try to reserve it after all. I don't have any objection to them doing this, but it's weird for them to make it sound like they've done a lot of work when they have no technology to set up.

One person's shortcut was another's long road to panic

Re: Genuinely curious...

I suppose you could try running your script in a chroot of the directory concerned, which depending on where the link was going might or might not prevent the program from going there as well. However, when you get to the point of involving chroot, you're also at the level where you could write explicit symlink logic. It sounds like this script had not gotten to either level.

Re: Genuinely curious...

One option is that there was a script somewhere which used relative paths and moving the script somewhere else was harder than just linking in the data for it to work on. I've had the experience, in fact I'm having the experience right now, of a script that's not written well but it would theoretically be faster for me to work around its errors rather than going in and fixing it. For instance, a script I have which needs Protobuf and does not work with modern versions of Protobuf. If this were an important part of a system, it would make sense for me to rewrite the logic to use modern behavior, which shouldn't be too hard (I didn't write the initial version), but since I run it manually and on offline data once every six months, I just keep around an old copy of Protobuf in there.