Comment by admax88q | Hacker News Reader

Comment by admax88q | Hacker News Reader

Parent Full thread

Take Background Sync for example.

Mozilla considers the periodic sync API "harmful" because you could use it to track users IP and consumer resources when it's not clear they're interacting with the site

Their stated position:

> We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed, however, addressing them for periodic background sync appears substantially harder than doing so for one-off background sync.

But you could achieve very similar behaviour by using Web Push (which they _have_ implemented) and just sending periodic push message. So now as an honest web developer if I want nice background sync behaviour I have to implement some Rube Goldberg system of periodic push messages from a backend rather than just asking the system to wake me up every now and then.

> But you could achieve very similar behaviour by using Web Push

The fact that something was implemented, shipped, and has security/privacy hole is not an argument to implement and ship something else with a similar hole.

If the hole exists and is not going to be closed, why refuse to add other useful features that use the same hole?

It's like taking a room, and refusing to add a back door for "security" when the front door already exists.

Why expand the surface are of the hole?

Besides, it's quite possible that the hole in WebPush does not allow for some/many scenarios that a background sync would.

Because if the hole exists at all, malicious actors will find a way to abuse it. But if non malicious developers have to jump through too many hoops to provide useful functionality to users they will just give up and users lose out.

> Because if the hole exists at all, malicious actors will find a way to abuse it.

Yes, they will. So the question remains: why expand the hole?

Because it makes no difference if the hole is small or large. To an attacker its the same size.

It does make the difference. You don't deliberately increase the surface of attack if you can help it.

I feel like your speaking in atitides, but not looking at this situation specifically.

If I can unlock your computer with your password or with the word "hello" and you have no intention of removing the "hello" feature, would you not agree that we might as well remove the password entirely?

How do we increase the attack surface of service workers by adding background sync, when we can get nearly identical behaviour using push?

If you goal is purely to not increase the attack surface, you might as well never add any new APIs ever.

s/atitides/platitudes

If you're going down the analogies rabbit hole: let's say your front door is unlocked. Should you then just open all your windows because, you know, everyone already has access to your house?

> when we can get nearly identical behaviour using push?

The devil is in the details: is it nearly identical behaviour? How nearly is it identical? I personally don't know.

One wakes up the background page on a timer, the other wakes it up based upon a external controllable trigger. It's trivial to fire that external trigger based upon a timer.

Reply on news.ycombinator.com