Apple: We're defending your privacy by nixing 16 browser APIs. Rivals: You mean defending your bottom line Apple has said it has decided not to implement 16 web APIs in its Safari browser's WebKit engine in part because they pose a privacy threat. Critics of the iGiant, including competitors like Google, see Apple's stance as a defense against a competitive threat. These APIs, developed in recent years to allow web developers to …
Apple do seem to be one of the only major tech players out there that are also genuinely concerned about user and device security. Sure, they don't get it right all of the time (and have made some glaring errors other the years), but they do try, do learn and are will to stand up to "big brother" state intervention.
Yes, and for nearly 2 decades consistently, but more for Virtue-Display purposes than actually caring about the user.
Example: I finally broke and bailed out of the make-you-cry subfunctionality vs MacOS that is Mac OS X, at version {Lion? 10.6?}, due to a similar Apple spasm. I'd been 1 of 3 tech guys on the London & Oxford Uni Mac User Groups, and Lion suddenly disappeared everyone's NASs. Unreachable, invisible. Turned out Apple'had unilaterally decided everyone should have then-military-grade security on NASs, and had created a mini-firewall to block any then-normal consumer-grade NAS.
No warning, no recovery.
The only way I found round it was to get a "correct" NAS disk and plug it in, at which point the daemon opened up fully its API, so you could tweak its config manually via shell, and add to the firewall's whitelist the old NAS's protocol.
It was like a piss-take on everything that MacOS was specifically designed and intended to let users not have to do. And I'd hit too many of them unremittingly since Panther 10.3 (Mac OS X's UI peak). I finally broke, finally ran out of camels, broadcast my fix then bailed out from both lists after ~10yrs with apologies. Every contact with Mac OS X since then has only underscored that it was the right decision -- it just gets worse and worse. User-contempt, as a corporate policy.
What good things are you going to do in a web app that you can't do in an app, or you can't do an app because Apple wouldn't approve it?
Measure that against the massive privacy violation of being able to be tracked in public places that have bluetooth beacons set up. Not to mention the potential for an evil web site (or one that has been compromised by malware) to attack or bug your bluetooth devices. Just because you can think of a few useful things you could do with it doesn't make the API any less of a security and privacy nightmare. I can think of a few positive outcomes if the FBI had a copy of keys to everyone's phone, but that doesn't mean I support that either.
Google just thinks they can create all sorts of privacy violating APIs and force them on people because they have the dominant PC browser, which will soon also be the dominant mobile browser on the dominant mobile OS. They're pissed that they aren't able to dictate standards like Microsoft used to, and people are seeing through their shenanigans so they're trying to frame the argument in a way that makes Apple look like the bad guy - ignoring that Firefox is also not on board with this stuff.
Whether you attribute this particular stand to Apple being on the side of privacy, or to Apple being on the side of walled gardens, and whether or not you ever use an Apple product at all you should thank them for standing in the way of this crap. You could have made the same argument when Jobs refused to support Flash and said only was only trying to protect their App Store, but in starting the avalanche that took down Flash they ended up rescuing the PC/Android world from that security nightmare.
Had Apple blindly supported Flash on iOS it would still be very much with us today. Probably have had a lot of "helpful" extensions added to it over the years that did stuff like interface with bluetooth and provide a list of wireless networks are near for the Flash app's author to use for tracking, and sale to data brokers. And all with Adobe's famous attention to security!
So you don't think there are any cross platform web apps that might need Bluetooth access?
How about a catering system that wants to print a reciept or talk to a kitchen display system? How well do you think it goes down when we tell US clients they can't use an iPad because Apple have crippled the Bluetooth in the exceedingly expensive devices they already bought?
> you can't do an app because Apple wouldn't approve it?
Well we could try telling customers that because they have iPads our 1% cut will need to be 31% so we can publish an app but somehow I don't think that is going to go well.
This is entirely down to Apple protecting their walled garden and it does break valid developer requirements.
PS: Flash is still with us today - it still exists, still gets updates and, annoyingly, some websites still require it to play video.
> So you don't think there are any cross platform web apps that might need Bluetooth access?
I personally think there shouldn't be any web apps that might need Bluetooth access. Much like there shouldn't be any TV shows (for instance) that need Bluetooth. It's pure unadulterated feature creep and just additional, new ways to spy and hack. Why?
Because a browser is a program made to browse HTTP web pages, period. If a distant server needs to talk to other kit around my house, I definitely want that to happen through a dedicated, serious, opt-in and secure program, not something the browser dragged in and which is probably as sloppily coded as most commercial websites.
(BTW, if you want to print some part of a web page, that feature has been implemented in most browsers a long time ago (including in tablets), it does not require some new specific app with Bluetooth access...)
"Web apps" are a solution looking for a problem to solve, and only make any sense in exceedingly rare cases. They are an excellent example of the "we can, ergo we must" mentality my manners forbid me from commenting on.
"Because a browser is a program made to browse HTTP web pages, period. If a distant server needs to talk to other kit around my house, I definitely want that to happen through a dedicated, serious, opt-in and secure program, not something the browser dragged in and which is probably as sloppily coded as most commercial websites."
Sure. But you cannot install apps on an iPad, just Apple-approved apps.
> you cannot install apps on an iPad, just Apple-approved apps
So?
The very specific and limited problem of Apple approval for apps isn't worth opening the box of Pandora and create a huge new attack vector.
I can understand developers wanting more power (more money), but users aren't just milk cows, we do want to be left in peace (of mind).
"How about a catering system that wants to print a reciept or talk to a kitchen display system?"
It can use the OS provided print function and the OS provided installed printer drivers to talk to whatever printer you want to print to.
"How well do you think it goes down when we tell US clients they can't use an iPad because Apple have crippled the Bluetooth in the exceedingly expensive devices they already bought?"
They should have done due diligence before buying those exceedingly expensive devices - more so given that they are exceedingly expensive devices.
because Apple have decided not to implement a few potentially privacy busting A.P.I.s"?
Well boo fucking hoo.
Funny how people from Google never comment about how it always seems to be an iPhone the F.B.I. or whoever, seem to have difficulty with decrypting. It never seems to be an Android phone. Funny that.
And Google, you never seem to mention the fact that you also take a 30 percent cut of the price of apps that you sell in your shitshow of a store. Would that include the apps that turn out to be malware?
Just saying.
Cheers… Ishy
Funny how people from Google never comment about how it always seems to be an iPhone the F.B.I. or whoever, seem to have difficulty with decrypting. It never seems to be an Android phone. Funny that.
Nice bit of whataboutery which isn't true. I-Phones are encrypted by default, with Android you normally have to enable it manually. But that doesn't mean it isn't secure and, just like Apple, Google cannot provide the keys to decrypt an encrypted Android device.
Apple's decision is more about scope: how much functionality can a browser provide safely? For several years there have been many people championing the browser as an OS. In order to do so this requires replicating OS services, which works well in some situations: notifications, hardware acceleration and even location services can make a lot of sense on (mobile) devices. But in other situations it essentially means breaking open the browser sandbox.
Quite: "I-Phones are encrypted by default, with Android you normally have to enable it manually."
Not true, at least not since late 2015 (for new devices).
Android has had full disk encryption on by default since Android 6 (late 2015). Google tried doing this (on by default) with Android 5 in 2014, but there were performance issues (mainly missing drivers for doing AES encryption/decryption in hardware, which meant many devices had to do this in software, which was very slow!).
By Android 6 Google tried this again, but this time made full device encryption a mandatory requirement of getting certified (needed if you wanted to pre-install Google apps like Maps and the Play Store etc).
So any Android 6+ device (so late 2015 onwards), that has Google Apps pre-installed has to be using full disk encryption by default. (The encryption is enforced on first boot, so even a factory reset won't remove it).
Looking at my Android 9 phone, there isn't even an option to turn encryption off.
Browsers really ought to put toggle switches on all of these, so the end users can decide whether or not they are available.
The amount of secret sauce being hidden in a piece of software that is then routinely used by god knows how many third party scripts is... disturbing.
This is an interesting one. Yes the fruit-cakes are probably right on the security issue but "off by default" rather than "no we can't trust users with control of their own devices, don't allow them the option".
That's where other browsers could seek the moral high-ground by blocking some APIs unless explicitly permitted by the end-user (including some currently "permitted by default" ones).
We need to be careful to avoid the legislators getting a sniff of this issue or we'll have mandated API alerts like the absurd and bloody annoying Cookies popups.
Google et.al. are not entirely wrong in saying Apple are protecting their walled garden. That approach has history with Microsoft too but they seem finally to have learnt the error of their ways, finally killing off MSIE and seeing sense with the changes to the Edge browser.
In the mid 1990s when Microsoft fancied the idea of monopoly power over the web (anyone remember "blackbird?") I recall a proposal that I accept a bundle of web authoring software on the condition that every web site I created include some features that meant the site would only render as intended on the MS browser. (I declined).
> "off by default" rather than "[not there]"
The problem with "off by default" is that it is utterly useless because only the good guys will respect it. The more ruthless ones will make their web apps "on by default" and gladly do what bad guys do.
As for a master switch in the browser, it is also utterly useless: Assuming there is one compelling use case for a "web app" (probably Facebook...), the user will have to switch the master switch to "on", which means that all the other unwanted apps will get permission to run as well. Stable door status: Wide open.
The only way to control programs running on your computer is to choose and download them yourself. Also, the less task-unrelated features a given program has, the more secure and reliable it tends to be. Let browsers browse, and programs do the programmy things.
Agreed. When I read that "Apple supports other APIs that can be abused, such as those related to orientation/acceleration, geolocation, camera access, GPU accelerated graphics, gamepad API, and file and directory upload " it feels kind of galling that there is all this hullabaloo about a Battery Meter API.
A website wants to know how much juice I have ? What for ? Sure, it's ridiculous, but then I can be tracked much more efficiently via my location, and apparently everybody is fine with that, including Apple.
True and there are other ways to check a web site is OK in safari without paying the apple tax (like ask a friend who has an apple).
I now take the view that it's not my job but that of the browser authors to ensure that any well coded W3C standards compliant web site functions on their platform. If it works on all the main browsers but not yours, that's a bug in your software not in my web coding.
Why? Because it’s pretty good. I use it all the time. It does everything I need. When I flip screens between Chrome on Windows (which I have to for work) back to Safari on macOS, I’m really glad I’m back on Safari. No little spy icon at the top RHS to remind me who I am. Back to Chrome. Slurpy data slurp slurp. Ooh look, the internet knows about me! Back to Safari. Hey, the content blocker’s working great. What’s that? It’s running lickety split. Let’s have a bit of pinch to zoom.
I’ll stick with Safari, thanks.
We all know the "This website wants to send push notifications, Allow yes/no" prompts. It has proven quite a well-working way to deal with site privileges. Nothing (ahem ... nothing technical) would stop browser vendors from defaulting all such APIs to disallowed, but present the user with a "This website asks for these privileges: 1., 2., 3., ..." dialog when first loaded,just the way it is with Apps from some App-store.
PWAs that actually put value into the users hand would have a good case, but not every click-bait site.
Removing the "secret" from "secret sauce" seems much saner to me than disallowing sauces alltogether. It would also help to move things from the "App"-Domain back into the "Open Web"-Domain, which is of cause what Apple fears like a Vampire fears daylight.
all web browsers on iOS devices use Safari's WebKit rendering engine
wouldn't that fall under the same category as the default navigator in Windows some years back ? Doesn't this violate interoperability laws sort-of everywhere ? Isn't this the same as a vendor of pasta that would require that you only use their sauce too ?
I can't see that having a chance in court if someone dared to challenge it.
Nope. Apple don’t sell iOS, iPadOS or macOS. They can do what they want with it, as it comes free with the device. They are at liberty to adopt whichever html standards they choose.
They killed off the Flash plugin years ago because it’s a resource hog. Whether you like Flash or not (let’s hope not) you won’t see it running on an Apple device.
They can do what they want with it
1) it's not they but the user, it's his phone after all. Of course they can ship with the pre-installed browser they want, but the question here is that they forbid the user to use another supplier of a standard item later. Even worse than the Internet Explorer times when it was only the default browser.
2) I think not: you cannot sell a car and force people to only use your tires. Tires are standard items and you are allowed to install any tyre you want (of the correct size). I think that this is now also true for spare parts: you are allowed to replace the clutch (and other parts) with parts from other vendors, not just the original equipment manufacturer's (that's why there is the OEM term). What Apple does here looks to me entirely illegal.
Mozilla CSS:
"Applications based on WebKit or Blink, such as Safari and Chrome, support a number of special WebKit extensions to CSS. These extensions are generally prefixed with -webkit-. Most -webkit- prefixed properties also work with an -apple- prefix. A few are prefixed with -epub-.
Note: Avoid using on websites. These properties will only work in WebKit applications."
-webkit-browser-not-standards
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
