31 ms·

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

428 points by coronadisaster 6y ago

raxxorrax 6y ago
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.
manishsharan 6y ago
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.
- WrtCdEvrydy 6y ago
  It's a choice between walled garden browser or walled garden market. The anti-trust lawsuit will probably be interesting.
  - bilal4hmed 6y ago
    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.
    - WrtCdEvrydy 6y ago
      Bundling of the browser to the platform and making other browsers non-viable is probably covered under the previous Microsoft case law.
- Cthulhu_ 6y ago
  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.
- pcmaffey 6y ago
  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.
  - cstuder 6y ago
    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_removin.html 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.
    - lopis 6y ago
      > It was so precise Then make it less so. Browser APIs can - and do - lie to their users. For example, if you try to query the color of a visited link, you won't get the actual color, but instead you get the default link color. This is to prevent an old bug that let you basically harvest a user's browsing history.
youngtaff 6y ago
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
- johnhenry 6y ago
  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.
- nnx 6y ago
  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 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."
deleted 6y ago
[deleted]
aogaili 6y ago
And better PWA support and notifications also privacy issue?
- johncolanduoni 6y ago
  To their credit, those weren’t put on this list (which I was half expecting).
coronadisaster 6y ago
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...
- selectodude 6y ago
  On Safari, when a website wants access to my webcam, it asks me.
  - coronadisaster 6y ago
    ok, so they just want to take the choice out of the user's hands
  - jonny_eh 6y ago
    Cool, so Apple "can" add features to Safari. They should add more.
    - sixstringtheory 6y ago
      That's one opinion. Another opinion is that they don't have to implement "standards" that other companies come up with just so they can further infiltrate the systems in place on their platform. Who says Apple shouldn't just make Safari a hypertext-only browser and let the consumers vote with their wallets and their feet? Honestly I'd prefer that.
      - jonny_eh 6y ago
        > Who says Apple shouldn't just make Safari a hypertext-only browser and let the consumers vote with their wallets and their feet? Me! I'm a consumer with a wallet and feet. And I would like Safari to have more features.
philistine 6y ago
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-ads/ https://9to5mac.com/2019/12/09/apple-safari-privacy-feature-...
- Sayrus 6y ago
  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/ https://audiofingerprint.openwpm.com/ [2] https://github.com/mozilla/OpenWPM https://github.com/mozilla/OpenWPM
  - reaperducer 6y ago
    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?
- needAnAltHN 6y ago
  "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.
- fastball 6y ago
  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.
dathinab 6y ago
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).
phkahler 6y ago
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.
- tgv 6y ago
  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.
  - cptskippy 6y ago
    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.
- azangru 6y ago
  Why is accessing this via a native app better than accessing it via web browser?
  - evgen 6y ago
    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.
    - azangru 6y ago
      > The difference is intent. By installing Chrome I do not intend on giving up every last bit of privacy and control over my computer You make it sound as if Chrome will expose your private data and the control over your computer to everyone who cares to use it. Aren't you in control over what you allow to access on the per-site basis?
dijit 6y ago
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.
- azangru 6y ago
  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.
- coronadisaster 6y ago
  I usually click no for microphone and camera requests unless I need it... I bet you do too
flanbiscuit 6y ago
> 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?
- Sharlin 6y ago
  The same as with native apps, sensing the device's orientation. For AR, navigation, what have you.
- alexdw_mgzi 6y ago
  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.
merb 6y ago
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)
deleted 6y ago
[deleted]
j-pb 6y ago
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.
- girst 6y ago
  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/ https://mozilla.github.io/standards-positions/ [2]: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...
  - j-pb 6y ago
    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.
    - girst 6y ago
      >because the existing implementation was too mature. That's not what I gathered from their official response to the deprecation[1]. But the major problem with WebSQL for Mozilla seems to be this: >We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don’t want changes to SQLite to affect the web later edit: and once again: security might have been a deciding factor, too[2]. [1]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... [2]: https://news.ycombinator.com/item?id=18685296 https://news.ycombinator.com/item?id=18685296
traveler01 6y ago
Ahhhh the new Internet Explorer...
- acheron 6y ago
  Wrong story, this one isn’t about Chrome.
Lio 6y ago
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.
- ryandrake 6y ago
  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.
  - remus 6y ago
    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.
dreamcompiler 6y ago
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.
deleted 6y ago
[deleted]
Jyaif 6y ago
I assume this means that APIs such as https://developer.apple.com/documentation/uikit/uidevice/1620042-batterylevel https://developer.apple.com/documentation/uikit/uidevice/162... are not available for their instant apps (the so called "Clips") ?
- djrogers 6y ago
  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.)
jamesgeck0 6y ago
> 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 https://github.com/mozilla/standards-positions/issues/58
- seph-reed 6y ago
  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-expanded-messages-list-status-bytes 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.
  - anyfoo 6y ago
    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.
  - strbean 6y ago
    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.
msoad 6y ago
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.
- nojito 6y ago
  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.
  - untog 6y ago
    I don't really understand: the PWA APIs are W3C APIs, they're not created by one company. Mozilla fully supports them.
    - ocdtrekkie 6y ago
      Just because they're standards doesn't mean they aren't standards written and promoted chiefly by Google. Mozilla also has pushed back on some of them, despite the fact that... Mozilla supporting them isn't a good argument since most of their revenue also comes from, you guessed it: Google.
      - asjw 6y ago
        I don't have to go full PWA to make useful apps And don't have to go through an app store, creating an account, paying Apple, waiting for their opaque reviews and giving them 30% of whatever amount I make through my app. Android has Firefox, thanks to Apple iOS doesn't.
EugeneOZ 6y ago
How a proximity sensor can be used for fingerprinting?
postalrat 6y ago
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.
ed25519FUUU 6y ago
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.
- yoz-y 6y ago
  It can certainly help tracking but the measure is very coarse. Basically an enum of 6 values.
dancemethis 6y ago
Cute how Apple wants to make their "users" believe they have an exclusive deal on breaching their privacy.
- threeseed 6y ago
  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.
  - cromwellian 6y ago
    Apple has been increasing displaying rent seeking behavior more and more recently. They're not just trying to make money from HW.
  - coronadisaster 6y ago
    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.
thayne 6y ago
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.
- chvid 6y ago
  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.
  - mavhc 6y ago
    Isn't Google the one implementing all these APIs though?
    - thayne 6y ago
      But for google, the benefits of having richer web apps on which they can show you ads and have app developers pay google for ads may be more valuable than any revenue they lose from the app store.
      - cthaeh 6y ago
        Or, google isn't as anti-competitive and anti consumer as apple. what a shocker.
Nursie 6y ago
The page visibility API should be on the list. It's none of your business if I'm looking at your page or not.
- cromwellian 6y ago
  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.
  - Nursie 6y ago
    > 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.
    - cromwellian 6y ago
      > Next you'll be telling me that pages should be able to use the camera They already do have access to the camera through the getUserMedia APIs, and WebXR has Gaze Tracking. Even your iPhone allows camera access through the Web.
SergeAx 6y ago
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.
tekstar 6y ago
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.
whalesalad 6y ago
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.
chipotle_coyote 6y ago
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.
darrinm 6y ago
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?
- threeseed 6y ago
  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.
larme 6y ago
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".
- m0xte 6y ago
  Gopher is what you’re after.
systemvoltage 6y ago
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.
- cromwellian 6y ago
  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.
dheerendra73 6y ago
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.
- nwienert 6y ago
  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.
skc 6y ago
So assuming these are standards pushed through the W3C process, is it fair to say Safari isn't standards compliant?
- suyash 6y ago
  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".
- sdfhbdf 6y ago
  You could say something similar about Firefox then.
larme 6y ago
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).
kennydude 6y ago
And yet there's still no reason why they won't add Web Notifications to iOS Safari.
stagas 6y ago
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.
firexcy 6y ago
> 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.

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.

manishsharan 6y ago

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.

WrtCdEvrydy 6y ago
It's a choice between walled garden browser or walled garden market. The anti-trust lawsuit will probably be interesting.
- bilal4hmed 6y ago
  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.
  - WrtCdEvrydy 6y ago
    Bundling of the browser to the platform and making other browsers non-viable is probably covered under the previous Microsoft case law.
Cthulhu_ 6y ago
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.
pcmaffey 6y ago
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.
- cstuder 6y ago
  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_removin.html 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.
  - lopis 6y ago
    > It was so precise Then make it less so. Browser APIs can - and do - lie to their users. For example, if you try to query the color of a visited link, you won't get the actual color, but instead you get the default link color. This is to prevent an old bug that let you basically harvest a user's browsing history.

youngtaff 6y ago

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

johnhenry 6y ago
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.
nnx 6y ago
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 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."

deleted 6y ago

[deleted]

aogaili 6y ago

And better PWA support and notifications also privacy issue?

johncolanduoni 6y ago
To their credit, those weren’t put on this list (which I was half expecting).

coronadisaster 6y ago

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

selectodude 6y ago
On Safari, when a website wants access to my webcam, it asks me.
- coronadisaster 6y ago
  ok, so they just want to take the choice out of the user's hands
- jonny_eh 6y ago
  Cool, so Apple "can" add features to Safari. They should add more.
  - sixstringtheory 6y ago
    That's one opinion. Another opinion is that they don't have to implement "standards" that other companies come up with just so they can further infiltrate the systems in place on their platform. Who says Apple shouldn't just make Safari a hypertext-only browser and let the consumers vote with their wallets and their feet? Honestly I'd prefer that.
    - jonny_eh 6y ago
      > Who says Apple shouldn't just make Safari a hypertext-only browser and let the consumers vote with their wallets and their feet? Me! I'm a consumer with a wallet and feet. And I would like Safari to have more features.

philistine 6y ago

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-ads/ https://9to5mac.com/2019/12/09/apple-safari-privacy-feature-...

Sayrus 6y ago
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/ https://audiofingerprint.openwpm.com/ [2] https://github.com/mozilla/OpenWPM https://github.com/mozilla/OpenWPM
- reaperducer 6y ago
  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?
needAnAltHN 6y ago
"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.
fastball 6y ago
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.

dathinab 6y ago

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

phkahler 6y ago

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.

tgv 6y ago
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.
- cptskippy 6y ago
  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.
azangru 6y ago
Why is accessing this via a native app better than accessing it via web browser?
- evgen 6y ago
  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.
  - azangru 6y ago
    > The difference is intent. By installing Chrome I do not intend on giving up every last bit of privacy and control over my computer You make it sound as if Chrome will expose your private data and the control over your computer to everyone who cares to use it. Aren't you in control over what you allow to access on the per-site basis?

dijit 6y ago

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.

azangru 6y ago
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.
coronadisaster 6y ago
I usually click no for microphone and camera requests unless I need it... I bet you do too

flanbiscuit 6y ago

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

Sharlin 6y ago
The same as with native apps, sensing the device's orientation. For AR, navigation, what have you.
alexdw_mgzi 6y ago
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.

merb 6y ago

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)

deleted 6y ago

[deleted]

j-pb 6y ago

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.

girst 6y ago
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/ https://mozilla.github.io/standards-positions/ [2]: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...
- j-pb 6y ago
  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.
  - girst 6y ago
    >because the existing implementation was too mature. That's not what I gathered from their official response to the deprecation[1]. But the major problem with WebSQL for Mozilla seems to be this: >We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don’t want changes to SQLite to affect the web later edit: and once again: security might have been a deciding factor, too[2]. [1]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis... [2]: https://news.ycombinator.com/item?id=18685296 https://news.ycombinator.com/item?id=18685296

traveler01 6y ago

Ahhhh the new Internet Explorer...

acheron 6y ago
Wrong story, this one isn’t about Chrome.

Lio 6y ago

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.

ryandrake 6y ago
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.
- remus 6y ago
  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.

dreamcompiler 6y ago

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.

deleted 6y ago

[deleted]

Jyaif 6y ago

I assume this means that APIs such as https://developer.apple.com/documentation/uikit/uidevice/1620042-batterylevel https://developer.apple.com/documentation/uikit/uidevice/162... are not available for their instant apps (the so called "Clips") ?

djrogers 6y ago
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.)

jamesgeck0 6y ago

> 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 https://github.com/mozilla/standards-positions/issues/58

seph-reed 6y ago
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-expanded-messages-list-status-bytes 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.
- anyfoo 6y ago
  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.
- strbean 6y ago
  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.

msoad 6y ago

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.

nojito 6y ago
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.
- untog 6y ago
  I don't really understand: the PWA APIs are W3C APIs, they're not created by one company. Mozilla fully supports them.
  - ocdtrekkie 6y ago
    Just because they're standards doesn't mean they aren't standards written and promoted chiefly by Google. Mozilla also has pushed back on some of them, despite the fact that... Mozilla supporting them isn't a good argument since most of their revenue also comes from, you guessed it: Google.
    - asjw 6y ago
      I don't have to go full PWA to make useful apps And don't have to go through an app store, creating an account, paying Apple, waiting for their opaque reviews and giving them 30% of whatever amount I make through my app. Android has Firefox, thanks to Apple iOS doesn't.

EugeneOZ 6y ago

How a proximity sensor can be used for fingerprinting?

postalrat 6y ago

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.

ed25519FUUU 6y ago

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.

yoz-y 6y ago
It can certainly help tracking but the measure is very coarse. Basically an enum of 6 values.

dancemethis 6y ago

Cute how Apple wants to make their "users" believe they have an exclusive deal on breaching their privacy.

threeseed 6y ago
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.
- cromwellian 6y ago
  Apple has been increasing displaying rent seeking behavior more and more recently. They're not just trying to make money from HW.
- coronadisaster 6y ago
  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.

thayne 6y ago

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.

chvid 6y ago
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.
- mavhc 6y ago
  Isn't Google the one implementing all these APIs though?
  - thayne 6y ago
    But for google, the benefits of having richer web apps on which they can show you ads and have app developers pay google for ads may be more valuable than any revenue they lose from the app store.
    - cthaeh 6y ago
      Or, google isn't as anti-competitive and anti consumer as apple. what a shocker.

Nursie 6y ago

The page visibility API should be on the list. It's none of your business if I'm looking at your page or not.

cromwellian 6y ago
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.
- Nursie 6y ago
  > 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.
  - cromwellian 6y ago
    > Next you'll be telling me that pages should be able to use the camera They already do have access to the camera through the getUserMedia APIs, and WebXR has Gaze Tracking. Even your iPhone allows camera access through the Web.

SergeAx 6y ago

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.

tekstar 6y ago

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.

whalesalad 6y ago

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.

chipotle_coyote 6y ago

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.

darrinm 6y ago

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?

threeseed 6y ago
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.

larme 6y ago

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

m0xte 6y ago
Gopher is what you’re after.

systemvoltage 6y ago

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.

cromwellian 6y ago
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.

dheerendra73 6y ago

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.

nwienert 6y ago
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.

skc 6y ago

So assuming these are standards pushed through the W3C process, is it fair to say Safari isn't standards compliant?

suyash 6y ago
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".
sdfhbdf 6y ago
You could say something similar about Firefox then.

larme 6y ago

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

kennydude 6y ago

And yet there's still no reason why they won't add Web Notifications to iOS Safari.

stagas 6y ago

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.

firexcy 6y ago

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