4 ms·

I don't buy Mozilla's/Apple's concerns for those APIs. Sure if seems sketch to access USB from the web, but as a user if I'm trying to achieve something and I

I don't buy Mozilla's/Apple's concerns for those APIs. 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.

admax88q 5y ago
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
dmitriid 5y ago
> 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. 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.
- admax88q 5y ago
  The fewer features the browser has, the more code ends up as native apps or on cloud backends instead of the user's device. 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.
  - dmitriid 5y ago
    > But there's room for thoughtful implementation of these features that users want. 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.
    - admax88q 5y ago
      There is a rush to implement stuff though. The demand for functionality continues to grow, and if the platform stagnates developers and therefore users will move to other platforms. 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.
cesarb 5y ago
> I don't buy Mozilla's/Apple's concerns for those APIs. 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. 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.
- admax88q 5y ago
  How is giving up on achieving something a win for users?

admax88q 5y ago

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

dmitriid 5y ago

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

admax88q 5y ago
The fewer features the browser has, the more code ends up as native apps or on cloud backends instead of the user's device. 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.
- dmitriid 5y ago
  > But there's room for thoughtful implementation of these features that users want. 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.
  - admax88q 5y ago
    There is a rush to implement stuff though. The demand for functionality continues to grow, and if the platform stagnates developers and therefore users will move to other platforms. 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.

cesarb 5y ago

> I don't buy Mozilla's/Apple's concerns for those APIs. 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. 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.

admax88q 5y ago
How is giving up on achieving something a win for users?