Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Service Workers

frontendian.co

Post reply on HN
Print view View original

21–30 of 68 posts

Re: Service Workers

#21

Post by Brakenshire »

michaelmrose wrote: post #4

"Imagine being able to respond to push notifications, intercept resource requests, and schedule background syncronization, all without the need for a user to actively have your website open in front of them." ".. by authoring special-purpose JavaScript which you register with the browser." Why does this seem like something useful for malware and generally annoying me.

Push requests only exists on Chrome and is behind a permission, intercepting resource requests within the domain of a website could cause some annoyances, can’t see the malware effect immediately. Scheduling a download for a stable connection, again, could be an annoyance, but what’s the malware implication?

Re: Service Workers

#22

Post by wbercx »

slow_donkey wrote: post #6
sbr464 wrote: post #3

Great write up. I’ve been exploring SWs recently to help with downloading and caching data in the background for faster UI. Question, I’d like to avoid doing large downloads or possibly cap the transfer rate to avoid any potential jank. Is there a best practice or is it possible to monitor the current browser interaction to determine how strategically best to pull data with a SW? Depending on what a user chooses to c…

Have you looked into using a fetch event hook? The first thing I thought of was an Axios interceptor if you're using Axios or other http lib. That should allow you to sum up download sizes.

Thanks for this! I've recently been asked how much data our React Native app uses. I totally hadn't thought of using Axios' interceptors to track this. So obvious!

Re: Service Workers

#23

Post by fungi »

michaelmrose wrote: post #4

"Imagine being able to respond to push notifications, intercept resource requests, and schedule background syncronization, all without the need for a user to actively have your website open in front of them." ".. by authoring special-purpose JavaScript which you register with the browser." Why does this seem like something useful for malware and generally annoying me.

Open up about:serviceworkers and observe the wonders of cookies 2.0

Kinda sucks that something with such promise is predominantly used as just another weapon for tracking.

Re: Service Workers

#24

Post by chrismorgan »

Brakenshire wrote: post #21
michaelmrose wrote: post #4

"Imagine being able to respond to push notifications, intercept resource requests, and schedule background syncronization, all without the need for a user to actively have your website open in front of them." ".. by authoring special-purpose JavaScript which you register with the browser." Why does this seem like something useful for malware and generally annoying me.

Push requests only exists on Chrome and is behind a permission, intercepting resource requests within the domain of a website could cause some annoyances, can’t see the malware effect immediately. Scheduling a download for a stable connection, again, could be an annoyance, but what’s the malware implication?

The malware angle is basically service-worker-powered cache poisoning: if you can get the server to serve your code once, users can get a service worker installed, and intercept resource requests under that path. It’s limited in practical value because you have to be able to serve a full JS file as the service worker, rather than just injecting a snippet of JS as the most common technique is, but it is a genuine attack vector.

Re: Service Workers

#25

Post by chrismorgan »

pmlnr wrote: post #7

Firefox: about:config dom.serviceWorkers.enabled;false Why: They bite. The generic idea may even be reasonable (offline working web app), but every single time I encounter service workers they make things worse. If you load a React frontend, it'll, by default, deploy a service worker. Good luck trying to load anything non-react from that resource/server. I never asked for a web app to work in the background once I cl…

My most delightful experience with a service worker was SVGOMG, https://jakearchibald.github.io/svgomg/. One time I was without an internet connection, and I thought to myself, “if only it had a service worker so it’d work offline!” and then I opened a tab to it, to remind myself to optimise the SVG I was working with later, and— huh. It loaded. On reflection, I decided that given who Jake Archibald is, it made sense that he’d be an early service worker adopter. So that day I was really pleased with the Just Works™ value of that service worker.

And SVGOMG is able to load faster thanks to service workers, too.

At FastMail, we’ll be getting round to adding service workers some time soon, and it’ll actually give us a quite fascinating performance boost: even without supporting full offlineness, simply caching the basic data you need can get you to the point where you need literally no requests before you can load the interface, showing meaningful data to the user, and then fetch updated data in the background. I’m confident we’ll be able to get startup time to under two seconds with service workers for code and data loading/caching, and hopeful that we’ll get it down to under a second.

Service workers can be badly implemented, but they also offer the possibility of some quite delightful improvements in websites and web apps.

Re: Service Workers

#26

Post by JeremyBanks »

fungi wrote: post #23
michaelmrose wrote: post #4

"Imagine being able to respond to push notifications, intercept resource requests, and schedule background syncronization, all without the need for a user to actively have your website open in front of them." ".. by authoring special-purpose JavaScript which you register with the browser." Why does this seem like something useful for malware and generally annoying me.

Open up about:serviceworkers and observe the wonders of cookies 2.0 Kinda sucks that something with such promise is predominantly used as just another weapon for tracking.

Service Workers isn't a new persistence mechanism, it uses existing ones.

Re: Service Workers

#27

Post by bryanrasmussen »

ahsanejaz wrote: post #17
dannyw wrote: post #5

I like service workers, but I don't like the lack of control I have. For example, I want Messenger to send me notifications if I have the tab open, but I don't want the service worker to maintain a persistent connection and send me notifications with the tab closed. Unfortunately, I am not able to block service workers. My only option is to block notifications entirely, which doesn't even stop the service worker.

The service worker does not maintain a persistent connection. Some websites/pwa's allow you to configure that.

but then you're depending on the website/pwa to be a good citizen and allow you to configure that

Re: Service Workers

#28

Post by pmlnr »

chrismorgan wrote: post #25
pmlnr wrote: post #7

Firefox: about:config dom.serviceWorkers.enabled;false Why: They bite. The generic idea may even be reasonable (offline working web app), but every single time I encounter service workers they make things worse. If you load a React frontend, it'll, by default, deploy a service worker. Good luck trying to load anything non-react from that resource/server. I never asked for a web app to work in the background once I cl…

My most delightful experience with a service worker was SVGOMG, https://jakearchibald.github.io/svgomg/ . One time I was without an internet connection, and I thought to myself, “if only it had a service worker so it’d work offline!” and then I opened a tab to it, to remind myself to optimise the SVG I was working with later, and— huh. It loaded. On reflection, I decided that given who Jake Archibald is, it made sens…

I've recently set an offline mail client to sync mail locally for my wife's laptop. Her two gmail accounts downloaded 22GB.

Be careful what offline actually means when it comes to mail; eg. that 22GB as service worker cache sounds a bit nasty to me, especially because service workers don't tend to differentiate between desktop and mobile.

Re: Service Workers

#29

Post by bryanrasmussen »

htor wrote: post #10
pmlnr wrote: post #7

Firefox: about:config dom.serviceWorkers.enabled;false Why: They bite. The generic idea may even be reasonable (offline working web app), but every single time I encounter service workers they make things worse. If you load a React frontend, it'll, by default, deploy a service worker. Good luck trying to load anything non-react from that resource/server. I never asked for a web app to work in the background once I cl…

> That is how the web works. good luck trying to convince google of that. they are shaping the web just the way they want it. push notifications? nobody ever except the marketing apartment thought that was a good idea to add to anything. if we try making everything on the web like mobile apps we're gonna get garbage features like this and false expectations on what the web should be like.

I'm pretty sure that everyone who ever used some sort of messaging application thinks that push notifications are a good idea.
Post reply on HN