nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

back to article
Apple signals it's willing to let next-gen web apps compete with iOS apps

Silver badge

Hope there's a way to disable this

Making it easier for web sites to run shitty scripts in the background that suck up your battery doesn't sound like a good thing to me. Already I'm annoyed by how many pages keep asking me if I want their stupid push notifications, which seems to be the main use of service workers I've observed with Firefox.

Until I started using Noscript, too often Firefox would pop up a dialog about a script running too long and ask me if I wanted to stop it. At least if there were pages that loaded down the browser you could kill that tab and avoid the problem. Now you'll get scripts that aren't owned by a page so you'll have to kill the whole damn browser to fix the problem.

Why does Google want to ruin the web with shit like this?

25
2
Bronze badge

Re: Hope there's a way to disable this

Exactly my concern. It's one thing to have this running on desktop browser (with little regard to power use and vastly more configurability), it's entirely different story to do so in Safari (or Chrome) on mobile device where not only battery life and performance are bottleneck but also there's next to no control over the browser (trust us, it just works mentality). While I like to keep multiple tabs open, I have no intent of them "workers" refreshing the content for no reason other then developers whim.

8
1

Re: Hope there's a way to disable this

Hi, I'm one of the editors of the service worker spec.

By default service workers only allow scripts to run in the background when the site is open. Eg, when you visit a site the service worker script let's the developer handle where that content comes from, which ideally means they can get content on screen without involving the network at all.

Service workers can also run in response to a push message when the site isn't open, but you need to explicitly grant permission for this functionality. Also, the site needs to show a notification when it does this, so if you're unhappy with the number of messages, you're probably also unhappy about the battery use — you can revoke this permission from the notification itself.

8
0
Anonymous Coward

Re: Hope there's a way to disable this

Why does Google want to ruin the web with shit like this?

At a guess because we're getting too good at blocking revenue stream one (ads) and alleged revenue stream two (resale of personal information and/or profiling). Basically they need a new way to subvert end user systems that have been smart enough not to install Chrome and this is it.

Damn Apple for going along with this, now I have to find a new browser which doesn't support it. It's back to Vivaldi, I guess.

7
4
Anonymous Coward

Re: Hope there's a way to disable this

but you need to explicitly grant permission for this functionality

Oh wow - yes, THAT will surely stop any abuse, because our end users are really, really good about not clicking on permissions when they shouldn't. </sarcasm>

if you're unhappy with the number of messages, you're probably also unhappy about the battery use — you can revoke this permission from the notification itself.

I don't even want it enabled, so I'm hoping any browser comes with an option to not bother downloading the code. I am feeling like we're starting the whole popup circus once again, but I guess it fits right in with all the other idiocy in the world like Trump, and Brexit.

Is this just a plot to drive more people to the first flight to Mars?

7
1
Silver badge

@Jake Archibald

When you say "only allow scripts to run in the background when the site is open" do you mean if the tab is open anywhere, or only if the tab is selected and in focus? If the latter, that's great. If the former, that's not much help for those of us who like to keep 50+ tabs loaded on our desktop (and usually about a half dozen on my iPhone)

7
0
TVU
Bronze badge

Re: Hope there's a way to disable this

"At a guess because we're getting too good at blocking revenue stream one (ads) and alleged revenue stream two (resale of personal information and/or profiling)".

...and we're only doing this because the ads have become too large, loud, intrusive and self starting. It's 100% the fault of advertisers for being far too aggressive in the first place and if they change their rotten behaviour then adblocking should start to decrease (I don't mind non-intrusive ads, for example).

2
0

Re: Hope there's a way to disable this

If you don't want it enabled, don't enable it. If you enable it by accident, you can revoke it in site settings, or in any notification you get. It's that simple.

3
0

Re: @Jake Archibald

If you have a tab open, it can already run code, so being able to run code in the background doesn't really make any difference.

On mobile, tabs are unloaded, although their UI remains. In this case, background code can't run either.

The exception here is push messages, but they're behind a user permission. For a messaging app, this means a push message can be delivered, which runs the service worker, executes for a short time, shows a notification, then goes away. Compare this to what happens today: the tab stays awake holding open a constant web socket. In this case the service worker is much kinder to system resources.

1
0

Re: Hope there's a way to disable this

Service Worker background scripts are VERY limited in scope, and can't just quietly sit in the background mining bitcoins- the browser is supposed to kill them dead if they execute too long. Like any browser feature, if you don't like service workers in chrome, disable them in chrome://settings. I am sure Apple will provide a similar option. In general, judicious implementation of PWAs should *decrease* your battery and network consumption over standard browsing (things like the fetch API provides a customisable transparent network cache for the app, and the ability to drop offline in crap network conditions where you would traditionally be re-transmitting corrupt packets).

Surely, service workers are far, FAR less of an attack surface than visiting a site, downloading their freaking binary from an app store with myriad more ways to punch into the kernel, which is the current state of affairs. All that for yet another glorified RSS reader. End users don't even think twice about doing this, and they have moved potentially malicious code through the bulkhead of a browser sandbox, and into a direct user space process.

Unfortunately I agree, the way many sites are adopting service workers is simply to nag you with push notifications, but 90% of the web is shit, and this is just another example of it being shit. Don't like being bugged to install push notifications on a site? Don't visit that site... Long term PWA provide scope for moving beyond Apple's walled garden iTunes store, where Apple skim 30% of *all* sales through your app, and will pull your product from the app store because it mentions there is an Android version.

Sure, like all technology there will be security issues discovered, but just like WebGL when everyone was losing their shit and Microsoft claimed it was far to insecure to implement, fast forward five years and every major browser (even Microsoft's) has an implementation and there hasn't been a string of exploits for WebGL subsystems released every other month like we had with Flash and Java.

1
0

Re: @Jake Archibald

If you have 50+ tabs loaded on your desktop every single one can be running setInterval scripts and chewing up your CPU and battery. This is true for iPhone or desktop, so that isn't really any different than now. Lots of tabs open is still lots of tabs open. And lots of sites are written by idiots. Sadly there is no W3C working group for making people write less shitty code.

0
0

We've been working with Safari engineers for years on the spec, but now they're being public about implementing.

Some Safari engineers joked that although developers want service workers in Safari, no one had filed an issue… so I did.

It didn't really get the ball rolling though, they were very much aware of it already.

It's very exciting though! It's currently difficult to convince developers to build fast network-resilient sites because they, in turn, can't convince mangers to let them spend time on stuff that won't impact iOS Safari. Good to see that changing.

1
0
Anonymous Coward

Well, I'm NOT excited about it because it represents yet another opportunity for drive-by infections on the web and the last thing I need is something added that happens in the BACKground. At the moment, hiding activity takes at least some effort but making this available you are encouraging management idiots that have no clue about security to mandate the development of essential services using this facility and so make it impossible to fully disable it on machines as it should. It's bad enough that some utilities only offer a customer interface through social media, now this.

I'm not impressed. Just when we thought we had at least *some* handle on online idiocy.

6
4
Silver badge

We need a toggle!

Yep. If any Safari devs are reading this, please give iOS a toggle to disable service workers entirely when you add support!

If the damn things do become useful on a few sites eventually, we'll need some sort of NoScript style plugin that lets us whitelist sites we'll allow to use service workers. Because it seems pretty likely they'll mostly be used for advertising and malware. Just like Javascript and Flash, in other words.

Most of the time people coming up with new specs spend too much time thinking about all the cool things that can be done with new capabilities, and not nearly enough thinking about how to prevent the bad.

7
0
Silver badge
Happy

Re: We need a toggle!

Doug, what particular capabilities of the web do you think have NOT been tainted? Got a list?

Okay okay, this web worker stuff will be "misused," by demons in human form, no doubt. But that's not the WW's purpose for existing. Web Workers are just a browser coding capability, like html and css and javascript and ajax and so on. The philosophy of the spec writers has always been enhance those capabilities generally, without trying to second guess the future too much. It's been a spectacular success (mostly).

It's hard to tell what methods and enhancements will eventually be accepted as "the best way" until it happens. So don't whinge so much about possible downsides that haven't happened yet. So far most of it's been up, as far as I can see. Heck, I make my living off it! :)

2
1

Re: We need a toggle!

Security has been paramount when developing the feature. If you've discovered an attack this enables, please share it.

4
0
Flame

Flash is dying long live the new flash

It needs to die now before it gets out in the wild

4
0
Anonymous Coward

App service workers

iOS doesn't even do those yet, something android has done from the outset.

My DSLR is a doddle to use on android (just send a bunch of pictures and the service receives the request, opens the app and receives the pictures), but a headache on iOS, as I have to open up the app and prepare to receive pictures manually, as it doesn't do services properly on iOS.

1
1
Silver badge

Actually a good thing

Bad apps run your battery dead and ruin privacy just fine with old tech, so this isn't making existing problems any worse. Don't use bad apps. What it does allow is faster UI interaction, fewer network round trips, and greatly reduced costs for the app provider. There's an opportunity to use less cellular data (which is very power hungry), apps no longer need to be installed for trials and casual use, and apps might get cheaper.

3
2
Anonymous Coward

Re: Actually a good thing

Yeah, because everyone knows apps are too expensive and need to get cheaper.

1
1
Anonymous Coward

I love Apple.

0
1

* its

0
0

Aren't push notifications a good thing?

Detractors of push notifications in this thread seem to suggest they're devoid of major benefit. I'd like to propose a benefit, and since I've never used an iPad, I welcome corrections if I'm wrong.

Suppose we have an authoring tool for a web app. ('Google docs' is the best known example.) Today on iOS you can already use Google Drive and save files off-line, even on iOS.

But using Push notifications, your saved files should be able to sync with the server automatically when network access is recovered, even if you've left the website and even if you've closed the browser by that time. Isn't that right... and damned useful?

0
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing