He just wants to be wanted by somebody. He was wanted for stealing a vehicle, so logically he stole another one so they would want him even more.

Tsk, everyone knows you shouldn’t use magnets to hold floppy disks. Just staple them into your lever arch file.

Not morons, just not educated enough about them to understand exactly what the implications of that action are.

Don’t go cold turkey, but if you reduce your intake slowly you can probably wean yourself off of it.

(Please don’t do this)

I agree that them having users’ phone numbers isn’t ideal. There are other identifiers they could use that would work just as well. However, both the client and server are open source, so you can build, at least the client, yourself. If you can content yourself that it does not leak your ID when sending messages, then you don’t need to trust the server as it does not have the information to build a graph of your contacts. Sealed sender seems to have been announced in 2018, so it’s had time to be tested.

Don’t get me wrong, the fact they require a phone number at all is a huge concern, and the reason I don’t really use it much, but the concern you initially stated was addressed years ago and you can build the client yourself to validate that.

You’re correct that if you use the system the way it used to work they can trivially build that connection, but (and I know this is a big assumption) if it does now work the way they say it does, they do not have the information to do that any more as the client doesn’t actually authenticate to the server to send a message. Yes, with some network tracing they could probably still work out that you’re the same client that did login to read messages, and that’s a certainly a concern. I would prefer to see a messaging app that uses cryptographic keys as the only identifiers, and uses different keys for different contact pairs, but given their general architecture it seems they’ve tried to deal with the issue.

Assuming that you want to use a publicly accessible messaging app, do you have any ideas about how it should be architected? The biggest issue I see is that the client runs on your phone, and unless you’ve compiled it yourself, you can’t know what it’s actually doing.

Strictly you’re having to trust the build of the client rather than the people running the server. If the client doesn’t send/leak the information to the server, the people running the server can’t do anything with it. It’s definitely still a concern, and, if I’m going to use a hosted messaging app, I’d much rather see the client built and published by a different group, and ideally compile it myself. Apart from that I’m not sure there’s any way to satisfy your concerns without building and running the server and client yourself.

‘Sealed sender’ seems to avoid this by not actually requiring the client to authenticate to the server at all, and relying on the recipient to validate that it’s signed by the sender they expect from the encrypted data in the envelope. As I mentioned in another reply, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address this issue.

Whilst I absolutely agree it’s correct to be skeptical about it, the ‘sealed sender’ process means they don’t actually know which account sent the message, just which account it should be delivered to. Your client doesn’t even authenticate to send the message.

Now, I’m just going on what they’ve published on the system, so either I could be completely wrong, or they could be being misleading, but it does look like they’ve tried to address the very issue you’ve been pointing out. Obviously it’d be better if they didn’t have your phone number at all, but this does seem to decouple it in a way that means they can’t build a connection graph.

With ‘sealed sender’ your phone number, or any other identifying information, is not included in the metadata on the envelope, only the recipient’s id is visible, and it’s up to the recipient’s client to validate the sender information that is inside the encrypted envelope. It looks like a step in the right direction, though I don’t use signal enough to have looked into auditing it myself.

Use cheap, low density wax and it’ll slowly melt under the studio lights over to course of the program, which would be hilarious.

How’s he doing? Well, he’s been up and down.

Look, I’m not attacking them over this, as you rightly said, it has plenty of other drawbacks and concerns, I’m just emphasising that Google do have a large degree of influence over them. For instance, Chromium is dropping manifest v2 support, so Brave pretty much has to do the same. They’ve said that, as Chromium has a switch to keep it enabled until June (iirc) they’ve enabled that, but after Chromium drops manifest v2 the most they can do is try to support a subset of it as best they can. The Brave devs may not want to drop support, but Google have decreed it will be dropped, so they end up dropping it and having to put in extra work to keep even a subset working for some period of time.

If Brave gets even a moderate market share, Google will continue to mess them around like this as they really don’t like people not seeing their adverts.

Ultimately it’s software, so the Brave devs can do pretty much whatever they want, limited by the available time and money. Google’s influence extends to making that either easier or harder, it much the same way as they influence the Android ecosystem.

Both Brave and Chrome are built on the open-source Chromium browser engine

That’s from the Brave website: https://brave.com/compare/chrome-vs-brave/

Yes there are plenty of changes, but it’s built on it, and shaped by it, and Chromium is heavily influenced by Google. If chromium doesn’t support v2 manifests it is unlikely that Brave will. In this particular case it may be that Brave’s ad blocking and privacy features are equivalent to uBO, but it’s still underpinned by an engine that Google has strong influence over, so it can’t completely shake their influence.

Dude, what are you actually trying to make right now? Like, this isn’t flight sim stuff anymore.

It’ll only be done when you can get out of your plane, walk around, find a computer and start playing Flight Simulator 2024.

So, you’re repeatedly performing the same task at the command of a computer. Are you certain you are a cephalopod, airborne or otherwise, and not, in fact, a robot? ;)

They may well be looking at how much the EU holds in Saudi assets, seeing those at potential risk of being seized and deciding tge write-down on dumping the bonds would be worth it. Long term, I don’t think it would have an effect on prices, but short term it may well do, depending on how concentrated their holdings are.

From what I can see, normal trading volume in bonds is about 500% per year, or about 2% per day assuming 250 trading days per year. If the 130bn you mention is spread across all government bonds across the EU then it accounts for about 4% of the total, or about two days of normal trade. Dump all of that in one go and it’d definitely have a short term effect. If their holdings are more concentrated they could have an even bigger effect on the bonds they hold.

Bonds tend to be issued on a regular basis, so even a short term drop in price could be timed to affect an auction. That has the twin effect of reducing the amount the government in question raises, and also tying them into effectively higher interest rates, potentially for decades to come.

I’m no expert trader either, so I could be barking up the wrong tree, but I assume that they would have a clear expectation of the results before making that threat, and I can’t really see any other effects it could be expected to have.

Absolutely. If they’re killed during their crime they should be completely anonymous. No names, no ‘manifestos’, no reference to the sorts of communities they were part of online, no last words, just, ‘they were a vile stain on humanity’ and then forgotten. Obviously, if they live more will come out as they’re prosecuted, but that should be minimized and once they’re jailed they can be forgotten by all but those tasked with keeping them alive to serve their sentence.

The price moves with supply and demand on the secondary market. Normally, yes, that’ll tend to vary to balance yield with the prevailing interest rates, however, the threat seems to be to dump bonds onto the secondary market, presumably without a minimum price. The glut would mean buyers could purchase them below that balance price, giving them a better yield. This would have (at least) two knock on effects, firstly it would make it harder for governments yo raise funds through bond issues as they’d effectively be competing with the cheaper ‘dumped’ bonds and so would need to offer an equivalently high yield, and secondly may allow ‘undesirable’ governments or groups to amass significant amounts of European debt, which potentially gives them more political leverage than European governments might like.

There’s a fair chance he knew that and wanted to die while killing as many as possible.

As you said, good riddance.