1. 45

  2. 28

    To be fair, it’s not just Apple, mostly Mozilla takes a similar approach: https://twitter.com/voxpelli/status/1286230638526435329

    1. 10

      So, we have the browser engine vendors today: Apple with Safari/WebKit, Mozilla with Firefox/Gecko, and Google with Chrome/Blink. Isn’t it kind of weird that so many web standards are being standardized with 2/3 of vendors unwilling to implement them? What’s the process here?

      1. 13

        They are drafts, drafts don’t necessarily get passed to be standards. For an example at hand, Geolocation API is a standard (ratified in 2016). Geolocation Sensor is not, it is a draft (last updated in 2018).

        1. 28

          Aha. From the title and article, it sounded like Apple refuses to implement standard APIs. So the real story is just that Apple and Mozilla won’t let some harmful APIs get standardized.

          1. 25


            1. 2

              Only it doesn’t really matter. Since Chrome is so big, whatever it does is a de-facto standard because Web developers are going to use those APIs, and users are going to blame other browsers for “not working”, which is going to maintain its share because of it.

              1. 9

                I would think that Safari on iPhone has enough market share to force web developers to support it. It would surprise me if a commercial website intentionally disregarded MobileSafari support.

                1. 3

                  They’ll just try to push the users to their mobile apps.

                  1. 3

                    Market share of mobile safari is actually quite poor. It’s usually supported despite the market share, as iPhone users are widely regarded valuable users (e.g., more likely to spend money online)

                    1. 3

                      I think it might also depend on where your customers are–even if iOS is only around 15% of the worldwide smartphone market, it’s 58% of the US, 51% of North America, and 26% of Europe.

                  2. 4

                    So the real story is that Google is using its near-monopoly power to circumvent the standards process? There’s some kind of irony here, but I just can’t tell WHAT.

                    1. 1

                      WHAT was a great force when Mozilla needed to pry the Web from Microsoft. It created a standard on which Firefox and later Chrome could build better browsers than IE and win users over. But then Google got big and took the process over, so here we are.

                      1. 2

                        No disagreement here! But worth pointing out that Mozilla could only make that move because Apple and Opera were backing them. I just think the important things to keep in mind about standards organizations is that they are inherently political, and that those with a seat at the table are generally large corporations who answer only to their shareholders. As such, they should be understood as turf where players jockey for competitive advantage by forming temporary strategic alliances. I think everyone paying attention to these things understands how this works, except for some programmers, who I guess are conditioned to treat even draft standards as holy writ descended directly from the inscrutable heavens, or maybe take the rhetoric about “serving users” a little too literally.

                        But as consolidation erodes consumer choice, there’s less of a game to play, and thus standards become less relevant.

          2. 11

            Looking at the list, it feels like the motivation for many of these APIs is to help close the gap between Chromebooks and other platforms. I can’t understand it otherwise.

            Web MIDI - really? Is there ever going to be a world where music professionals are going to want to work in the web browser instead of in for-purpose software that is designed for high-fidelity low-latency audio?

            1. 7

              For Web MIDI there are some nice uses, for example, Sightreading Training - this site heavily benefits from being able to use a connected MIDI keyboard as a controller, rather than having the user use their regular keyboards as a piano, which is pretty impractica (and limited).

              Another website which uses the Web MIDI API is op1.fun - it uses MIDI to let you try out the sample packs right on the website, without downloading it.

              So no, it’s probably never going to be used for music production, but it’s nice for trying things out.

              1. 17

                Not everything that’s “nice” should be shipped to millions of people, “just in case”.

                1. 8

                  Which is why these APIs should be behind a permission prompt (like the notification or camera APIs). Don’t want it, it stays off, if you want it, you can let only the sites that will actually use it for something good have access.

                  1. 4

                    yeah +1 on this. So many of these things could be behind a permission. It feels really weird to hear a lot of these arguments when we have webcam integration in the browser and its behind a permission. Like one of the most invasive things are already in there and the security model seems to work exceptionally well!

                    The browser is one of the most successful sandboxes ever, so having it be an application platform overall is a Good Thing(TM). There’s still a balance, but “request permission to your MIDI/USB devices” seems to be something that falls into existing interaction patterns just like webcams.

                    Stuff like Battery Status I feel like you would need to offer a stronger justification, but even stuff like Bluetooth LE would be helpful for things like conference attendees not needing to install an app to do some stuff.

                    1. 3

                      I don’t fully understand why webUSB, webMIDI etc permissions are designed the way they are (“grant access to a class of device” rather than “user selects a device when granting access”).

                      I want some sites to be able to use my regular webcam. I don’t want any to have access to my HMD cam/mic because those are for playing VR games and I don’t do that in Firefox.

                      However, Firefox will only offer sites “here’s a list of devices in no particular order; have fun guessing which the user wants, and implement your own UI for choosing between them”.

              2. 6

                Don’t forget Android Go - Google’s strategy of using PWAs to replace traditional Android apps.

                Is there ever going to be a world where music professionals are going to want to work in the web browser instead of in for-purpose software that is designed for high-fidelity low-latency audio?

                Was there ever going to be a world where programmers want to edit code in a browser rather than in a for-purpose editor? Turns out, yes there is, and anyway, what programmers want doesn’t really matter that much.

                1. 3

                  Yes, web MIDI is useful. Novation has online patch editors and librarians for some of their synths, like the Circuit. I’ve seen other unofficial editors and sequencers. And there are some interesting JS-based synths and sample players that work best with a MIDI keyboard.

                  It’s been annoying me for years that Safari doesn’t support MIDI, but I never knew why.

                  MIDI doesn’t carry audio, anyway, just notes and control signals. You’d have the audio from the synth routed to your DAW app, or recording hardware, or just to a mixer if you’re playing live.

                  1. 3

                    Apple’s concern seems to be that WebMIDI is a fringe use-case that would be most popular for finger printing (e.g. figuring out which configuration your OS and sound chipset drivers offer, as an additional bit of information about the system and/or user configuration).

                    I’d love to see such features present but locked away behind user opt-in but then it’s still effort to implement and that where this devolves into a resource allocation problem given all the other things Apple can use Safari developers for.

                    1. 4

                      It’s not just fingerprinting that’s the concern.

                      The WebMIDI standard allows sites to send control signals (SysEx commands to load new patches and firmware updates) to MIDI devices. The concern is that malicious sites may be able to exploit this as an attack vector: take advantage of the fact that MIDI firmware isn’t written in a security conscious way to overwrite some new executable code via a malicious SysEx, and then turn around and use the MIDI device’s direct USB connection to attack the host.

                      1. 1

                        Could this be prevented by making the use of Web MIDI limited to localhost only?

                        1. 2

                          at that point you’re requiring a locally run application (if nothing else a server). In which case you might as well just have a platform app - if nothing else you can use a webengine with additional injected APIs (which things like electron do).

                          1. 2

                            Ok, thanks for your reply.

                      2. 1

                        It may be worth pointing out that Apple also has some incentive to protect its ecosystem of native music apps.

                        1. 1

                          I personally wish there was incentive to make the Music app remember where I was and in which playlist I was in… :-/

                  2. 6

                    Good. We can’t have “random documents I view while pottering around the internet” and “applications I have installed and actually want to have some sort of ongoing relationship with” being the same set of interactions and permissions.

                    1. 5

                      I am puzzled why these even exist. What is the point? To have the browser be an OS?

                      1. 9

                        Yes, the dream of a PWA revolution requires the browser to have access to everything like the underlying OS does but that will never happen because it’s too easy to make malicious PWAs when there’s no central store/authority to police them.

                        I want freedom too, but the world is full of idiots who still click on “your computer is infected” popups and voluntarily install malware.

                        1. 4

                          They exist to allow web pages controlled and sand-boxed access to resources otherwise only available to black-box native apps which also happen to award Apple 30% of their revenue, so me personally, I’m taking that privacy argument with a grain of salt.

                          1. 11

                            Web apps are just as black-box as native apps. It’s not like minified JavaScript or WebAssemly is in any reasonable way comprehensible.

                            1. 8

                              I would somewhat agree if Apple was the only vendor who doesn’t support these APIs, but Mozilla agrees with Apple on this issue. That indicates that there’s some legitimacy to the privacy argument.

                              1. 2

                                The privacy reason seem not too opaque, as the standard way of identifying you is creating an identifier from your browser data. If you have some hardware attached and exposed, it makes identification more reliable, doesn’t it?

                                1. 2

                                  Apple led the way early on in adding APIs to make web apps work like native mobile apps — viewports and scrolling and gesture recognition — and allowing web apps to be added as icons to the home screen.

                                  1. 2

                                    Originally iPhones apps were supposed to be written in html/js only, but then the app store model became a cash cow and that entire idea went down the drain in favor of letting people sharecrop on their platform.

                                    1. 9

                                      I mean, too, the iOS native ecosystem is much, much, much richer and produces much better applications than even the modern web. So, maybe it’s more complicated?

                                      1. 1

                                        Agreed. I think that native apps were the plan all along; progressive-ish web app support was just a stop-gap measure until Apple finalized developer tooling. Also, given that most popular apps (not games) are free and lack in-app purchases, odds are that the App Store isn’t quite as huge of a cash cow as it is made out to be. The current top 10 free apps are TikTok, YouTube, Instagram, Facebook, Facebook Messenger, Snapchat, Cash App, Zoom, Netflix, and Google Maps. The first six make money through advertisements. Cash App (Square) uses transaction fees and charges merchants to accept money with it. Zoom makes money from paid customers. Netflix used to give Apple money but has since required that subscriptions be started from the web (if I remember correctly). Google Maps is free and ad-supported.

                                2. 1

                                  The browser already is an OS. The point of these is to have it be a more capable and competitive OS. Just so happens that at present there’s only one player who really wants that… but they’re a big one, and can throw their weight around.

                                3. 3

                                  I really do wish Apple had gone into a lot more detail about how they specifically think each API could be used to harm user privacy. A lot of people are concerned that Apple has an ulterior motive behind denying to implement these APIs, and providing extensive documentation could alleviate some of that.

                                  In an ideal world, Apple would have proposed alternative APIs to accomplish the same behavior.

                                  1. 4

                                    When I listened to this podcast where a couple of the people on the Safari team spoke, I came away thinking that they were either working on ways that they could implement them without introducing privacy risk, or working toward proposing alternative approaches.

                                    I also came away with the impression that the ad hoc nature of this particular set of standards makes it harder.