hjkgfdfgh

Yes, the described interaction with TM went down prior to contacting Amex, and was relayed to Amex. The form originally submitted for the online dispute detailed that, but the dispute was still instantly denied.

There is very clearly a relationship between Amex and TM where TM is receiving preferential treatment, as TM transactions no longer even show a dispute option online.

Good luck with the chargeback. I tried to open one with Amex online and it was insta-denied with a note to the effect that I needed to work it out with Ticketmaster myself. I'm hoping Amex phone support is willing to work with me, whenever I make it through.

Ticketmaster's phone support tells you to open a live chat, then hangs up on you. When you open a live chat you get a canned response that the show is postponed and to go away until it's either canceled or rescheduled... then auto ends chat.

If nothing else, I can at least enjoy the minor irony that is getting fucked by the machine over a few Rage Against the Machine tickets.

To pile on against X11 over ssh, forwarding on a modern Linux workstation is spectacularly painful. I recently needed to forward a lightweight gtk app from one workstation to another over 10gbe and a single switch hop.

With ssh and X forwarding, my local gnome constantly threw up modal dialogs that the forwarded window was unresponsive, forcing me to keep clicking "Wait" to dismiss the modal, then quickly interact with the forwarded window before the next "unresponsive" modal popped up.

If Signal were federated, there would be no single entity to shut down. Alas...

No. They just purchase votes.

Where are you trying to go with this?

You start off trying to claim the entire class of vulnerability isn't possible because a few vendors made sane architectural decisions. When it's pointed out those sane vendors are in the minority, and there are real world examples of the terrible shared memory architecture being exploited, you scoff at the example being for a single device.

Nobody is claiming baseband == root, only that the terrible architecture prevalent in Android phones (the devices that make up the majority of the market) combined with the terrible software practices of SoC vendors results in a situation far more likely to be exploitable than shunting the baseband off on a non-dma capable bus.

Passengers are (for the most part) considered equal for W&B calculations. It's about "Is this seat occupied?"

Seems clear they are interested in the NeXTSTEP aesthetic in addition to the underlying framework.

I wish something like this existed that could additionally proxy FCM notifications. Allowing push notifications without any Google involvement is the ideal long term goal, but one transitional path I dream about would be forcing Google to proxy all their notifications through a host of your choice (ideally that you control).

I think I have about 30 false start projects with names like PushMux and rough outlines on potential ways to accomplish it.

Tangentially, I also dream of having true one-way push notifications. Send a minimal notification to the target device via FLEX/POCSAG or even one-way Iridium, and allow the device to connect to the internet as needed to fetch the rest of the notification.

That may be true of Apple, and is true of the PinePhone and Librem, but for the majority of Android devices, that's blatantly false.

On Qualcomm chipsets in particular heavily utilize shared memory for baseband to application processor communication.