> 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.
Fun fact: for quite a long time Chrome skipped over the user permission step in the Web MIDI spec, always allowing access and silently giving ad networks a list of connected USB MIDI devices with no user consent:
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.
It's kind of sad though because it's still 10X easier to build a browser app than a native app simply because of the wealth of highly-usable stuff written for JS.
Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.
Android programming is another can of worms and I'm frankly fed up with Gradle updates breaking my project every update and needing 79+ files, multiple cludgy steps for signing APKs, zipalign (wtf) and other crap just for a Hello World.
What would be nice to have is "installable" apps that use the webkit rendering engine but have full access to the system including directly opening TCP ports and direct access to /dev. These would have to be trusted apps obviously. Websites that load code without consent should be restricted, of course.
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.
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.
One point not discussed here is by relying so much on app store and apple's walled garden, what do you do when china or other country ask apple to remove certain apps?
Bypassing geo block on websites is easy and there isn't a single source of truth on the web like app store is for the users. Can apple explain why they took down apps on the request of china in HK and how do you think that will play out when no web apps can work reliably on apple devices?
Censorship is a huge problem for app stores. They censor anything sexual but sexuality is part of human nature. They censor anything politically charged but it's part of human nature too. I hope the anti trust fine plays out.
Apple can protect the privacy of people by making it harder for them to be vulnerable by choice. People here point towards stupid users when saying that a normal user won't be able to connect usb and enable a feature. Why can't the same happen with browsers or apps on ios? Why the $99 fee just to side load apps? Why the need for a mac?
Just admit it's for profit seeking reasons. Ads in your app store are a proof of that.
It's still possible to partially implement it while keeping it safe by excluding sysex messages. Probably more than 90% of the end users will never need sysex messages so why bother?
I'm curious now that I read this, this means that web midi can access the virtual midi devices created under alsa on linux also? Which means if you have it routed to other software using Jack or aconnect, websites could send midi notes directly into whatever software your midi device is routed through?
So theoretically then, could a Jack aware payload be created that runs in the background, say disguised as a vst or ladspa plugin and when a user browses a malicious site, this site could, recognize the malicious midi device, create connections to other software and gain access through possible buffer overflows or other things?
It seems like a stream of midi notes could itself possibly cause a buffer overflow in certain programs. Muse and rosegarden are a bit buggy as is and frequently crash for me. From what i can tell there's a lot of midi aware audio software that likely contains a bunch of avenues for exploits and when you throw virtual midi devices into the mix capable of doing far more than hardware midi devices...
I don't see why the API should even allow enumerating devices. Put that behind a browser dialog. Webpages don't get to enumerate directories/files on your system - they pop up a file picker dialog. The same should happen with device selection. Once you've granted the site access to a device, it can ask you to associate a name with the handle, and provide whatever shiny device selection / device management UI it wants.
Better yet, reasonably abstract the raw MIDI protocol away with something that has suitable security and privacy properties for the web, and translate it to MIDI on the host. In any case, the current proposal does not seem to cut it.
I agree that it would be nice to have a limited amount of the Web MIDI spec, but bear in mind the staggering few people who actually have MIDI devices, and the even more staggering few of those people who want to use whatever website has midi support for its features.
To answer your question about why not to just limit the API: because that would be another data point to use to fingerprint users, and because the amount of engineering time that would have to go into Web MIDI support (including testing, security auditing, etc.) would never be worthwhile compared to putting those same developers on something that might be beneficial to vastly more users.
(Also note that Firefox made the same decision to implement nothing at all.)
Yeah. It's crazy to me that they haven't decided to create some abstract virtual midi instrument.
That you can instruct the browser to pass through to your devices.
It's a shame, but it proves just what a futile affair it is to retrofit ancient protocols that never had to consider host security. Especially because MIDI is so elegantly simple!
Sending binary firmware updates (sysex) is not a necessary part of the API... they don't have to implement that, and if they do, they can ask for additional permissions.
Allowing you to use a keyboard as an input device is incredibly powerful, and even that can be handled much as camera and microphone is: you give the site permission.
If you get the MIDI device to act as a keyboard it’s not for typing things in the browser but in the OS... you are out of the sandbox so it’s possible to download and install any payload.
There may be some legitimate fingerprinting concenrs. But given the list of API's it's hard not to see this as Apple crippling PWAs to prevent them from replacing native iOS apps (and hurting Apple's revenue from the Apple tax).
And maybe I'm missing something, but wouldn't the fingerprinting concern be mitigated by the fact the app has to ask for permission before using the API? If an app that doesn't have to do with MIDI asks for permission to use my MIDI device, I'm going to be instantly suspicious.
Exactly. This is about making sure web apps are not as powerful as native apps.
One thing is the revenue generated by the App Store but suppose JavaScript web apps were just as powerful and well integrated as native apps; then why use native apps at all? Why have an App Store at all? Why have a Mac or an iPhone if any device with a modern web browser would do?
When Huawei tried to create their alternative to Android. The big thing missing wasn't the hardware or the operation system. It was the App Store with your map app, your banking app, your scooter app and so on.
The App Store and the proprietary development platforms for Android and Apple has become a way to keep their duopoly in place.
I like having apps that work and feel the same. I can bring my knowledge from one app to another. I can develop expertise on a platform. The web is culturally unable to do that.
Look at a sophisticated web app, like Google Docs. This has a menu bar, which is a bad copy of the native Mac menu bar. Web apps are copying native app conventions, to try to be more familiar. But they're also eroding those conventions.
Eventually only click and swipe will be left. And this problem is not going to be solved by Web MIDI or whatever.
Do you honestly think that Apple would lose enough money by implementing Web MIDI for Safari on iOS that this would be even the most remote consideration? Like, the Safari team was in a meeting about Web MIDI and some manager said "but think of the impact on our stock options!" and they all went "oooooh" and scrapped it?
Or is it that Tim Cook was looking at Apple's balance sheet and decided that they couldn't afford to lose the 30% cut of all the MIDI-capable iOS/iPadOS apps that could be completely replaced by a web app?
The reality is that the real cost of this feature to them would be developer time; it would be a colossal waste of their limited WebKit/Safari developer resources to implement Web MIDI rather than something that would actually be used by more than a scant sliver of a percentage of Safari users.
apple fanboys will accept anything from apple. No headphone jack? it's an improvement! w3 spec not implemented? they are working on more important features! antenna stops working if you hold the phone wrong? I like it that way!
> If an app that doesn't have to do with MIDI asks for permission to use my MIDI device, I'm going to be instantly suspicious.
Sure, you'll be suspicious, but I seriously doubt you're the average user. I bet a very large proportion of Safari users have no idea what a MIDI device is and some significant portion of them wouldn't think twice about granting those permissions.
Are you all serious about this ask for permission thing? Good luck explaining MIDI, HID, NFC and so on to the average Joe, in a small popup. We already have enough “I agree” buttons popping over the screen. Web should be built for everybody, it’s not the nineties anymore.
Sorry, but Average Joe needs to learn this one thing to adapt to the modern web:
Say no.
Average Joe doesn't need to learn what all these things are. In the unlikely event he knows what the thing is and knows that he wants it, he can answer yes. But his default response needs to be no.
Sure, but Apple could solve that by requiring a user action to show that popup dialog. Or they could even block everything by default and force you to give permissions manually. That way average Joe is blisfully unaware of anything and completely safe while you just have to suffer a minor inconvenience of whitelisting that one legit website the first time you use it.
I don’t even want these 16 api’s. I want a way to do notifications and a way to store more than 50 mb on ios. Sure, make me and the user jump through hoops to make sure I’m not abusive, but with those two there are a ton of apps which I can build as pwa’s.
The app clips feature they showed? That should have been a qr code triggered pwa with notifications, except everybody had to build it as an app because they couldn’t do notifications, and then apple used the cumbersome nature of those apps as the reason for app clips. It’s the snake eating its own tail, and I’m getting IE6 vibes because microsoft also strategically stopped improving IE for web apps because they wanted to push app developers to native because of the improved user experience. Yeah, the web is worse, but worse is better.
Apple is a corporation listed on a US exchange, an entity where the only motivation is to generate profit for shareholders. It helps for corporations to frame business decisions in moral terms. If Apple cares about privacy, it is only because there is alignment with profit. If Apple cares about locking out APIs that disrupt their App Store profit, it doesn't hurt to frame the decision in privacy terms.
Currently my desire for both privacy, convenience, and usability align with Apple's current business decisions, so I choose iPhone. When Apple pivots to a new business model, I'll find the best compromise product.
I disagree strongly. Apple leaves money on the table by not aggressively tracking its users. And their investment in e.g. accessibility is certainly not driven by bottom-line considerations.
Apple is relevant today because they actually are focused on products, not profits. Sometimes it really is that simple.
Every time I see this argument I have the same question. How many successful web apps are there for Android? Apps that make the most money on the App Store are free to play games with in app purchases of loot boxe, coins, etc. how many of those are feasible on the web?
On the other hand, which apps that make money via in app purchases would be viable and successful as web apps?
I think most would be as successful IF they had an equally frictionless payment system. Big hits like Candy Crush could easily be built as a web app. These are not pushing the boundaries of software, they're just exploiting our psychology.
counterpoint to that argument: if you want to create an app that runs on both Apple and Android products, and you know that Apple doesn't support the progressive web app specification, why would you waste your time? It makes more sense to use a cross-platform development tool and release on the app store when one of the two big software platforms doesn't support the spec.
PWA's have always lagged behind Native Capabilities, even when API's exist the performance has been poor for high performance apps so the allegation doesn't quite make sense to me.
Google's developer relations team have done a good job convincing web devs that those APIs are pushed by Google to enable "Amazing PWAs", yet we haven't seen them used by any major app. People are choosing to download native apps for more sophisticated applications.
However Google is pushing those APIs because they know tracking people without cookies in future is a big challenge for them and they need new ways of tracking people.
So sad that Google has taken over the web. From the most used browser (Chrome) to the content hijacking (AMP) to the standards (PWA). All to sell you to advertisers.
On Android you can use web apps in Firefox, with content blocking powered by uBlock Origin and Privacy Badger. This is because Android allows real Firefox, engine and all and Firefox implements the web push API.
This gives you unmatched privacy. As I've said elsewhere too, see this Facebook page listing apps that share data with them via FB's SDK and marvel at how privacy friendly your iOS device really is:
If PWAs die, we will be struck with this duopoly in smartphone OS for foreseeable future as native apps are the ones which help them retain their position.
If we want upcoming pure Linux smartphone OS, Sailfish or any other platform which protect the mobile computing from becoming proprietary; we need web apps & PWAs to grow and capture significant market.
Apple's treatment towards PWAs has been well known as PWAs are the only threat for its Appstore monopoly in iOS.
From a developer's point of view, I can see the value in PWAs (for them), but as an end user, I really don't see the benefit of PWAs over native apps. The UX is almost always severely degraded when compared to their native counterparts (even if the feature set is ostensibly identical). Why would I use a Twitter PWA, when the native app provides a much better UX?
Name three PWA apps please. I know I've built two PWA POC some time ago (using service workers and Notification API), but I've never use any PWA in the wild.
> However Google is pushing those APIs because they know tracking people without cookies in future is a big challenge for them and they need new ways of tracking people.
Why would it be? They have the search data, they know what you clicked on, they have GA on 60-80% of sites, they have plenty of information, tracking and profiling users isn't the issue. Tracking and profiling users legally is what's hard.
You have to build these APIs before people use them, and a lot of what Google has been building into Chrome is stuff native apps can do, so the use-case is clearly there.
IMO native apps are capable of far more invasive privacy violations than the web is. But for some reason they're given a very free pass by comparison.
Native apps are not handling my bank account passwords. They're also not collecting data about my consumer behavior with the goal of displaying more ads. This is a big difference.
Well, because native apps are intended to be trusted. They do not have a motivation to invade your privacy: proprietary apps are usually paid upfront and risk their future clients, open source can be inspected.
Instead, the overwhelming web business model is "free to use" (akin to f2p in games). That means ads and other monetization side channels become the priority of the app, not the app itself.
And that is for trusted web apps. Let's not even talk about the fact that you are executing random code every time you visit any webpage. That just does not happen with native apps.
Never trust what they say, Google is known to offer so called "free" services for your good, ultimately people realize they are paying with their private data.
Interesting thought. I wonder if there's a genuine threat of google "AMP-ifying" PWAs. And by that, I essentially mean Google using their properties to exert control over PWAs, just as they have with web articles and other content. Given Google's virtual stronghold over the web, I'd assume so.
I’ve heard so many people complain on HN about Safari’s lack of support for APIs. Before now, we didn’t have a public justification why Apple refused to implement them. Now we know.
The price of a Safari user in the ad market is going down, and it’s exactly what should be happening. I’m very happy with Apple.
You can implement these APIs while at the same time requiring explicit permission from the user before a web application can use them. This preserves privacy while also giving users the option to have much more powerful web applications.
Apple doesn't want to implement these APIs because currently if you want access to these things on iOS, you need to go through their walled garden App Store, where they get a big chunk of any revenue you might make on such a service and can nerf competitors and all the other anti-competitive stuff they're doing.
Except on the long term that would have no effect in empowering users. We all know that when faced with a deluge of permission requests, or pressured by the fact that enough people have already accepted and it's the entry price to collaborate, people will just hit accept and be done with it.
They only need to get the foot in the door and then you'll find that plenty of stuff ends up conditioned on you giving them access. Every one of these APIs is a Trojan horse. Past experience just proves that they will be hijacked for purposes that don't do the user any favors.
Look no further than JS which is there to enrich the web to benefit users but 99% of it is garbage slid under the door to benefit site owners. That's because plenty of things that should work just fine without it are now tied into it, disable JS and the site experience breaks.
I don't want random web sites I open (and their ads) to ask permission to scan bluetooth in my area and use usb devices connected to my computer. A website has no business doing any of that. There is no justification for these API to exist.
I've seen Apple get away with this bad monopolistic behavior through hypocrisy more and more.
Apple is denying people their real rights to install whatever they want in their own machines, forcing everything to go through their app store, where they have the last word of who can or cannot distribute software to the platforms they have created.
They know that if they use the common "we are thinking of your well being" their customers and fans will just believe they are a good-willing company with no other interests than their users safety and well being.
I don't know why the majority of the crowd here in HN, who use to be so harsh in pointing out this kind of behavior in companies like Google and Microsoft, have this blindness with everything that has to do with Apple.
It will worth nothing, if after have defeated this beast with GNU, Linux, the Web, open software revolution, etc.. we end up not protecting what we have achieved so far, because somehow one company trying to secure their profits and its position in the market, get away with behaviors that can ultimately destroy the culture of freedom, open-source software and ultimately, digital rights, which our legislators are not prepared to defend, really understanding the threats and the dire future they represent if we dont uncover the true intentions behind this BS.
Recently I’ve seen a jump in the number of random sites popping up a “this site wants to access VR hardware” dialogs in FireFox; news articles nothing to do with VR or visualisation. I don’t have any VR devices.
How do you do this bit “requiring explicit permission from the user before a web application can use them” without the fallout of “its just a hundred thousand popups and you’re done!” on every page?
I sympathise with the walled garden App Store argument. I hate it that Apple keep such a tight grip on the application distribution channel. At the same time, I really hate the trend where browsers are operating systems and I use native apps whenever possible.
Apple has the ability to put every submitted app through rigorous analysis before publication on the App Store to look for forbidden behavior, in order to protect their customers. They don't have that ability with arbitrary websites.
Firefox doesn't support them either. Most of these are implemented on Chromium, for Google's ChromeOS primarily.
They're kinda useless for web browsers, but people see them in Chromium and believe they must be there for a reason other than ChromeOS. Apple and Firefox are doing it right. These things don't have a place in browsers.
They didn’t mention the biggest one that people (including me) complain about, which is the push notification API. That’s intellectually honest of them (it inherently requires explicit permission before activating for a particular origin), but pointing to these far less likely to be used APIs is not making a good case for neutering PWAs on privacy grounds.
Safari already implements API that leaks enough information to uniquely fingerprint a device.
For instance, the Audio API. You can test it using OpenWPM [1][2] and you will get the same ID in both normal and incognito mode. And this is only one of many things not blocked by default. ETAG tracking is pretty popular on pixels.
I'm not saying they aren't right, I'm just saying that they are somehow doing more PR than anything else. And as other comments are calling out, this makes it even harder to compete on IOS using PWA (How is a website asking for permission different from an app? Can't we have a permission framework just like apps?).
I agree, with a caveat - Apple can and does remove apps which are caught stealing data permanently. The App Store and Apple's policies act as a safeguard for users. As far as I know, there is no reliable way to do that for web apps.
Outside this list Safari's support is limited or nor for many other APIs. MediaRecorder and many WebRTC APIs have no clear roadmap for support.
Many APIs including getUserMedia and all of WebRTC are not supported in WkWebView (only way Firefox/Chrome works on iOS due to Apple policy blocking them from building their own browser) Means some apps will only work in iOS-Safari and not in iOS-Chrome/Firefox.
None of this has to do with privacy, being able to record media locally without sending to STUN/TURN server increases privacy not reduce it.
There's an unintended consequence in this, though. Which is that if you don't use an ad blocker you'll see the lowest cost, and thus lowest quality of ads. So in addition to keeping a private presence you're required to use an ad blocker. And services which have built their business around being ad-supported will see you as a deadbeat. Which motivates them to be more aggressive in upselling you, or denying service if you don't whitelist their ads.
Which is that if you don't use an ad blocker you'll see the lowest cost, and thus lowest quality of ads
I haven't worked with web ads in a while, but from what I remember when I did, people with little data on file with the advertising networks got more ads, and better ads, because there was no record of them having seen the high-paying ads already.
The longer you surfed, and the longer you were tracked, the lower quality the ads became.
Again, I haven't been in this arena for a while, but that was true at the time, as told to me by the president of one of the larger non-FAANG advertising networks, over coffee.
But it's all a red herring anyway, isn't it? Are there any people out there saying, "I wish there was a way to give Google more information about me so that I can see better quality ads!"
IMO we need to stop giving more permissions to browsers. Everytime I install a new browser (I am intentionally not taking sides about which browser), the first thing I do is disable notification, microphone access, webcam, and location access.
All applications that want to interact with system level hardware needs to go through the system vendor. Get proper driver cert, developer account with their physical company address.
I have a special distaste for plugins, extensions, PWAs, and even <canvas> tag. Browsers ditched system UI and favor of CSS driven UI elements which created the soup of unimaginable mess, inconsistency and lack of quality of UI in the browser. And this is just UI, the level of scrutiny given to a browser extention is insanely passive. Extensions get bought and sold like a hot commodity and no one bats an eye.
I can't use a system level blocker (such a Little Snitch) to stop an extension from communicating to the internet without blocking the browser itself rendering it useless. I need to resort to a horrifying mess of blocklists and a Raspberry pi hoping to catch one of these domains in its hole.
I personally want a browser to display HTML, may be some interaction with the DOM to help out (check all boxes using jQuery for example) and that's all. I don't want anything more.
Prior to canvas, you had Flash and server-side rendered round-tripped graphs. You really think this was better?
Browsers bring friction-free exploration, literally "surfing". Hit the back button, or clear all your caches, and you're done, but otherwise, it's fire and forget.
The installable App model creates "shit work". Everytime I install something, it permanently takes up both screen real estate, and storage, and creates a cleanup task for me to delete it at a later date. Steve Jobs said "don't give your users shit work", well, app install and uninstall is shit work.
I don't want to install stuff, I want to use stuff and get work done, and want things to go away if I don't want them without having to become a System Janitor.
You complain about notification janitor work, which is fair, but native apps have the same problem, my iphone is deluded with notification spam.
The whole app model is a complete reversal of decades of movement to thinner clients, back to the Windows model.
Every time I go to a new restaurant, a new milk tea place, a new airport, or a new airline, they're asking me to install their native app. How many god damned United/American/SFO/InAndOut/FiveGuys/Chipotle/Starbucks/et al apps do I need on my device?
And no, "Instant Apps" are a worse solution to this. Why do I need to download a friggin 5mb iOS executable, even if it isn't perma-installed, just to display a form with 4 boxes on it to pay for a parking meter.
Form-filling is literally the use case for SGML from the beginning.
No, we don't need a native-locked-down-walled garden for every physical point of sale in the real world. And since Apple will never own 100% of the market, this means developers will end up needing to write, x2, silly little point of sale apps which clog up people's phones.
Ephemerality, transparency, portability, are desirable properties in addition to security and privacy. Apple leans too much on the latter at the expense of the former with relatively dubious justifications that could be fixed with better design, instead of refusing to participate in improving the specs to meet the desired properties.
I don't entirely understand your argument: I would love to use those things in the browser; in fact I do. But those are precisely the things I don't want to give random web API access to!
> Prior to canvas, you had Flash and server-side rendered round-tripped graphs. You really think this was better?
Bringing up flash here is like responding to an argument against capital punishment with "prior to lethal injection, you had firing squads, which do you think is better?"
> Hit the back button, or clear all your caches, and you're done, but otherwise, it's fire and forget.
Then of course websites can override the behavior of the navigation buttons...
> The installable App model creates "shit work". Everytime I install something, it permanently takes up both screen real estate, and storage, and creates a cleanup task for me to delete it at a later date. Steve Jobs said "don't give your users shit work", well, app install and uninstall is shit work.
Steve Jobs also thought he could cure his pancreatic cancer with a vegan diet. Perhaps shit work is a necessity if you don't shit laying around in inconvenient places, and this was one of Jobs' neuroticisms that didn't contribute to his genius.
That an app takes up permanent screen real estate is a matter of designing the operating system interface. On my computer, apps certainly don't take up permanent screen real estate.
> I want to use stuff and get work done, and want things to go away if I don't want them without having to become a System Janitor.
I feel the same way and my apartment is currently an absolute mess for this reason.
> The whole app model is a complete reversal of decades of movement to thinner clients, back to the Windows model.
So is the direction of the web, where clients are expected to do more and more work to make the server side application work. This is why computers that were sold as "thin clients" back when this concept was actually considered relevant are now pretty much useless for browsing the web. We're now working towards rich clients for better or for worse.
> Every time I go to a new restaurant, a new milk tea place, a new airport, or a new airline, they're asking me to install their native app. How many god damned United/American/SFO/InAndOut/FiveGuys/Chipotle/Starbucks/et al apps do I need on my device?
In my experience, none. I pay cash, debit card or in some cases using a single phone number based bank transfer app that's ubiquitous in my home country. In no cases have I needed a vendor-specific app to do this. Are you telling me that you can't go to Starbucks and buy coffee without installing their crapware?
> And no, "Instant Apps" are a worse solution to this.
No one mentioned "instant apps" and I've never heard of the concept until now. I agree that it's a stupid and pointless idea. This is not a problem that needs a solution in the first place, and "instant apps"/webapps/whatever are just part of a spectrum of stupid solutions to a stupid and incorrectly posed problem.
The problem they want to solve which is not as stupid, but all the more privacy invasive and manipulative to make up for it, is that of knowing as much about their customers as possible and to be able to push marketing information to them on that basis. To the credit of "instant apps" it only partially solves that problem.
> Form-filling is literally the use case for SGML from the beginning.
Yes, and if you limit your web app to the simple task of letting a user fill a form and submit it you don't need any of the stuff added to browsers in the last 25 years.
> No, we don't need a native-locked-down-walled garden for every physical point of sale in the real world. And since Apple will never own 100% of the market, this means developers will end up needing to write, x2, silly little point of sale apps which clog up people's phones.
No one needs to do that. If you mean that a big web API surface is necessary to create proprietary point of sale systems in a way that's more convenient to the vendor, I consider it only appropriate to limit the API surface to prevent them from doing so.
> Ephemerality, transparency, portability, are desirable properties in addition to security and privacy. Apple leans too much on the latter at the expense of the former with relatively dubious justifications that could be fixed with better design, instead of refusing to participate in improving the specs to meet the desired properties.
It is clearly the case now that security and privacy significantly suffers from the browser API surface.
Maybe thats all you need from the browser. But I am happy that the browser can do all that stuff.
I can use BigBlueButton to participate in lectures, talk, share my webcam, even my screen. And why I should I care, if I can at any time, revoke that permission?
I use many web apps, which are incredibly sophisticated, from TickTick for todo lists, to LucidChart for creating diagrams, to google docs do collaborate on documents, to notion for creating documentation. I could go on for days.
I am happy, that the browser is as feature packed as it is, because it allows for so many wonderful apps, that wouldn't have been made otherwise, if they had to be made with any other technology, that is not as easy to develop cross platform applications for.
So basically everything that would allow web apps to become capable enough to provide a viable alternative to their App store.
If they really cared about privacy they'd auto-generate their new privacy labels based on a websites api access pattern, and put them in an easy to access place.
They should also simply ask the user for permission if a privacy critical api is being accessed, same as we do with the microphone and gps. Or if they want to prevent users from being bothered, they could make them opt in as others have pointed out. So you have to manually go to the privacy label, and select the stuff you want to allow.
I'd love to be able to plug midi devices into my phone.
Implement pwa games that use local bluetooth connections for gameplay with friends in the train.
Or be able to access my 3d printer from my phone without having to release a ridiculous App store app.
nearly all of those APIs are also considered 'harmful' by Mozilla[1]. Some have even been disabled after implementation because of this[2]. These were developed by Google for Chrome OS, and besides the privacy issues, they substantially increase attack surface for security vulnerabilities.
I don't like that Apple has this tight-fisted control over the app store but I'd hate it even more if websites got the same freedoms as apps. For better or worse there is some sort of diligence being done when an app is accepted in the app store and there is a chance it gets booted out if it abuses power. There is no such mechanism for web sites. Once this is out there there's no taking it back, there's no reigning it in, we're stuck with it. Deprecating these APIs is harder than just not implementing them in the first place.
Each of these APIs is sold as a life improving feature but put together you basically end up giving way too much access to any website. Because you know most users will not understand the problem and will just accept which is like sideloading APKs from random corners of the internet. And it's not their fault, you can't be literate in every field. Even as an expert you'd have a hard time deciding if a certain feature is used legitimately or the site will piggyback on it to screw you over. That's why you pay $1000 for a phone, so the manufacturer protects you from these risks.
I think it's about user expectations. As a user, when I'm browsing the web, I expect to be reading primarily text, with a hyperlink here and there, maybe some images. If I need to interact with the web site, I expect to see text input fields, a "submit" button of some sort, etc. When I click on a link and browse to another web page, I expect to see something similar: Hypertext, images, maybe a form field or two. I don't expect to have a peripheral attached to my computer get its firmware updated.
The APIs listed in the article are so far outside what I would expect to be a HTML browser's business. It's ridiculous. If I want to do any of these, I'll install an application to do them.
Installing an application is a nice speed bump. It's a deliberate action that the user has to take and think about. When I hand over my root password to my installer, or when my operating system asks me, "Do you really want to install this application?" it gives me the opportunity to pause and reflect on what I'm doing here. Who is the company behind this application? What access to my life am I giving it? Am I OK with running this application on my personal computer? Sometimes, after reflection, I hit cancel and get rid of the installer.
This whole contemplative speed bump goes away when rando web site written by rando developer, getting paid by collecting who-knows-what can suddenly do a Bluetooth scan or talk USB to one of my devices, merely by my issuing a GET request.
I think this is a pretty narrow vision of what the web can be. For example, text + hyperlinks excludes things like google maps and youtube, which are quite literally world changing pieces of technology.
For sure there is a balance to be struck in terms of how much access we allow other people to our phones and computers, but let's not kill off whole classes of novel applications before they've even had a chance to be built.
> ... web pages that talk to ... health devices ... there is no way to block ads in an app
Wait, what?? Why on earth would you use an app with ads for health devices?!?
Moreover, why on earth are you using apps with ads for anything?
Please, please, please, pay for your apps and games. Stop making everything an ad service. The race to the bottom in the web and mobile world is disturbing.
Would you want to pay for your house plumbing by being forced to watch an ad every time you shower? Think about how dystopian that sounds. There are even Black Mirror episodes on that.
> Wait, what?? Why on earth would you use an app with ads for health devices?!?
GP said they want to _write_ a web app that talks to health devices. And that they like the web platform because it's easy to block ads shown to you by other web apps.
I will add that it's also easier to detect/block tracking. Browsers such as Firefox even try to do this for you these days. And to generally examine what the app is doing (e.g. by running it in JS debugger).
Yes, paid apps usually (but not always) remove ads. They keep the telemetry, though.
On the privacy end of things, ads certainly aren't helping, but a pretty large number of even paid apps are happily vacuuming up data and sending them to the developer and often third parties (vendors of analytics/debugging platforms in particular). I tend to think of an app for most things as a loss of privacy and try to avoid using them when possible.
I am less likely to accidentally give you permission over my computer to do shady shit if I am forced to install an app vs happen to click the wrong link on my browser.
The difference is intent. By installing Chrome I do not intend on giving up every last bit of privacy and control over my computer, they just want to trick me into doing so by stuffing functionality into web APIs that should never have been web APIs in the first place.
I wouldn't have any problems giving these APIs access via the web, but one challenge with the websites is that I'm never 100% sure that when I "retract" a permission or say "stop tracking me" that it's done. I think that if access to these API's were wrapped in some sort of Privacy API that superseded each website's privacy and data collection polices I would be more comfortable with this. These changes just seem like something Google threw over the wall to get things working with Chrome and every other browser developer said "no thanks".
IMO, it's not the web-developers, it's the web-site owners. The devs (well, the small sample I know) is not interested in collecting user information to make a better fingerprint.
It's usually marketing teams who aren't thinking about privacy implications, just how to perpetuate or further engagement.
Seemingly innocuous features they devise to streamline engagement often come with huge privacy implications and I've had to shoot down ideas many times in my career that were well into the realm of creepy.
Good. Those APIs were awful. If your website needs to know the battery status or other such information , you need to be writing an app which I will never download.
I dont think you are going to see Apple get in to any anti trust. What you will see is Google get broken up, with Apple, Tencent, Huawei, Microsoft etc swooping in and buying those pieces up.
You need a strong single Apple so that we can have our singular place to buy smartphones.
There is a use case for that kind of API for PWA's that a user would install, e.g. fullscreen games or applications that change their behaviour if battery is low (or network is slow). But those are far and few between.
The listed "Idle Detection" is a different spec that is way more invasive than requestIdleCallback (which seems on track to be deployed more generally in Safari).
It's about detecting user idleness, including in the case the user has another tab active, not a way to queue and coalesce bits of work at an "idle" moment to optimise for latency and battery life.
I'm really excited about the new permissions model that Apple is using. Perhaps in time -- after some testing -- they will gradually enable these APIs, as they are quite useful.
Nobody would care if Apple allowed other browsers on their mobile platforms. The problem isn't what APIs they do or don't support, it's their refusal to allow alternatives to WebKit.
Lot of people on this thread are saying that put these behind permissions and call it a day!
You people don't understand that not everyone is tech savvy and understand permissions well.
My dad keeps giving on permissions on any website asking on his Android device as he just wants to get rid of them.
Think about how many websites you visit and how many apps you install. I bet second number is way smaller than first one. When installing apps - you put some trust into app and lot of non tech people understand same (thankfully taught by antiviruses to not install random thing). People are not willing to install lot of apps but always willing to visit websites to "check it out".
Privacy fundamentally limits UX and there is direct trade-off. I believe Apple is doing right thing to protect privacy of millions of non tech people.
And you people don’t seem to understand that UX doesn’t need be the same. Websites can make the prompts default to no, even hiding them by default behind an icon.
There’s no reason you can’t make the UX cater to the use case such that it’s clear and secure by default.
It’s just tiring dealing with people who channel their hatred for JavaScript essentially into nerfing the only truly open platform we have, one with far better primitives than the native ones and with a massive potential that is only held back by the feet dragging of every major company (Google and Apple both).
Then you go to HN where you’d expect we could agree that a web that complemented apps if done well should exist, and instead we have nerds gaslighting other nerds using every fake reason they can find (my dad wouldn’t understand the notification, or, good because I don’t want powerful sites) when in reality they just lack any imagination that would easily allow them to have both worlds, thus keeping those who do have some imagination stuck in this special hell of having to re-make the same points over and over.
Browsers should just bundle all the advanced but privacy concerning APIs into a single App permissions dialog that you get on the domain you visit and that's it. That should include everything JS except simple DOM manipulations, so you don't have to completely disable it as most regular websites just need a few hover events and image carousels. When a website needs to be an app, the web can and should act as an application delivery platform with proper permission dialogs and installation prompts. Separate the concerns and you're done, instead of this farce, but of course when an OS company is focusing only on short-term revenue rather than empowering their users in the long run, they would be blind to solutions like these.
I still think the right way to do this stuff is to "support" the APIs but have them produce random data so the site cannot refuse to work if the API is not supported. The best way to deal with fingerprinters is to flood them with garbage.
I admit to a bit of head-scratching over some the comments here. The most common criticism on HN of Apple's approach to native iOS apps is the way they're locked down through sandboxing and various restrictions in the name of privacy. But a major criticism running throughout these comments of Apple's foot-dragging on supporting various Web APIs is that we should be using PWAs because, compared to native apps, they are locked down through sandboxing and various restrictions in the name of privacy. And... huh.
Yes, I get that in the first case it's Apple setting the restrictions and maintaining the control, and in the latter it's ostensibly open and not controlled by any one party. It's a good principle. But it's easy to forget that the first steps toward web apps were largely taken by Apple back in 2007, with Steve Jobs enthusiastically talking about the "sweet solution" they had for installing third party apps on the iPhone: web apps. There's a future we can imagine where if Apple had stuck to their guns and really ramped up their APIs, PWAs would have taken over mobile computing a decade ago. But they didn't, and the reason they didn't is because both developers and users hated them. Hated hated hated.
"But those web apps sucked and modern ones are much better!" Yes, I agree! But to users, the difference between going to the app store for their platform and downloading Twitter and going to the Twitter web site and tapping "Save as Web App" is pretty minimal, and there is no effective difference between the two once they're installed. Well, I take that back; I don't think a web app can provide a sharing extension, or be automated through Shortcut actions, or offer Siri suggestions. So actually, I'd rather have the real app still, thanks.
And, on point for privacy concerns, for me this isn't as much about "trusting Apple" as not trusting web sites. Yes, I'm sure there are valid reasons for all of these APIs to exist, but when push comes to shove, I'd rather go through the extremely mild inconvenience of having to download an iPad MIDI sequencer as a web app than discover that a web site -- or an advertisement on a web site -- has used that to track me or even deliver a malicious payload to me.
Why is it ok for native apps to do all such (and more) fingerprinting, utilized across apps, and not the web? Maybe I’m saying this backwards, why aren’t native apps given the same restrictions?
And on the app install page there is verified data about the developer which you can use to contact/sue them if they violate your privacy. Good luck getting access to that information for a web app.
So many web developers keep pushing to give web the same power as native apps. "What's the difference between a PWA and native app? Why web cannot access the same api?"
So I want to ask another question: "What's the difference among knives, guns and missiles. Why almost everyone can buy a knife, but need a license to buy a gun, and may never able to buy a missile (even with enough funds)". One possible (and obvious )answer is because guns and missiles are more powerful than knives, we want to give them more restrictions.
Now can we reverse the logic and say, if we are able to decide the power of items, we should give items with less restriction less power? Let's limit our discussion on a mobile device, it's very easy to visit a website. But if you want to use a native app, you need to go to the app store, tap the download button, confirm, wait until the download is finished and the app is installed, and then finally open it. The app was also reviewed by the app store beforehand. This makes a difference. In fact, I think the ubiquity of web means we should never allow it to have the same power of what an native app can have.
And people are talking about the monopoly of apple. But if web become THE operating system one day, google will be a more dominant monopoly. They control both the implementation of the os (chrome) and the entry (search engine).
They surly can be used for fingerprinting, but they also can be guarded with requiring user opt in permission, one which maybe clearly informs the user how the API can be abused and warm them to only s allow it if they know what they are doing. Which is fine given that most usage are for more advanced use-cases. (Through some come from the Firefox OS use-case and might be better if not to be implemented as close to all current usage would be abuse, e.g. the proximity API).
Ubiquitous web midi support would enable a new and better round of patch management and sharing collaboration around music hardware. It's a shame it won't come to safari. For example see elk-herd for managing the Elektron digitakt.
> - Removed support for custom fonts. This means only presenting built-in fonts which are the same for all users with the same system.
I really hate this. I'm opinonated on typography and rely on userscripts to replace fonts I think to be subpar (Arial, Times New Roman, etc.) with ones with higher quality. Since ~2 years ago Safari has lost the ability to designated any font with custom 'font-family: ' CSS other than built-in fonts, totally breaking my use case. I hadn't use Safari as my daily driver browser since then despite its privacy benefits.
the bigger question is that why aren't these standards meeting privacy best practices in their API designs? Why are companies like Google influencing these standards so much ? In my opinion if that continues, we should disregard these so called "standards".
So if a page is running a computation in the background, for example, rendering some real time chart or something, you'd rather it continue to do work and waste battery life, then to throttle itself?
But then you'll say "well the browser should just throttle any tab i'm not looking at" (which it already does), but then you'll complain the first time an app you actually want live updating doesn't work properly.
> So if a page is running a computation in the background, for example, rendering some real time chart or something, you'd rather it continue to do work and waste battery life, then to throttle itself?
Yep, that's the behaviour I expect. If I want you to stop I'll close you.
> But then you'll say "well the browser should just throttle any tab i'm not looking at"
Why would I say that? I explicitly don't want pages to act differently when I'm not looking at them. If they're updating when I'm looking at them then they should keep doing that when I flick away to something else.
It's a privacy issue and it's a functionality issue. It's literally none of the page's business whether I have it in view or not.
Next you'll be telling me that pages should be able to use the camera and face sensing tech in smartphones to detect if I'm looking in the right direction. For my convenience of course, nothing to do with advertising, tracking, analytics...
FYI I've managed to find an addon for firefox that blocks this API. No noticeable difference in battery life.
> Magnetometer API - Allows websites to access data about the local magnetic field around a user, as detected by the device's primary magnetometer sensor.
I have never heard of this API, what's a use case for it?
If you had access to the magnetometer, you could make a navigation compass. Or, you could animate a map to rotate as the phone rotates. It might be good for implementing a GeoCaching helper app as a website.
Accept cookies, yes; but decline the requests for the sites to send me push notifications. And decline when Google asks me to enable geolocation if I don't want to.
And of course I just leave the site if it gets obnoxiously needy and invasive.
This is not related to developing App Clips, just Safari. (Aside -not sure why you're using such a derisive tone with that 'so called' stuff - companies name technologies for many good reasons, so just go ahead and use the name.)
So, basically, Apple users are doomed to stay inside their walled garden in the sake of privacy (which mostly means that Apple is reserving access to their private data solely for itself). No functional-rich PWAs for them. Well, it is always people's (customer's) choice.
besides the nfc api, which might be feasible with a good privacy the api's are simple not needed.
nfc would be a good idea to make authentication over nfc devices feasible or nfc checkout.
we basically developed a native app, just because we needed to access an nfc reader for "tag" authentication. it does not more things. printing works over ipp, server-side.
the app basically does two things:
- nfc reading
- barcode scanner reading (basically they work like a hid keyboard device, so it doesn't really use any hid device driver or anything, we just detect it by watching how much keystrokes per ms are coming in. (which would be possible with in a webapp, aswell)
Everything on this list seems like it would be extremely useful in tracking people. The approximate memory API? That, along with geolocation, could effectively unmask you across the web.
Safari has been my primary browser for a few years now. Nothing beats the performance on macOS and no other tech giant is going to respect and fight for your privacy the way Apple does.
Here is Apple making it harder for the web to compete with closed wall gardens. Web apps could require the same permissions for accessing hardware as mobile apps do. On Firefox, when a website wants access my webcam, it asks me, for example...
> 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
Fun fact: for quite a long time Chrome skipped over the user permission step in the Web MIDI spec, always allowing access and silently giving ad networks a list of connected USB MIDI devices with no user consent:
https://www.obsessivefacts.com/blog/2018-10-20-chrome-allows...
Here's what appeared on porn site xhamster.com once newer versions of Chromium got around to implementing the permission check (SFW-ish):
https://www.obsessivefacts.com/images/blog/2020-04-04-the-ja...
Guessing it was for additional browser fingerprinting.
16 replies →
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.
The browser is indeed an application platform. Even HackerNews is an app, although it uses a minimum of browser functionality.
Maybe you don't want things like videochat or paint programs or music learning apps to run in a browser, but lots of people do.
Imagine if Firefox said "we're not going to let any web page access the camera"... their market share would probably drop in half overnight.
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.
15 replies →
Then disable those permissions.
3 replies →
It's kind of sad though because it's still 10X easier to build a browser app than a native app simply because of the wealth of highly-usable stuff written for JS.
Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.
Android programming is another can of worms and I'm frankly fed up with Gradle updates breaking my project every update and needing 79+ files, multiple cludgy steps for signing APKs, zipalign (wtf) and other crap just for a Hello World.
What would be nice to have is "installable" apps that use the webkit rendering engine but have full access to the system including directly opening TCP ports and direct access to /dev. These would have to be trusted apps obviously. Websites that load code without consent should be restricted, of course.
12 replies →
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.
Because people don't expect their web browser to be able to brick their hardware.
7 replies →
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.
3 replies →
One point not discussed here is by relying so much on app store and apple's walled garden, what do you do when china or other country ask apple to remove certain apps?
Bypassing geo block on websites is easy and there isn't a single source of truth on the web like app store is for the users. Can apple explain why they took down apps on the request of china in HK and how do you think that will play out when no web apps can work reliably on apple devices?
Censorship is a huge problem for app stores. They censor anything sexual but sexuality is part of human nature. They censor anything politically charged but it's part of human nature too. I hope the anti trust fine plays out.
Apple can protect the privacy of people by making it harder for them to be vulnerable by choice. People here point towards stupid users when saying that a normal user won't be able to connect usb and enable a feature. Why can't the same happen with browsers or apps on ios? Why the $99 fee just to side load apps? Why the need for a mac?
Just admit it's for profit seeking reasons. Ads in your app store are a proof of that.
It's still possible to partially implement it while keeping it safe by excluding sysex messages. Probably more than 90% of the end users will never need sysex messages so why bother?
> so why bother?
maybe 10% is enticing for those who create botnets
2 replies →
I'm curious now that I read this, this means that web midi can access the virtual midi devices created under alsa on linux also? Which means if you have it routed to other software using Jack or aconnect, websites could send midi notes directly into whatever software your midi device is routed through?
So theoretically then, could a Jack aware payload be created that runs in the background, say disguised as a vst or ladspa plugin and when a user browses a malicious site, this site could, recognize the malicious midi device, create connections to other software and gain access through possible buffer overflows or other things?
It seems like a stream of midi notes could itself possibly cause a buffer overflow in certain programs. Muse and rosegarden are a bit buggy as is and frequently crash for me. From what i can tell there's a lot of midi aware audio software that likely contains a bunch of avenues for exploits and when you throw virtual midi devices into the mix capable of doing far more than hardware midi devices...
Why not just limit allowed midi status to: Note On, Note Off, CC, Aftertouch, and Pitch Bend? Or maybe be readonly?
Is there a way to escalate that I'm not seeing? AFAI remember, all programming is done through status messages 11110000 and above.
https://www.midi.org/specifications-old/item/table-2-expande...
Full Disclosure: I made a web synth and really want to be able to use midi to play with it.
I don't see why the API should even allow enumerating devices. Put that behind a browser dialog. Webpages don't get to enumerate directories/files on your system - they pop up a file picker dialog. The same should happen with device selection. Once you've granted the site access to a device, it can ask you to associate a name with the handle, and provide whatever shiny device selection / device management UI it wants.
Better yet, reasonably abstract the raw MIDI protocol away with something that has suitable security and privacy properties for the web, and translate it to MIDI on the host. In any case, the current proposal does not seem to cut it.
I agree that it would be nice to have a limited amount of the Web MIDI spec, but bear in mind the staggering few people who actually have MIDI devices, and the even more staggering few of those people who want to use whatever website has midi support for its features.
To answer your question about why not to just limit the API: because that would be another data point to use to fingerprint users, and because the amount of engineering time that would have to go into Web MIDI support (including testing, security auditing, etc.) would never be worthwhile compared to putting those same developers on something that might be beneficial to vastly more users.
(Also note that Firefox made the same decision to implement nothing at all.)
1 reply →
Yeah. It's crazy to me that they haven't decided to create some abstract virtual midi instrument. That you can instruct the browser to pass through to your devices.
Exactly. Apple can choose to implement what they consider to be a safe interface for WebMIDI. Instead, they refuse all of it?
In my opinion, Apple has an incentive to keep the web crippled in some aspects, and this is just another symptom of that deeper underlying cause.
Well, I guess if I ever need WebMIDI features, I'll put a banner for Safari users to switch to Firefox.
(Or.. Maybe Firefox on iOS is forced to use the same engine as Safari..?)
It's a shame, but it proves just what a futile affair it is to retrofit ancient protocols that never had to consider host security. Especially because MIDI is so elegantly simple!
Sending binary firmware updates (sysex) is not a necessary part of the API... they don't have to implement that, and if they do, they can ask for additional permissions.
Allowing you to use a keyboard as an input device is incredibly powerful, and even that can be handled much as camera and microphone is: you give the site permission.
If you get the MIDI device to act as a keyboard it’s not for typing things in the browser but in the OS... you are out of the sandbox so it’s possible to download and install any payload.
1 reply →
The alternative is that users download executable to apply firmware updates. Then the attacker doesn't even need to find a hardware vulnerability!
There may be some legitimate fingerprinting concenrs. But given the list of API's it's hard not to see this as Apple crippling PWAs to prevent them from replacing native iOS apps (and hurting Apple's revenue from the Apple tax).
And maybe I'm missing something, but wouldn't the fingerprinting concern be mitigated by the fact the app has to ask for permission before using the API? If an app that doesn't have to do with MIDI asks for permission to use my MIDI device, I'm going to be instantly suspicious.
Exactly. This is about making sure web apps are not as powerful as native apps.
One thing is the revenue generated by the App Store but suppose JavaScript web apps were just as powerful and well integrated as native apps; then why use native apps at all? Why have an App Store at all? Why have a Mac or an iPhone if any device with a modern web browser would do?
When Huawei tried to create their alternative to Android. The big thing missing wasn't the hardware or the operation system. It was the App Store with your map app, your banking app, your scooter app and so on.
The App Store and the proprietary development platforms for Android and Apple has become a way to keep their duopoly in place.
I like having apps that work and feel the same. I can bring my knowledge from one app to another. I can develop expertise on a platform. The web is culturally unable to do that.
Look at a sophisticated web app, like Google Docs. This has a menu bar, which is a bad copy of the native Mac menu bar. Web apps are copying native app conventions, to try to be more familiar. But they're also eroding those conventions.
Eventually only click and swipe will be left. And this problem is not going to be solved by Web MIDI or whatever.
2 replies →
Android supports PWA and let's you install apps without their app store, not the same as apple at all
Isn't Google the one implementing all these APIs though?
4 replies →
No. This is about privacy.
Why have native apps at all?
Because web apps are crap, excuse my Swahili.
Do you honestly think that Apple would lose enough money by implementing Web MIDI for Safari on iOS that this would be even the most remote consideration? Like, the Safari team was in a meeting about Web MIDI and some manager said "but think of the impact on our stock options!" and they all went "oooooh" and scrapped it?
Or is it that Tim Cook was looking at Apple's balance sheet and decided that they couldn't afford to lose the 30% cut of all the MIDI-capable iOS/iPadOS apps that could be completely replaced by a web app?
The reality is that the real cost of this feature to them would be developer time; it would be a colossal waste of their limited WebKit/Safari developer resources to implement Web MIDI rather than something that would actually be used by more than a scant sliver of a percentage of Safari users.
apple fanboys will accept anything from apple. No headphone jack? it's an improvement! w3 spec not implemented? they are working on more important features! antenna stops working if you hold the phone wrong? I like it that way!
I wished they implemented the Fullscreen API for iPhones...
> If an app that doesn't have to do with MIDI asks for permission to use my MIDI device, I'm going to be instantly suspicious.
Sure, you'll be suspicious, but I seriously doubt you're the average user. I bet a very large proportion of Safari users have no idea what a MIDI device is and some significant portion of them wouldn't think twice about granting those permissions.
I'd assume the small percentage with a midi device who are going to music app websites would be more likely to know
4 replies →
Are you all serious about this ask for permission thing? Good luck explaining MIDI, HID, NFC and so on to the average Joe, in a small popup. We already have enough “I agree” buttons popping over the screen. Web should be built for everybody, it’s not the nineties anymore.
Sorry, but Average Joe needs to learn this one thing to adapt to the modern web:
Say no.
Average Joe doesn't need to learn what all these things are. In the unlikely event he knows what the thing is and knows that he wants it, he can answer yes. But his default response needs to be no.
>Web should be built for everybody
Exactly. That's why Average Joe needs to adapt.
Sure, but Apple could solve that by requiring a user action to show that popup dialog. Or they could even block everything by default and force you to give permissions manually. That way average Joe is blisfully unaware of anything and completely safe while you just have to suffer a minor inconvenience of whitelisting that one legit website the first time you use it.
I don’t even want these 16 api’s. I want a way to do notifications and a way to store more than 50 mb on ios. Sure, make me and the user jump through hoops to make sure I’m not abusive, but with those two there are a ton of apps which I can build as pwa’s.
The app clips feature they showed? That should have been a qr code triggered pwa with notifications, except everybody had to build it as an app because they couldn’t do notifications, and then apple used the cumbersome nature of those apps as the reason for app clips. It’s the snake eating its own tail, and I’m getting IE6 vibes because microsoft also strategically stopped improving IE for web apps because they wanted to push app developers to native because of the improved user experience. Yeah, the web is worse, but worse is better.
I’m very glad a web page cannot store 50mb data and send notification to me.
You only think from a developer’s perspective. What if you are the user receiving 50 notification requirement a day from a web browser?
12 replies →
Despite this, I believe PWAs will eventually win, and Apple will be forced to comply if they wish to stay relevant.
Their browser share dropped a little recently (https://gs.statcounter.com/browser-market-share). If that continues, it'll certainly irk them!
IMO, that won't happen until either Apple gives up their control on browser "engine" choices on iOS or Apple itself becomes irrelevant.
Consider that browser share usage could shift around as device usage shifts around during a pandemic.
3 replies →
Apple is a corporation listed on a US exchange, an entity where the only motivation is to generate profit for shareholders. It helps for corporations to frame business decisions in moral terms. If Apple cares about privacy, it is only because there is alignment with profit. If Apple cares about locking out APIs that disrupt their App Store profit, it doesn't hurt to frame the decision in privacy terms.
Currently my desire for both privacy, convenience, and usability align with Apple's current business decisions, so I choose iPhone. When Apple pivots to a new business model, I'll find the best compromise product.
I disagree strongly. Apple leaves money on the table by not aggressively tracking its users. And their investment in e.g. accessibility is certainly not driven by bottom-line considerations.
Apple is relevant today because they actually are focused on products, not profits. Sometimes it really is that simple.
1 reply →
Every time I see this argument I have the same question. How many successful web apps are there for Android? Apps that make the most money on the App Store are free to play games with in app purchases of loot boxe, coins, etc. how many of those are feasible on the web?
On the other hand, which apps that make money via in app purchases would be viable and successful as web apps?
I think most would be as successful IF they had an equally frictionless payment system. Big hits like Candy Crush could easily be built as a web app. These are not pushing the boundaries of software, they're just exploiting our psychology.
6 replies →
counterpoint to that argument: if you want to create an app that runs on both Apple and Android products, and you know that Apple doesn't support the progressive web app specification, why would you waste your time? It makes more sense to use a cross-platform development tool and release on the app store when one of the two big software platforms doesn't support the spec.
2 replies →
Yep, seems like apple made another move against the web.
PWA's have always lagged behind Native Capabilities, even when API's exist the performance has been poor for high performance apps so the allegation doesn't quite make sense to me.
Almost certainly an excuse to further suppress PWAs.
Google's developer relations team have done a good job convincing web devs that those APIs are pushed by Google to enable "Amazing PWAs", yet we haven't seen them used by any major app. People are choosing to download native apps for more sophisticated applications.
However Google is pushing those APIs because they know tracking people without cookies in future is a big challenge for them and they need new ways of tracking people.
So sad that Google has taken over the web. From the most used browser (Chrome) to the content hijacking (AMP) to the standards (PWA). All to sell you to advertisers.
On Android you can use web apps in Firefox, with content blocking powered by uBlock Origin and Privacy Badger. This is because Android allows real Firefox, engine and all and Firefox implements the web push API.
This gives you unmatched privacy. As I've said elsewhere too, see this Facebook page listing apps that share data with them via FB's SDK and marvel at how privacy friendly your iOS device really is:
https://www.facebook.com/off_facebook_activity
The notion that Apple is not implementing the web push API for example, for privacy reasons, is stupid.
"Your off-Facebook activity is currently turned off."
Seems fine to me?
The problem with having an Android phone is that then you have to actually use the damn thing.
On a more serious note though, in iOS 14 app developers are responsible for any SDK's their app uses including data egress.
If PWAs die, we will be struck with this duopoly in smartphone OS for foreseeable future as native apps are the ones which help them retain their position.
If we want upcoming pure Linux smartphone OS, Sailfish or any other platform which protect the mobile computing from becoming proprietary; we need web apps & PWAs to grow and capture significant market.
Apple's treatment towards PWAs has been well known as PWAs are the only threat for its Appstore monopoly in iOS.
From a developer's point of view, I can see the value in PWAs (for them), but as an end user, I really don't see the benefit of PWAs over native apps. The UX is almost always severely degraded when compared to their native counterparts (even if the feature set is ostensibly identical). Why would I use a Twitter PWA, when the native app provides a much better UX?
24 replies →
We almost have a duopoly in browsers as well - you have Firefox, and everything else with market share are forks of WebKit.
Name three PWA apps please. I know I've built two PWA POC some time ago (using service workers and Notification API), but I've never use any PWA in the wild.
12 replies →
Nah people can just program in Java again.
> However Google is pushing those APIs because they know tracking people without cookies in future is a big challenge for them and they need new ways of tracking people.
Why would it be? They have the search data, they know what you clicked on, they have GA on 60-80% of sites, they have plenty of information, tracking and profiling users isn't the issue. Tracking and profiling users legally is what's hard.
You have to build these APIs before people use them, and a lot of what Google has been building into Chrome is stuff native apps can do, so the use-case is clearly there.
IMO native apps are capable of far more invasive privacy violations than the web is. But for some reason they're given a very free pass by comparison.
Native apps are not handling my bank account passwords. They're also not collecting data about my consumer behavior with the goal of displaying more ads. This is a big difference.
2 replies →
They're given a very free pass because it's incredibly easy to block a native app from sending data back or even connecting to the internet at all.
You have a lot more control over something that's running locally than something running serverside that simply using the client to harvest data.
4 replies →
Well, because native apps are intended to be trusted. They do not have a motivation to invade your privacy: proprietary apps are usually paid upfront and risk their future clients, open source can be inspected.
Instead, the overwhelming web business model is "free to use" (akin to f2p in games). That means ads and other monetization side channels become the priority of the app, not the app itself.
And that is for trusted web apps. Let's not even talk about the fact that you are executing random code every time you visit any webpage. That just does not happen with native apps.
4 replies →
Never trust what they say, Google is known to offer so called "free" services for your good, ultimately people realize they are paying with their private data.
Rhe fact that people don't realize PWAs are the next push by Google to regain control is shocking.
The number of hackernews threads calling out Apple for not supporting PWAs is just as insane.
Interesting thought. I wonder if there's a genuine threat of google "AMP-ifying" PWAs. And by that, I essentially mean Google using their properties to exert control over PWAs, just as they have with web articles and other content. Given Google's virtual stronghold over the web, I'd assume so.
I don't really understand: the PWA APIs are W3C APIs, they're not created by one company. Mozilla fully supports them.
6 replies →
I’ve heard so many people complain on HN about Safari’s lack of support for APIs. Before now, we didn’t have a public justification why Apple refused to implement them. Now we know.
The price of a Safari user in the ad market is going down, and it’s exactly what should be happening. I’m very happy with Apple.
https://9to5mac.com/2019/12/09/apple-safari-privacy-feature-...
Except "privacy" as a justification is BS.
You can implement these APIs while at the same time requiring explicit permission from the user before a web application can use them. This preserves privacy while also giving users the option to have much more powerful web applications.
Apple doesn't want to implement these APIs because currently if you want access to these things on iOS, you need to go through their walled garden App Store, where they get a big chunk of any revenue you might make on such a service and can nerf competitors and all the other anti-competitive stuff they're doing.
> requiring explicit permission
Except on the long term that would have no effect in empowering users. We all know that when faced with a deluge of permission requests, or pressured by the fact that enough people have already accepted and it's the entry price to collaborate, people will just hit accept and be done with it.
They only need to get the foot in the door and then you'll find that plenty of stuff ends up conditioned on you giving them access. Every one of these APIs is a Trojan horse. Past experience just proves that they will be hijacked for purposes that don't do the user any favors.
Look no further than JS which is there to enrich the web to benefit users but 99% of it is garbage slid under the door to benefit site owners. That's because plenty of things that should work just fine without it are now tied into it, disable JS and the site experience breaks.
17 replies →
I don't want random web sites I open (and their ads) to ask permission to scan bluetooth in my area and use usb devices connected to my computer. A website has no business doing any of that. There is no justification for these API to exist.
32 replies →
I've seen Apple get away with this bad monopolistic behavior through hypocrisy more and more.
Apple is denying people their real rights to install whatever they want in their own machines, forcing everything to go through their app store, where they have the last word of who can or cannot distribute software to the platforms they have created.
They know that if they use the common "we are thinking of your well being" their customers and fans will just believe they are a good-willing company with no other interests than their users safety and well being.
I don't know why the majority of the crowd here in HN, who use to be so harsh in pointing out this kind of behavior in companies like Google and Microsoft, have this blindness with everything that has to do with Apple.
It will worth nothing, if after have defeated this beast with GNU, Linux, the Web, open software revolution, etc.. we end up not protecting what we have achieved so far, because somehow one company trying to secure their profits and its position in the market, get away with behaviors that can ultimately destroy the culture of freedom, open-source software and ultimately, digital rights, which our legislators are not prepared to defend, really understanding the threats and the dire future they represent if we dont uncover the true intentions behind this BS.
Recently I’ve seen a jump in the number of random sites popping up a “this site wants to access VR hardware” dialogs in FireFox; news articles nothing to do with VR or visualisation. I don’t have any VR devices.
How do you do this bit “requiring explicit permission from the user before a web application can use them” without the fallout of “its just a hundred thousand popups and you’re done!” on every page?
5 replies →
next headline: "Apple devices won't display any video other than those from tv+"
Apple bros on HN: "Good! finally someone standing up to the BigTech abuse of privacy"
I sympathise with the walled garden App Store argument. I hate it that Apple keep such a tight grip on the application distribution channel. At the same time, I really hate the trend where browsers are operating systems and I use native apps whenever possible.
Apple has the ability to put every submitted app through rigorous analysis before publication on the App Store to look for forbidden behavior, in order to protect their customers. They don't have that ability with arbitrary websites.
7 replies →
Firefox doesn't support them either. Most of these are implemented on Chromium, for Google's ChromeOS primarily.
They're kinda useless for web browsers, but people see them in Chromium and believe they must be there for a reason other than ChromeOS. Apple and Firefox are doing it right. These things don't have a place in browsers.
They didn’t mention the biggest one that people (including me) complain about, which is the push notification API. That’s intellectually honest of them (it inherently requires explicit permission before activating for a particular origin), but pointing to these far less likely to be used APIs is not making a good case for neutering PWAs on privacy grounds.
Safari already implements API that leaks enough information to uniquely fingerprint a device.
For instance, the Audio API. You can test it using OpenWPM [1][2] and you will get the same ID in both normal and incognito mode. And this is only one of many things not blocked by default. ETAG tracking is pretty popular on pixels.
I'm not saying they aren't right, I'm just saying that they are somehow doing more PR than anything else. And as other comments are calling out, this makes it even harder to compete on IOS using PWA (How is a website asking for permission different from an app? Can't we have a permission framework just like apps?).
[1] https://audiofingerprint.openwpm.com/
[2] https://github.com/mozilla/OpenWPM
Safari already implements API that leaks enough information to uniquely fingerprint a device.
What's your point? Because one API can be used for something, Apple should let Safari be a free-for-all?
Native apps are much, much more privacy-invasive.
Apple forces you to use those. You have no choice, like on other platforms.
I agree, with a caveat - Apple can and does remove apps which are caught stealing data permanently. The App Store and Apple's policies act as a safeguard for users. As far as I know, there is no reliable way to do that for web apps.
1 reply →
Outside this list Safari's support is limited or nor for many other APIs. MediaRecorder and many WebRTC APIs have no clear roadmap for support.
Many APIs including getUserMedia and all of WebRTC are not supported in WkWebView (only way Firefox/Chrome works on iOS due to Apple policy blocking them from building their own browser) Means some apps will only work in iOS-Safari and not in iOS-Chrome/Firefox.
None of this has to do with privacy, being able to record media locally without sending to STUN/TURN server increases privacy not reduce it.
There's an unintended consequence in this, though. Which is that if you don't use an ad blocker you'll see the lowest cost, and thus lowest quality of ads. So in addition to keeping a private presence you're required to use an ad blocker. And services which have built their business around being ad-supported will see you as a deadbeat. Which motivates them to be more aggressive in upselling you, or denying service if you don't whitelist their ads.
Which is that if you don't use an ad blocker you'll see the lowest cost, and thus lowest quality of ads
I haven't worked with web ads in a while, but from what I remember when I did, people with little data on file with the advertising networks got more ads, and better ads, because there was no record of them having seen the high-paying ads already.
The longer you surfed, and the longer you were tracked, the lower quality the ads became.
Again, I haven't been in this arena for a while, but that was true at the time, as told to me by the president of one of the larger non-FAANG advertising networks, over coffee.
But it's all a red herring anyway, isn't it? Are there any people out there saying, "I wish there was a way to give Google more information about me so that I can see better quality ads!"
> Which is that if you don't use an ad blocker you'll see the lowest cost, and thus lowest quality of ads.
Is this a thing? Do people in demographics which are less appealing to advertisers also see more intrusive ads?
1 reply →
"privacy" the new excuse for monopolistic practices.
Apple users hate to hear they believe the marketing, but it doesn't get more clear cut than twisting these things to be positive.
IMO we need to stop giving more permissions to browsers. Everytime I install a new browser (I am intentionally not taking sides about which browser), the first thing I do is disable notification, microphone access, webcam, and location access.
All applications that want to interact with system level hardware needs to go through the system vendor. Get proper driver cert, developer account with their physical company address.
I have a special distaste for plugins, extensions, PWAs, and even <canvas> tag. Browsers ditched system UI and favor of CSS driven UI elements which created the soup of unimaginable mess, inconsistency and lack of quality of UI in the browser. And this is just UI, the level of scrutiny given to a browser extention is insanely passive. Extensions get bought and sold like a hot commodity and no one bats an eye.
I can't use a system level blocker (such a Little Snitch) to stop an extension from communicating to the internet without blocking the browser itself rendering it useless. I need to resort to a horrifying mess of blocklists and a Raspberry pi hoping to catch one of these domains in its hole.
I personally want a browser to display HTML, may be some interaction with the DOM to help out (check all boxes using jQuery for example) and that's all. I don't want anything more.
Prior to canvas, you had Flash and server-side rendered round-tripped graphs. You really think this was better?
Browsers bring friction-free exploration, literally "surfing". Hit the back button, or clear all your caches, and you're done, but otherwise, it's fire and forget.
The installable App model creates "shit work". Everytime I install something, it permanently takes up both screen real estate, and storage, and creates a cleanup task for me to delete it at a later date. Steve Jobs said "don't give your users shit work", well, app install and uninstall is shit work.
I don't want to install stuff, I want to use stuff and get work done, and want things to go away if I don't want them without having to become a System Janitor.
You complain about notification janitor work, which is fair, but native apps have the same problem, my iphone is deluded with notification spam.
The whole app model is a complete reversal of decades of movement to thinner clients, back to the Windows model.
Every time I go to a new restaurant, a new milk tea place, a new airport, or a new airline, they're asking me to install their native app. How many god damned United/American/SFO/InAndOut/FiveGuys/Chipotle/Starbucks/et al apps do I need on my device?
And no, "Instant Apps" are a worse solution to this. Why do I need to download a friggin 5mb iOS executable, even if it isn't perma-installed, just to display a form with 4 boxes on it to pay for a parking meter.
Form-filling is literally the use case for SGML from the beginning.
No, we don't need a native-locked-down-walled garden for every physical point of sale in the real world. And since Apple will never own 100% of the market, this means developers will end up needing to write, x2, silly little point of sale apps which clog up people's phones.
Ephemerality, transparency, portability, are desirable properties in addition to security and privacy. Apple leans too much on the latter at the expense of the former with relatively dubious justifications that could be fixed with better design, instead of refusing to participate in improving the specs to meet the desired properties.
I don't entirely understand your argument: I would love to use those things in the browser; in fact I do. But those are precisely the things I don't want to give random web API access to!
7 replies →
> Prior to canvas, you had Flash and server-side rendered round-tripped graphs. You really think this was better?
Bringing up flash here is like responding to an argument against capital punishment with "prior to lethal injection, you had firing squads, which do you think is better?"
> Hit the back button, or clear all your caches, and you're done, but otherwise, it's fire and forget.
Then of course websites can override the behavior of the navigation buttons...
> The installable App model creates "shit work". Everytime I install something, it permanently takes up both screen real estate, and storage, and creates a cleanup task for me to delete it at a later date. Steve Jobs said "don't give your users shit work", well, app install and uninstall is shit work.
Steve Jobs also thought he could cure his pancreatic cancer with a vegan diet. Perhaps shit work is a necessity if you don't shit laying around in inconvenient places, and this was one of Jobs' neuroticisms that didn't contribute to his genius.
That an app takes up permanent screen real estate is a matter of designing the operating system interface. On my computer, apps certainly don't take up permanent screen real estate.
> I want to use stuff and get work done, and want things to go away if I don't want them without having to become a System Janitor.
I feel the same way and my apartment is currently an absolute mess for this reason.
> The whole app model is a complete reversal of decades of movement to thinner clients, back to the Windows model.
So is the direction of the web, where clients are expected to do more and more work to make the server side application work. This is why computers that were sold as "thin clients" back when this concept was actually considered relevant are now pretty much useless for browsing the web. We're now working towards rich clients for better or for worse.
> Every time I go to a new restaurant, a new milk tea place, a new airport, or a new airline, they're asking me to install their native app. How many god damned United/American/SFO/InAndOut/FiveGuys/Chipotle/Starbucks/et al apps do I need on my device?
In my experience, none. I pay cash, debit card or in some cases using a single phone number based bank transfer app that's ubiquitous in my home country. In no cases have I needed a vendor-specific app to do this. Are you telling me that you can't go to Starbucks and buy coffee without installing their crapware?
> And no, "Instant Apps" are a worse solution to this.
No one mentioned "instant apps" and I've never heard of the concept until now. I agree that it's a stupid and pointless idea. This is not a problem that needs a solution in the first place, and "instant apps"/webapps/whatever are just part of a spectrum of stupid solutions to a stupid and incorrectly posed problem.
The problem they want to solve which is not as stupid, but all the more privacy invasive and manipulative to make up for it, is that of knowing as much about their customers as possible and to be able to push marketing information to them on that basis. To the credit of "instant apps" it only partially solves that problem.
> Form-filling is literally the use case for SGML from the beginning.
Yes, and if you limit your web app to the simple task of letting a user fill a form and submit it you don't need any of the stuff added to browsers in the last 25 years.
> No, we don't need a native-locked-down-walled garden for every physical point of sale in the real world. And since Apple will never own 100% of the market, this means developers will end up needing to write, x2, silly little point of sale apps which clog up people's phones.
No one needs to do that. If you mean that a big web API surface is necessary to create proprietary point of sale systems in a way that's more convenient to the vendor, I consider it only appropriate to limit the API surface to prevent them from doing so.
> Ephemerality, transparency, portability, are desirable properties in addition to security and privacy. Apple leans too much on the latter at the expense of the former with relatively dubious justifications that could be fixed with better design, instead of refusing to participate in improving the specs to meet the desired properties.
It is clearly the case now that security and privacy significantly suffers from the browser API surface.
1 reply →
Maybe thats all you need from the browser. But I am happy that the browser can do all that stuff.
I can use BigBlueButton to participate in lectures, talk, share my webcam, even my screen. And why I should I care, if I can at any time, revoke that permission?
I use many web apps, which are incredibly sophisticated, from TickTick for todo lists, to LucidChart for creating diagrams, to google docs do collaborate on documents, to notion for creating documentation. I could go on for days.
I am happy, that the browser is as feature packed as it is, because it allows for so many wonderful apps, that wouldn't have been made otherwise, if they had to be made with any other technology, that is not as easy to develop cross platform applications for.
So basically everything that would allow web apps to become capable enough to provide a viable alternative to their App store.
If they really cared about privacy they'd auto-generate their new privacy labels based on a websites api access pattern, and put them in an easy to access place.
They should also simply ask the user for permission if a privacy critical api is being accessed, same as we do with the microphone and gps. Or if they want to prevent users from being bothered, they could make them opt in as others have pointed out. So you have to manually go to the privacy label, and select the stuff you want to allow.
I'd love to be able to plug midi devices into my phone. Implement pwa games that use local bluetooth connections for gameplay with friends in the train. Or be able to access my 3d printer from my phone without having to release a ridiculous App store app.
nearly all of those APIs are also considered 'harmful' by Mozilla[1]. Some have even been disabled after implementation because of this[2]. These were developed by Google for Chrome OS, and besides the privacy issues, they substantially increase attack surface for security vulnerabilities.
[1]: https://mozilla.github.io/standards-positions/
[2]: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...
Mozilla also killed WebSQL because the existing implementation was too mature...
I don't know what they're driven by, but it's not pragmatism.
27 replies →
I don't like that Apple has this tight-fisted control over the app store but I'd hate it even more if websites got the same freedoms as apps. For better or worse there is some sort of diligence being done when an app is accepted in the app store and there is a chance it gets booted out if it abuses power. There is no such mechanism for web sites. Once this is out there there's no taking it back, there's no reigning it in, we're stuck with it. Deprecating these APIs is harder than just not implementing them in the first place.
Each of these APIs is sold as a life improving feature but put together you basically end up giving way too much access to any website. Because you know most users will not understand the problem and will just accept which is like sideloading APKs from random corners of the internet. And it's not their fault, you can't be literate in every field. Even as an expert you'd have a hard time deciding if a certain feature is used legitimately or the site will piggyback on it to screw you over. That's why you pay $1000 for a phone, so the manufacturer protects you from these risks.
I agree overall, but:
> That's why you pay $1000 for a phone, so the manufacturer protects you from these risks.
is wishful thinking. You pay 1000$ because that is what people is willing to pay.
4 replies →
> so the manufacturer protects you from these risks.
Gigabytes of pictures in an archive called "the fappening" say a different story.
I'm sad that this is necessary.
Most comments here seem to of the "Good no one should write a web page that accesses bluetooth and I don't care if you want to do that".
This is sad for me because I would like to be able to write web pages that talk to smart turbo trainers and other health devices.
Now you might say why not write a app to do that but personally I prefer accessing stuff from web pages.
I find apps restrictive as a user. For example there is no way to block ads in an app and often no way to zoom or select text.
Again you might be fine with that but I just wanted to offer an alternative opinion.
I think it's about user expectations. As a user, when I'm browsing the web, I expect to be reading primarily text, with a hyperlink here and there, maybe some images. If I need to interact with the web site, I expect to see text input fields, a "submit" button of some sort, etc. When I click on a link and browse to another web page, I expect to see something similar: Hypertext, images, maybe a form field or two. I don't expect to have a peripheral attached to my computer get its firmware updated.
The APIs listed in the article are so far outside what I would expect to be a HTML browser's business. It's ridiculous. If I want to do any of these, I'll install an application to do them.
Installing an application is a nice speed bump. It's a deliberate action that the user has to take and think about. When I hand over my root password to my installer, or when my operating system asks me, "Do you really want to install this application?" it gives me the opportunity to pause and reflect on what I'm doing here. Who is the company behind this application? What access to my life am I giving it? Am I OK with running this application on my personal computer? Sometimes, after reflection, I hit cancel and get rid of the installer.
This whole contemplative speed bump goes away when rando web site written by rando developer, getting paid by collecting who-knows-what can suddenly do a Bluetooth scan or talk USB to one of my devices, merely by my issuing a GET request.
I think this is a pretty narrow vision of what the web can be. For example, text + hyperlinks excludes things like google maps and youtube, which are quite literally world changing pieces of technology.
For sure there is a balance to be struck in terms of how much access we allow other people to our phones and computers, but let's not kill off whole classes of novel applications before they've even had a chance to be built.
1 reply →
> ... web pages that talk to ... health devices ... there is no way to block ads in an app
Wait, what?? Why on earth would you use an app with ads for health devices?!?
Moreover, why on earth are you using apps with ads for anything?
Please, please, please, pay for your apps and games. Stop making everything an ad service. The race to the bottom in the web and mobile world is disturbing.
Would you want to pay for your house plumbing by being forced to watch an ad every time you shower? Think about how dystopian that sounds. There are even Black Mirror episodes on that.
> Wait, what?? Why on earth would you use an app with ads for health devices?!?
GP said they want to _write_ a web app that talks to health devices. And that they like the web platform because it's easy to block ads shown to you by other web apps.
I will add that it's also easier to detect/block tracking. Browsers such as Firefox even try to do this for you these days. And to generally examine what the app is doing (e.g. by running it in JS debugger).
Yes, paid apps usually (but not always) remove ads. They keep the telemetry, though.
> ... web pages that talk to ... health devices ... there is no way to block ads in an app
You’ve selectively mixed two paragraphs to change the meaning of what I actually said.
I did not say I want to use apps with ads with health devices, at all. That’s a complete straw man.
I said I want to access my own sports equipment via Bluetooth from a webpage I’ve written myself.
I also said that I dislike apps because the user looses control over things like tracking, selecting text, zooming and whether adverts are shown.
On the privacy end of things, ads certainly aren't helping, but a pretty large number of even paid apps are happily vacuuming up data and sending them to the developer and often third parties (vendors of analytics/debugging platforms in particular). I tend to think of an app for most things as a loss of privacy and try to avoid using them when possible.
1 reply →
There are many apps that continue to show ads even in their paid version / upgrade. Might not be an option for him?
1 reply →
Those APIs should not exist. Web site creators need to stop acting like they are entitled to access whatever they want on someone's computer.
I dont care about your unique SaS usecase, these are invasive. Make a native app if that's what you need.
Why is accessing this via a native app better than accessing it via web browser?
I am less likely to accidentally give you permission over my computer to do shady shit if I am forced to install an app vs happen to click the wrong link on my browser.
The difference is intent. By installing Chrome I do not intend on giving up every last bit of privacy and control over my computer, they just want to trick me into doing so by stuffing functionality into web APIs that should never have been web APIs in the first place.
10 replies →
I wouldn't have any problems giving these APIs access via the web, but one challenge with the websites is that I'm never 100% sure that when I "retract" a permission or say "stop tracking me" that it's done. I think that if access to these API's were wrapped in some sort of Privacy API that superseded each website's privacy and data collection polices I would be more comfortable with this. These changes just seem like something Google threw over the wall to get things working with Chrome and every other browser developer said "no thanks".
Creating these APIs doesn't just grant access to them to well-thought-out PWAs with a clear use case.
It grants access to every shady malware ad that wants to siphon your data and that of everyone around you.
7 replies →
From a tech point of view browsers are switching the roles of client and server. It's getting to be like X windows or something.
IMO, it's not the web-developers, it's the web-site owners. The devs (well, the small sample I know) is not interested in collecting user information to make a better fingerprint.
It's usually marketing teams who aren't thinking about privacy implications, just how to perpetuate or further engagement.
Seemingly innocuous features they devise to streamline engagement often come with huge privacy implications and I've had to shoot down ideas many times in my career that were well into the realm of creepy.
> Make a native app if that's what you need.
i.e. Make binary that includes a web browser just for this one web app.
Good. Those APIs were awful. If your website needs to know the battery status or other such information , you need to be writing an app which I will never download.
What if battery status was used to triage tasks? Wait to do something intensive if you’re low, etc. Seems like a respectful enhancement.
If theses APIs are only accessible with user consent, I don’t see the problem.
It's not easy. Mozilla ran into the privacy implications of the battery status API a couple of years ago: It was so precise that it allows the mentioned fingerprinting: https://www.schneier.com/blog/archives/2016/11/firefox_remov...
Every additional API added to the browser makes the risk of such side effects greater.
1 reply →
It's a choice between walled garden browser or walled garden market. The anti-trust lawsuit will probably be interesting.
I dont think you are going to see Apple get in to any anti trust. What you will see is Google get broken up, with Apple, Tencent, Huawei, Microsoft etc swooping in and buying those pieces up.
You need a strong single Apple so that we can have our singular place to buy smartphones.
1 reply →
There is a use case for that kind of API for PWA's that a user would install, e.g. fullscreen games or applications that change their behaviour if battery is low (or network is slow). But those are far and few between.
Really good move from Apple. Normally I don't see problems, but until we regulate ad tech, properties from this will be used for fingerprinting.
At least one of the API's listed (requestIdleCallback) is available behind the Experimental Features switch in Safari on iOS13.5
Apple seem to take a more cautious approach but it would be good to see some more of those API's available in Safari
We don't need a battery API but understanding whether a device is in low power mode would be useful
The listed "Idle Detection" is a different spec that is way more invasive than requestIdleCallback (which seems on track to be deployed more generally in Safari).
It's about detecting user idleness, including in the case the user has another tab active, not a way to queue and coalesce bits of work at an "idle" moment to optimise for latency and battery life.
The Idle Detection spec at https://github.com/WICG/idle-detection says it itself:
"As opposed to the requestIdleCallback, this is not about asynchronously scheduling work when the system is idle."
I'm really excited about the new permissions model that Apple is using. Perhaps in time -- after some testing -- they will gradually enable these APIs, as they are quite useful.
Nobody would care if Apple allowed other browsers on their mobile platforms. The problem isn't what APIs they do or don't support, it's their refusal to allow alternatives to WebKit.
Lot of people on this thread are saying that put these behind permissions and call it a day! You people don't understand that not everyone is tech savvy and understand permissions well. My dad keeps giving on permissions on any website asking on his Android device as he just wants to get rid of them.
Think about how many websites you visit and how many apps you install. I bet second number is way smaller than first one. When installing apps - you put some trust into app and lot of non tech people understand same (thankfully taught by antiviruses to not install random thing). People are not willing to install lot of apps but always willing to visit websites to "check it out".
Privacy fundamentally limits UX and there is direct trade-off. I believe Apple is doing right thing to protect privacy of millions of non tech people.
And you people don’t seem to understand that UX doesn’t need be the same. Websites can make the prompts default to no, even hiding them by default behind an icon.
There’s no reason you can’t make the UX cater to the use case such that it’s clear and secure by default.
It’s just tiring dealing with people who channel their hatred for JavaScript essentially into nerfing the only truly open platform we have, one with far better primitives than the native ones and with a massive potential that is only held back by the feet dragging of every major company (Google and Apple both).
Then you go to HN where you’d expect we could agree that a web that complemented apps if done well should exist, and instead we have nerds gaslighting other nerds using every fake reason they can find (my dad wouldn’t understand the notification, or, good because I don’t want powerful sites) when in reality they just lack any imagination that would easily allow them to have both worlds, thus keeping those who do have some imagination stuck in this special hell of having to re-make the same points over and over.
And better PWA support and notifications also privacy issue?
To their credit, those weren’t put on this list (which I was half expecting).
Browsers should just bundle all the advanced but privacy concerning APIs into a single App permissions dialog that you get on the domain you visit and that's it. That should include everything JS except simple DOM manipulations, so you don't have to completely disable it as most regular websites just need a few hover events and image carousels. When a website needs to be an app, the web can and should act as an application delivery platform with proper permission dialogs and installation prompts. Separate the concerns and you're done, instead of this farce, but of course when an OS company is focusing only on short-term revenue rather than empowering their users in the long run, they would be blind to solutions like these.
I still think the right way to do this stuff is to "support" the APIs but have them produce random data so the site cannot refuse to work if the API is not supported. The best way to deal with fingerprinters is to flood them with garbage.
I admit to a bit of head-scratching over some the comments here. The most common criticism on HN of Apple's approach to native iOS apps is the way they're locked down through sandboxing and various restrictions in the name of privacy. But a major criticism running throughout these comments of Apple's foot-dragging on supporting various Web APIs is that we should be using PWAs because, compared to native apps, they are locked down through sandboxing and various restrictions in the name of privacy. And... huh.
Yes, I get that in the first case it's Apple setting the restrictions and maintaining the control, and in the latter it's ostensibly open and not controlled by any one party. It's a good principle. But it's easy to forget that the first steps toward web apps were largely taken by Apple back in 2007, with Steve Jobs enthusiastically talking about the "sweet solution" they had for installing third party apps on the iPhone: web apps. There's a future we can imagine where if Apple had stuck to their guns and really ramped up their APIs, PWAs would have taken over mobile computing a decade ago. But they didn't, and the reason they didn't is because both developers and users hated them. Hated hated hated.
"But those web apps sucked and modern ones are much better!" Yes, I agree! But to users, the difference between going to the app store for their platform and downloading Twitter and going to the Twitter web site and tapping "Save as Web App" is pretty minimal, and there is no effective difference between the two once they're installed. Well, I take that back; I don't think a web app can provide a sharing extension, or be automated through Shortcut actions, or offer Siri suggestions. So actually, I'd rather have the real app still, thanks.
And, on point for privacy concerns, for me this isn't as much about "trusting Apple" as not trusting web sites. Yes, I'm sure there are valid reasons for all of these APIs to exist, but when push comes to shove, I'd rather go through the extremely mild inconvenience of having to download an iPad MIDI sequencer as a web app than discover that a web site -- or an advertisement on a web site -- has used that to track me or even deliver a malicious payload to me.
Why is it ok for native apps to do all such (and more) fingerprinting, utilized across apps, and not the web? Maybe I’m saying this backwards, why aren’t native apps given the same restrictions?
Because native apps are vetted by Apple.
And on the app install page there is verified data about the developer which you can use to contact/sue them if they violate your privacy. Good luck getting access to that information for a web app.
So many web developers keep pushing to give web the same power as native apps. "What's the difference between a PWA and native app? Why web cannot access the same api?"
So I want to ask another question: "What's the difference among knives, guns and missiles. Why almost everyone can buy a knife, but need a license to buy a gun, and may never able to buy a missile (even with enough funds)". One possible (and obvious )answer is because guns and missiles are more powerful than knives, we want to give them more restrictions.
Now can we reverse the logic and say, if we are able to decide the power of items, we should give items with less restriction less power? Let's limit our discussion on a mobile device, it's very easy to visit a website. But if you want to use a native app, you need to go to the app store, tap the download button, confirm, wait until the download is finished and the app is installed, and then finally open it. The app was also reviewed by the app store beforehand. This makes a difference. In fact, I think the ubiquity of web means we should never allow it to have the same power of what an native app can have.
And people are talking about the monopoly of apple. But if web become THE operating system one day, google will be a more dominant monopoly. They control both the implementation of the os (chrome) and the entry (search engine).
They surly can be used for fingerprinting, but they also can be guarded with requiring user opt in permission, one which maybe clearly informs the user how the API can be abused and warm them to only s allow it if they know what they are doing. Which is fine given that most usage are for more advanced use-cases. (Through some come from the Firefox OS use-case and might be better if not to be implemented as close to all current usage would be abuse, e.g. the proximity API).
Ubiquitous web midi support would enable a new and better round of patch management and sharing collaboration around music hardware. It's a shame it won't come to safari. For example see elk-herd for managing the Elektron digitakt.
> So far, Apple said it:
> - Removed support for custom fonts. This means only presenting built-in fonts which are the same for all users with the same system.
I really hate this. I'm opinonated on typography and rely on userscripts to replace fonts I think to be subpar (Arial, Times New Roman, etc.) with ones with higher quality. Since ~2 years ago Safari has lost the ability to designated any font with custom 'font-family: ' CSS other than built-in fonts, totally breaking my use case. I hadn't use Safari as my daily driver browser since then despite its privacy benefits.
So assuming these are standards pushed through the W3C process, is it fair to say Safari isn't standards compliant?
You could say something similar about Firefox then.
the bigger question is that why aren't these standards meeting privacy best practices in their API designs? Why are companies like Google influencing these standards so much ? In my opinion if that continues, we should disregard these so called "standards".
The page visibility API should be on the list.
It's none of your business if I'm looking at your page or not.
So if a page is running a computation in the background, for example, rendering some real time chart or something, you'd rather it continue to do work and waste battery life, then to throttle itself?
But then you'll say "well the browser should just throttle any tab i'm not looking at" (which it already does), but then you'll complain the first time an app you actually want live updating doesn't work properly.
> So if a page is running a computation in the background, for example, rendering some real time chart or something, you'd rather it continue to do work and waste battery life, then to throttle itself?
Yep, that's the behaviour I expect. If I want you to stop I'll close you.
> But then you'll say "well the browser should just throttle any tab i'm not looking at"
Why would I say that? I explicitly don't want pages to act differently when I'm not looking at them. If they're updating when I'm looking at them then they should keep doing that when I flick away to something else.
It's a privacy issue and it's a functionality issue. It's literally none of the page's business whether I have it in view or not.
Next you'll be telling me that pages should be able to use the camera and face sensing tech in smartphones to detect if I'm looking in the right direction. For my convenience of course, nothing to do with advertising, tracking, analytics...
FYI I've managed to find an addon for firefox that blocks this API. No noticeable difference in battery life.
4 replies →
> Magnetometer API - Allows websites to access data about the local magnetic field around a user, as detected by the device's primary magnetometer sensor.
I have never heard of this API, what's a use case for it?
If you had access to the magnetometer, you could make a navigation compass. Or, you could animate a map to rotate as the phone rotates. It might be good for implementing a GeoCaching helper app as a website.
The same as with native apps, sensing the device's orientation. For AR, navigation, what have you.
Good; and to those saying "why not just make it an opt-in pop-up". How do you feel about cookie pop-ups?
I bet you just click accept, I know I do.
Accept cookies, yes; but decline the requests for the sites to send me push notifications. And decline when Google asks me to enable geolocation if I don't want to.
And of course I just leave the site if it gets obnoxiously needy and invasive.
I usually click no for microphone and camera requests unless I need it... I bet you do too
I assume this means that APIs such as https://developer.apple.com/documentation/uikit/uidevice/162... are not available for their instant apps (the so called "Clips") ?
This is not related to developing App Clips, just Safari. (Aside -not sure why you're using such a derisive tone with that 'so called' stuff - companies name technologies for many good reasons, so just go ahead and use the name.)
And yet there's still no reason why they won't add Web Notifications to iOS Safari.
So, basically, Apple users are doomed to stay inside their walled garden in the sake of privacy (which mostly means that Apple is reserving access to their private data solely for itself). No functional-rich PWAs for them. Well, it is always people's (customer's) choice.
besides the nfc api, which might be feasible with a good privacy the api's are simple not needed.
nfc would be a good idea to make authentication over nfc devices feasible or nfc checkout. we basically developed a native app, just because we needed to access an nfc reader for "tag" authentication. it does not more things. printing works over ipp, server-side.
the app basically does two things: - nfc reading - barcode scanner reading (basically they work like a hid keyboard device, so it doesn't really use any hid device driver or anything, we just detect it by watching how much keystrokes per ms are coming in. (which would be possible with in a webapp, aswell)
hn miss the old internet where content is the king
hn also ask for more apis that make the internet such a shithole today, so we can make more useless web "apps".
Gopher is what you’re after.
How a proximity sensor can be used for fingerprinting?
Everything on this list seems like it would be extremely useful in tracking people. The approximate memory API? That, along with geolocation, could effectively unmask you across the web.
It can certainly help tracking but the measure is very coarse. Basically an enum of 6 values.
Safari has been my primary browser for a few years now. Nothing beats the performance on macOS and no other tech giant is going to respect and fight for your privacy the way Apple does.
Here is Apple making it harder for the web to compete with closed wall gardens. Web apps could require the same permissions for accessing hardware as mobile apps do. On Firefox, when a website wants access my webcam, it asks me, for example...
On Safari, when a website wants access to my webcam, it asks me.
Cool, so Apple "can" add features to Safari. They should add more.
2 replies →
ok, so they just want to take the choice out of the user's hands
Cute how Apple wants to make their "users" believe they have an exclusive deal on breaching their privacy.
What possible motivation would Apple have for doing this.
They aren't an advertising company and they make money from selling hardware not from selling data.
Apple has been increasing displaying rent seeking behavior more and more recently. They're not just trying to make money from HW.
Im pretty sure that the NSA pays Apple for the data that they get but I am unsure if Apple sells it to anyone else.
Ahhhh the new Internet Explorer...
Wrong story, this one isn’t about Chrome.