Wait... why does Signal need to send notification content to Firebase to trigger a push notification on device? I would instead expect that Signal would send a push to my Android saying nothing more than "wake up, you've got a message in convo XYZ", then the app would take over and handle the rest of it locally.
I also didn't realize that Android stores message history even after I've replied or swiped them away. That's nuts - why!?
If your app needs to send a notification while it's not currently a running process, it must go through Firebase on Google's side and APNS on Apple's side. There is no way for a non running app to send a notification entirely locally, this is by design of both companies.
Signal developer here. Not entirely sure what you're saying. I'm only an Android guy, but FCM messages are certainly one trigger that can allow an app process to run, but it's not the only trigger. You can schedule system alarms, jobs, etc. And the notification does not need to be provided by the FCM message. In our case, the server just sends empty FCM messages to wake up the app, we fetch the messages ourselves from the server, decrypt them, and build the notification ourselves. No data, encrypted or otherwise, is ever put into the FCM payloads.
Sure but it needs to go through Firebase regardless of the content of the notification message, I do not believe there is a way to use a third party notification service which does not depend on Firebase.
It doesn't. The API for displaying a notification is purely local.
Receiving a ping from Firebase Cloud Messaging triggers the app to whatever it does in order to display its notification. In the case of Signal, that probably means something like fetching the user's latest messages from the server, then deciding what to show in the notification based on the user's settings, metadata, and message content.
Sorry I should clarify, by "it" I meant any sort of ping must go through Firebase Cloud Messaging, not that the message content itself goes through Firebase.
Looks like there is a way to bypass Firebase by using something like UnifiedPush which runs a perpetual background process that acts similar to Google Play Services to pick up notifications from the server and calls the local notification API.
It's theoretically possible to just keep an app running in the background all the time and periodically poll a server.
That's unreliable though since some OEM Android builds will kill it for that even if the user disables battery optimizations. Those OEMs sort of have a point; if lots of apps did that it would drain the battery fast.
Not clear what your point is. The Signal server wakes up the app via an empty message. At most the info this conveys is that a Signal app got a message to pull.
My point is there is no reasonable way to remove oneself from Google and Apple even with a fully custom application, they control the notification servers for their devices.
How? I'm not talking about an application backend server but a notification server which Google and Apple have for all apps. I'm not sure besides polling or having a persistent connection to send notifications to an app while that app is not running.
This is more of a fundamental technical limitation of operating systems and networks; I don't think it is possible to design distributed communication between arbitrary service provider infrastructure and end-user devices without an always-online intermediary reachable from anywhere (a bouncer, in IRC terms) that accepts messages for non-present consumers.
Yes, however the fact that it is not customizable is what is annoying, you are forced to rely only on the OS makers' implementations, which I guess should be expected in the day and age.
It sounds like you’re hinting at being unhappy with the lock-in forced by the ecosystem.
The flip side of the coin: any possibly avenue to exfiltrate data and do (advertising) tracking by app developers will be used. The restrictions also protect my privacy.
I’ll note that whatever other reasons it’s also the only way to make this battery efficient. Having a bunch of different TCP connections signaling events at random times is not what you want.
Ideally the app also is responsible for rendering rather than having to disclose the message but that can be challenging to accomplish for all sorts of reasons).
But there is a way to do this encrypted, so that when the notification is received on your iPhone, the process itself needs to decrypt it.
Except you need an entitlement for that, because it requires that your app has the ability to receive a notification without actually showing it (Apple checks this).
Your app gets woken up, decrypts the message, and then shows a local notification.
Markets do not model that especially well. When it comes down to these situations, it's not about the rising price of food motivating producers to enter the market - it's about the people starving. During a war, no amount of money can cause more munitions to appear fast enough. Blast-resistant concrete can take weeks or months to cure, workforces take time to train. These "momentary" disruptions can swamp the whole.
We have a hard division between "Core" repos (those which are deployed to production / customer sites) and everything else. The expectation in Core repos is that everything goes through a PR process where the pull request message is intended to explain the what and why of the change (perhaps with reference to a ticket, but with the key information restated in the PR), and goes through a review just like the code. Changes are then either squashed with that as the commit message or (if they're larger and benefit from a clear separation of commits), may be rebased with `git rebase -i` assuming the final PR body ends up in one of the commit messages.
Non-Core repos are absolute free-form anything goes. You can commit 8 times a day without a PR as long as you're not deploying to production. This is excellent for things like test harnesses, CI/CD nonsense, one-off experiments, demos, prototypes, etc.
My last Core commit had something like 20 to 1 ratio between lines of commit message to lines of code (small change touching something deep that required a lot of explanation). My last non-Core commit message was "hope this works" (it did not).
Yeah it's a bit odd to use a Haskell server to serve a static file which nginx then needs to buffer. You'd do much much better just serving the file out of nginx. You could authenticate requests using the very simple auth_request module:
>If this somehow does end up being a reproducible performance issue (I still
suspect something more complicated is going on), I don't see how userspace
could be expected to mitigate a substantial perf regression in 7.0 that can
only be mitigated by a default-off non-trivial functionality also introduced
in 7.0.
Ukraine has a sound-based version of this, supposedly using cell phones as the primary hardware element. The idea is to scatter hundreds of sensors along the front in some depth, then use simple on-device models to classify sounds and send an alert when a sound matching a known drone signature is detected.
You can use ESP32 with GPS modules and their PPS signals. The PPS signal from the module often has has a roughly precision around 60ns against the global GPS standard.
With that signal you can PID-control an internal timer of the ESP32 - which then can be used to timestamp audio frames. Send that to a central host over Wifi and you can use your standard localization math.
The trick is to use the internal ESP32 10MHz hardware which automatically kicks timestamps into a register if a GPIO does something. Not using high-level C constructs that must eat their way through x API layers.
I've been interested in deploying something like this around my property to localize sounds that I hear just for fun.
IMO having the on-device model to pre-filter to the signals of suspected drones is potentially a good idea in a wartime environment. Not only does it conserve bandwidth (which might be a limited resource), but it also reduces airtime and thus makes the devices harder to spot.
GPS is also unreliable in Ukraine, especially near the front line.
It's unclear which approach would be better from a power budget point of view. One requires substantially more local processing power but much less radio time, while the other requires continuous radio transmission.
> GPS is also unreliable in Ukraine, especially near the front line.
There are GPS antennas that physically can block out signals that are not coming from the sky with a huge amount of decibels. Maybe Aliexpress has some of them in stock? This was heavily ITAR-ed but this ban was lifted recently.
Other option: try to sync against the DCF77 signal from Germany. Not only the beep-beep-beep time signal but also the integrated phase modulation. Jamming VLF is difficult. 77KHz is in the range of ADCs.
Then make a voter: if GPS/GLONASS/Galileo/Beidou is available prefer them, if not fall-back to DCF77. If this fails: free-running.
Cell phones are kinda nice because they're hard to ITAR. Anyone can buy them. Old and crappy ones are generally still good enough for this kind of micro model. They come with their own batteries to hold-over between power loss or overnight. They also come with their own sensors, radios, and compute already integrated. Basically, you can just write software and ignore the hardware side entirely.
Remember, this isn't planned to be a long term solution, or to provide the highest quality available, or to be the cheapest or most efficient solution. It's intended to allow Ukraine to quickly plug sensor gaps in the lines and to scale easily.
That's a fun cobra effect. Age verification ("intended" to make children safer online, if you take the most charitable view) forces more and more people to use VPNs, which overall degrades the value of IP reputation as a signal, forcing providers to accept less reputable IPs because real customers come from them, which means that providers are more vulnerable to attacks that can be used to target children.
The point isn't protection from attacks that target children, it's gatekeeping content to keep it away from children. Providers are more vulnerable to attacks, overall, because of that gatekeeping, because of ht inevitable use of tools like VPNs and proxies to bypass the mechanisms being used. This sort of anti-anonymity is specifically and precisely targeted at decreasing the security of individuals, subjecting them to surveillance and control by the state. It has nothing to do with "protecting the children" and never did.
The four horsemen of the infocalypse are always about power grabs, they're never about actually protecting citizens, or children, or securing a country or region.
I also didn't realize that Android stores message history even after I've replied or swiped them away. That's nuts - why!?
reply