
Apple declined to implement 16 Web APIs in Safari due to privacy concerns - coronadisaster
https://www.zdnet.com/article/apple-declined-to-implement-16-web-apis-in-safari-due-to-privacy-concerns/
======
jamesgeck0
> 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
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...](https://www.midi.org/specifications-
old/item/table-2-expanded-messages-list-status-bytes)

Full Disclosure: I made a web synth and really want to be able to use midi to
play with it.

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

~~~
seph-reed
This is just a philosophical standpoint, but I think supporting the interests
a small group of experimental pioneers is generally more useful than their
numbers would imply.

The idea that "staggering few" is a negative disappoints, given it has almost
always been the "staggering few" who've progressed humanity.

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

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

~~~
cj
I think you’re trying to say that Mac OS or Windows native apps have pretty
much the same UI/UX conventions which makes it easy to use any app on that
platform. And that Web Apps have UI/UX that is less consistent than apps
across OS’s.

I can’t say I agree with this. There are a ton of MacOs apps that implement
fully custom GUI (first one that comes to mind is Jira native Mac app which
looks nothing like a Mac app I’ve seen before)

I agree web apps are likely eroding OS conventions though. The Jira app is an
example of that (they decided to make their native app look and behave the
same as the Jira Web App instead of using standard MacOS GUI conventions.

It’s a tough trade off.

~~~
millstone
Yeah and Spotify is another one. Electron is clearly at work here, probably in
your Jira example too.

These apps are frustrating for someone accustomed to the Mac UI. Basic
interactions (like context menus) don't work at all, or work in unexpected
ways. I have no idea what these apps can do because they all have a unique UI
vocabulary. So I don't try.

I think Apple has really dropped the ball on this. They ought to have spotted
and embraced the web's great strengths early. Ephemeral, zero-install apps,
using native components - that's the platform I want. Though I understand how
others may disagree.

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

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

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

~~~
mikewhy
Why would I use the Twitter app, when I can get the same out of the PWA and
not have to download a hundred meg update every week for "bug fixes and
improvements"?

~~~
Eugeleo
Maybe in the case of Twitter it makes sense (I'm not using Twitter myself),
but in general, as the OP notes, the UX is worse with PWAs than it is with
native apps. So, to rephrase your comment to reflect this

> Why would I use the app, when I can get /something worse but workable/ out
> of the PWA and not have to download a hundred meg update every week

And then the answer might be --- because your phone has 128 gigs of memory,
your home wi-fi has unlimited bandwidth, and the updates all get downloaded
automatically while you're sleeping, you might decide to go for the better UX
in exchange for _nothing at all_.

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

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

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

~~~
Sayrus
I don't want _most_ websites doing this. There are some websites (especially
PWA) where they are definitely useful and can replace a heavy client.

Maybe it shouldn't "asking for permission" but "giving your permission"
explicitly. If you don't need such an API, you would never be bothered by it
if the model is opt-in without notification/popups.

I understand the problem you have with websites asking for permissions,
especially push notifications permissions, as they keep showing up. And I do
definitely agree that having a website that does not need any of these
permissions ask for it would be even more annoying but there are definitely
cases where I'm glad a website can help me out (and I don't have to download a
heavy client that might or might not have tracking and analytics in it)

~~~
ornxka
>There are some websites (especially PWA) where they are definitely useful and
can replace a heavy client.

How can this be so when the web browser itself is a heavy client?

~~~
josephcsible
Unless you only use one such website ever, then it's a win for the browser to
be the heavy client instead of having separate ones for each.

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

~~~
saagarjha
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!

~~~
cromwellian
Then don't. But if a web form at a coffee place wants to ask you for payment,
it should be able to call up the WebPayment API to ask for one time
permission, to which you can acknowledge. I shouldn't need a native app to do
it.

And once you acknowledge that asking for access to spend your credit card is
ok on the Web (and it is, because Apple supports the W3C Payment Request API),
why do you think it is far worse to plug into a USB device, and be prompted to
ask if your Web page can access it. There are any number of reasons to do
this, like Arduino projects, IoT devices, etc.

I use a Chrome app that lets me install APKs over USB thanks to this API.
Super helpful for installing built artifacts from a Continuous Integration
result page for example.

Or maybe you're at an airport, or your company, and you want interact with a
vending machine through NFC or BlueTooth. Why is a one-off permission tied to
that one use any worse than the previous example of payment approval.

Most of the people responding on HackerNews seem to think Web apps can use
these APIs without requesting user permission.

~~~
millstone
> I use a Chrome app that lets me install APKs over USB thanks to this API

What the fuck.

> Most of the people responding on HackerNews seem to think Web apps can use
> these APIs without requesting user permission.

Nobody will have malware sideloaded because it requires clicking an OK button?

Most of the web is scams. Search for _anything_ and most links will be scams.
From that perspective, these APIs are profoundly reckless.

~~~
cromwellian
You can’t side load something by clicking an OK button, you have to put your
phone into developer mode and click a “trust this computer” dialog on your
computer AND also click ok in the browser.

And yes, if you have a continuous integration system building your binaries in
the cloud it is helpful to be able to install them without going through a
damn store process. You are installing your OWN apks that you compiled with
this extension I’m talking about.

>most of the we is scans

Talk about hyperbole. The only time I’ve ever encountered harmful scams is
when I searched for pirated content.

The web is the most useful human invention since the PC era. Most of peoples
time in apps is spent in social media consumption. I’ll take web content over
TikTok and Instagram any day.

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

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

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

~~~
buzzerbetrayed
> You pay 1000$ because that is what people is willing to pay.

And they are willing to pay that, at least in part, because

> the manufacturer protects you from these risks

Not sure what point you're trying to make. Your logic is circular.

~~~
jfkebwjsbx
The average customer is not paying 1000$ for getting "protection from those
risks", and it is that customer that drives the price, not the average user in
HN.

And that is assuming they are trying to "protect you", but that is a different
discussion.

~~~
buran77
> they are trying to "protect you"

They certainly are trying to protect you but I am not naive to think it's out
of the kindness of their corporate heart. It's because that's what many people
want right now. Apple tried to compete with Google and Facebook at their own
game, predictably lost, so changed the rules of the game. Which was a
brilliant strategy and if next year they change their stance I will happily
reconsider my opinion.

And people don't have to know explicitly every feature and how it's achieved
technically. The phone is now almost a commodity, like toothpaste. You buy one
because that manufacturer built a trust. You probably buy Colgate, Sensodyne,
or OralB (Crest). But not because you carefully analyzed their chemical
composition, or pored through study after study. You just trust one, a friend
or dentist recommended it, it just works for you, and so on.

That protection the phone affords you may not be immediately apparent but
enough people start noticing eventually even if they don't understand the
underlying technical part.

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

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

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

~~~
jfkebwjsbx
> a pretty large number of even paid apps are happily vacuuming up data and
> sending them to the developer and often third parties

Please name some examples. I certainly do not have not use nor know about any
paid software that "vacuums" my actual data or tries to track me.

> analytics/debugging platforms

You cannot compare anonymous, aggregate details about overall usage of an app
or crash stacktraces (which is what most paid/OSS apps do) to the kind of
identification webs do for ads.

Again: native apps do not care about showing personalized ads to you nor their
business depends on it.

> I tend to think of an app for most things as a loss of privacy

Mobile apps from vendors like Facebook definitely. Normal paid/OSS desktop
software, no.

------
coronadisaster
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
On Safari, when a website wants access to my webcam, it asks me.

~~~
jonny_eh
Cool, so Apple "can" add features to Safari. They should add more.

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

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

~~~
azangru
Why is accessing this via a native app better than accessing it via web
browser?

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

~~~
MaxBarraclough
I don't follow this line of thinking at all.

If you're questioning whether they're trustworthy, you should be going out of
your way to _avoid_ installing their native app, preferring a web-based
solution instead.

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

Is Chrome really so bad about accidentally granting privileges (webcam, say)
to websites?

Perhaps there's a more privacy-oriented browser that lacks such functionality
entirely? Sounds like a good idea, come to think of it.

~~~
evgen
That is just the point. I can avoid installing their native app, but it is
much more difficult to opt out of these insidious and unnecessary web APIs.
This is especially the case when the leading browser happens to be created by
a data collection company.

Yes, Chrome is bad at managing privileges and leaking data back to Google and
any other web site that is smart enough to know how to ask for it. Avoiding
browsers that implement this and shaming sites that use the APIs is apparently
the approach that will be necessary going forward.

~~~
MaxBarraclough
> it is much more difficult to opt out of these insidious and unnecessary web
> APIs

I don't know what you mean by this. A native app has far more access to your
machine than a website has. If you've installed untrusted native code, it's
game over.

Are you thinking of web-trackers like the infamous Facebook 'Like' button
tracking you around the web? We have a solution to that, and it doesn't
involve trusting native apps. Firefox Containers sound like just the ticket.
[0]

> This is especially the case when the leading browser happens to be created
> by a data collection company.

> Avoiding browsers that implement this and shaming sites that use the APIs is
> apparently the approach that will be necessary going forward.

As far as I know Chrome doesn't leak browsing data back to Google any more
than any other browser, not counting features like auto-complete. If you want
a Google-free browser, though, you can either go with Firefox, or a Firefox
derivative, or go with an alternative like 'ungoogled-chromium' [1]

As for shaming, I have very little confidence that this could work. The
'cookie law' gave websites the choice between not using tracking cookies, or
showing a popup announcing to the user that the website uses tracking cookies.
In response, virtually the entire web now shows a popup announcing their use
of tracking cookies. Many of us thought the law would have a sort of shaming
effect, but it didn't.

 _edit_ I'm ignoring the option to click the 'Deny' button that the popups are
required to give. I wonder how many people click to deny. I don't think I've
ever seen hard numbers.

[0] [https://addons.mozilla.org/en-GB/firefox/addon/multi-
account...](https://addons.mozilla.org/en-GB/firefox/addon/multi-account-
containers/)

[1]
[https://news.ycombinator.com/item?id=18053079](https://news.ycombinator.com/item?id=18053079)

~~~
phkahler
>> it is much more difficult to opt out of these insidious and unnecessary web
APIs > I don't know what you mean by this. A native app has far more access to
your machine than a website has. If you've installed untrusted native code,
it's game over.

You're either trolling or clueless. Everyone needs a web browser. There are
basically 2 of them. These are used (or necessary) to access a lot of things
in today's world, from ordering a pizza to accessing government publications.
Nobody NEEDS one particular web app. We can avoid installing apps, but not
standards compliant web browsers.

~~~
MaxBarraclough
You seem to be agreeing with me, yet you're accusing me of either trolling or
being clueless.

If you use Firefox Containers, you avoid untrusted native code, _and_ you
avoid persistent cookies tracking you around the web.

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

~~~
pcmaffey
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
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...](https://www.schneier.com/blog/archives/2016/11/firefox_removin.html)

Every additional API added to the browser makes the risk of such side effects
greater.

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

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

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

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

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

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

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

------
aogaili
And better PWA support and notifications also privacy issue?

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

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

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

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

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

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

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

~~~
sdfhbdf
You could say something similar about Firefox then.

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

~~~
Nursie
I am at least asked permission for camera use, as far as I know. Not so for
the visibility API.

If gaze tracking or camera access is to be allowed without permission, I would
consider that a gross violation of privacy.

~~~
cromwellian
Well many of the APIs Apple rejected asked for permission.

If asking permission is what it takes for Safari to implement something than
they could suggest a modification with permissions.

Flat out rejecting everything comes across as Microsoft style aggression back
when MS was actively seeking to kill open platforms in favor proprietary APIs.

Apple could even suggest tying permissions into the App Store and require web
domains to be signed and approved by app stores for the permissions to work,
but not presenting alternative proposals suggests they are not interested in
making the Web better.

The whole App clips thing is kind of ludicrous because it’s a text book
example (eg paying a parking meter) that the Web model excels at. The fact
that they didn’t choose the web for that is telling. WeChat for example has
deployed such mini apps for years in China to support interactions with
vending machines, restaurants, etc by simply scanning a QR code. It works
brilliantly and didn’t need an App Store.

~~~
Nursie
But the argument there is also quite reasonable - the UX of popping up boxes
for this stuff is terrible, it annoys people and they just start clicking
"Yes" all the time or "no" all the time.

And this is because, while there clearly are good and valid web apps that use
this functionality, the web is also a cesspit of abusers who will use any
means they can to track, trace and infiltrate.

I don't know what the solution is, suffice to say I haven't really seen a good
one yet, and until such time as one comes along I am happy using a browser
that either lets me turn this stuff off in a blanket fashion or flat out
doesn't include it.

Mildly lower friction on payment apps is not enough of a trade-off

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

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

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

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

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

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

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

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

------
larme
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
Gopher is what you’re after.

------
EugeneOZ
How a proximity sensor can be used for fingerprinting?

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

------
ed25519FUUU
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
It can certainly help tracking but the measure is very coarse. Basically an
enum of 6 values.

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

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

------
traveler01
Ahhhh the new Internet Explorer...

~~~
acheron
Wrong story, this one isn’t about Chrome.

