Not offering solutions here, because I think it's more multi-faceted than I know about. But when people are afraid to take on the debt of on-board EMS for a 911 call, and local pharmacies are forced out to be bought up by the top national pharmaceutical companies letting them rent-seek, I do think "for profit" is part of this multi-faceted problem.
I'm thinking more of a future where big tech successfully moves the overton window for AI, people gradually rely on getting information/entertainment from LLM's more than books, then it can follow the regular plotline of 451 with the public voting to ban books.
TFA is a bit obtuse about it, and assumes you've read their previous article on the topic, but from what I gathered, it's about whether the AAMVA would standardize cryptographically signing the barcodes of driver licenses to mitigate creating fakes in the US/CA. Cali showed it's entirely possible, but there's still no pressure for the standard to change across the board.
I was flagged by Facebook to provide a government ID years ago, presumably because I tend to use a VPN and never really provided any personal information. I imagine it doesn't take much on any of the other social media platforms to look too much like an anomaly before it warrants a suspension. The platform has nothing to lose since "personalization" and ad revenue won't be lost; in fact, you wouldn't want your personalization algorithm to be trained on such users.
It will always be a cat-and-mouse game. I don't think it's possible to have any sort of visual that an algorithm can't be trained to recognize.
sidenote: did Adversarial Fashion stop selling the ALPR shirts/hoodies? That was my favorite thing to wear years back. And they're probably still effective at inserting noise.
Just because RCS can't be done without metadata doesn't mean it's a fruitless endeavor. Why not have someone use RCS to then get on Signal? That is so much better than plaintext SMS to Signal.
And for most people, RCS between Android <-> iOS is the biggest advancement in encrypted communication for the layman that I've seen since Let's Encrypt.
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.
Google Messages is essentially the only remaining RCS client for Android and it's the only one with end-to-end encryption. It already works on GrapheneOS via a toggle for ICC authentication extending our sandboxed Google Play compatibility layer. We want to add support for it to our own Messaging app but that's not straightforward since it's not at all an open platform even to the extent of SMS/MMS.
I appreciate the update. I wish RCS was more open. I'm still astonished that it wasn't until 2024 that iOS adopted the protocol. Relying on everyone in your group chat to be all Android or all iOS (iMessage) wasn't helping anyone.
That is a positive progression for sure. I guess it sounds like RCS is gatekept behind a play store API on the android side so there isn't an open source solution quite yet? Mostly I'm lamenting that even with signal there's meta-data you can infer behavior from. I know Session messenger has a bit of a network shuffle (is it garlic routing?) That blurs metadata collection a bit, but then they watered down several of Signals' security/privacy choices. I'm constantly curious and overwhelmed at the choice of text communication platforms, just so many!
Thanks! I noticed on one of my phones that RCS breaks once the Messages app is out of date by a certain amount of revisions. I hope this is an arbitrary decision by Google to invalidate older versions, given that the RCS protocol hasn't changed. I wouldn't want the Graphene team to have to keep up with each change Google makes with their Messages app, and instead is a security oversight Google has found in their own app.
We definitely will have to keep up with the changes. We already do in order to provide support for using RCS via Google Messages on GrapheneOS. Recently, they made a change which broke it on GrapheneOS and we had to quickly fix that in under a day.
To look for a certain waveform, wouldn't you need to obtain all of the mic data at all times? I think that's what's implied by "listening" here, but semantics are rarely an interesting discussion.
Yeah, I can see maaaany layers to have to differentiate between when discussing. E.g., for just a few random examples:
- The microphone always vibrates from the sound waves
- The microphone is powered in a way that the sound waves change electrical readings in some way
- The electrical readings are sent to another component reading them
- A component receiving the data does some kind of unbuffered processing related to triggered actions (e.g. a clapper or a activation wave)
- Some component temporarily uses a buffer of the data but not for permanent storage (e.g. live, unstored transcription for the deaf or a 'nevermind' after a triggered activation)
- Some component stores or sends data generated by the sound, but not necessarily the original audio or even any attributions of who (e.g. voice trigger web search sends the search query as text)
- Some component generates a stored copy of the transcription with attribution of who
- Some component stores the actual audio in a way that can be later replayed
I'd say this "sounds" like a mess to deal with, but then I'd be worried about falling into a category ;).
The lack of single-file components is one of several reasons I wouldn't reach for React prior to the LLM craze[0]. For personal projects, I love Svelte. You wouldn't need tailwind there for the reasons proposed given their support for it.
[0] Things have probably changed, but Svelte 5 was a litmus test for how recent the data cutoff was for an LLM model. Meanwhile React _especially_ has no reason to change how the framework is used by coders. Thus there's years of scraped tutorials and sites for how to throttle a function or what-have-you in React.
Lifetime pass user long before the ridiculous price hikes for it and the direction for the service going down a path I didn't want to support. You can run Plex and Jellyfin on the same server concurrently pointing to the same media files. My Plex server was still running until I was able to transfer everything over and their mobile app ecosystem got up to parity.
reply