If you can "coach someone to ignore standard security warnings", you can coach them to give you the two-factor authentication codes, or any number of other approaches to phishing.
> Installing an app that silently intercepts SMS/MMS data is a persistent technical compromise. Once the app is there, the attacker has ongoing access.
The motivating example as described involves "giving the scammer everything they need to drain the account". Once they've drained the account, they don't need ongoing access.
Persistence allows the scammer free license to attempt password recoveries for every account the victim could possibly have. Other banks, retirement accounts, the victim's email account.
Scammer that thrive are greedy, but not too greedy. Easier to break into one type of account for 10 victims, than to break into 10 different account of one victim. Persistence is risk.
When the victim's relatives send them money because they need to eat and pay rent after handing everything over to the scammer, the persistent backdoor lets that money be drained as well... You're underestimating the persistence and ruthlessness of the scammers.
This is still not a root cause solution, it's just a mitigation. Because you do not require side loading to install malware. The play store and apple app store both contain malware, as well as apps which can be used for nefarious purposes, such as remote desktop.
A root cause solution is proper sandboxing. Google and apple will not do this, because they rely on applications have far too much access to make their money.
One of the fundamentals of security is that applications should use the minimum data and access they need to operate. Apple and Google break this with every piece of software they make. The disease is spreading from the inside out. Putting a shitty lotion on top won't fix this.
> A root cause solution is proper sandboxing. Google and apple will not do this, because they rely on applications have far too much access to make their money.
Oh they do this quite well. Thing is, these sandboxes are meant to protect apps from you, not the other way around. That's why some apps - not just platform vendor apps but also select third-party apps - get special access and elevated privileges, while you can't even see what data they store in `/storage/emulated/0/android/data` even with ADB trickery.
>The play store and apple app store both contain malware
Wow, that a major claim. What apps are malware, exactly?
>This is still not a root cause solution, it's just a mitigation.
Requiring signed apps solves the issue though, as it provides identification of whoever is running the scam and a method for remuneration or prosecution.
> Wow, that a major claim. What apps are malware, exactly?
I don't understand how this is a major claim at all, it should be obvious. All repositories of large enough sizes contain malware because malware doesn't declare itself as malware.
This is exacerbated by the fact the Google Play Store and Apple App Store allow closed-source applications. It's much easier to validate behavior on things like the Debian repos, where maintainers can, and do, audit the source code.
Google does not have a magic "is this malware" algorithm, that doesn't exist. They rely on heuristics and things like asking the authors "hey is this malware". As you can imagine, this isn't very effective. They don't even install and test the apps fully. Not that it matters much, obviously malware can easily change it's behavior to not be detectable from the end-user just running the app.
> Requiring signed apps solves the issue though, as it provides identification of whoever is running the scam and a method for remuneration or prosecution.
It doesn't, for three reasons:
1. Identifying an app doesn't magically make it not malware. I can tell you "hey I made this app" and you still have zero idea if it's malware. This is still a post mitigation. Meaning, if we somehow know an app is malware, we can find out who wrote it. It doesn't do the "is this malware" part of the mitigation, which is the most important part.
2. Bad actors typically have little allegiance to ethics, meaning they typically will not be honest about their identity. There are criminal organizations which operate in meatspace and fake their identities, which is 1000x harder than doing it online. Most malware will not have a legitimate identity tacked to it.
3. Bad actors typically come from countries which don't prosecute them as hard. So, even if you find out if something is malware, and then find out the actual people behind it, you typically can't prosecute them. Even large online services like the Silk Road lasted for a long time, and most likely still do exist, even despite the literal US federal government trying to stop them.
A lot of what you said in the second portion isn't at all true (for instance, Google definitely doesn't just ask the author if what they are uploading is malware as a sole check if an app is malware). But I don't think we can even continue the discussion until you prove the "obvious" assertion that there are apps in the Play Store that are malware. So I am going to ask again: give a single name of an app currently in the Play Store that is malware. We are not talking about Apple, but I will extend it so that you can give an app in the Apple App Store that is malware as well.
Let me know when you can provide a single specific name.
You'll then get more warnings if you want to give the sideloaded app additional permissions. And if they want to make the sideloading warnings more dire, that wouldn't be nearly as unreasonable.
Pins can still be phished. Just make the phishing a live proxy resembling the real site.
A fundamental difference with e.g. FIDO2 (especially hardware-backed) is that the private credentials are keyed to the relying party ID, so it's not possible for a phising site to intercept the challenge-response.
The phisher’s app or login would be from a completely new device though.
Passkeys are also an active area to defeat phishing as long as the device is not compromised. To the extent there is attestation, passkeys also create very critical posts about locking down devices.
Given what I see in scams, I think too much is put on the user as it is. The anti-phishing training and such try to blame somebody downward in the hierarchy instead of fixing the systems. For example, spear-phishing scams of home down payments or business accounts work through banks in the US not tying account numbers to payee identity. The real issue is that the US payment system is utterly backward without confirmation of payee (I.e. giving the human readable actual name of recipient account in the banking app). For wire transfers or ACH Credit in the US, commercial customers are basically expected to play detective to make sure new account numbers are legit.
As I understand it, sideloading apps can overcome that payee legal name display in other countries. So the question for both sideloading and passkeys is if we want banks liable for correctly showing the actual payee for such transfers. To the extent they are liable, they will need to trust the app’s environment and the passkey.
Never ending worm approach is to get remote control via methods on android or apple. Then scam other contacts.
It’s built into FaceTime. Need 3rd party apps for android.
> My biggest problem with rust right now is enormous target/ dirs.
We're working on that and it should get better soonish. We're working on shared caches, as well as pruning of old cached builds of dependencies that are unlikely to be reused in a future build.
I am an upstream developer on the Rust Project (lang, library, cargo, others), and obviously a big fan of Rust. This kind of advocacy doesn't help us, and in fact makes our jobs harder, because for some people this kind of advocacy is their main experience of people they assume are representative of Rust. Please take it down a notch.
I think Rust is the best available language for many kinds of problems. Not yet all, but we're always improving it to try to work for more people. It gets better over time. I'd certainly never call it, or almost any other software, "defect free".
And I'd never call it "the final language"; we're building it to last the test of time, and we hope things like the edition system mean that the successor to Rust is a future version of Rust, but things can always change, and we're not the only source of great ideas.
If you genuinely care about Rust, please adjust your advocacy of Rust to avoid hurting Rust and generating negative perceptions of Rust.
I’d also add: as a lover of forward progress, I really hope rust isn’t the last good idea programming language designers have. I love rust. But there are dozens of things I find a bit frustrating. Unfortunately I don’t think I’m clever & motivated enough to write a whole new language to try to improve it. But I really hope someone else is!
For a taste: I wish we didn’t need lifetime annotations, somehow. I wish rust had first class support for self borrows, possibly via explicit syntax indicating that a variable is borrowed, and thus pinned. Unpin breaks my brain, and I wish there were ways to do pin projections without getting a PhD first. I wish for async streams. I wish async executors were in std, and didn’t take so long to compile. I could go on and on.
I feel like there’s an even simpler & more beautiful language hiding inside rust. I can’t quite see it. But I really hope someone else can bring it into the world some day.
> For a taste: I wish we didn’t need lifetime annotations, somehow. I wish rust had first class support for self borrows, possibly via explicit syntax indicating that a variable is borrowed, and thus pinned. Unpin breaks my brain, and I wish there were ways to do pin projections without getting a PhD first. I wish for async streams. I wish async executors were in std, and didn’t take so long to compile. I could go on and on.
I would like all of that as well. I think we can do much of that in Rust. I would love to see self-borrows available, and not just via pinning; I would also like relative pointers. I would like people to almost never have to think about pin or unpin; one of my rules of thumb is that if you see Pin or Poll, you've delved too deep, and nobody should need those to write almost any async code, including the interiors of trait implementations and async runtime implementations. And I would absolutely like to see async iterators, async executors, and many kinds of async traits in the standard library.
I also think there are plenty of things we are unlikely to get to even in an edition, and that might never happen without a completely different language. I'm not sure if we'll find a path to doing those in Rust, or if they will be the domain of some future language that makes different trade-offs.
> I also think there are plenty of things we are unlikely to get to even in an edition, and that might never happen without a completely different language.
Yes, this is my feeling too. All programming languages - perhaps, all computer programs - must decide how malleable they should be. Fast moving systems are exciting, but they're very annoying to use, or build on top of. I think generally we want a very slow moving language for infrastructure software, like databases or the linux kernel. Slow moving languages are often good for users, because they don't need to learn new things or rewrite existing software. (I think thats one of the reasons python3 was so poorly received.)
It might be too late for large changes in rust. This a sign of maturity, but its also a little bit sad. I want all those features you mention too.
Some day. Maybe LLMs will help somehow. Rust is, thankfully, not the last programming language humans will invent.
I'm sorry my autistic elation for Rust is perceived as being over the top, but I truly do mean everything I say. I could have articulated it in a less saccharine tone.
> > Defect free.
There's a Google talk on the matter. "Defect rate" / "defect free" is a term that is used quite a bit. I've latched onto this, because I find it true. Rust is a far more defect free language on a line by line basis measured and compared to other statically typed languages.
> And I'd never call it "the final language"
I honestly disagree, and I'm sticking to this prediction.
I don't think we're going to be writing code much longer by ourselves. The machines are going to outpace us soon.
Maybe something that's LLM-oriented will take over, but at that point these won't be "human" languages anymore. So I'll revise my claim to "Rust is the last human language".
If I want to serialize my thoughts to code, Rust is the language for it. It's probably the last one I'll be hand-writing or sending my revisions back to the LLM for.
Rust will also be an order of magnitude easier to author, at which point there shouldn't be much holding people back from producing it. If you have a choice between generating Java, C++, Go, or Rust, you're going to pick Rust almost every time unless you have to fit into those other ecosystems.
If you haven't used Claude or Codex with Rust, it's sublime and you should drop what you're doing to try it.
OrbStack has some invasive elements inside it trying to provide filesystem integration, and the filesystem they use is not POSIX compliant and causes breakage with some build systems and other software.
A bit more expensive than the one I linked previously at $1,400, though it's a full color display. It's unfortunately missing a description, so the only evidence that it's a touch screen is in the title itself. Would obviously require some due diligence with the manufacturer.
I'm sure there are other options as well (the breadth of vendors on Alibaba is pretty impressive actually)
A world of no in so many ways. Nothing still running Android 7 should be connected to the Internet, and in any case I don't want a display that has a computer and networking in it (though I realize some people do want that). I'm specifically trying to find an E-ink touchscreen that's just a display, to be attached to a real computer whose software can be updated and customized.
> For example the washing machine. You dont need real time information because you know how long it takes since you've done it 1000s of times and it beeps.
It beeps, on the other end of the house (or on another floor), where it's inaudible. (And, thankfully, where the loud sounds of it operating are also inaudible.)
> All these things are just managed in our heads subconsciously.
And when you remove the need to track that in your head, your head gets freed up for other things.
To be explicit, I don't like "smart appliances" that connect to a cloud server. I do like the idea of devices that can connect locally to something like Home Assistant.
I'll just add this tip for those who struggle with this sort of thing.
I leave the empty basket in front of the machine, which for me happens to be somewhere where I'll pass by frequently until I need to take it out. That keeps it 'in sight, in mind'. Heck you could even put it in the kitchen to remind you.
I don't like the extra complexity that often comes with digital solutions, but I do like having a system. The simpler and less thought required, the better.
I do this for a number of different things. Rather than put it on a list I put it somewhere where it's in the way.
But this then means I have to have something on the floor in the way, which I also have to remember to do, and it doesn’t tell me anything about how long is left.
That requires more thought and clutter than just having the information when it’s relevant.
My pro tip is one of my girlfriends scrunchies stolen and put on my wrist - annoys me intermittently and therefore repeatedly reminds me to check the laundry.
You know, sometimes it doesn’t and sometimes it does. And also I’ve been known to forget it overnight and wake up to moldy clothes.
I have a friend who will say things like “I have to go at 3” and get up at 3 on the dot without even looking at her watch/phone. I’m not that guy and I need buzzers, timers, and ambient displays all working together anything done at a time.
OT but if your washing gets mouldy after being left in the washing machine overnight, you need to clean your washing machine (and/or use more detergent).
A bit OT but you may want a side loader. It's obviously not ideal to leave it overnight but the few times that's happened to me there isn't any mold. I'm guessing you have a top loader, it may not have been cleaned in a long time, and that it's in a basement that's prone to mold also.
For me it's not the washing machine, it's the dryer. The time remaining reported by the dryer when you start the cycle has almost no relation to how long it will actually take. Sometimes I go down to the basement after an hour (the dryer says 45m when you start it), and it still says 30m remaining. It's not the end of the world of course, but it is annoying, and it's the sort of annoyance technology can solve pretty easily.
On all settings except timer, my dryer is pretty much useless. I set it to dry my bedsheets and towels with bulky item preset, max dry (who chooses minimum dry for anything?) and it'll say it'll take 1h30m, ends up taking 30 minutes, and everything is still wet, despite it having a "dryness sensor"
I've just started using the timer function on the dryer and it's been mostly accurate, plus or minus a few minutes perhaps.
I got a 4-pack of zigbee power plugs that report usage, and I have a home assistant automation that goes ding (or whatever) when the washer or dryer had been using electricity for at least a few minutes and then stops using electricity.
And the timer goes off when you are in the shower - by the time you are done you forgot about the alarm. (I have more than once stopped an alarm I intended to just snooze)
Your comment reminds me of those infomercials where they try really hard to make something as simple as cooking spaghetti look like an unimaginable nightmare that no one could possibly accomplish
You have to imagine other people might think differently than you do...
I forget, it happens, nothing I can do with it. Having notification on my phone (place I'll look sooner or later) that laundry is done was great lifehack for me. No longer I forget and leave it there for whole night or even days...
Not sure why this is being downvoted, it's a pervasive flaw across all these IoT products. See my description elsewhere here about how Haier "smart" controls work. It's completely insane, and pointless. For systems that can't fail--I include heating systems in the winter--this kind of "move fast and break shit" way of doing it is malpractice. The last thing in the entire world I want my furnace controls doing is an automatic OTA firmware update. Ever.
Sell an additional $200 box containing a Raspberry Pi with Home Assistant on it and a cheap capacitive touchscreen and pre-configure it with Tailscale. Would be reasonably consumer-friendly. Give it a fancy name and start slapping "{$HOME_ASSISTANT} Compatible" branding logos on partners boxes.
If it's not quite as consumer-friendly as you want it to be, contribute your engineering hours to the Home Assistant product until it is.
Bonus points for giving it 25-250W audio output to power speakers and letting you pair them together to play music in sync across different rooms of your house connected to speakers of your choice.
The number of people who 1) really want local-only control and 2) can deal with Home Assistant and Tailscale but 3) don't actually have the skill set to put together a Raspberry Pi or other small Linux box and set up HA and TS themselves is tiny.
The cloud systems are insecure and invasive, but it's really hard to get Normal People to understand why it's a problem. "So someone can tell if I'm not home; so what? I live in a gated community, they can't just drive in at night and burgle the house." They're not entirely wrong about that; it is unlikely. The hard push for subscription services by these companies has turned out to be the best way to push people into locally hosted alternatives, because they don't want to pay for another service, but the usual approach is just to do without the service when they realize that the "smart" functions are not that useful. Most people don't have the free time, knowledge, or inclination to set up and maintain Home Assistant. They can appreciate it when they see it done well, but they aren't going to pay for a professional installation and maintenance and they aren't able to do it themselves.
Agreed, and with open, auditable design it's far more trustworthy. So you can satisfy both the paranoid tech nerds (guilty as charged) and the folks who just want to get it running with the least amount of effort are safer--whether they know it or not--because it's audited.
> The cloud systems are insecure and invasive, but it's really hard to get Normal People to understand why it's a problem.
In the case of HVAC systems the danger is a collective one not individual. Sure if someone really wanted to they could watch you and wait until you're not home then turn your heat off and freeze your pipes. But they're not gonna do that, probably. Instead the kind of havoc they'll wreak with this access is to wait until some off-peak time and instantaneously fire up all the AC units and shut them down simultaneously, repeatedly, causing a huge demand spike. If supply doesn't ramp up fast enough then frequency will drop and then the grid will start trimming off branches to self-correct (or something like that? I'm not a power grid expert someone correct me) and you basically have chaos.
So you don't need to get individuals to care about it, and there's some argument to be made that they shouldn't, or at least shouldn't have to. But the power company damn well should, and governments damn well should.
EDIT: the major issue here is the people who are affected by a vulnerability like that aren't the people who purchased and installed the attack vector. They're everyone on the same power distribution network. So it's not like "oh well, they did a dumb thing and trusted a tech company" it's far bigger than that.
I'm hoping that things like Matter and Thread will help with this, but in the meantime, I have no problem with "optional remote-access service that you don't have to use and have to explicitly enable, or you can use it entirely locally".
Associate it with the specific service they don't want you using, or transactions they don't want you making, or conversations and connections they don't want you having.
reply