Apple's opinions are simple: If they have a good browser, then the app store - their cash cow - becomes unneeded.
And these days more often than not Mozilla (which has no stakes in either apps or online advertisement) sides with Apple: https://webapicontroversy.com
Sure if seems sketch to access USB from the web, but as a user if I'm trying to achieve something and I can't do it on the web, I'll end up installing a native app which has way more access to my system.
As a developer I would much rather be able to just deploy cool things on the web instead of having to package up native apps for every platform just to do things like read/write NFC tags, or send notifications to users who want them.
There's a third possibility: that you give up achieving that something. The "activation energy" of installing an app is higher than loading a website, so if the user's desire for achieving that something is not strong enough, the native app won't be installed.
And besides, most users know (or should know) that installing apps can be risky, while a website is supposed to be sandboxed. That is, absent exploitable browser implementation bugs, going to any website should be safe.
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.
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.
It's like taking a room, and refusing to add a back door for "security" when the front door already exists.
Besides, it's quite possible that the hole in WebPush does not allow for some/many scenarios that a background sync would.
Yes, they will. So the question remains: why expand the hole?
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.
> 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.
This is not an argument to just go ahead and implement WebUSB/Bleutooth/Serial/whatever.
> As a developer I would much rather be able to just deploy cool things
Ah yes. It would so very nice if we could just trust all developers to not be malicious actors.
How many IoT devices could have just used bluetooth for interactive with them, but instead they all phone home to some central cloud server because the user experience of just hitting a web page is better than installing some clunky native app.
Should we "just go ahead" and expose everything? Of course not. But there's room for thoughtful implementation of these features that users want. A super secure platform that nobody uses provides security to no one.
Yes, there is. And that's exactly the position of both Firefox and Safari: don't rush in and implement stuff just because you can.
It needs to be thoughtful, but the firefox position appears to be that web apps have no business accessing bluetooth or usb. Which as I explained earlier leads to user installing clunky native apps to interact with their bluetooth/usb gadgets, or the gadgets being deployed with phone home functionality so that user can still access them through a web portal.
If firefox wishes to remain relevant they're going to have to implement the things that developers and users want. Nobody wants a dumb document browser anymore, that ship has sailed. Browsers are a ubiquitous application platform.