I fully migrated over to linux 20 years ago. I ran chrome until recently. I added pi-hole + a caching proxy to speed up my garbage internet speeds at the time. I was on a very bad ADSL service.

Now that I'm on fiber and have upgraded to a recent AMD based machine I find Brave really fast. Accidentally I launch chrome on occasion. I find chrome more sluggish with noticable hickups when loading. I have to assume this is ads or some marketing garbage that slips past pi-hole.

What's got me stuck mostly on Brave is the ad blocking. The tracking garbage that is now injected into chrome ( has been for years ) is getting so much worse.

And the sites that don't like simply aren't used anymore. I've actually blocked several news sites in pi-hole simply because of all the garbage they try to send into the browser. Not to mention news sites that host effectively mallware in it's add slots.

I had a few friends get completely hosed by the infamous app update.

I was always suspicious of the platform. Since it just didn't bother with any sort of interop.

When they sorta bricked all installs in one move I did laugh. That was the ultimate in bad releases. Clearly no one bothered to even review the Test Plan let alone the results.

I will never sign up to anything that smells of vendor lock in. Oracle, Salesforce, Microsoft, Are the kings of this.

I find a ton of issues with locking down/securing platforms at the Enterprise level.

1. Surface area, There is just way to much tech debt out there. Business rarely go back and pay this down. The costs are enormous. All of this tech debt needs to be secured at an ever increasing cost.
2. Almost non-existent secrets management. I will forever find important secrets embedded in config / git / orchestration etc.
3. Logs rarely secured and properly setup so that sensitive info doesn't leak out. Developers forever turning on debug and not telling anyone.
4. Low levels of network segmentation. This allows attackers to laterally move about the network with almost no controls to stop them.
5. Supply chain attacks increasing everyday. With little put in place to monitor and threat analysis of these external dependency.
6. AI coming in and eroding the checks and balances of reviewing changes. With AI I'm also seeing a loss of pre-prod environments. I'm even seeing straight to prod be the pattern of the day.
7. Exec teams having zero clue what AI is actually doing. I see a lot of people thinking AI systems are bullet proof.

Overall a loss of IP is the most concerning at the moment.

What a lot of people forget is that AI is creating a larger surface area. It's unlikely that all of the work put into legacy software is being replicated in AI software builds. This means that there are likely more opportunities in financial software for "hacking".

Of course as this article points out. With AI it is far easier and quicker to "hack" So it's bad on both ends.

Retirement funds which hold enormous amounts of funds are likely early targets.

Secure your accounts with 2FA as quickly as possible.

You can bet the UK is making sure that they can't get on the public net now. I'm fairly sure whether the pings got through or not would be a state secret.

Now there are a lot of ways to implement a ping of sorts.
- Advanced ones use an API to send back some telemetry. This could literally be anything in the payload. This is by far the most dangerous.
    - A subset would be some sort of REST API on a web service. This has a lot of advantages as you can do geo location tricks to place listeners all over the planet. This is basic http infra type stuff. So China could have receivers outside of the great wall.
- And actual dedicated service with a proprietary interface. Highly unlikely as this poses no advantage over the first and would be handcuffed with missing features that http protocols/implementations offer.
- Using some sort of exfil technique. Such as a structure DNS request to a specific DNS server. ( This is a common exfil technique of nation states. ) This can often work. I would hope however that a DoD environment blocks this. There are a lot of other ways to exfil data through normal basic services. But the article did not mention anything that would imply obfuscated exfil for a ping.
- A simple TCP open socket request. A fairly primitive. This is old school not really used by IoT devices much.
- ICMP ping. An actual ping. But this would likely not be the case as it is a component that was calling home so the odds are that the mac address would not match the component in the end. And ICMP is generally locked down these days.

So I lean to a rest API call. Pure guess but it's by far the easiest to implement. and like you said I would hope this is blocked by the UK DoD. That said drones are evolving very rapidly. So it's highly unlikely they are as security tested as the DoD would like before hitting operational status.

As usual these little "announcements" have a lot more that isn't said than said. The threat board is growing in length for a lot of orgs with this sort of announcement.

It actually does.

It does a few things. ( If the heart beats actually make it back to China. ) They would likely make it back since the devices would likely have redundant connection mechanisms. A lot of drones use starlink now and this is effectively public. The US has an early starshield capability. Not sure if this is shared with friendlies yet.
1. The device is alive. Meaning turned on and active. Meaning it is in use for an operation or training.
2. It's ping or latency time can be used to build a heat map of likely world wide locations. This used to be tricky not so much any more.
3. It's giving away at least part of the network path to the device.

So basically it can tells China with this data what the theatre of operations likely is. Which destroys the element of surprise. If a bunch of English drones all of a sudden start showing up around Taiwan for example it's tells China a lot. This could and would compromise operational security and potentially lives. It would also raise tension levels between nations.

If enough drones are doing the same thing then the data quality will improve.

And at no time does the drone have to be hacked. No attempt to communicate with the drone needed. The simple fact that a phone home command is sent is enough to compromise safety.

So it does matter.

I don't use Mac. I've always had issues with the pay to be cool thing.

In this day and age there is now touch? OK this little factoid caught me by complete surprise.

I'm Linux/Unix dude with the occasional Windows use. So I'm completely out of touch with MacOS.

Again I'm completely shocked this isn't in the OS yet.

Yes rare earths are actually far from rare.

Whats actually rare is the willingness to process the ores with highly toxic processes. Canada and Australia are sitting on gigantic reserves of rare earths in general. However they have a strong unwillingeness to face the consequences of processing the ores.

So its welcome to see less poluting processes.

I feel that tokens consumed by residents of a nation should be taxed by that nation in the form of tokens.

Those tokens are than used to improve the quality of life of it's citizens. Ideally not used for Offence or Defence purposes but rather put to addressing social issues in society.

Drone just means autonomous. Drones we use today all we are doing is giving them commands. Flying drones for example automatically compensate for level, drift, speed so that their behaviour matches the operators inputs.

It would be near impossible for a single person to control each of 4 rotors on a common drone. Onboard electronics take care of that for us.

This is the "autonomous" part.

On the moon it would be a rocket propelled or wheel based device that would to give commands. From as simple as travel this fast this direction to go fly here and pick up that rock and bring it back.

It's accepted that Lithium is not rare.

There are however 3 big issues.
1. Cost and Toxic waste associated with extraction. ( This article shows progress in this regard. )
2. Stability, Lithium batteries have an issue with nasty fires.
3. Density of viable lithium related ores. EG in the west most lithium ore is from 2 areas. Canada and Australia. Both locations are actually rather remote in each country.

Lithium is not a good battery base. Why? It's not stable. Energy density is pretty good. But as we know when you push the limits you can get issues. Samsung did this with a series of phone batteries. They ended up with a lot of fires and a very expensive recall. So something that is energy dense but has a significant risk the health and life. It no longer is a good option for batteries.

For reasons like this lithium will ultimately be deposed as the king of batteries.

That said this process is welcome. As it has a dramatic reduction in toxic residuals from processing. So this is a major plus.

If this was discovered even 2 years ago my personal belief is the investment in the process would be huge.

However,

With recent industrial progress on Sodium batteries investors are going to have to weigh the pros and cons. With many big investors actually holding money back from both until they see real results from both systems.

I want to invest but I'm definitely holding back myself.

Have a look at the recent developments around Sodium batteries.

If the momentum holds for sodium they will replace lithium in a very short period of time. BYD in China is already using them in cars.

They have many significant advantages over lithium. One of them being the ignition problem.

The biggest issue is trusting the collector of this personal information with the information.

Most do not trust big tech. How will this information be used to exploit me in the future.
Few trust the government with my personal information and app / internet usage.

The general thought that drove the bill is that if the os holds the personal information the informatikn can then be seperated from big tech/gov from the appli ation owners. This should i theory protect the leakage of personal information.

This falls apart quickly however. As big tech owns the os in most cases. There are no standards or compliance requirements that govern what can be collected and how it is managed. So over reach in data collection is likely and expected.

In addition not all users are interactive.

Lastly any data collection method will certainly be defeated in moments.

More effort needs to be put into standards around identity and identity attribute management. So that laws can be based on accepted standards rather than vague wishful thinking ideas.

ISP Routers are typically locked such that the end user update the firware. And if they could the process is often extremely difficult for even technically minded people.

In some cases the ISP installs very specific software to do other things.

Example: In Australia Telstra issues routers that create and entire second network on the router. Which allows them to setup roaming wifi connections that the ISP subscriber can use. So a subscriber can walk around town and never lose their wifi. As the simply are hoping between routers stashed in homes/business/public access points.

Other companies put software on the routers to implement tracking networks that constantly scan for wifi and bluetooth broadcast identifiers etc. Then they send this data to the mother ship to create air tag like functionality.

So the problem is now bigger. Not only can't you just simple as a user update to OpenWRT, The ISP is often now stuck with the problem of migrating functionality to a complete new device / OS with little time to implement it.

Note ISP's do not retain the Intelectual property any more for these addon services. They claim they do but generally these things are implemented by contractors or vendors and the knowledge of how to actually put it all together is generally lost. So this makes it even harder to migrate to a "US" made router.

And on top of that internent subscribers do not upgrade their routers often. They are used untill they break or are bricked or the subscriber changes provider. This time line is usually well over 5 year time frames.

So moving to OpenWRT is very unlikely on mass. ( I actually run OpenWRT on multiple devices and I'll likely never go back to a vendor supply router software stack again. )