4 ms·

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

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.

dmitriid 5y ago
> 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.
- admax88q 5y ago
  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.
  - dmitriid 5y ago
    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.
    - admax88q 5y ago
      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.
      - dmitriid 5y ago
        > 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?
        admax88q 5y ago
        Because it makes no difference if the hole is small or large. To an attacker its the same size.
        dmitriid 5y ago
        It does make the difference. You don't deliberately increase the surface of attack if you can help it.
        admax88q 5y ago
        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.
        admax88q 5y ago
        s/atitides/platitudes

dmitriid 5y ago

> 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.

admax88q 5y ago
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.
- dmitriid 5y ago
  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.
  - admax88q 5y ago
    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.
    - dmitriid 5y ago
      > 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?
      - admax88q 5y ago
        Because it makes no difference if the hole is small or large. To an attacker its the same size.
        dmitriid 5y ago
        It does make the difference. You don't deliberately increase the surface of attack if you can help it.
        admax88q 5y ago
        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.
        admax88q 5y ago
        s/atitides/platitudes