Hacker Newsnew | past | comments | ask | show | jobs | submit | dlcarrier's commentslogin

In 2008, I had a Nokia phone running Symbian that had a pretty janky graphical interface on a tiny resistive touch screen, but the voice commands were far more useful than any phone I've seen since.

Changing the brightness was a chore, that required holding the power button more than half a second but less than one second, to bring up the menu. Hold it for too short and the phone would lock, or for too long and the phone would shut down completely. From the menu, there was a settings option, then brightness, which finally brought up a slider.

Using voice prompts, was much easier though, which made sense at the time, because it was a phone. I often used it from a helmet intercom, while riding a motorcycle, with the phone packed away in my luggage. I could press the button on the intercom, then say a command like "Call Sue Mason" and it would usually respond with "Call Sue Mason mobile" but sometimes with something like "Call Sam Isleton home", and I could respond accordingly, before placing the call. I could also say something like "Navigate to 132 Larch Street, Springfield, East Virginia", and get a similar confirmation, then turn-by-turn directions.

With modern phones, the have huge capacitive touch screens and somewhat better navigation menus, but they'll just call Sam Isleton without a chance to stop it, or bring up navigation with an on-screen button to continue, so it's completely useless without interacting with the display.

I feel bad for anyone who's blind. I usually navigate web pages with a keyboard, because it's faster, even though I'm perfectly capable of using a mouse. A bunch of web pages have started hijacking keyboard navigation for accessibility overlays, which make everything far more difficult to use. I ended up adding the overlay hosts to my add block, but found it hilarious that they're so reviled that there's a Chrome extension just to block them: https://www.accessibyebye.org/


If they can figure out how to make price tags that show different prices to different people, they should be targeting to display different images to each eye and selling it as glasses-free 3D.

Five years ago, it would have been blockchain powered.

But? Of course anyone familiar with VR is going to be bearish on the Vision Pro.

Switchgrass isn't all that uncommon in parts of the US that process corn into ethanol, and it is more efficient but less subsidized, so corn beats it out. Sugarcane is even more efficient, but it doesn't grow in most of the US.

The real question isn't about using biofuels in place of electric power, it's most important in place of other fuels in applications where electrification isn't possible, like air travel.

Air travel is not only the fastest form of travel in common use, it's also one of the most efficient, due to the thin air at cruising altitudes. If jet fuel derived from sugarcane or switchgrass becomes cost effective, airplanes can be solar powered for cheap.


I agree with most of your comment except for this one:

> Air travel is not only the fastest form of travel in common use, it's also one of the most efficient, due to the thin air at cruising altitudes

While airplanes are slightly more efficient than cars at transporting passengers on a distance/energy basis (and only if you exclude electric cars), trains are still much more efficient by about 30%. See https://en.wikipedia.org/wiki/Energy_efficiency_in_transport...

With respect to carrying freight, cargo ships are the most efficient of all.


I'm talking about the physics, not the logistics. Logistics are a present challenge, but physics are a hard limit, so load capacity and power conversion losses don't really have the same insurmountable bearing as rolling resistance and drag. Drag increases with the square of the speed, so fuel efficiency is really only comparable at a given speed.

Water is extremely viscous, so it creates a lot of drag, and cargo ships must scale to huge sizes and stay under 20 knots to have high efficiency. Trains are only flowing through air, which is much thinner than water, so freight trains and most passenger rail go double or triple that speed. High-speed rail doubles to triples the speed again, but is much, much less efficient than rail traveling at freight speeds, because it has no means of avoiding the added drag.

If you were to try and increase high-speed rail by another two to three times, you'd need a rarefied tunnel to make it approach being practical, which is basically what Hyperloop proposed. It's much more practical to use the already existing rarefied atmosphere at high altitudes, which is why airplanes have unmatched efficiency for travel at those speeds.

When travel time going into days or even weeks doesn't matter, e.g. for cargo, all that matters to efficiency is how slow you can go. When time is taken into consideration, as speeds go up rail becomes more efficient than boats, but they top out and airplanes are more efficient than rail. Eventually sub-orbital rockets become more efficient than airplanes, but there isn't a lot of travel needed at those speeds.


That’s ignoring a lot of other losses. Like in air travel you’re instantly losing 10-15% of your fuel generating lift, then you have to add in the fuel used for carrying the other fuel required throughout the flight. Whereas with high speed rail, rolling resistance (which we could say is the equivalent of lift in aircraft) is less than 1% from a quick search, and for a lot of passenger rail and almost all high speed rail you don’t need to carry fuel which is supplied as electricity from an overhead line.

Hyperloop of course was always a non-starter because the kind of energy that would be required to pump down such a huge volume would be ludicrous, maintaining the low pressure extremely difficult, and the amount of materials needed for the tube would be ridiculously large.


This was a bug that left it cached on the device. Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring.

If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.


> Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring.

>If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.

This incorrect on two counts:

1. As per what you wrote immediately before the quoted text, the issue was that the OS keeps track of notifications locally. Google/Apple's notification servers have nothing to do with this

2. It's entirely possible to still have end-to-end messaging even if you're forced to send notifications through Google/Apple's servers, by encrypting data in the notification, or not including message data at all. Indeed that's what signal does. Apple or Google's never sees your message in cleartext.


If Signal wants to show you a notification with message text, it needs to put it on the screen through an OS service. That service was storing the plaintext on the device.

Through an OS service yes, but not a hosted backend service. Obviously that service has store the notification in plaintext (although everything on an iPhone is encrypted at rest, but notification crypto keys have to stay in active memory for the lock screen to work), otherwise it wouldn’t be able to display the notification text.

Apple support applications sending encrypted notifications, where the OS launches the app the decrypt the notification body locally and pass it back to the OS for display.


I think the idea here is that the notification text was also being put somewhere else that was not really tied to the lifetime of it being shown on screen.

This thread is about Apple servers accessing the contents. Of course the OS has access to the contents of your messages, how else do you expect it to show a preview of the message? Do you want each notification to be a custom-rendered widget from the app?

If the contents are that sensitive you must disable the preview. Even then, the OS has access to the pixels in your app so it really is a moot point.

The caching issue here was evidently a bug.


They have to. The device storage is itself encrypted, so the FBI already broke into the phone. When the device is unlocked, notifications are visible by design and therefore available in plain text to the user. The edge case is with disappearing messages, a feature Apple did not build for. The message is intended to be plainly visible to the user, but only for a controlled time on the assumption that the users privileges may eventually be compromised.

This makes for a very odd and specific interaction with a 3rd party feature. Security is a hard problem.


This wasn't a disappearing messages case, this was a case where they had uninstalled Signal entirely, including all their messages. But Apple was storing the received message text from the notification in its local database. I don't think it is edge case, in that if someone uninstalls their Whatsapp or Signal or whatever, or they delete a chat/message within that app, that it should be gone off your phone. The OS storing end to end encrypted message content in notification history for no reason (why store content in a database at all) makes message deletion work differently than most people would expect, so it doesn't feel like an edge case to me.

Signal (at least on iOS) has a setting called "Notification Content" which defaults (unsafely in the light of this bug) to "Name, content, and Actions", but allows you to select either "Name Only" or "No Name or Content".

I assume that "Name only" option results in the push notification only sending "Signal message from Bob", and the "No Name or Content" one only sending "You have a new Signal message" - instead of the whole "Signal message from Bob: Let's rob the bank tomorrow!"

If I could have it work the way I'd prefer, Signal would let me set those Notification Content on a per contact and per chat basis - so I could set my bank robbing crew and group chats to "No Name or Content" while leaving mom and the family group chat on "Name, content, and Actions".

(But realistically, if I _did_ have a bank robbing crew they'd all be on my burner phone, not the phone I do family group chat with.)


How did the FBI break into the phone in the first place? Shouldn't they be fixing that bug too?

This is correct, but my understanding of it is that the push notification (which is not the same thing as the actual "Notification" that is shown on the screen) basically contains a "hey $DEVICE, go talk to $APP_NOTO server they got something for you".

APNS just taps on the device's metaphorical shoulder and hands them a courtesy phone "call for you sir"


That’s not how it works. Not on iOS anyway.

For a standard notification the content of that notification is sent through the push notification servers. This includes the title, text, icon, grouping, and sound presets to use. The majority of user-visible notifications are sent this way - the app on the device does not run.

That allows the OS to display your notification without ever running the app, which saves limited resources on the phone. Originally this was the only option, a push notification couldn’t start your app.

These days an app can also register a notification extension which is a standalone program that can modify the incoming notification. It has 30 seconds to do whatever it needs to, though you need to be careful with RAM use or the OS will kill the process and present the notification unaltered. Generally you’d put something generic in the push as a fallback.

There’s also background notifications. These let the app run for 30 seconds and the app can post a local notification during this time, but they’re not guaranteed to be delivered. The OS can decide the system doesn’t have the resources and defer or drop them, or terminate the app before it’s finished if the ram is needed elsewhere.

There are some other special cases depending on what your app does.


> the app on the device does not run.

That explains an oddity I was experiencing.

Work uses Webex. I had work webex installed on my phone. My password changed on my account in the office, if i try to open Webex on my phone I would be prompted to re-authenticate which I would never do because it required 2FA and the token generator is on my laptop which I generally wouldn't have with me when using my phone.

However, despite not being able to open the app as my account, I was still getting full messages in the push notification for anyone who had messaged me recently while the app was functioning. Anyone new would pop up as 'Message From X'.


More details are documented in the ntfy docs: https://docs.ntfy.sh/config/#ios-instant-notifications

Yes, but that service is running locally.

> it needs to put it on the screen through an OS service. That service was storing the plaintext on the device.

Technically, so can the OS's text drawing primitive while drawing Signal's UI.


Yes, but it shouldn't ;)

Agreed 100%, but my point is that you have no option but to trust your OS.

You are correct, but you omitted one complication: Clients trust Google's and Apple's servers to faithfully exchange the participants' public keys.

Apps (such as Signal) that care about end-to-end encryption do their own key management. So, Apple / Google servers only ever see ciphertext, and don't have access to the key material that's used for the encryption.

Afaik, e2e messengers don't include ciphertext with push notifications. It's an empty push to wake the client. Then the client contacts the origin to fetch the ciphertext.

This is how it used to work; notifications can be encrypted now and Signal uses an extension to decrypt them.

A Signal developer 12 days ago said Our FCM and APN notifications are empty and just tell the app to wake up, fetch encrypted messages, decrypt them, and then generate the notification ourselves locally.[1]

[1] https://news.ycombinator.com/item?id=47723445


Ah, yes, they would be right. I feel like I had read that someone had migrated at some point, maybe it was WhatsApp or something.

Sending public keys through the notification system is an unnecessary complication.

Which clients?

Isn’t that what Contact Key Verification solves? Or do I misunderstand how that works?

... and hold participants' private keys truly private, which you cannot verify without a rooted phone.

You don’t need a rooted phone. An open source OS with reproducible builds is enough. That way you can validate what the code does without giving up verified boot, or opening up another attack vector, etc.

> You don’t need a rooted phone.

I disagree.

1. I need to be able to change SSL root cert, disable SSL cert pinning, and intentionally MITM installed apps and see what they are sending about me to their servers. Open source OS isn't enough if the apps aren't open source.

2. "Apps sending information about me to their motherships that I don't consent to them sending" is a MUCH bigger problem these days than people messing with SSL, so I accept the risks of (1)

3. Verified boot is big brother's dream. I want to be able to verify my own OS.


What about when my notifications are showing up on my MacBook next to the phone via mirroring?

> What about when my notifications are showing up on my MacBook next to the phone via mirroring?

See perhaps §iMessage and §Continuity in Apple Platform Security:

* https://help.apple.com/pdf/security/en_US/apple-platform-sec...


Those notifications are transfered peer to peer (from your Phone to your computer) using Apple Wireless Direct Link. The contents are encrypted using AES-GCM.

talking totally out of my ass, but apple seems to have robust infrastructure for e2ee communication between your devices, for example it is known that location information in find my is not visible to apple. I’d be surprised if the channel to send iphone notifications to your mac wasn’t also e2ee

Unless something has changed since I last did this, the app's server initiating the apns doesn't encrypt using some public key for the destination. So no e2ee at that layer. But you could encrypt the payload and have the app decrypt it if you're managing the keys yourself.

Both Apple and Google offer the ability for your app to intercept and modify messages before being displayed. Use that to send encrypted messages and decrypt them there, using your own code on the user’s device.

That framing Makes it sound like the app developer has to do something active to keep message cleartext out of notifications. That's not how it is on Android.

A Firebase Cloud Messaging push notification contains what the app developer's server puts in it. That could include the message body or it could just be an instruction to the app to poll the server for new messages. It has nothing to do with the notification that's displayd on an Android device. Those are entirely local.

An app that cares about privacy wouldn't send anything more than a poll instruction over FCM.


You can implement either approach on iOS as well.

But if you have strong end-to-end encryption for messages, then you don’t have to care about the transport anymore, you assume they’re all compromised. At that point you might as well use the push notification system as your transport, given both OSs allow applications to intercept the push notification locally and decrypt it before it’s displayed to the user.


Plus, decrypting using a key stored locally cuts out a network roundtrip, which has battery and data usage impacts.

This has performance/reliability tradeoffs.

In fact this is what both iMessage and Signal (and maybe Whatsapp too but I can’t tell from a quick google) do.

This is the notification layer, but the same structural problem exists one level deeper: the OS vendor is the custodian of the user's entire digital identity, not just message contents, but context, behavioral history, and application relationships. The notification routing is a symptom. The custody assumption underneath it is the root.

As long as your identity lives inside a vendor-controlled OS, encryption at the app layer is a patch on a structural problem


> If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.

We have no idea if this actually works or even what it does, because we can't see the source code. We just have to take Apple and Google's word for it. Which is not exactly a smart thing to do.


> If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.

Why would an encrypted app broadcast your messages to notifications? That sounds like a failure of the messenger service vendor to secure their app. My banking app requires me to log in to read messages and my account statement EVERY TIME. I get a notification that is just that, notifies me of some pending information, not the information itself.


The fact that you received messages at specific times can be enough to identify you, if you have the data from the sending side.

From the discussion under this comment it seems its a lot more complicated than that, and lots of people think they know how it works and then lots of other people disagree with them. So all very murky

> set your notifications to only show that you have a message, not what it contains or who its from.

I'm pretty sure that's the default in GrapheneOS. Or at least that's how mine behaves.


Right, it would be too hard to just have a server send a notification and to jumble that notification locally with the read of the unlocked message without it going through Apple/Google servers.

Incorrect. At least according to the Matrix (chat) app FAQs I have read recently.

With Matrix apps, certain metadata is pushed from the chat server, to a push server, through Google and then to my device. But the message is not part of that data - it's E2EE. What happens is the app wakes up from the metadata notification, and then fetches the message and displays it in the notification field.

Your last point is correct, at least until/unless this is remedied in Android, too.


Honestly, there are so many good reasons to turn off notifications entirely. Sure, maybe leave them on for phone calls from people you know. But past that, I think getting interrupted by your phone is more trouble than it's worth.

This is misinformation, and is false.

For many apps, they choose to do it this way. For most e2ee apps, they do not. The notification displayed on screen does not need to be the notification pushed through APNS.


But in the real world, for maximal battery savings and therefore UX, routing any notification data via APNS is recommended.

Fortunately you can choose the payload by yourself and just send a notification "ping" without any data about the messages. But if we're serious about security, you just don't ping the client about new messages because even the time and existence of a notification can be compromising. _The user will know that they got a message, when they open the app and see that they got a new message._


Telegram secure chat messages do this by default.

Oh please, Telegram being mentioned positively during a discussion of security, privacy or state surveillance? Telegram is a security nightmare, it’s not e2ee no mater what BS their very very untrustworthy founder keeps spouting, it’s not default and what they do offer is probably not secure. Servers owned by Russian oligarchs loyal to Putin. Durovs rebel persona, where he’s persona non grata in Russia is also BS. He was shown to be freely traveling in and out of Russia and having negotiations with the Russian government around censorship of Telegram all while Durov was telling us he couldn’t return. And the Russian FSB won’t use it because it’s known in their circles as being compromised.

https://www.youtube.com/watch?v=a2eBDU5ea0A&t=392s

> "That largely depends on what an officer does outside of work. If someone is involved in corrupt dealings, and in fact, I know very few who aren't, then they reason like this. Can this messenger be monitored by internal security officers? Previously, many used WhatsApp. Almost no one used telegram because there's a wellfounded belief that this messenger is to some extent controlled by the Russian authorities. People used signal. Some use three months, but all that has now been shut down again. Why is it monitored? I think they're worried about a possible coup and trying to limit the ability to coordinate mass actions via communication channels from abroad. Hence the Max messenger. So now most security officers have switched to Chatty. That's a Dubai based messenger, but it's definitely not a universal remedy. Some have moved to Zangi, which is [clears throat] an Armenian app that markets itself as American. When it comes to targeting the opposition, the state will always find the resources. It's one of the main priorities, more important than any financial or commercial issue, even more than counterterrorism."


You are right in that it is Google’s and Apple’s OS notification api, and we do give them the plaintext messages.

Seems like you should use an app like Signal for anything sensitive at all so you don't have to worry about megacorp ecosystems as much.

As mingus88 said, this story is literally in response to Apple leaking messages sent through Signal. Doesn't matter if the message is securely transmitted if the operating system then keeps it lying around in plain text in a cache.

From the linked article:

> The independent news outlet reported that the FBI had been able to extract deleted Signal messages from someone’s iPhone using forensic tools, due to the fact that the content of the messages had been displayed in a notification and then stored inside a phone’s database — even after the messages were deleted inside Signal.


This article is about Apple fixing what they considered a bug, that signal messages were cached locally.

You can easily configure Signal not to show the message contents if you want, though.

The original comment mentions this but gives the wrong reasoning. The APNs are encrypted either way, but this setting prevents Signal from decrypting them client-side and letting the notification cache store it. Yeah this is more secure because it means not trusting Apple to do their job right with local storage, but it's also kind of a reasonable thing to trust.

That's what Signal does on my iPhone, I thought it was the default?

Except even when you turn off message previews, it has to be specifically from within Signal settings. Not the iOS settings for notifications for the Signal app. To the user it looks the same, so it’s easy to make the mistake of turning off the previews in iOS settings instead of from within Signal settings. I didn’t even know there was a difference between the two until the recent posts about it.

Nope, Signal messages were stored in the phones notification DB even after the app was deleted

https://www.404media.co/fbi-extracts-suspects-deleted-signal...


totally agree

This is also an oversimplification. If I understand the issue correctly, the notification with the message contents was what was cashed locally and then accessed. This same vulnerability would exist with Signal if you had the notifications configured to display the full message contents. In this case, it has nothing to do with either Apple or Signal.

The real question is why iOS caches notification payloads to a persistent SQLite DB in the first place. The notification content only needs to live long enough to render the banner and be shown in the lock screen shade. Persisting it to disk for a month past dismissal isn't a "bug", it's a design choice that someone signed off on. Signal can set UNNotificationContent to show empty/placeholder text, but the default path for any app that hasn't opted out hits this cache. Worth reading the 404 Media piece for the forensic tooling details, this isn't a 0day, it's Cellebrite reading a plist.

I’ve been looking into reproducing the extraction of unredacted data. Found this, and it’s speculative, but Magnet Forensics has an internal “infomercial” on reconstructing content from notifications, too.

“find the inclusion of this information interesting because there is a chance that this still contains communications even when the record has been deleted from the sms.db file. I've yet to find definitive proof that this is the case however and it's possible that it is purged at the same time as sms.db is cleared.”

From: https://web.archive.org/web/20220120174606/www.doubleblak.co...

See also: https://theforensicscooter.com/2021/10/03/ios-knowledgec-db-...


It's not very conductive, so it won't have any appreciable discharge, but the hairs will repel each other, which is easy to see. Search for "Van de Graaff generator" and "hair", to see lots of pictures.

The lines about oxidizers cleaning the air reminds me of the aspects of late 1800's and early 1900's product marketing oversimplifying hygiene. Bleach everything, whether it needs it or not; anything that indiscriminately kills all bacteria can only make the world a better place!

To be fair with the lack of refrigeration and general spread of disease and vermin this could have been a great idea at the time

As my 401(k) statement once said "past performance is not an indicator of future performance". Comparing current prices to past inflation-adjusted prices has no relation to current markets, even for books.

Whenever I pull up Hacker News in the evening in the Pacific US, it's a complete dead zone. I'm not at all surprised that 6:00 to 11:00 AM PDT is peak time.

Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: