Most active commenters

    ←back to thread

    Apple declined to implement 16 Web APIs in Safari due to privacy concerns

    (www.zdnet.com)
    428 points coronadisaster | 13 comments | 29 Jun 20 10:16 UTC | HN request time: 1.264s | source | bottom
    Show context
    jamesgeck0 ◴[29 Jun 20 16:27 UTC] No.23679063[source]▶
    > Web MIDI API - Allows websites to enumerate, manipulate and access MIDI devices.

    This API is actually a bit horrifying from a security perspective. In addition to allowing you to use MIDI keyboards as input devices on websites, it also allows websites to send binary firmware updates to MIDI devices. The reason is that it's common to use custom firmware to backup/restore settings and enable neat effects and functionality on MIDI devices.

    Mozilla's engineers have reasonably pointed out that an attacker utilizing Web MIDI could use MIDI devices as a stepping stone to launch an attack against the user's PC outside of the web sandbox. One such attack might be by reprogramming the device to appear as a standard USB computer keyboard and "typing" commands to the host.

    At least one well known manufacturer has vouched for the technical safety of their musical instruments, noting that they're physically designed in such a way that the MIDI firmware can't alter USB firmware. But there's no way to know that every MIDI device has been similarly well designed.

    As neat as Web MIDI is, I think Mozilla and Apple probably made the right security call here.

    https://github.com/mozilla/standards-positions/issues/58

    replies(11): >>23679155 #>>23679165 #>>23679283 #>>23679303 #>>23679633 #>>23680706 #>>23681158 #>>23681737 #>>23682770 #>>23683437 #>>23683855 #
    1. alerighi ◴[29 Jun 20 18:30 UTC] No.23680706[source]▶
    What is the problem if the user give the permission to do so?

    I don't get this let's not allow this web api because it's dangerous, well you only move the problem to an application that the user installs on his PC.

    If the permission mechanism is correct there is no danger, a web applcation wants to access my MIDI interface or my USB or Bluetooth or whatever and it can. Isn't the same for mobile applications and permission?

    So maybe and I say maybe we could stop having to ship an entire Chromium engine with Elecron just for a web application to access devices or files on the computer.

    replies(2): >>23680761 #>>23681442 #
    2. oneplane ◴[29 Jun 20 18:35 UTC] No.23680761[source]▶
    Because users are users and they win inevitably do the wrong thing. Normally not such a big deal, but with the interconnected world a compromised user is a big problem. It's used as a stepping stone to compromise others, cause problems to other systems by using them as slaves in a botnet or simply using them to send spam.

    Users need to be protected against themselves as long as they can't take responsibility for their actions.

    replies(1): >>23681453 #
    3. Jonnax ◴[29 Jun 20 19:22 UTC] No.23681442[source]▶
    Because people don't expect their web browser to be able to brick their hardware.
    replies(2): >>23681558 #>>23688000 #
    4. evv ◴[29 Jun 20 19:24 UTC] No.23681453[source]▶
    If the user is going to be tricked on the web, they can be tricked in other ways. If the web doesn't support MIDI, users will just download MIDI malware as an app.

    By your logic, the web should not have video support either, because users are users and it will inevitably be misused.

    If you were serious about addressing this: We need clear and robust and granular permission dialogs on web and native apps. Ideally they'd be consistent across web/native, which would help users trust their software, and understand the permissions they give.

    replies(1): >>23682532 #
    5. searchableguy ◴[29 Jun 20 19:32 UTC] No.23681558[source]▶
    Then change the expectations. Native apps aren't much better as far as privacy goes. Users should absolutely verify everything they use.
    replies(3): >>23681898 #>>23682137 #>>23682258 #
    6. dkersten ◴[29 Jun 20 19:56 UTC] No.23681898{3}[source]▶
    Sure but for a long time web has been touted (rightly or wrongly) as this safe sandboxed convenient distribution platform. The expectation is very much still that a website shouldn’t be able to harm your computer and that expectation isn’t going to change any time soon.

    In top of that, less technically inclined people don’t even expect native applications to be able to harm their computer and we haven’t been able to change that expectation.

    7. ppeetteerr ◴[29 Jun 20 20:11 UTC] No.23682137{3}[source]▶
    Native apps go through an approval process
    replies(1): >>23682364 #
    8. _trampeltier ◴[29 Jun 20 20:18 UTC] No.23682258{3}[source]▶
    That's why I have almost no Apps on my phone. Just a lot of different browsers. I think the new mobile Vivaldi browser is the first with an option to switch of the 3d sensor for the website
    9. edoceo ◴[29 Jun 20 20:24 UTC] No.23682364{4}[source]▶
    Correction: some native apps on some platforms
    replies(1): >>23683576 #
    10. mavhc ◴[29 Jun 20 20:33 UTC] No.23682532{3}[source]▶
    And then we need to crowd source what the default should be for each site, because otherwise every site will have 100 permission popups
    replies(1): >>23683578 #
    11. danudey ◴[29 Jun 20 21:47 UTC] No.23683576{5}[source]▶
    Correction: Native apps on the platform this thread is about.
    12. forgotmypw17 ◴[29 Jun 20 21:47 UTC] No.23683578{4}[source]▶
    Couldn't we hide the rarely used features behind a checkbox in advanced settings?
    13. om2 ◴[30 Jun 20 08:35 UTC] No.23688000[source]▶
    Not only brick the attached device, but also potentially fully compromise either the attached device or the device you are on. It doesn't seem responsible to put that kind of tis behind a permission dialog. Users are not in a position to make the judgment. The web should have a higher standard of security and privacy.