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

> 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

Besides, I know they want to turn the browser into an os, but it's not one.

It's sandboxed from the os and limited to some use cases, which is the point. I don't want something capable of hot loading code from any web site to have the capabilities of my OS.

I wonder if and when the splitup will happen between the "text" web and "app" web.

I know you can disable Javascript, but this is still different.

What would Hacker News be? How about email apps such as Gmail or Yahoo mail?

There are email clients.

There are. I used Eudora up to 2005. Incidentally, I can't look at my email history before 2005, because, you know... formats become obsolete, hard drives die, etc.

Do those clients work on my mac, my chromebook, my windows box, and my android phone?

Call me crazy, but I prefer web apps for that kind of stuff. I'm also glad I don't have to download an app to use Hacker News.

As an independent developer, I am quite pleased that I can target one platform, the web, without having to deal with all the mess of multiple native apps, and worry that people won't run my simple app because they don't trust me not to delete their hard drive, and so on.

>Do those clients work on my mac, my chromebook, my windows box, and my android phone?

Yes.

>Call me crazy, but I prefer web apps for that kind of stuff. I'm also glad I don't have to download an app to use Hacker News.

Web means HTTP, Email is POP3/SMTP/IMAP. Different protocol, different programs. That you can use a website to view and send emails is not the default case and is merely a interface to those protocols.

I understand how email works. "Default case" is a matter of interpretation. Most people today use web based email (at least on computers as opposed to mobile devices), and it is much easier for most people to set up and get working than using a native client. The vast majority never think about wire protocols. I have implemented both HTTP and SMTP in C etc back in the day, but that is not relevant here.

Regardless, I said my preference is to use web based email, that's all.

It's not about how people use it, the RFCs are clear on this.

What's "it"? "The relevant issue"?

Because the relevant issue is most certainly how people use it. People use web browsers to read their email. Why is what the RFCs say important to this?