jeroenhd

> All I'm saying is it's all digital on the PC side of things, and has been for ages, but we have means of maintaining access to the games we love over here, and it's one of the reasons I've gravitated to the PC for quite a while now.

It all depends on where you buy your games of course; GOG will let you download DRM-free installers, but if Steam goes down, your libraries goes down with it. They have made a vague promise that they would prevent that if the company ever went out of business, but who knows if they will keep that promise.

Guarantees about playability went out the window the day free, easily-obtained updates came out on PC as much as consoles.

At least on the PC side, there's a vibrant piracy community.

> AND people don't use a random site on the internet for such filth

Actually, they do. Small, independent image hosts are great because they don't do any sort of VPN busting or user tracking, so hitting them with a few quick images to share is just as reliable, maybe even more reliable, than dedicated image hosting options.

You should double check your local legislation, and the legislation of the country you're hosting in. There's a chance you're liable for illegal imagery, regardless of whether you put it there or not. Plus, the moment someone puts something malicious on there and the indexers find out, your domain will be reported as dangerous/phishing and become inaccessible to 99% of the internet.

It bodes well for Europeans when the Americans begin their invasion of Denmark, at the very least. Not great for a potential Russia-USA war and Taiwan wouldn't get as much support if the Chinese invade would also be difficult, though.

The title says "virtually all" but the first paragraph says "much". The actual stockpile is probably larger than this news report would make it seem. It would be convenient for Trump and his Russia-loving cronies if it would appear that the USA has no more weapons to support Ukraine with, of course.

Many advanced NATO weapons being difficult to produce and only being available in small quantities is something that has been discussed before, I don't think that's news. The rate at which they're being spammed without much result at Iran is, but that's hardly surprising given the current people in charge.

There are valid edge cases where you want traffic to be encrypted on the internet, but be readable by some intercepting device under your control. Parental control software has done that for decades, and there are (in my opinion misguided) regulations in some sensitive industries that suggest having to store a decrypted traffic log.

Corporate MitM boxes are quite prevalent (they caused 5-10% of TLS 1.3 traffic to get dropped before they changed the protocol to fake TLS 1.2 session resumption) and when it comes to corporate-owned devices, that usually shouldn't pose too much of a privacy/security issue.

These setups were a lot easier back in the day when TLS let you set static keys, but you can still dump TLS key files and/or reject all non-proxied traffic with your MitM proxy if you want to do such a setup. It'll break loads of apps thanks to certificate pinning, but that's probably a good thing for such corporate networks.

I too would much prefer it if Google were to open-source their messaging app and provide a full RCS API to Android users, but that doesn't change the fact that both the protocol and the underlying OS are open, and others can implement them. Google isn't the Linux Foundation, you shouldn't rely on them to release everything open source and ready to use.

The AOSP messaging app is barebones to say the least, and has been abandoned since the day Google announced Google Messages and its predecessors. Back when that app was still relevant, RCS practically didn't exist.

RCS is not as simple as SMS. You need access to the SIP/RTSP/RTP layer to do video calling, for instance. RCS registration is tied directly to IMS registration, it was never designed to have multiple apps use the protocol at the same time; it does support multi-device setups, as long as all partipants run compatible software. Break that, and you break basic message reception.

Skipping features that go beyond basic messaging entirely, you could probably have some limited RCS support if Google were to take care of all of the internals. You would still need someone to do regular maintenance, like updating protocols to support things like gRPC transports (which landed this month), taking care of the end-to-end encryption, and whatever else comes up in the future. End-to-end encryption in RCS has been in the spec for maybe a year and a half, Android 14 and lower would not be able to use it at all, and Android 15 would miss out on Apple-compatibility as well. Not sure how you would deal with the payment exchange API in such a system, that would need some carrier/bank-run verification scheme.

AOSP's RCS implementation (https://source.android.com/docs/core/connect/ims-single-regi...) was never used by Android's messenger, it only provides very basic functionality: it exists because it has to for basic IMS operations to work, but Google never really bothered with RCS until very recently, long after they stopped maintaining their SMS app.

One could ask the same of other messengers: why can I not access Signal's message database? Why can I not enumerate emails, or query for browsers' search histories? All are built on open technologies, after all.

You can't build a modern messenger equivalent on IRC. You need a new protocol.

"New" is relative of course, XMPP is 27 years old. Still, XMPP lacks official support for something as basic as "I want to log in on a new device and see the old, encrypted messages that are on my other devices".

IRC itself is a reinvention of `talk` and BBSware. For as long as there will be new use cases, there will be new protocols.

Android has an accessible hardware attestation API already (https://developer.android.com/privacy-and-security/security-...). It's what powers the attestation API that GrapheneOS made as an alternative to Play Integrity and friends (demo app: https://github.com/GrapheneOS/Auditor)

It's up to third party app developers to choose what library to use, of course. A court case between the EU and Google isn't going to chance anything about the verification steps apps like Netflix or your bank might use, that will have to be a separate case.

RCS is partially open. The protocol is public, as are one or two authentication features. The biggest restriction for custom RCS implementations is that carriers often require access to SIM card functionality to authenticate a phone to their IMS. Only system software (your OS vendor, Google, maybe additional libraries like Facebook in some products) can access those. Unlike SMS, there is no simple "send this string to the modem and you've sent a message" communication method. The entire thing is SIP+RTP+a few other protocols, wrapped up in a brandable package. RCS is as open as SMS has been for a while, perhaps even more open as the SMS stack can only be reliably implemented in IP-only software stacks in LTE+ networks; 3G and below require integrations not even the Android system supports natively.

If you run a custom ROM, you can sign your own RCS app and have no such restrictions, of course. The same is true for devices with root access. There's nothing preventing anyone from writing a fully featured RCS client or library for custom ROMs, except maybe carriers filtering out unofficial ROMs, but those are a SIM card swap away. Nobody seems to have started working on an RCS app for those platforms yet. There are a few open source libraries out there, but they don't see much activity, and none of them implement the full RCS suite (which includes video calling and even exchanging money).

When people complain about RCS being closed off, most of them don't care about the RCS protocol. They want Google's libraries to handle all the hard work for them and provide an API to interact with without having to implement the carrier protocol side. RCS is already open, but they want Google Messages to be open, not RCS.

However, the EU's laws regarding gatekeepers require that a significant amount of people actually use the supposedly gatekept platform. Very few people within the EU use RCS. I don't think RCS is even close to being relevant for the EU's gatekeeper regulations. The only people talking about RCS on the European market are companies trying to peddle their RCS marketing spam delivery mechanism to other companies.

If the USA would adopt similar laws, the situation would probably be different. Don't expect the EU to care about gatekeepers in a market consumers aren't interested in.

The thing is: Google is one of the few Android phone vendors that makes doing so possible at all. Samsung, Nokia, Xiaomi, Oppo, and all the others lock their bootloaders and provide no way to relock them with your own key once you've managed to break them. Google is one of the few (if not only) vendor that actually designs their hardware to permit this. That's how GrapheneOS has blossomed.

When it comes to running patched operating systems, Google's phones are pretty much the only ones that provide a decent option for running secure and user-controlled firmware. It's every other vendor, from Apple to Xiaomi, that's preventing people from doing so.

That said, there are a few companies out there that will happily put your brand and your firmware on their hardware. That's how the Trump Phone was made, the biggest example of this practice in the west. Other utility brands have been releasing cheap crap branded phones for years (like the Gigaset smartphone). You'll need money upfront and a decent minimum order quantity, but getting phones with firmware you control straight from the factory is still an option.

Obviously the Google Play features being available only to Google are a problem, and it's good that the EU is forcing Google to cut the crap, but Google's restrictions aren't the reason companies aren't running custom ROMs. It's pretty much everyone but Google that's at fault for that, from vendors restricting user freedom to app developers restricting their apps to Google Play certified devices only.

Ironically, Google's own Pixel line is the only reliable source of phones I know of that's both unlockable and relockable with your own keys. The latter is an important feature that even the "hacker friendly" brands like early OnePlus skipped out on.

Hopefully the hardware vendor GrapheneOS is working with can add a second product line to the list.

My bank had NFC payments for years. None of the remote attestation bullshit. I think it used Google's library for doing QR code scans so it wouldn't work without Google Play, but that's beside the point.

Android already supports this, and has supported this for over a decade. The restriction here is on the side of the finance ecosystem. Everyone has congregated on doing Apple/Google Pay because it's cheap and easy to maintain compared to the alternative. Cards companies and banks make deals with Google, just like they do with companies like Apple, Samsung, and Garmin.

Any fintech startup with serious backing can create an Android app that works on any ROM you can imagine. I don't think you'd have an easy time finding investors for this with how much money you need to partake in the ecosystem, but the API is ready for you to implement.

He stopped going to security briefings before, maybe he simply doesn't care to know.

I find the bridge setup rather suboptimal, but with a complete lack of a good Pidgin alternative for the modern age, it's the best system around, whether you do it with Matrix or with XMPP.

People still use IRC. You can't run your own server and talk to people on other servers without a load of work, you cannot do any kind of encryption, file transfers (images?) are a privacy nightmare if they work at all, web clients need a proxy. Authentication doesn't really exist. Messages disappear if you disconnect and reconnect unless you set up an additional server that will make it seem like you're always connected.

The protocol was written for a different age. If you're going with old-and-proven tech, XMPP is a much better jumping-off point than IRC. Everything that made it simple and easy to use back in the day, makes it hard to use in a modern setting.

Element X does video calls fine. It's been ages since it was the messy beta you describe it as. In fact, it does calls better these days. There's no good reason to go with Element Classic anymore, I don't understand why they don't just drop the old thing.

All the other things are just as true if you replace "Matrix" and "Element" with "email" and "outlook"/"gmail".

If you don't think the person you're talking to understands the difference between apps and emails ("I can email outlook people from my gmail?" is a serious question these days), just don't mention it. They're not going to get into the weeds anyway.

When I tried to explain the different "servers" in Discord to some a-technical people I had the same problem and disabling invites + not bothering with explaining the server concept seems to work out a lot better. I've given up trying to explain computer things to people who don't want to understand how the things they rely on work.

There is no technical reason why migrating between homeserver software doesn't work, there just is no tooling for it. Someone could build a Dendrite-to-Matrix exporter+importer. The protocol itself doesn't really care about what server software you're using.

I don't know any good messenger that doesn't tie their accounts to something portable. Plus, I think the ability to reset your password/passkey/whatever if you forgot it is way more important than having users manage their own identity roots for any serious messenger. The alternative is very cool, technology wise, but not really something I would care to use and maintain.

For users migrating accounts, there was a tool (not sure why it died) on the Matrix website that would log in to both accounts, go through each room and where possible invite the new account, and leave with the old account. As long as you have invite/join permissions, that's all you need to do for most chat rooms. 1-on-1 chats need some extra commands to set the metadata right so clients recognise them for what they are, but even they can be ported over, mostly. It's not a perfect solution, but it's lots better than nuking your entire account and starting over from scratch.

We've had MMX for a while now, I don't think we need to wait much longer.

I don't really see why you would need specific hardware to express a type in a programming language, though.

It would make for a good alternative, but so would any app that doesn't implement scanning. If they can force Signal to implement client-side scanning or ban it entirely, they can do the same to PGP software. In theory you could do RSA by hand, but it would require a lot of hard work.

Honestly, I wouldn't be opposed to that either. If we're protecting kids, we should also protect the old and feeble. Old people, people with developmental handicaps, you name it: they're being exposed to a world that can and will abuse you if you have any faith in humanity left and don't have the technical skills to identify things like fake domains and scam sites.

For some reason we're making sure no 12 year old can drive or run for any government positions, but a 90 year old can keep the driver's license that they've had since before the start of colour television, or make critical decisions affecting millions. We can't have it both ways.

Parental controls have been part of mobile devices for years, but so have bypasses. For instance, you can bypass Google's parental control settings by opening the help page in the Google settings and clicking links until you get to the Google homepage.

I doubt it matters because nobody seems to configure the parental controls that are there, anyway. Only schools seem to try, and only because they're legally held responsible for what kids do on their computers.

The authorities open letters all the time. Try sending a letter to prison without it getting scanned.

The problem with this comparison is that the authorities can open a letter if they need to for various well-intended reasons, but they cannot open an encrypted message. Either the authorities can scan all messages, or they can scan no messages, there's no inbetween.

The mandate to verify age before selling alcohol has been around forever. This is not a new idea. The biggest restriction until now has been that there was no good way to do these kinds of age verification, but that problem has been solved. You can still debate whether or not age verification is a good idea for specific subjects, but selling 10 year olds alcohol or porn has been illegal for much longer than the internet has existed.

Laws have been written that mandate that applications and services treat various age ranges differently. You can't serve porn to kids, kids under 15/16 have very strict privacy regulations in some areas, and certain content age ratings are an industry standard only because that was the industry way of getting out of being regulated.

For kids this is a privacy risk because there are so many thresholds. Once you're above 18, all you need to care about is "are you a pensioner".

Kids have been lying about their age since the dawn of the internet and people have started catching on, so now we're getting actual restrictions rather than the assertion that nobody in their right mind would click "I am 18 or older" to access a website.

Californian law mandates that operating systems keep track of their users' age, so of course Android must follow. In all of the cases listed on Google's blog, though, the option to not share information and download an app that doesn't ask for your age range is still an option.

They're Americans trying to appeal to other Americans. Of course everything they do is justified and everything everyone else does is an evil scheme to plot the ruin of American freedoms. How else are you going to convince the dementia patients in charge of the country?

If China, India, the EU, and everyone else has any sense, they should take this letter to heart as much as Anthropic wants the American government to.

Dutch iDeal|Wero uses incompatible QR codes and a bank selection flow compared to international Wero. The real Wero implementation comes next year.

They're trying to ease in Dutch customers to the Wero brand, but in the mean time they're confusing every tourist or immigrant with their wero-but-not-wero system.

I like the Taiwanese approach. Every receipt is a lottery ticket, so people have good reason to demand registered receipts.

The Wero system isn't just a rebrand of iDeal. It also includes a wallet app and the ability to transfer money between regular people, not just online checkout.

From the article:

> Decathlon switched on Wero on decathlon.de on July 20, making Germany the first market in the French group’s international footprint to carry the European payment scheme.

That's probably the cause for confusion, because the Dutch system has been rebranding itself to Wero for ages and switched over permanently very recently.

Decathlon.nl has had Wero for months, though they did it through a different implementation method. Of course, the marketeers prefer to put the focus onto the next-gen system their German counterparts have just implemented.

You can use it. Just use any other browser. Chrome is free, Brave is free, Vivaldi is free.

We can't even agree on wasting less fuel or moving to less damaging fuel sources.

One of my issues had to do with pure bandwidth, dozens of bots were requesting the same image over and over again adding random crap to the query. My server was being slow for me during crawling peaks.

> An actual proper static site would likely 10x that.

A lot of the stuff I host isn't static. Any non-static content also gets overloaded pretty quickly. Hosting something like a Git server can turn pretty resource intensive if shitty bots start diffing every commit with every other commit.

I'm generally lazy when it comes to blocking IPs, but when I do run into an issue, I just blanket block IP ranges. When that doesn't work, ASNs get blocked. So far I haven't had to take most measures mentioned here but I probably will once the broken bots start coming from botnets using residential IP addresses.