Hacker News Reader

Comment by JumpCrisscross | Hacker News Reader

> Haven't we learned our lesson on this?

What is the purported lesson we should have learned? Users choose phones with rich messaging features. This was a major selling point for iPhone, first, with iMessage, and later with Android until iOS caught up with RCS.

View on HN

One of the things Apple's Lockdown mode does is disable previews of images or links that are sent to you.

It seems like the lesson is that you shouldn't be processing data sent to the device by random strangers without the user explicitly choosing to open the file or follow the link.

That should be the default behavior, not a special lock down option that also disables other features.

Why can't they just make it like most email clients? No preview by default, give a banner with an option to explicitly allow a preview for that specific message or conversation?

>That should be the default behavior

It is! The phishers try to socially engineer their way into getting link previews or in fact clickable links period.

Screenshot here of the automatic link/preview disable-

https://www.bleepingcomputer.com/news/security/phishing-text...

I tend to agree.

But how does that prevent one from receiving and opening a malicious message?

Because many people know not trust unknown senders.

I should have said “a well crafted malicious email” or SMS etc.

No such thing as completely idiot proof. But I think we can all agree an exploit that requires a click is a lot better for the intended victim than one that doesn't. This way they at least have a chance to not click it. Then we can start tackling the other problems with separate solutions

Phishing is big business and ways to combat are not fool proof. Education helps. Spam detection helps.

Education helps, but it puts the burden on the user. The real fix is shutting down the phishing source, not just filtering the symptom.

You know that E-Mail clients blocking stuff came after right?

Sorry, but that is an insanely defeatist attitude blended with a hint of blaming users for wanting features.

Image decoders are pure functions and all should have been rewritten as 100% safe Rust years ago.

Users need functionality.

It’s up to us to figure out how to provide that safely.

Saying to users they shouldn’t have those features isn’t sage advice, it’s admitting failure.

They are actually pushing Rust quite hard now in Android:

https://blog.google/security/rust-in-android-move-fast-fix-t...

Even to the baseband firmware:

https://blog.google/security/bringing-rust-to-the-pixel-base...

Since it's a pure function, you can even keep using the legacy C code while still putting it in a sandbox: compile to WASM, then AOT transform to native code, and now it runs in the WASM sandbox at practically-native speed.

https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

(Of course, new code is preferred in Rust over C, for sure.)

Rust wont save you from malicious SVG+JS files, EPS/PostScript files and so on.

The thing is, nobody's happy just previewing jpegs and pngs.

Before you know it, people want to preview SVGs, PDFs, video, HTML and so on.

And to do that properly means you've got to support obscure formats like JBIG2 and CCITT Fax. Malicious vector images with a billion elements to render. XML that lets one file embed another.

And good luck getting the budget to re-implement them all from scratch in a better language, when the only business value the feature delivers is a postage-stamp-sized preview image.

Perfection is the enemy of the perfectly good.

And let's be honest, you'll have what, 0.0001% of users who want to preview CCITT in 2026? Less? Probably less.

It's a part of PDF, so if there's a PDF renderer which makes preview, it supports G4 and JBIG2.

The business value is reduced attack surface which is a marketable attribute. Seems like the exact type of thing Apple would do.

At what point do we just refuse to parse obscure rarely used formats

Most of these are solved problems to one degree or another. Web browsers have generally switched over to decoding legacy unsafe formats like PDF using safe managed languages, typically JavaScript.

> JBIG2 and CCITT Fax

Since performance isn't such a critical concern with obscure legacy formats, it really wouldn't be much more than a day or two of work for a competent developer with AI agent tooling to convert an existing decoder to safe Rust.

Meta set nearly a hundred billion dollars on fire for a total failure that everybody saw coming, a trillion dollars is what the current AI investment crazy is pouring into concrete and TSMC chips, but... a couple of days for a developer is asking too much!?

> legacy unsafe formats like PDF using safe managed languages, typically JavaScript.

Are you ironic? If any JS and v8 have tons of CVE's.

Stop being deluded with these hip languages. Rust? you wish. Maybe inferno with proper namespaces AND in-kernel namespace support. No, not like Linux. LIke 9front.

https://app.opencve.io/cve/?product=v8&vendor=google

Well, one could argue that the lesson from CVE-2017-0780[1] should've been "don't automatically decode rich messages from untrusted sources".

[1]: https://www.trendmicro.com/en_us/research/17/i/cve-2017-0780...

Stagefright is even older:

https://en.wikipedia.org/wiki/Stagefright_(bug)

Where are users being given an actual choice? There is no option for "iphone without these features", and I would wager that it has 0 bearing on anyone's decision to purchase a new iphone

There is a choice, but almost nobody uses it: https://support.apple.com/en-us/105120

> What is the purported lesson we should have learned?

Not to automatically execute things within data that we have been sent.

The subtle lesson, which we won't learn is [astronaut meme] all communication is potentially remote code execution. This isn't a computer thing, it's in the inherent nature of how communication works for us too. You can be more or less careful, but you can't eliminate the problem entirely or else communicating ceases to be effective.

Hey, you! Stop executing code in my head!

I think it's "don't use parsers written in unsafe languages".

All languages are unsafe. Some just make it less obvious.

Treat every input as an attack vector.

I think it's simpler: don't touch untrusted content unless/until you need to.

But that just moves it from 0-touch, to 1-touch (which is of course better).

But users are morons.

We STILL NOW, have people getting phished and pwning their employers.

Let's think about why that happens though

We all go through that stupid phishing training. They give us a list of red flags to help determine if an email is legit.

Then the next day, the CTO sends out an email that says IMPORTANT and the only text body says PLEASE READ THE ATTACHED .DOCX FILE. This is exactly what we were just trained not to open, but its from some exempt C-level who didn't have time to take the training, and all he is now doing is training the employees to open mails that look like phishing.

Alas, there are a lot of things that you need to touch that are untrusted.

That's easy, and already done. Phones only touch untrusted content when they need to, it's just that they need to touch it immediately upon receipt

Who are these people that are buying phones based on their 1st party SMS features?

There's a plethora of 3rd party messaging apps, namely WhatsApp or WeChat -- I haven't felt that messaging has sucked since then BBM days.

Didn't Android switch their codec stack to rust?

Reply on news.ycombinator.com