4 ms·

Web push is basically useless because Google hasn't prioritized fixing the issues causing Android to delay the notifications by 10 minutes or more. They are bas

Web push is basically useless because Google hasn't prioritized fixing the issues causing Android to delay the notifications by 10 minutes or more. They are basically only useful for "re-engagement" spam, nothing time critical. https://bugs.chromium.org/p/chromium/issues/detail?id=777106 https://bugs.chromium.org/p/chromium/issues/detail?id=777106 There are a whole bunch of sad bugs about Web Push in the issue tracker. It's disappointingly typical of the PWA APIs. They sound like they have the capabilities you need until you try to use them and uncover a minefield of five year old known issues that will never be fixed.

awesomeMilou 3y ago
> They sound like they have the capabilities you need I'm curious about what sounds so endearing about them to app developers. I wrote a WebPush scheduler once that implemented the VAPID protocol. Along the road I came across a myriad of resources that hinted at the fact that it's a heavily restricted feature, due to the fact that browser vendors know it's mostly abused for spam. I kinda figured you wouldn't implement them unless you're forced to explore any avenue for engagement.
- michaelt 3y ago
  Theoretically you might use them for a calendar app reminding people of upcoming appointments, a video call app receiving a call, or things along those lines. Of course we all know that in reality, 99.9% of usage is engagement spam.
  - josephg 3y ago
    Yeah. I don’t know why browsers have them enabled by default. Banning web notifications in my browser is one of the first things I do whenever I set up a new machine. I don’t want every second shitty news site to show browser dialogs asking if the site can spam me, even when I’m not on the page. What a horrible experience and a horrible feature.
  - modeless 3y ago
    What I'm saying is it's literally not possible to use them for a calendar app or a video calling app or anything along those lines. People simply won't get the notifications until ten minutes after the person called or the calendar event started. (No, it's not consistently 10 minutes, it's random, and can be several hours in the worst case, so you can't schedule the notification earlier to compensate in the calendar case). If these things were possible then maybe people would see the benefit of web push. But spam is the only possible application right now, so spam is all you see. It's really unfortunate because there are many other legitimate uses that should be possible...
    - danShumway 3y ago
      Let me add to this, they're also not possible to use without a serverside component. Using them for a calendar should be possible without a server, you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server. I agree with this, Google made a system that's only good for spam, refuses to fix it or expand on it, and as a result everyone hates it.
      - jessehattabaugh 3y ago
        > you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server. This isn't entirely true; WebPush is server only, but the Notification API can be used locally. You could schedule a timeout that causes a notification, as long as the page stays open, and to do it while the page is closed you could use a ServiceWorker. Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user.
        modeless 3y ago
        ServiceWorkers are subject to the same delay issues. In fact the ServiceWorker requirement is the whole reason for the issue in the first place: receiving a Web Push notification requires running a ServiceWorker and Android won't let it run in the background except at certain times. IMO the fix is to change the Web Push API so that you can send (or schedule ahead of time) notifications that can be displayed without activating the ServiceWorker. Alternative solutions would be for Android to relax the restrictions that prevent ServiceWorkers from running, or for Chrome to try to fit ServiceWorkers into the existing restrictions somehow. But for some reason Google refuses to try any of these, and so Web Push rots.
- afavour 3y ago
  I’m not sure why Web Push is often singled out for this criticism, the same goes for app notifications. I’ve never actually gone down the road of creating one but in theory you could make an almost entirely decentralized peer to peer messaging service with a PWA implementing the Web Push API to exchange messages. I agree that sadly most of the use cases are spammy nonsense but it remains an interesting API to me.
zubairq 3y ago
I didn’t know this. I always thought web push could mean no more need for apps?
lucideer 3y ago
It's worth noting that this is almost certainly a deliberate policy to push Firebase Cloud Messaging signups & inclusion of accompanying blobs in 3rd-party Android apps. Even within the non-PWA app world, low adoption of initiatives like UnifiedPush[0] & Android OpenPush[1] mean the canonical way for even open-source Android apps to do efficient push is by including proprietary Google blobs for FCM support, all mediated through Google servers. This is by far the biggest blocker for otherwise FOSS apps to distribute "clean" releases without proprietary code. If Google are putting up these kind of hurdles for app store apps, it makes sense they wouldn't make it any better for PWAs. [0] https://unifiedpush.org/ https://unifiedpush.org/ [1] https://bubu1.eu/openpush/ https://bubu1.eu/openpush/
- modeless 3y ago
  I don't believe it's any kind of conspiracy to make life hard for open source apps. There are legitimate technical reasons to use a single service for push messaging. This is just a regular old case of bad incentives. Chrome doesn't do a good job of prioritizing issues with user impact and Android doesn't support other teams well.
  - dathinab 3y ago
    As far as I can tell the story was something along the line of: 1. design push notifications as technical solution but not the necessary UX/UI and any abuse mitigations making them the perfect tool for abuse (both Chrome and FF, on Windows I only have seen Chrome impl. and it was horrible) 2. oh dang it get's abused 3. add abuse mitigations 4. which do not really mitigate the abuse at all but do prevent any proper use The the 4th point is the wtf something seems fishy point. If they would outright removed it arguing "too much abuse" I would not have been surprised. If they had tried to add proper abuse migrations and failed I would not have been surprised. But they added migrations which very obviously would not fix the most common wide spread abuse but would kill most proper use. And where that isn't a unexpected result, but a very easily predictable result. And that is what is strange because it is as if they kept it around as a pretense at the cost of a lot of non technical users "safety/experience" and iff that was intentionally I would guess it's to cause enough damage so that external institutes like consumer safety groups ask for it to be removed. Which if that would be the case would be quite disgusting. Firefox could fix that by fixing the UI/UX abuse issue (it's all about things outside of the web standard, i.e. doable without changing the standard). But as far as I can tell they do not care, and either implemented it for feature compatibility with chrome or I think the now gone FirefoxOS.
jessehattabaugh 3y ago
What solution is there here? No one would suggest that letting every site set up a long-lived network connection would be a good idea. So you need a central trustworthy connection. If you don't trust the company that makes your browser/OS then why are you using it?
wruza 3y ago
Why was the movement for push on ios then, if it never worked? Is it a kind of thing that everybody “wants” but no one buys?
- lucideer 3y ago
  > Why was the movement for push on ios then, if it never worked? Is it a kind of thing that everybody “wants” but no one buys? It's the kind of thing that consumers want but corps don't as it allows individual app developers to easily self-host efficient realtime notification instead of being locked in to centralised proprietary services from Apple & Google.
  - llm_nerd 3y ago
    Do consumers actually want it? This feels like developer projections. The GP have a point: For years we heard that mobile web apps were almost there but for the laggard Apple (see all of the "Safari is the new IE" comments). The argument never made any sense given that Android hits monopoly levels in many areas, and has an enormous global base of over a billion users, yet mobile web apps see extraordinarily little uptake. But it was an argument nonetheless. So now Apple made mobile web apps first class and implemented all of the must-haves and mobile web apps...still have negligible uptake. And the panacea platform still has critical defects that make it a subpar experience regardless. The new IE?
    - lucideer 3y ago
      > Do consumers actually want it? This feels like developer projections. Asking whether consumers want any developer API they clearly don't know exists is always tricky as is going to be a "want" by proxy. First and foremost, there's cost. Developers will pass on FCM service costs in app pricing which is clearly bad for consumers. Service choice encourages price competitiveness. But beyond that, in this case, I would also say that consumers installing a secure messaging client or non-Google email client likely don't want Google collecting metadata on all of their secure messages (& potentially actual data on their plaintext messages - regional legal compliance depending). > For years we heard that mobile web apps were almost there but for the laggard Apple Both Google and Apple each have their primary focus areas when it comes to marketing & propaganda - for Apple, its privacy (the justification for their walled gardens); for Google, they're pushing the web forward. Neither are true. The reality Google have always been behind what's actually needed in implementing true PWAs (despite inventing the term) - calling out Apple was a distraction tactic. Google will only ever push PWAs to the point that they don't interfere with their adjacent revenue priorities. Which is often. > The new IE? Nothing new about it. Chrome has been the new IE almost since inception. Here's an entertaining sendup from 13 years ago, just 3 years after its inception - the parallel to Chrome was already obvious enough at the time to not even require mention: https://brucelawson.co.uk/2010/in-praise-of-ie6/ https://brucelawson.co.uk/2010/in-praise-of-ie6/
Tistron 3y ago
Does firefox suffer the same 10 min delay or does it work there? I'm considering using it to give myself some notifications from my website.
- nacs 3y ago
  I've implemented this and it works as expected in Firefox (no delay, notifications are 1 or 2 seconds of latency at most from send time). Be ready to do lots of debugging to implement this though -- its far from straightforward and overly complicated IMO.
deleted 3y ago
[deleted]

awesomeMilou 3y ago

> They sound like they have the capabilities you need I'm curious about what sounds so endearing about them to app developers. I wrote a WebPush scheduler once that implemented the VAPID protocol. Along the road I came across a myriad of resources that hinted at the fact that it's a heavily restricted feature, due to the fact that browser vendors know it's mostly abused for spam. I kinda figured you wouldn't implement them unless you're forced to explore any avenue for engagement.

michaelt 3y ago
Theoretically you might use them for a calendar app reminding people of upcoming appointments, a video call app receiving a call, or things along those lines. Of course we all know that in reality, 99.9% of usage is engagement spam.
- josephg 3y ago
  Yeah. I don’t know why browsers have them enabled by default. Banning web notifications in my browser is one of the first things I do whenever I set up a new machine. I don’t want every second shitty news site to show browser dialogs asking if the site can spam me, even when I’m not on the page. What a horrible experience and a horrible feature.
- modeless 3y ago
  What I'm saying is it's literally not possible to use them for a calendar app or a video calling app or anything along those lines. People simply won't get the notifications until ten minutes after the person called or the calendar event started. (No, it's not consistently 10 minutes, it's random, and can be several hours in the worst case, so you can't schedule the notification earlier to compensate in the calendar case). If these things were possible then maybe people would see the benefit of web push. But spam is the only possible application right now, so spam is all you see. It's really unfortunate because there are many other legitimate uses that should be possible...
  - danShumway 3y ago
    Let me add to this, they're also not possible to use without a serverside component. Using them for a calendar should be possible without a server, you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server. I agree with this, Google made a system that's only good for spam, refuses to fix it or expand on it, and as a result everyone hates it.
    - jessehattabaugh 3y ago
      > you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server. This isn't entirely true; WebPush is server only, but the Notification API can be used locally. You could schedule a timeout that causes a notification, as long as the page stays open, and to do it while the page is closed you could use a ServiceWorker. Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user.
      - modeless 3y ago
        ServiceWorkers are subject to the same delay issues. In fact the ServiceWorker requirement is the whole reason for the issue in the first place: receiving a Web Push notification requires running a ServiceWorker and Android won't let it run in the background except at certain times. IMO the fix is to change the Web Push API so that you can send (or schedule ahead of time) notifications that can be displayed without activating the ServiceWorker. Alternative solutions would be for Android to relax the restrictions that prevent ServiceWorkers from running, or for Chrome to try to fit ServiceWorkers into the existing restrictions somehow. But for some reason Google refuses to try any of these, and so Web Push rots.
afavour 3y ago
I’m not sure why Web Push is often singled out for this criticism, the same goes for app notifications. I’ve never actually gone down the road of creating one but in theory you could make an almost entirely decentralized peer to peer messaging service with a PWA implementing the Web Push API to exchange messages. I agree that sadly most of the use cases are spammy nonsense but it remains an interesting API to me.

zubairq 3y ago

I didn’t know this. I always thought web push could mean no more need for apps?

lucideer 3y ago

It's worth noting that this is almost certainly a deliberate policy to push Firebase Cloud Messaging signups & inclusion of accompanying blobs in 3rd-party Android apps. Even within the non-PWA app world, low adoption of initiatives like UnifiedPush[0] & Android OpenPush[1] mean the canonical way for even open-source Android apps to do efficient push is by including proprietary Google blobs for FCM support, all mediated through Google servers. This is by far the biggest blocker for otherwise FOSS apps to distribute "clean" releases without proprietary code. If Google are putting up these kind of hurdles for app store apps, it makes sense they wouldn't make it any better for PWAs. [0] https://unifiedpush.org/ https://unifiedpush.org/ [1] https://bubu1.eu/openpush/ https://bubu1.eu/openpush/

modeless 3y ago
I don't believe it's any kind of conspiracy to make life hard for open source apps. There are legitimate technical reasons to use a single service for push messaging. This is just a regular old case of bad incentives. Chrome doesn't do a good job of prioritizing issues with user impact and Android doesn't support other teams well.
- dathinab 3y ago
  As far as I can tell the story was something along the line of: 1. design push notifications as technical solution but not the necessary UX/UI and any abuse mitigations making them the perfect tool for abuse (both Chrome and FF, on Windows I only have seen Chrome impl. and it was horrible) 2. oh dang it get's abused 3. add abuse mitigations 4. which do not really mitigate the abuse at all but do prevent any proper use The the 4th point is the wtf something seems fishy point. If they would outright removed it arguing "too much abuse" I would not have been surprised. If they had tried to add proper abuse migrations and failed I would not have been surprised. But they added migrations which very obviously would not fix the most common wide spread abuse but would kill most proper use. And where that isn't a unexpected result, but a very easily predictable result. And that is what is strange because it is as if they kept it around as a pretense at the cost of a lot of non technical users "safety/experience" and iff that was intentionally I would guess it's to cause enough damage so that external institutes like consumer safety groups ask for it to be removed. Which if that would be the case would be quite disgusting. Firefox could fix that by fixing the UI/UX abuse issue (it's all about things outside of the web standard, i.e. doable without changing the standard). But as far as I can tell they do not care, and either implemented it for feature compatibility with chrome or I think the now gone FirefoxOS.

jessehattabaugh 3y ago

What solution is there here? No one would suggest that letting every site set up a long-lived network connection would be a good idea. So you need a central trustworthy connection. If you don't trust the company that makes your browser/OS then why are you using it?

wruza 3y ago

Why was the movement for push on ios then, if it never worked? Is it a kind of thing that everybody “wants” but no one buys?

lucideer 3y ago
> Why was the movement for push on ios then, if it never worked? Is it a kind of thing that everybody “wants” but no one buys? It's the kind of thing that consumers want but corps don't as it allows individual app developers to easily self-host efficient realtime notification instead of being locked in to centralised proprietary services from Apple & Google.
- llm_nerd 3y ago
  Do consumers actually want it? This feels like developer projections. The GP have a point: For years we heard that mobile web apps were almost there but for the laggard Apple (see all of the "Safari is the new IE" comments). The argument never made any sense given that Android hits monopoly levels in many areas, and has an enormous global base of over a billion users, yet mobile web apps see extraordinarily little uptake. But it was an argument nonetheless. So now Apple made mobile web apps first class and implemented all of the must-haves and mobile web apps...still have negligible uptake. And the panacea platform still has critical defects that make it a subpar experience regardless. The new IE?
  - lucideer 3y ago
    > Do consumers actually want it? This feels like developer projections. Asking whether consumers want any developer API they clearly don't know exists is always tricky as is going to be a "want" by proxy. First and foremost, there's cost. Developers will pass on FCM service costs in app pricing which is clearly bad for consumers. Service choice encourages price competitiveness. But beyond that, in this case, I would also say that consumers installing a secure messaging client or non-Google email client likely don't want Google collecting metadata on all of their secure messages (& potentially actual data on their plaintext messages - regional legal compliance depending). > For years we heard that mobile web apps were almost there but for the laggard Apple Both Google and Apple each have their primary focus areas when it comes to marketing & propaganda - for Apple, its privacy (the justification for their walled gardens); for Google, they're pushing the web forward. Neither are true. The reality Google have always been behind what's actually needed in implementing true PWAs (despite inventing the term) - calling out Apple was a distraction tactic. Google will only ever push PWAs to the point that they don't interfere with their adjacent revenue priorities. Which is often. > The new IE? Nothing new about it. Chrome has been the new IE almost since inception. Here's an entertaining sendup from 13 years ago, just 3 years after its inception - the parallel to Chrome was already obvious enough at the time to not even require mention: https://brucelawson.co.uk/2010/in-praise-of-ie6/ https://brucelawson.co.uk/2010/in-praise-of-ie6/

Tistron 3y ago

Does firefox suffer the same 10 min delay or does it work there? I'm considering using it to give myself some notifications from my website.

nacs 3y ago
I've implemented this and it works as expected in Firefox (no delay, notifications are 1 or 2 seconds of latency at most from send time). Be ready to do lots of debugging to implement this though -- its far from straightforward and overly complicated IMO.

deleted 3y ago

[deleted]