Val Packett 🧉2d ago

In preparation for daily driving #MobileLinux I've been thinking a lot about what must be done for reliable and power-efficient push notifications.

Spoiler alert: while UnifiedPush may be a relevant service for some apps, it's not where platform dev focus should be. We want a future full of p2p apps that reject permanently-addressable "servers" entirely, after all! And centralization is not where the bulk of the power-saving magic is anyway. The "magic" is in the fact that the SoC can be in deep sleep and the modem will still wake it up with an interrupt when data arrives on an open connection. It should be fine to have apps' own service processes listen for notifications!

My rough sketch of a to-do list would be:

  • making sure wakeups don't turn the display on xD
  • research into what's needed to set up filtering on the modem for which sockets can wake the SoC up (but initially, fine to just rely on "nothing else has open sockets anyway, only the background services waiting for pushes" maybe?)
  • easy API for establishing the push connection specifically over mobile data if available (since only modem supports wakeup well rn)
  • support for robust background services: unlike what the Background portal offers now, let #Flatpak apps install systemd-user services, which would have metadata connecting them to the .desktop entry, making them introspectable and accountable via settings GUIs (not via control center popups! they shouldn't show up as "annoying left-over in-process thing possibly eating battery"! they're a different thing, expected to run permanently!)
  • actually getting apps to separate push notification listeners into background services

#postmarketOS #linuxmobile #freedesktop

Show threadDemi Marie Obenour1d ago
@valpackett I’d love to be using mobile desktop-based Linux, but that will need a security model that is better than “yolo” 😆.
Show threadVal Packett 🧉1d ago
@alwayscurious yeah :) I wonder what is your threat model roughly wrt. mobile?
Show threadDemi Marie Obenour

@valpackett These are at least some of the things missing from desktop Linux:

  • Disk encryption using the secure element and hardware-wrapped inline encryption keys that are tied to an OS signed by a specific key. Without this, disk encryption is usually very simple to brute force.
  • Protection against USB-based attacks. These are the main attacks used by Cellbrite. GrapheneOS (and only GrapheneOS) provides very strong protections against this.
  • Strong verified boot with distrust of persistent state. Android has it. Desktop-based Linux systems don’t.
  • As-strong-as-feasible application sandboxing. Flatpak’s sandbox is disabled by many popular apps. Android doesn’t allow that.
  • Security researchers seriously looking for vulnerabilities so they can be fixed.
  • New code in system services being written in safe languages (Rust, Kotlin, Java) rather than in C or C++. New code in applications is usually written in Kotlin or Java, which are both memory safe.
  • Forcing applications to migrate to new (and incompatible) APIs over time, rather than allowing them to stay on old APIs that provide excessive access.

    • Desktop Linux is maybe 15 years behind on these things, give or take a few years.

    The hardest part of the problem to solve isn’t technical, though. It’s developer mindset. The Android team at Google is paid to be concerned with security. Desktop Linux developers are generally way more concerened with getting stuff to work at all. This doesn’t mean that they don’t care about security, but rather that it isn’t anywhere near as high a priority. For instance, Flathub is not willing to kick out apps that aren’t strongly sandboxed, and Flatpak doesn’t strictly enforce the use of runtime permissions rather than install-time permissions.

    You can be secure or you can be compatibile with existing applications. You can’t have both unless you are willing to provide fake versions of everything the app thinks it has access to but doesn’t. Android has repeatedly shown it is willing to impose stronger and stronger restrictions, and Google Play Store policies force app developers to accept new restrictions on their apps as a condition of being able to update them. I know that the Google Play Store monopoly is bad, but it really does prevent app developers from doing lots of really bad things.

    I think that Spectrum could solve many of the technical problems. It’s designed for verified boot from day 1, uses VMs for sandboxing, and uses Rust for its services. Unfortunately, it still doesn’t solve the disk encryption problem. Also, BTRFS is significantly more complex than F2FS, and desktop Linux apps ~never distrust persistent mutable state. Finally, the amount of resources required might be beyond what most phones can afford.

    Mar 23 at 12:50pmWeb
    Show threadAdrian Vovk1d ago
    @alwayscurious @valpackett The good news is that there is work ongoing to improve this status quo