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.
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
You need a strong single Apple so that we can have our singular place to buy smartphones.
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-...
It's about detecting user idleness, including in the case the user has another tab active, not a way to queue and coalesce bits of work at an "idle" moment to optimise for latency and battery life.
The Idle Detection spec at https://github.com/WICG/idle-detection says it itself:
"As opposed to the requestIdleCallback, this is not about asynchronously scheduling work when the system is idle."
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?).
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.
I dont care about your unique SaS usecase, these are invasive. Make a native app if that's what you need.
Why not? It makes complete sense for something like a website that backs up the photos stored on your camera. What's even the counter argument, that if people want to back up their data they should have to pay Apple?
If you've granted a website access to a restricted API, the browser can just paint a flashing red border around the website or whatever, similar to how people configure their terminals when they're SSH'd into prod.
How do you do this bit “requiring explicit permission from the user before a web application can use them” without the fallout of “its just a hundred thousand popups and you’re done!” on every page?
Except on the long term that would have no effect in empowering users. We all know that when faced with a deluge of permission requests, or pressured by the fact that enough people have already accepted and it's the entry price to collaborate, people will just hit accept and be done with it.
They only need to get the foot in the door and then you'll find that plenty of stuff ends up conditioned on you giving them access. Every one of these APIs is a Trojan horse. Past experience just proves that they will be hijacked for purposes that don't do the user any favors.
Look no further than JS which is there to enrich the web to benefit users but 99% of it is garbage slid under the door to benefit site owners. That's because plenty of things that should work just fine without it are now tied into it, disable JS and the site experience breaks.
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)
I have never heard of this API, what's a use case for it?
Isn't App store apps (Not reserved to Apple's one, this also works for Google, Microsoft and many others) untrusted code too? It runs with even more privileges than your browser's code and have access to more fingerprinting information if that's what it is going to do.
As far as I see it, a PWA with these permissions has less privacy risks than a native application I can find on a store. I'd really like to understand how installing an app is not an issue but having the access from the browser is. Is it simply the permission framework that is broken and you don't trust it to not leak information when the API is disabled?
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)
> capabilities to perform sensitive operations in software which also deals with untrusted input from the Internet.
But native apps don't deal with input coming from the internet? If that's what you think, you're... wrong.
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.
Is this a thing? Do people in demographics which are less appealing to advertisers also see more intrusive ads?
I love the web that actual dynamic logic on the frontend has allowed. I want more of that, not less.
The alternative to web apps that can do these things is native apps that can do these things. If you don't think native apps are tracking your behavior, you are sorely mistaken.
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.
Every additional API added to the browser makes the risk of such side effects greater.
And of course I just leave the site if it gets obnoxiously needy and invasive.
However, I have to admit that displaying one icon per permission would not scale great when having a dozen of them.
Most comments here seem to of the "Good no one should write a web page that accesses bluetooth and I don't care if you want to do that".
This is sad for me because I would like to be able to write web pages that talk to smart turbo trainers and other health devices.
Now you might say why not write a app to do that but personally I prefer accessing stuff from web pages.
I find apps restrictive as a user. For example there is no way to block ads in an app and often no way to zoom or select text.
Again you might be fine with that but I just wanted to offer an alternative opinion.
I think you missed my point, I also truly love that 1% of useful stuff that JS brings and wouldn't want to lose the functionality. But I absolutely hate the other 99% which I have no control over or I have to jump through uMatrix hoops to control.
Let's put it another way. You probably love that electricians and plumbers exist to fix your stuff. But if once you let them in they could invisibly camp in any room of your house without you even knowing where they are and what they're doing, would you still open the door for them?
These APIs can either give you a relatively broad "Allow on this site" option, or they can flood you with granular choices. The first opens the door for them camping in bed with you. The second is like someone triggering your alarm every 5 seconds until you disable it. Accept all. Then they can camp in bed with you.
Doesn't your experience tell you the same?
> If you don't think native apps are tracking your behavior, you are sorely mistaken
You see, this is exactly what I meant. "Those guys are screwing you over so it's OK if these ones do too". This is how the "screw the user over" arms race happens where everybody tries to outdo the others with even more invasive techniques, and users take it because each is just a slight escalation from before. When native apps were adding these "features" someone loved them for one reason or another. Frog in hot water.
P.S. Example of how the innocent battery API access can be sold as "to save battery" and then repurposed to screw you over:
https://metro.co.uk/2019/09/27/uber-charge-battery-lower-107...
[1]: https://mozilla.github.io/standards-positions/
[2]: https://developer.mozilla.org/en-US/docs/Web/API/Battery_Sta...
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.
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...
I'd be far more worried about the mess at the core of the web, css and rendering, than about exploitable bugs of SQLite. The fact that a RCE in SQLite is HN worthy is indicative of that. Browsers have tons of RCE that are fixed every year, but it happens silently because everybody is so numbed to it.
The quoted argument is a copout of them. HTML is also a "Living Standard" a.k.a. we just implement whatever we feel like, and write it down once we feel like it has stabilised a bit. They could have done the same for SQL, but NoSQL was en vogue at the time so they pretended that SQL needs to somehow hold up to much higher standards than the usual mess they produce.
SQLite is probably one of the few pieces of software that is actually trustworthy, unlike the dumpster fires of C++ and feel good essays, that we call browsers.
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.
They're kinda useless for web browsers, but people see them in Chromium and believe they must be there for a reason other than ChromeOS. Apple and Firefox are doing it right. These things don't have a place in browsers.
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.
The solution to privacy concerns is not "nuke functionality", it's "don't let websites abuse functionality for tracking purposes".
Just like how with native apps on iOS, the solution is not "don't let apps ever access GPS data", it's provide a UX that makes it fairly easy to choose and don't provide permissions to apps that don't need them.
Mozilla opposed it, rightfully so, in that it would dictate that SQLite be the implementation used everywhere. Mandating the inclusion of SQLite is not a spec.
As much as I like SQLite and looked forward to it being in 2/3 of browsers, Mozilla made the right call. The web should be implementable entirely by the specification.
Google likes to define the spec as the identity function of the implementation. Popeye specs, "I yam what I yam and dats all that I yam".
But somehow "paving the cowpaths" doesn't apply to tech that they don't find attractive.
Similarly, and that is actually a statement loaded with opinion, I've seen way to many self proclaimed "spec hackers" at mozilla. People who relish in the joy of writing out ideas, I mean who doesn't love building castles in the skys, but who completely ditch the implementation. It doesn't matter if you have the most beautiful spec in the world if the implementations are shoddy, or if it specifies the wrong thing.
Web specs are the modern hackers "waterfall" design process. Sure everybody talks a lot, and there are many pretty documents that come out of it. But once you start implementing the stuff, you start to realise that all your assumptions were wrong, and now you've made a mess.
I think specs actually produce less diverse implementations. Because they are so easy to write, in comparison to code, and because writing them doesn't give you immediate feedback on when you've reached a good minimal feature set, it's almost inevitable that you end up with way more stuff than you actually need. There is a reason that there are essentially only 2 Multitrillion dollar companies that can keep up with that mess. And mozilla would have died long ago if google wasn't keeping them alive to avoid anti-trust investigations.
In all fairness Living Specs try to acknowledge this, but somehow we still collectively pretend that they are more than mere documentation, that by calling them a "specification" instead of "documentation" they somehow make the web run.
Specs don't run the web. Code does.
Blink is a fork of Webkit, an engine soo much better than the alternatives, that it almost over-night became the de-facto standard.
Did webkit ruin the web? Eventually apple and google disagreed and blink was forked of off webkit.
The same thing would have happened to SQLite as the foundation of a living WebSQL spec.
It's ironic that Mozilla pushed IndexedDB through, yet they were among those too lazy to provide their own implementation. Instead they simply dump everything into SQLite, same strategy done by Apple. They left it to google to implement the only differing implementation based on LevelDB.
But hey, it's totally important to have multiple independent implementations...
Those ads might be terrible chum bucket stuff, but they would not be intruding into your privacy.
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.
Is there a way to escalate that I'm not seeing? AFAI remember, all programming is done through status messages 11110000 and above.
https://www.midi.org/specifications-old/item/table-2-expande...
Full Disclosure: I made a web synth and really want to be able to use midi to play with it.
What would be your opinion if everybody just decided to use Google's implementation of WebRTC wholesale, rather than building out their own systems? What if Mozilla decided to rebase on top of Blink, and give up on building its own rendering engine, tomorrow?
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?
That said, as long as the SQL implementation they choose is free and open source I'm not sure this is such a bad thing. I mean we are also stuck with Javascript in the browser and that hasn't been a total disaster. The whole point of standardization is to choose one particular solution and have everybody use it.
You need to think about the barriers to implementation: if everyone ships SQLite, developers will inevitably write code which depends on that exact implementation and anyone shipping something new will need to copy it - including unintentional behavior and bugs – to work with existing sites. That is extremely expensive and might lock in something we’re going to regret later if someone finds a behavior which wasn’t intended for this context and has security or performance issues.
Anyone working on the web should be especially sensitive to this since we came close to having the specs for all web technologies be “whatever IE6 does”.
It's sandboxed from the os and limited to some use cases, which is the point. I don't want something capable of hot loading code from any web site to have the capabilities of my OS.
The point is that they would clearly never, ever diverge. Any sqlite quirks (of which there are plenty) would be enshrined into the backwards-compatibility requirements of any browser that used it. Plus building a database isn't simple - so why not just use sqlite? Setting out to fork or rewrite sqlite is not a task that makes any sense.
How is that any different from apps on the App Store?
maybe 10% is enticing for those who create botnets
You are free to use SQLite on Wasm, in your browser, you break no one and no one breaks you.
Wasm was designed well from a spec and community perspective, Google matured and Mozilla matured and in the end all the browser vendors go together and designed something that lots of folks can implement w/o multimillion dollar development efforts.
You know, I have written web apps that use SQLite and Lua running in the browser. They shouldn't be included inside the browser and nor should browser vendors have to worry about it.
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.
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.
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.
https://www.obsessivefacts.com/blog/2018-10-20-chrome-allows...
Here's what appeared on porn site xhamster.com once newer versions of Chromium got around to implementing the permission check (SFW-ish):
https://www.obsessivefacts.com/images/blog/2020-04-04-the-ja...
Apple puts every submitted application through an enormous battery of automated (and sometimes manual) tests and disassembly to look for malicious or non-permitted behavior before publishing apps to the App Store. They don't have that ability with random websites.
Now what's the level of control anyone has over a website? In your lifetime you visited many orders of magnitude more websites than apps. How do you plan on validating every link you ever click on? Every redirect? Browsers are the front line on the internet, they face the biggest threats because they can't afford to work in a walled garden with curated content. You are one minor bug away from giving access to your USB connected devices to some random website without even realizing.
I don't think anyone is arguing that you are wrong about what you want. Just that what you want is wrong. Like a kid wanting more sugar, they can't spell diabetes so it can't be a problem. You're selling your privacy for trinkets and that wouldn't be anyone else's concern if there wasn't a critical mass of such users pushing everyone in the same direction. Every questionable decision made by companies was made with the (ignorant) backing of people like you who saw the shiny feature and couldn't see past that. And again, you have every right to want whatever you want no matter how smart or dumb that may be. But don't be so shocked when people call you out on it. It's only because you brought just your own personal preference into the discussion instead of the merits of giving up every shred of control over your stuff in exchange for some marbles.
IMO native apps are capable of far more invasive privacy violations than the web is. But for some reason they're given a very free pass by comparison.
> 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.
If anybody was expecting 100% compatibility all the time, we wouldn't get any new standards, and would all use chromium.
Like I said, webkit and blink are the perfekt example for this.
As for the first point. It doesn't really matter if they have their own glue code, all the important parts are shared.
You have a lot more control over something that's running locally than something running serverside that simply using the client to harvest data.
Instead, the overwhelming web business model is "free to use" (akin to f2p in games). That means ads and other monetization side channels become the priority of the app, not the app itself.
And that is for trusted web apps. Let's not even talk about the fact that you are executing random code every time you visit any webpage. That just does not happen with native apps.
We should kill JS, and EVERY WebSpec, except for WASM and WASI. Take the best parts of html and css and implement a virtual dom / immutable data driven document format for WASI.
Focus all our efforts on carving useful capabilities for WASI and end this web nightmare once and for all.
Not realistic, but a man can dream...
Open source is neither here nor there: both web sites and native apps can be open source. In fact, the web is unique in allowing you to actually inspect the source that is running on your machine, you have no way of verifying that the code in an open source repo is what actually runs inside your iOS app.
Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.
Android programming is another can of worms and I'm frankly fed up with Gradle updates breaking my project every update and needing 79+ files, multiple cludgy steps for signing APKs, zipalign (wtf) and other crap just for a Hello World.
What would be nice to have is "installable" apps that use the webkit rendering engine but have full access to the system including directly opening TCP ports and direct access to /dev. These would have to be trusted apps obviously. Websites that load code without consent should be restricted, of course.
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.
And "heavy client" is a fallacy. Operating systems come with runtimes too. Very complex native app can be very small in size if it uses the native controls and APIs. They can be KB in size. Any asset is going to be bigger than the binary itself.
The web-as-native apps are the ones that are huge, because they embed a behemoth (a browser) which is akin to an entire operating system.
Living specs don't give any guarantees, yet they still "pave the cow paths" while keeping ridiculous bugs and behaviours for backwards compatibility, and breaking existing specs for convenience. It all depends on the person dealing with the problem.
Nobody expects compatibility with existing specs, why should they for WebSQL? Especially when it's a living standard.
If those things were true, we would all use the same browser by now and never see new standards, and Blink and Webkit would have never diverged from another.
Open source quarrels basically guarantee a steady supply of competing forks.
There are perfectly valid reasons to want usb/bluetooth support for websites: fingerprint readers, smartcard readers and plenty of special-purpose hardware that would be useful to access through some web apps.
Does this mean every site should have access to all your hardware? Of course not. Let's make sure you have to bless a site to allow such access, make sure that the API can only be used from https-enabled (and trusted) origins, etc..
Your position of "just no because I don't see a need for it today" is a very close-minded one...
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.
What's your point? Because one API can be used for something, Apple should let Safari be a free-for-all?
I haven't worked with web ads in a while, but from what I remember when I did, people with little data on file with the advertising networks got more ads, and better ads, because there was no record of them having seen the high-paying ads already.
The longer you surfed, and the longer you were tracked, the lower quality the ads became.
Again, I haven't been in this arena for a while, but that was true at the time, as told to me by the president of one of the larger non-FAANG advertising networks, over coffee.
But it's all a red herring anyway, isn't it? Are there any people out there saying, "I wish there was a way to give Google more information about me so that I can see better quality ads!"
You're conflating browsers (Chrome, Firefox, etc) with user applications. User applications are still not handling your bank passwords.
> They're also not collecting data about my consumer behavior with the goal of displaying more ads.
lol? Absolutely wrong here.
Especially in the porn industry where the end users are likely using incognito mode or a VPN.
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.
This is my original point. They 100% absolutely are. Look at some of the ad and tracking frameworks for native apps. Somehow no one cares.
Ignoring those two, you get damn near every major web app. All of Google's applications, Facebook, Twitter, etc. etc.
Firefox Send
Spotify
This gives you unmatched privacy. As I've said elsewhere too, see this Facebook page listing apps that share data with them via FB's SDK and marvel at how privacy friendly your iOS device really is:
https://www.facebook.com/off_facebook_activity
The notion that Apple is not implementing the web push API for example, for privacy reasons, is stupid.
Fastmail, Facebook, Twitter.
None of them work on iOS due to lacking web push notifications. All of them can work on Android as PWAs and as PWAs they are more secure and privacy friendly (not only due to less permissions granted, but also because you can protect yourself with uBlock Origin et all).
Keep in mind that your personal experience is an anecdote.
To be fair, this is changing with WASM. On the other hand, there are tons of obfuscation opportunities with native executables that don't exist for WASM.
In theory native apps are "trusted", but I think for the vast majority of users the trust between a companies website and app are equivalent, vetted the same, and probably do an equivalent amount of tracking if not more by the native app (facebook SDKs are pretty common in native mobile apps).
I don't get this let's not allow this web api because it's dangerous, well you only move the problem to an application that the user installs on his PC.
If the permission mechanism is correct there is no danger, a web applcation wants to access my MIDI interface or my USB or Bluetooth or whatever and it can. Isn't the same for mobile applications and permission?
So maybe and I say maybe we could stop having to ship an entire Chromium engine with Elecron just for a web application to access devices or files on the computer.
Users need to be protected against themselves as long as they can't take responsibility for their actions.
Apple is denying people their real rights to install whatever they want in their own machines, forcing everything to go through their app store, where they have the last word of who can or cannot distribute software to the platforms they have created.
They know that if they use the common "we are thinking of your well being" their customers and fans will just believe they are a good-willing company with no other interests than their users safety and well being.
I don't know why the majority of the crowd here in HN, who use to be so harsh in pointing out this kind of behavior in companies like Google and Microsoft, have this blindness with everything that has to do with Apple.
It will worth nothing, if after have defeated this beast with GNU, Linux, the Web, open software revolution, etc.. we end up not protecting what we have achieved so far, because somehow one company trying to secure their profits and its position in the market, get away with behaviors that can ultimately destroy the culture of freedom, open-source software and ultimately, digital rights, which our legislators are not prepared to defend, really understanding the threats and the dire future they represent if we dont uncover the true intentions behind this BS.
Web sites have no business looking at my devices, nor using other APIs (I was disappointed not to see the page visibility API on the linked page too).
If you want a dynamic app delivery framework, perhaps it's time we find a way to do that which doesn't massively overload what many expect is just an informational service.
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.
Second of all, there's no App Store review process for malicious websites. An app that wants to harvest your data will at least have to have some vaguely plausible useful purpose in order to even have a chance to try.
So I don't know about you, but personally, if you were to ask me, "Do you think a restriction that reduces the number of people able to harvest your data in this particular way by about 90%, or is it totally useless if it's not 100%?", I'd say go for the 90% solution rather than just throwing up my hands and saying it's hopeless.
Forcing them to install a native app also massively reduces the number of people who are going to actually let you in.
You can enable add-to-home-screen for websites with a single meta tag,
<meta name="mobile-web-app-capable" content="yes">
But for the sake of this discussion, let's consider PWAs to be one which uses app manifest[2] and uses some high level device features.
My parents aren't techsavy at all, so when they get those push notification requests, they just hit "accept". They now get dozens of spammy ads sent to them via push notifications (eg, "30% off sale, buy now!")
I've disabled web push notifications entirely, but I still get JavaScript-based prompts asking me for permission to turn on notifications. I already explicitly said no, yet web developers still feel compelled to find workarounds to interrupt my work and ask me for permissions (why?).
I get that in theory, web notifications are supposed to be valuable, but in practice its been nothing more than a constant annoyance for me.
If Google got their way, we'd be shipping modified LLVM bitcode to clients ("PNacl"), and every browser would be shipping some random fork of LLVM stuck in the past forever. If Microsoft got their way, GMail would be an ActiveX plugin.
Gecko has massive improvements over Webkit/Blink, btw - WebRender is huge.
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.
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.
Mobile apps are increasingly sandboxed too, like websites, precisely because of that.
Personally, I think that’s the solution. Provide access to the most common and safe features while disallowing the unsafe one. You’d still get far more functionality than you have now and only sacrifice a little in exchange for safety (vs not having any at all).
There is a modern overreliance on apps for everything these days.
Tastes vary, I suppose.
So apparently we now have to restrict all interesting functionality in the name of keeping the lowest common denominator from shooting their metaphorical feet. If there's a more charitable way to read their stance, I'd love to hear it.
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.
By your logic, the web should not have video support either, because users are users and it will inevitably be misused.
If you were serious about addressing this: We need clear and robust and granular permission dialogs on web and native apps. Ideally they'd be consistent across web/native, which would help users trust their software, and understand the permissions they give.
I suspect the bigger demand for PWAs is for non-consumer apps. If you are selling to businesses or building internal apps for a business, often delivering a multi-platform + web app with decent performance/ UX, often a PWA or PWA + Web platform is the way to go.
> Why would I use a Twitter PWA, when the native app provides a much better UX?
This is why I think vertical/ internal apps make a lot more sense for PWAs. If consumers have a choice on what they use, they are going to opt for the faster/ better integrated app and PWAs can't compete. For a purchasing manager, the difference between a cross platform PWA and delivering 2 native mobile apps plus a web app can easily be tens or even hundreds of thousands of dollars in development costs.
(FWIW, I work on a large SAAS web app/ PWA which obviously colors my perceptions)
I'm interested in the many quirky apps and niche experiments made by people who won't or can't make cross platform native apps.
It's this stuff I care about. I don't care about whether you faang of choice chooses to go native or not.
And that is assuming they are trying to "protect you", but that is a different discussion.
One thing is the revenue generated by the App Store but suppose JavaScript web apps were just as powerful and well integrated as native apps; then why use native apps at all? Why have an App Store at all? Why have a Mac or an iPhone if any device with a modern web browser would do?
When Huawei tried to create their alternative to Android. The big thing missing wasn't the hardware or the operation system. It was the App Store with your map app, your banking app, your scooter app and so on.
The App Store and the proprietary development platforms for Android and Apple has become a way to keep their duopoly in place.
I would never use a social network native app, ever, as the category has a history of abusing privacy, poorly utilizing resources or any number of other things.
For business, it's a much easier decision. If I can do what I need to do in a PWA, why futz around with iOS, Windows variants, and multiple versions of Android apps? App Stores are a much bigger PITA than shipping web code, and I don't have the time, budget or care to make a polished user experience for employees.
But you're not following the analogy. You just took it word for word and attacked something that wasn't even the point of it. You may as well have said "but websites aren't made of sugar".
I made concrete points on why websites shouldn't be trusted with such access. You did more of what was shown before, rattled the trinkets. And the use cases you listed don't seem like something you can't achieve now with existing APIs or dedicated apps, which makes more sense.
Stands to prove that the point of the analogy is more appropriate than ever: people can't understand the problem, let alone the solution.
Why would it be? They have the search data, they know what you clicked on, they have GA on 60-80% of sites, they have plenty of information, tracking and profiling users isn't the issue. Tracking and profiling users legally is what's hard.
I don't Android, so I really don't know - but are those PWAs the only or primary options for most users on the Android platform?
If not, they're really just "native apps which are also available as PWAs", and without data on relative adoption rates it's not really very useful information.
Sure, you'll be suspicious, but I seriously doubt you're the average user. I bet a very large proportion of Safari users have no idea what a MIDI device is and some significant portion of them wouldn't think twice about granting those permissions.
Bypassing geo block on websites is easy and there isn't a single source of truth on the web like app store is for the users. Can apple explain why they took down apps on the request of china in HK and how do you think that will play out when no web apps can work reliably on apple devices?
Censorship is a huge problem for app stores. They censor anything sexual but sexuality is part of human nature. They censor anything politically charged but it's part of human nature too. I hope the anti trust fine plays out.
Apple can protect the privacy of people by making it harder for them to be vulnerable by choice. People here point towards stupid users when saying that a normal user won't be able to connect usb and enable a feature. Why can't the same happen with browsers or apps on ios? Why the $99 fee just to side load apps? Why the need for a mac?
Just admit it's for profit seeking reasons. Ads in your app store are a proof of that.
Yes? I haven't claimed there aren't free native apps.
> Web apps tied to subscriptions are also plentiful.
Fair, but most of the ones I know are usually technical apps or they offer something else that is not about software (for instance, storage more than the app).
> the web is unique in allowing you to actually inspect the source that is running on your machine
That is not unique, nor true.
Uniqueness: you have apps made in scripting languages everywhere. Even for compiled languages it is a decision not to give you the code, not a technical one.
Truthness: many webs are obfuscated on purpose like native apps are.
> you have no way of verifying that the code in an open source repo is what actually runs inside your iOS app.
False, you can definitely verify that a binary matches the source code in deterministic builds and even provide debugging symbols etc. The fact that many projects don't care about that does not mean there is "no way", it just means the overwhelming majority of users do not care.
I suspect this has more to do with the state of native Linux development tools versus Javascript dev tools then it has to do with the general case. Dev tools for Windows and iOS/ MacOs are fairly straight forward. Not sure about Android, since my burning hatred of Java has removed my desire to mess with that platform entirely. (I know Kotlin exists, still not interested)
Update: I'm basing my comment of what it's like based on the quoted comment, not making an assertion about how good/ bad it is.
You mean the same way you are in control over what data tracking you allow and what cookies can be set on a per-site basis? In theory perhaps, in practice no.
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.
At least in democracy we can elect the people who define whats allowed or forbidden to us, and they can only do it, in the constraints of a constitution.
If we let companies get away with it, we are allowing them to create shadow states, a sort of new digital feudalism, where our digital overlords can control a big part of our lives. (Remember that we are going to a process of digitalization of our lives and experience, with IOT, AI, smart gadgets, to take into account how powerful a entity who can control all of this can be)
Today, its just Apple. But with people normalizing this kind of behavior, it will be more and more over time, til its too late for all of us.
By enforcing other browsers to use their implementation of Web platform, for instance, they knew they could control the Web from being a good contender to their exclusive application platform.
This kind of action alone, should be outlawed, because is pure uncompetitive behavior, not to say its hurting their customers freedom to choose whats best for them, and that actually have nothing to do with the privacy or safety of their users.
In top of that, less technically inclined people don’t even expect native applications to be able to harm their computer and we haven’t been able to change that expectation.
Web apps are also more strongly sandboxed which is important considering how much of Android install base is running on devices without security updates. (Android devices notoriously stop getting them after only couple of years after device launch, or even sooner)
I get different types of failures and messages from different versions of Chrome, Firefox, and IE. None of which have any midi devices. Those errors, or the structure of the resulting object if it succeeds, are all fingerprint inputs.
Their browser share dropped a little recently (https://gs.statcounter.com/browser-market-share). If that continues, it'll certainly irk them!
But the fact that there are multiple implementations remains. and it remains a goal that one should be able to create a _new_ implementation by implementing the spec. Notably, this goal was not achievable with the pre-HTML-5 specification.
In the specific case of WebSQL, if someone were to actually create a specification for it that didn't boil down to "run this exact version of SQLite and pass things on to it", that would have allowed for the "possible to create an implementation from the spec" goal to be achieved. But no one ever stepped up to do that.
thats a very good reason then for an app-store to enforce rules and code checking then, isnt it?
Can't speak much for Windows, but the Apple dev story is pretty good. Platform SDKs are deep and capable, if sometimes not well documented, and there's a clear "right" way to do most things. One can build a "world class" app with nothing but Swift+UIKit and few or no third party libraries. SwiftUI is rapidly improving this too, bringing a fully native "modern" reactive approach that works across all Apple OSes.
Xcode can be a cantankerous beast at times but it's been getting a lot better in recent releases.
> Not sure about Android, since my burning hatred of Java has removed my desire to mess with that platform entirely. (I know Kotlin exists, still not interested)
It's slowly improving but still very much a mess. Jetpack Compose looks to be poising itself as the SwiftUI of Android and that will no doubt improve things, but I have doubts that Android development will ever be as nice as iOS development is.
> False: you can definitely verify that a binary matches the source code in deterministic builds
If I want to check an app I have installed from the iOS App Store matches the code provided in an open repo, how would I go about doing that?
>Truthness: many webs are obfuscated on purpose like native apps are.
True. But their underlying behaviour, i.e., what data they send and where they send it, is viewable and blockable by browser extensions.
Are they? It's probably been a decade since I touched a native GUI (and I was without a mentor and working on already-old software) so I legitimately don't know. Using something like Visual Studio's form builder was fine enough, but it was not a very expressive toolset as I recall.
Web you can get started "instantly". Your browser covers most of the tooling you need and you can tweak any live site.
I don't like that that's how it is. From an abstract perspective I'd rather not be working on web because it seems like we're trying to make a better car by building a bicycle inside of it. But the low bar for entry is hard to beat.
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.
Vast majority of users will use whatever you throw at them, especially if they're friction free (no account needed, no credit card, no updates, no space occupied, immediately available, even on slow networks, etc. etc.)
It felt weirdly like writing Vue-like code.
Microsoft nailed it imo, VS2017 and C# have come along way since I used to do .net 3.5 stuff.
I really liked C#, it’s http and a sync/await stuff was excellent.
In my opinion, Apple has an incentive to keep the web crippled in some aspects, and this is just another symptom of that deeper underlying cause.
Well, I guess if I ever need WebMIDI features, I'll put a banner for Safari users to switch to Firefox.
(Or.. Maybe Firefox on iOS is forced to use the same engine as Safari..?)
> 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.
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.
Having different organisations with different goals is what prevents these scenarios.
Otherwise the webkit blink thing wouldn't have been successfull.
Mozilla could also have forked blink and started replacing it with rust, and you would've gotten the same improvments.
Mozilla could have taken SQLite as a foundation, started a living spec, and immediately begun translating the codebase to rust. The effort would have been the same as for their half assed IndexedDB stuff, but the result would have been much better.
It doesn't matter where a code base comes from, it matters where it goes to. And when it comes to diversity of implementation the repelling forces of different ideas, viewpoints and aesthetics that normally result in dreaded project forks, work for the advantage of all in browsers.
Conways law: The software of projects reflects their social structure.
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.
Many APIs including getUserMedia and all of WebRTC are not supported in WkWebView (only way Firefox/Chrome works on iOS due to Apple policy blocking them from building their own browser) Means some apps will only work in iOS-Safari and not in iOS-Chrome/Firefox.
None of this has to do with privacy, being able to record media locally without sending to STUN/TURN server increases privacy not reduce it.
That's why they buy 99$ phones
You're comparing a few millions people living in SV with billions of people making less than 10 dollars a day and assuming that they have the same PPA and that they represent the entirety of the World's user opinions and/or will
You haven't made a single point, on the contrary, web wins on ALL of them.
The one single point you can make but you didn't, is that native apps often (but not always) feel smoother or more responsive. Which shouldn't be an issue on browsing static content.
The parent comment implies a bad actor using the API for something like fingerprinting, and a common user who may have never even heard of MIDI, let alone have a device.
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.
GP said they want to _write_ a web app that talks to health devices. And that they like the web platform because it's easy to block ads shown to you by other web apps.
I will add that it's also easier to detect/block tracking. Browsers such as Firefox even try to do this for you these days. And to generally examine what the app is doing (e.g. by running it in JS debugger).
Yes, paid apps usually (but not always) remove ads. They keep the telemetry, though.
You’ve selectively mixed two paragraphs to change the meaning of what I actually said.
I did not say I want to use apps with ads with health devices, at all. That’s a complete straw man.
I said I want to access my own sports equipment via Bluetooth from a webpage I’ve written myself.
I also said that I dislike apps because the user looses control over things like tracking, selecting text, zooming and whether adverts are shown.
I am still confused. How is it different from the native app situation? How can you be sure which of your data is being tracked by the Facebook app, or Twitter app, or Instagram app, or whatever the cool kids use these days?
Obviously you can splat some HTML into a browser and get instant results, but once you start talking about apps with even moderate amounts of interaction, the simplicity of web apps falls away quickly. If you are talking about a sophisticated app, I don't think the complexity is any less when you are using javascript/ React versus Swift/ UIKit. The big win I've seen for javascript/ web apps is the fact that you are reasonably platform independent, obviously if you use Chrome and Chrome specific APIs, that falls away too.
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.
The app clips feature they showed? That should have been a qr code triggered pwa with notifications, except everybody had to build it as an app because they couldn’t do notifications, and then apple used the cumbersome nature of those apps as the reason for app clips. It’s the snake eating its own tail, and I’m getting IE6 vibes because microsoft also strategically stopped improving IE for web apps because they wanted to push app developers to native because of the improved user experience. Yeah, the web is worse, but worse is better.
I specifically do not want push notifications from Twitter or almost any other app aside from calendars and alarms. Having Twitter notify me about every stupid online interaction was causing my life to be buried in constant distraction. Without a doubt, my life is better without it, and I don't think that's an unusual perspective.
Also, I would be curious about your reasoning that running an app gives fewer ways to track the user. I would tend to believe the opposite.
*Edit: 1 minor typo
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).
Allowing you to use a keyboard as an input device is incredibly powerful, and even that can be handled much as camera and microphone is: you give the site permission.
Browsers bring friction-free exploration, literally "surfing". Hit the back button, or clear all your caches, and you're done, but otherwise, it's fire and forget.
The installable App model creates "shit work". Everytime I install something, it permanently takes up both screen real estate, and storage, and creates a cleanup task for me to delete it at a later date. Steve Jobs said "don't give your users shit work", well, app install and uninstall is shit work.
I don't want to install stuff, I want to use stuff and get work done, and want things to go away if I don't want them without having to become a System Janitor.
You complain about notification janitor work, which is fair, but native apps have the same problem, my iphone is deluded with notification spam.
The whole app model is a complete reversal of decades of movement to thinner clients, back to the Windows model.
Every time I go to a new restaurant, a new milk tea place, a new airport, or a new airline, they're asking me to install their native app. How many god damned United/American/SFO/InAndOut/FiveGuys/Chipotle/Starbucks/et al apps do I need on my device?
And no, "Instant Apps" are a worse solution to this. Why do I need to download a friggin 5mb iOS executable, even if it isn't perma-installed, just to display a form with 4 boxes on it to pay for a parking meter.
Form-filling is literally the use case for SGML from the beginning.
No, we don't need a native-locked-down-walled garden for every physical point of sale in the real world. And since Apple will never own 100% of the market, this means developers will end up needing to write, x2, silly little point of sale apps which clog up people's phones.
Ephemerality, transparency, portability, are desirable properties in addition to security and privacy. Apple leans too much on the latter at the expense of the former with relatively dubious justifications that could be fixed with better design, instead of refusing to participate in improving the specs to meet the desired properties.
I can use BigBlueButton to participate in lectures, talk, share my webcam, even my screen. And why I should I care, if I can at any time, revoke that permission?
I use many web apps, which are incredibly sophisticated, from TickTick for todo lists, to LucidChart for creating diagrams, to google docs do collaborate on documents, to notion for creating documentation. I could go on for days.
I am happy, that the browser is as feature packed as it is, because it allows for so many wonderful apps, that wouldn't have been made otherwise, if they had to be made with any other technology, that is not as easy to develop cross platform applications for.
Maybe you don't want things like videochat or paint programs or music learning apps to run in a browser, but lots of people do.
Imagine if Firefox said "we're not going to let any web page access the camera"... their market share would probably drop in half overnight.
If you're going to write a native app, I am not subject to any of its radical security implications every time I try to browse the Web in general, and we are no longer in conflict.
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.)
Or is it that Tim Cook was looking at Apple's balance sheet and decided that they couldn't afford to lose the 30% cut of all the MIDI-capable iOS/iPadOS apps that could be completely replaced by a web app?
The reality is that the real cost of this feature to them would be developer time; it would be a colossal waste of their limited WebKit/Safari developer resources to implement Web MIDI rather than something that would actually be used by more than a scant sliver of a percentage of Safari users.
This is not my experience, I've never quite cared for all the finicky setup needed to get things right, and it always feels a bit laggy. (Though IntelliJ is a world better than Eclipse).
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.
WebKit on the iPhone limits the APIs that a web site can access. An app has fewer limits, even on an iPhone. This means that with a VPN, a decent DNS server, and some content blockers on the iPhone I can limit what data Facebook has access to in ways that an app does not allow. This is only possible because I have the choice between the app (with fewer limits and protections) and a restrictive browser environment. If the browser provided all of the goofy APIs Google wants to shove down people's throats I would have a much more limited set of options.
So theoretically then, could a Jack aware payload be created that runs in the background, say disguised as a vst or ladspa plugin and when a user browses a malicious site, this site could, recognize the malicious midi device, create connections to other software and gain access through possible buffer overflows or other things?
It seems like a stream of midi notes could itself possibly cause a buffer overflow in certain programs. Muse and rosegarden are a bit buggy as is and frequently crash for me. From what i can tell there's a lot of midi aware audio software that likely contains a bunch of avenues for exploits and when you throw virtual midi devices into the mix capable of doing far more than hardware midi devices...
Why would I use the Twitter website, when I can get the same out of the app, it loads faster, and it actually works consistently? Plus I don't have to log in in app webviews all the time.
I had 2 points actually, which I thought I made very legibly. I didn't think they they need a fourth reading but here we are... They are both solidly confirmed by present day reality. 1) is what you mentioned already. As seen with cookie prompts, app permissions, actual scientific studies, etc. if you pester people with alerts and popups they are desensitized and start ignoring and accepting them. 2) is that once you give a website permission you lost control. They lack even the modicum of oversight apps receive.
> So apparently we now have to restrict all interesting functionality
All? Hyperbole much? Or did you just decide that these 16 APIs are the crux of "interesting functionality" and freedom? It doesn't matter how much you allow there's always going to be someone to shout "they restricting eeeeverything around here". This is what security and privacy measures do, restrict some things because the benefit doesn't outweigh the cost/risk. All those features are sold as "essential" when in fact most of them at best address some minor nuisance. Then they're promptly hijacked for nefarious purposes because there's always going to be some wannabe coder who insists that his website needs to know my battery level for some (undoubtedly good) reason.
Care to ponder how we got here in the first place? With every piece of tech around trying to steal data from you one way or another, usually in a dishonest way? There's a reason Google is championing this and it's not that they want to give you "interesting features".
It's always a compromise and for the past decade+ we've been compromising a lot more on the privacy side. If you truly believe you can have both privacy and aaaaalll interesting functionality in the real world you're either naive or sitting on a gold mine.
A good example here would be the MIDI interface getting blocked because it allows binary uploads via certain control message, as well as device enumeration.
If privacy is the main issue with this API, then the allowed control messages that the API would accept could be limited strictly to note on, note off, key velocity, etc.. things that have no realistic possibility of data leakage or compromise.
But instead, no, we lose the whole thing, even though a more nuanced approach (and in this case, one that's easy to implement - MIDI being rather straightforward) would satisfy any privacy concerns.
So with that in mind, the fact that a privacy-respecting alternative exists, no. I don't believe for a hot minute that that this is all about privacy - that is mere marketing fluff. I instead believe it is Apple is using privacy as a pretext for ensuring that PWAs remain as gimped second-class citizens on the platform in furtherance of their lock-in.
Also, you mention without evidence that Apple's actions have no relation to the safety or privacy of users. Are you claiming that their actions are merely a pretext, and that Apple provides no such value, or that they have no such intent? If so, how do you know?
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...
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.
People have very strict mental models of what “the web” and “native” should do but they’re not actually based on anything. There’s no actual reason why a web app sending you notifications (which it has to prompt for permission to do) is different to an app doing it. From the non developer perspective the divide makes no sense.
Not to mention the privacy argument by Apple feels disingenuous. The reason people are so outraged by tracking on the web is because they know it’s happening. Meanwhile native apps include bundles from Facebook to implement sign in with Facebook and it does whatever it wants. But because you can’t inspect and check no one talks about it.
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.
Oh if I had a penny for every time someone said with such certainty that "this is safe" only to be proven wrong sooner rather than later I'd have a second yacht :).
> I don't believe for a hot minute that that this is all about privacy
Of course it's not. It's about appealing to the customer base Google and the likes are losing by using an actually useful feature as a bridge to them. For the moment our interests align, whether by side effect or not. That's it.
But while you get your "first class interesting features" in apps, and second class shaky experience in the browser, what do I get for privacy? They're both already turning (turned?) to malignancy with too much of the code dedicated to actual data extraction. You have your apps, let others have their browser at least. That was the escape when you wanted to touch Facebook and Google Maps and no 10ft pole was around. If you think I'm unreasonable for wanting a last bastion of privacy (saying this is a bit of a stretch), just think that you're the one who insists everything should be how you want it by turning even the browser into the hot mess that apps already are. And this in exchange for some "interesting features" that you already have if you need them just not in every single piece of software.
You're ostensibly a coder so I don't need to point you to all the instances of trust being breached via conscious decisions. But surely this time they won't abuse that power. Neither will the host of obscure and completely unvetted websites one may access.
I don't think there's more to be said. It never ceases too amaze me how cheaply people are willing to sell their privacy for and how much they're willing to fight to make sure this is everybody else's only option.
from the page https://support.apple.com/en-gb/HT203033
Web apps by default talk to an outside server, native apps by default do not. Native apps will always be the more private by default option.
Currently my desire for both privacy, convenience, and usability align with Apple's current business decisions, so I choose iPhone. When Apple pivots to a new business model, I'll find the best compromise product.
Do those clients work on my mac, my chromebook, my windows box, and my android phone?
Call me crazy, but I prefer web apps for that kind of stuff. I'm also glad I don't have to download an app to use Hacker News.
As an independent developer, I am quite pleased that I can target one platform, the web, without having to deal with all the mess of multiple native apps, and worry that people won't run my simple app because they don't trust me not to delete their hard drive, and so on.
I use web apps all the time, even on mobile. And I'm sure I'm not alone.
Speaking of which Fastmail's Android and iOS apps are just the web app packaged in a native shell ;-) and they are not alone. For them clearly it was cost efective to work on that web app.
As for why they bothered to package their web app in a native shell? Maybe that's were the problem is.
Huh? There is no permission prompt for native apps to be able to access the internet. By default they can (and definitely do!) talk to outside servers for analytics etc. It’s just that you can’t see them they way you do on the web.
I get that making an app instead of a PWA is a pain the in the ass, but the reason I pay $$$ to Apple is so that pains like that exist in the developer’s ass instead of mine. I want to be in their walled garden and I want them to keep lazy developers and poor UX out.
Note that Apple does not regularly exercise that ability…
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.
A native app sits on your device, executing all kinds of code, sometimes without your knowledge. With PWAs, the code is more or less open source - all the JS is there for you to inspect - even after obfuscation, you can see the network requests being made in the dev tools of any browser.
I am fairly certain that I have posted to Hacker News with Lynx, which means that everything is handled server side.
About 20 years ago, I created a personal webmail client that was implemented entirely on the server side.
The distinction is important and while it would produce a very different web, but it does not mean a web of static content.
Say no.
Average Joe doesn't need to learn what all these things are. In the unlikely event he knows what the thing is and knows that he wants it, he can answer yes. But his default response needs to be no.
>Web should be built for everybody
Exactly. That's why Average Joe needs to adapt.
Apple has no proper concept of digital property, as it thinks its entitled to do anything with the machines that i own, and of course, to make it less offensive, they will use the card that they are doing this always thinking of me like a loving mother.
Its not just Apple, but any company, giving the financial games they need to play, the goal is to maximize profits, so the well being of its user or consumer is secondary to that (You know that CEO XYZ that actually were thinking about the user first? gone.. the board kick him out of the company because the profits were bad in the last quarter). If they can get away with using BS, where people buy the reasons their are using to justify their actions, they will do it, because its good for their real goals.
If you want context, we can use the same on this thread. Where you can clearly see that is reasonable from the security perspective to bar some of them, but a lot of others, is to bar the web platform to compete with their app platform.
Its not just now, nor just this.. if you have been following closely, aware that they do this kind of thing, you see this pattern in a lot of other places.
With Apple is not even difficult to create a Dossie to point this out. But if you didnt notice this since the beginning of the iphone launch, i guess theres little i can do here.
Apple is very good at creating a emotional bound with its things.
I dont like this "evil vs. good" kind of narrative, and Apple is not evil or good per-se (this is a childish pointf of view). Its a tech company that will use their power and position to survive and thrive. But we also need to be aware that with novelties, new problems will arrive. And we need to be aware that sometimes with the sweet, there's also this sour taste that may become a big trouble in the following years, if we are not aware of it.
Cant you see which web apis, from the ones that were bared, that are not actually security threats, but would become a threat not to security but to their monopoly on the app platform in the devices they ship?
But wait, we can just use Chrome right? nope.. because Apple is forcing every other browser to use their own version of Webkit.
Even without the need to go through every move Apple is making, isn't that clear to you?
Its clear for me how Apple is and will be the new "IE 6" of tech, being a impediment not just to the evolution of the web, but all the tech moving forward, all because they need to maintain their feud where we end with less and less option of what we can do with the stuff that we own.
Its not very clear right now, because they are still moving the needle, but if you looked into te Microsoft of the nineties, you would also not believe it.. and yet in the 2000's it happened..
This is an old trope that has been disproven not only in law but also in practice. Many public companies' boards allow their executive teams the discretion to sacrifice short-term profits for long-term gains and to build customer trust. Apple is one such company; Amazon another.
Cant you see which web apis, from the ones that were bared, that are not actually security threats, but would become a threat not to security...
I'm no security expert, but Apple is full of security experts. When they say a web API has the potential to be a security vulnerability, I believe them. They've earned my trust. Perhaps they haven't earned yours--which is fine--but if you disagree with one of their conclusions, why don't you point out which ones you think they are wrong about, and the specific bases for your disagreement?
Furthermore, native apps can be retained and often installed after they're no longer supported by their developer. Web apps vanish into the night, and leave you with nothing.
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.
Now, I can't see people suddenly not using their iPhone because of the pandemic (quite the contrary actually) - perhaps this signifies a slowdown in iPhone sales?
1) code navigation, editing, refactoring 2) integration with Git/GitHub, Issue Trackers, Cloud Providers 3) external build system support 4) multiplatform editing (java, js, typescript, kotlin, python, etc) 5) integration with testing, continuous integration, deployment 6) code analysis, finding problems 7) tons of special support for DSLs and third party frameworks
The only thing XCode is better at IMHO is UI building and OSX instrumentation. If you're writing tons of code that doesn't have a UI, especially for cloud backends, I don't think you'd use it.
Even simple things, like language injection, work wonders in the editor window. Having the IDE know how to syntax color, check, and code complete SQL, CSS, HTML, Regex, etc inside strings is a huge help.
I spend 15 years on emacs, and the last 15 on InteliJ, and having an editor that slices and dices code in a myriad a ways with easy to use automation, and actually indexes the code and builds a deeper understanding of the totality of your project is well worth it. I just wish it was less laggy in the UI.
If I was writing an iOS app, sure, I'd use XCode, but I can't envision being it general purpose for anything else, unlike the versatility of other competitors like VSCode.
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.
Do you? What would the average user install on their iPhone to allow such intervention? What’s the native equivalent of incognito mode?
I won’t argue with you in the retention point but that’s not really related to the privacy discussion at hand.
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.
import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk
class MyWindow(Gtk.Window):
def __init__(self):
Gtk.Window.__init__(self, title="Hello World")
self.button = Gtk.Button(label="Click Here")
self.button.connect("clicked", self.on_button_clicked)
self.add(self.button)
def on_button_clicked(self, widget):
print("Hello World")
win = MyWindow()
win.connect("destroy", Gtk.main_quit)
win.show_all()
Gtk.main()
<html><body>
<button onclick="alert('Hello World')">Click Here</button>
</body></html>
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.
Just this last month I have been building an app to manage my pantry (keep track of expiration dates) using QR codes I stick on everything. I built the "app" in VueJS (wanted to sharpen those skills) and did the whole thing in the browser. Scanning QR's and scanning UPCs (to track items) was all done using browser apis. I then tried to use it on my phone and hated dealing with the loss of space to the browser UI and it hiding/showing as I scrolled. It was a terrible experience.
So I migrated all my code over into Quasar (a VueJS framework that will let you build for PWA, SSR, regular web, and Cordova/Capacitor. I told myself I wasn't going to use cordova for this, I was going to stick to the browser and try to make it a homescreen icon. It was still shit. It was a pain to get the app to go fullscreen and not pop webkit views on top of my "app". The nail in the coffin was Apple doesn't let you have camera access when the app is running in that mode (it's really just unacceptable IMHO). I spent <10min getting the cordova app running and it's been smooth sailing ever since.
I still do some development on my laptop in the browsers but I would never run a PWA if I had the option of an app (even a cross-platform web app in a cordova wrapper).
Edit: I see the disconnect now. I'm not saying Google/chrome added the midi API for fingerprinting. I'm saying the screenshot way up this thread is an example of a site using it for that purpose.
On the other hand, which apps that make money via in app purchases would be viable and successful as web apps?
Which practice? Boeing? which law? the same one that have a tendency to favor this bad practice?
What about blind trust? People trusted their children to Priests, thinking they deserve trust because "of course they are priests, and priests are inherently good people right?"
People trusted their lives to Boeing entering their airplanes, because "Hey, its Boeing! they care a lot about safety, and you know those Boeing board members, CEO and that top management, and top airplanes experts cares a lot about my safety, i dont even need to bother".
An yet, there was something rot. And for me, its in the design of the whole system. It eventually will lead to another disaster like this, and i bet a lot of us will just point to the direct culprits, as to not spoil the whole game where a lot of people are doing great..
About the security aspect of those, the web have a permission system, have sandboxes, and a lot of security already implemented, that could let to the user to see if the site he is visiting really need what they are asking for. In the end isn't how people install apps anyway? If thoses features are security threats, why apps can use them? But you wont get Apple to discuss in this level, because they know, they wont be able to stand their argumentation, if its showed to them that the same level of security of apps, can also be there in the Web. They wont, because its not in their interest to do so, and it has nothing to do with their users.
Truth to be told, i dont like the trend of the web to become a whole OS... its flawed by design to do this sort of thing. But i expect Apple to be the worst kind of judge to this sort of thing, because they know that theres a tendency to develop for the Web even for phones, because its cheap for companies to follow this path.
They will as long as they can, to make the web platform appear weak in comparison to their private offerings. Why not? I even expect them to do this, as long as they can get away with it. And as long as Apple has users that believe and trust them, they will get away with it. As you have said, you voted with your wallet, and a lot of people are willing, not aware, or dont care.. they just dont want to bother.
The same security they implement for apps, they can implement for the web, permissions systems, sandboxes and the like.
I've seen the list, and as long as there a permission system, and there's not a security flaw in the browser being exploited, i cant see a reason why not to allow this, except for the most obvious reason, and a lot of other practices from Apple that make obvious that they care more about being in control, otherwise not only its users security, but freedoms would being taking into account.
Less features, more secure, of course.. So they will always be able to get away with this kind of excuse.
But as Microsoft have learned, its not just about the users, but also making the developers happy. In the end is the collective of devs, and all the hours they expend in the platform, that will make the experience in that platform great for the end users.
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.
But the payment stack is also very complicated. It touches everything from the secure enclave up to the Merchant over the network.
And if accessing the USB stack is bad, then doing it from a native app is too bad. The Web execution environment is more isolated and abstracted than the native app SDK, see https://blog.zimperium.com/dr-jekyll-and-mr-hide-how-covert-... for example of live malware getting past the app review process and accessing geo location and other things to fingerprint.
My computer has never, in at least the last 15 years, been infested by usage of Web APIs. Since the time of Firefox and Chrome taking over from IE4-IE6, I have been free of exploits. It's fair to say that the web is used by billions of people, and for the most part, large scale carnage using browser vectors has been limited.
I don't think your conclusions are based on actual security researcher threat modeling, but more about an implicit bias against Web apps and towards native.
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.
So, who's the culprit here? You were able to create an app which can perfectly run in browser but now apple forces you invest in hundreds if not thousands of dollars in equipment, effort in learning a new programming language(although it's open-source), $99 every year for license and give it 30% cut of your revenue when you earn it just to preserve its monopoly in Appstore?
That's my argument, issue is never been the PWAs it's Apple's support for it. So, is the reason it doesn't allow any other browser engines on iOS as well. Apple has branded 'Privacy' and uses it for weaponising marketing.
Edit: Forgot the yearly license.
Apple is relevant today because they actually are focused on products, not profits. Sometimes it really is that simple.
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.
I used to think this, because I am like this, but living with my wife made me realize that for a lot of people, the phone is the primary internet device. Probably one factor is that she is a nurse, so she works on her feet. Also, she generally does not have a deep relationship with her machines, computers to her are strictly tools, so laptop is basically for word processing and storing photos when the phone gets full.
Another way to look at it is that it's not that browsing the internet is better for her on the phone, it's that sitting down with a laptop is a disruption in her routine that needs to be justified.
Business apps: do whatever, who cares. Social networking is its own hell and yeah, sandbox that stuff (for now - doesn't have to be that way).
Apps intended to be tools, to be vehicles for creation - well those are rarefied these days, huh!
Frankly Twitter is borderline unusable except for "see what's new," which is by design. A native app designed to empower users is a threat, which is why Twitter decided to kill them.
I would never expect Xcode to be the best general purpose editor/ IDE. It's good for Swift/ iOS development which is what its build around. Personally, much of the time I'd rather have a performant editor than one that has a million bells and whistles.
> - 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.
In theory, the purpose of a standard is to allow other people to implement it, from spec. The spec cannot be "just use this existing codebase". Otherwise we'd have one HTML parser that sits entirely undocumented, and the HTML spec would be "do whatever libhtml does" - we've seen that in the form of OOXML. The media streaming spec would be "just use this binary blob from Adobe, or you can't do video at all". If I came along today, and wanted to implement WebSQL, which is entirely specified as "do whatever SQLite does", from scratch... how exactly would I start? In theory, right now, with enough time and money, I could implement a javascript interpreter or html renderer or whatever else without ever referring to any other browser's source code or depending on anything - a clean room implementation. Some companies still actually do that, because Webkit, Blink and Gecko don't meet their needs and wouldn't without a complete rearchitecture. Imagine if the javascript spec was "just do whatever V8 does", and we could never get things like QuickJS or Duktape.
When I, a web developer, come across something that looks like a bug in the One True Codebase, how do I know whether it's a bug or something someone forgot to document properly? What if that bug isn't present in another implementation? Do we have to be 100% bug compatible with some arbitrary version of SQLite/V8/Blink forever? Getting rid of most "quirks" was the best thing to happen to the web from a developer perspective in a very long time, IMO.
What about when someone comes along and suggests something that would work really well in the One True Codebase, GeBlinKit, but it turns out that nobody else with a different code design could reasonably implement it?
If you use Firefox Containers, you avoid untrusted native code, and you avoid persistent cookies tracking you around the web.
It's not a great experience, mind, but it does work.
A lot of people also do have a virtual MIDI device installed whether they know about it or not. The name of this device differs between different operating systems and operating system revisions.
Yes.
>Call me crazy, but I prefer web apps for that kind of stuff. I'm also glad I don't have to download an app to use Hacker News.
Web means HTTP, Email is POP3/SMTP/IMAP. Different protocol, different programs. That you can use a website to view and send emails is not the default case and is merely a interface to those protocols.
Nobody ever argued that it was about the programming languages or equal implementations, but about project stewardship and diverging code bases. They influence each other, it's not only about one or the other.
I don't know where you get your weird 100% bug compatibility idea from, that's literally how nothing is handled anywhere. This is also orthogonal to specs, you can have specs that completely dictate specifications (like CORBA) or that are super loose in what they allow (ANSI C).
There are not only reference documents but also reference implementations, as projects grow it's ok do diverge from them, and find common ground in other documents like specs. Sometimes they cover reasonable behaviour so well that they can work as an alternative to a specification, like sqlite and https://sqljet.com/ . That doesn't mean that they'll never change, SQLite regularly has bugs discovered and fixed. If the SQLite devs don't even adhere to your assumed "aLL bUgS aND BEhAViOUrs aRE SAcrEd AnD MUsT Be KEpT InDeFInitElY" philosophy, why would anybody else?
As if there is some kind of weird rigid black and white process involved with these complex projects, that is either good base implementation and no spec ever in the future with 100% backwards compatibility, or waterfall spec development followed by implementations that asymptotically approach the spec.
Where theres a will theres a way, these projects and documents are all about people and the ways they collaborate and work. It's not as rigid as you make it out to be.
>When I come across a bug how do I know whether it's a bug or something someone forgot to document properly? What if that bug isn't present in another implementation?
You do what you currently do. You go to a place where the people that steward the project reside and you ask. Why and how do you think specs get revised? They contain ambiguities, bugs, and unspecified behaviour. Somebody stumbles upon it, and asks a question.
>What about when someone comes along and suggests something that would work really well but it turns out that nobody else with a different code design could reasonably implement it?
You'd do what you currently do. You talk about it, and in the end you might even write it down somewhere, in a spec, in an rfc, in a piece of documentation.
You seem to think that SQLite would stay the reference implementation for ever, which is simply not true. It's a good starting point yeah. But webkit didn't stay the reference implementation either, nor did netscape.
Don't be so rigid.
Bringing up flash here is like responding to an argument against capital punishment with "prior to lethal injection, you had firing squads, which do you think is better?"
> Hit the back button, or clear all your caches, and you're done, but otherwise, it's fire and forget.
Then of course websites can override the behavior of the navigation buttons...
> The installable App model creates "shit work". Everytime I install something, it permanently takes up both screen real estate, and storage, and creates a cleanup task for me to delete it at a later date. Steve Jobs said "don't give your users shit work", well, app install and uninstall is shit work.
Steve Jobs also thought he could cure his pancreatic cancer with a vegan diet. Perhaps shit work is a necessity if you don't shit laying around in inconvenient places, and this was one of Jobs' neuroticisms that didn't contribute to his genius.
That an app takes up permanent screen real estate is a matter of designing the operating system interface. On my computer, apps certainly don't take up permanent screen real estate.
> I want to use stuff and get work done, and want things to go away if I don't want them without having to become a System Janitor.
I feel the same way and my apartment is currently an absolute mess for this reason.
> The whole app model is a complete reversal of decades of movement to thinner clients, back to the Windows model.
So is the direction of the web, where clients are expected to do more and more work to make the server side application work. This is why computers that were sold as "thin clients" back when this concept was actually considered relevant are now pretty much useless for browsing the web. We're now working towards rich clients for better or for worse.
> Every time I go to a new restaurant, a new milk tea place, a new airport, or a new airline, they're asking me to install their native app. How many god damned United/American/SFO/InAndOut/FiveGuys/Chipotle/Starbucks/et al apps do I need on my device?
In my experience, none. I pay cash, debit card or in some cases using a single phone number based bank transfer app that's ubiquitous in my home country. In no cases have I needed a vendor-specific app to do this. Are you telling me that you can't go to Starbucks and buy coffee without installing their crapware?
> And no, "Instant Apps" are a worse solution to this.
No one mentioned "instant apps" and I've never heard of the concept until now. I agree that it's a stupid and pointless idea. This is not a problem that needs a solution in the first place, and "instant apps"/webapps/whatever are just part of a spectrum of stupid solutions to a stupid and incorrectly posed problem.
The problem they want to solve which is not as stupid, but all the more privacy invasive and manipulative to make up for it, is that of knowing as much about their customers as possible and to be able to push marketing information to them on that basis. To the credit of "instant apps" it only partially solves that problem.
> Form-filling is literally the use case for SGML from the beginning.
Yes, and if you limit your web app to the simple task of letting a user fill a form and submit it you don't need any of the stuff added to browsers in the last 25 years.
> No, we don't need a native-locked-down-walled garden for every physical point of sale in the real world. And since Apple will never own 100% of the market, this means developers will end up needing to write, x2, silly little point of sale apps which clog up people's phones.
No one needs to do that. If you mean that a big web API surface is necessary to create proprietary point of sale systems in a way that's more convenient to the vendor, I consider it only appropriate to limit the API surface to prevent them from doing so.
> Ephemerality, transparency, portability, are desirable properties in addition to security and privacy. Apple leans too much on the latter at the expense of the former with relatively dubious justifications that could be fixed with better design, instead of refusing to participate in improving the specs to meet the desired properties.
It is clearly the case now that security and privacy significantly suffers from the browser API surface.
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.
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.
So they might catch some rogue apps, but far from reliable or trustworthy. They protect their platform image, nothing more.
With webapps at least I can take some measures like ad and tracking blocking myself. I don't have to give access to the system unless some case really warrants it.
The internet became more powerful so it does more things. The PWA spec allows for zero-install apps that are just as performant (or more) than native apps. You can view their network requests in the console, and they run in a sandboxed environment. You want to download and install a binary for something that can be accomplished in a few kb of cached JavaScript?
I don’t want any websites triggering the browser to ask me if they can send me notifications.
I don’t want any websites asking me if they can ask the browser to ask me to send me notifications.
I don’t want any websites using their classic scams like tiny “x” buttons that have insufficient contrast and are impossible to click on a mobile device anyways to ask me if they can ask the browser to send me notifications.
I don’t want to see my grandma dealing with scammers who trick her into allowing potentially phicious notifications that she doesn’t know how to cancel, or even what the source is.
I want developers to jump through as many bullshit hoops as possible before even having the chance to send me notifications. Apple and their review prices help me out there, and for all above points.
It seems to me like you believe everyone is the same as you: they value small package size, they personally audit all code they run, they want random corporations to have an easier time getting a presence on their home screen, and they’d be able to easily identify and stop all corporate badgering they do end up receiving. I don’t think any of those are true even for me (someone in the industry), let alone the population at large.
> I don’t want any websites triggering the browser to ask me if they can send me notifications
That’s fine for you but some of us who are in niche communities or have weird applications don’t want to wait for a VC to fund the development of a native app.
Right now I can’t get notifications from IRC at all which pushes me and everyone else to centralized chat services. This has distorted the evolution of the internet and I would argue has contributed heavily to the “fake news” problem.
> It seems to me like you believe everyone is the same as you
You’re projecting. We want a feature that the user can disable, not ever being able to use this at all means everyone has to want the same things you do.
There's no way you can argue that a single "grant all permissions" step is more privacy friendly than fine grained permissions.
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
It doesn’t take a VC to make an app, I made some starting in HS (with push, yes), and you can too. Be the change you wish to see.
The idea that "staggering few" is a negative disappoints, given it has almost always been the "staggering few" who've progressed humanity.
Thankfully I already have another reason for paying for the app store dev program so I am able to leverage that for my own personal apps or ones I might publish.
I agree with you actually, but not everybody does. Some people do want push notifications when they get a new email or Facebook update. I wish it weren't so, but it is.
> I don’t want any websites triggering the browser to ask me if they can send me notifications.
> I don’t want any websites asking me if they can ask the browser to ask me to send me notifications.
> I don’t want any websites using their classic scams like tiny “x” buttons...
Given that we live in a world where there are notifications, you have the choice to disable them on your device, or decline them on a site by site basis. For your grandma, I'd suggest the former strategy.
But if you don't want the site to ask you, and you don't want the browser to ask you, and you don't want to disable them for all sites, you're setting yourself up for disappointment. All the whining isn't going to bring back 90s internet.
> It seems to me like you believe everyone is the same as you: they value small package size, they personally audit all code they run, they want random corporations to have an easier time getting a presence on their home screen, and they’d be able to easily identify and stop all corporate badgering they do end up receiving
What's the difference between a native app asking to send you notifications vs a web app?
I imagine other browsers probably do, too.
Regardless, I said my preference is to use web based email, that's all.
Most (all?) of us like to be the one who controls what we can do with our own devices.
These standards return some control to the user, rather than the corporation.
But then we get more prompts! Well, not necessarily. The user could choose to have all prompts automatically rejected, and only opt-in when they desired. This would not create more information for trackers to track, because Apple could make it the default for all of their devices.
This seems to solve the problem: People who want the features can have them, and the people who don't want them can ignore them without interruption.
This is where our problem with Apple is: there are solutions to be found but rather than solve them, Apple hides behind lies in order to protect their bottom line while harming many users and the internet as a whole.
My point was essentially that you can run a native app without internet access most of the time (and can easily block the app making calls out by switching the internet off or blocking the calls its making) but a web app you have absolutely no control over, you just have to not use it.
All of the APIs that Apple isn’t supporting wouldn’t help a single major revenue producing app move to the browser.
Really, in practice how often are you prevented from leaving a website? Except for porn and pirate websites, almost never, and taking over the back button/onWindowExit is now mitigated in most browsers. For the majority of the people on the planet, they browse hundreds of websites, without ever needing to give a cognitive thought of cleaning up their cache. Websites are effectively emphemeral from a cognitive standpoint to most people, whereas app installation is not.
The web surfing is like channel surfing TV, when you change the channel, you're done. App installation eventually creates an environmental cleanup task for you.
The install model is a giant regression to the ease of consumption and low cognitive overhead the web brought.
> In my experience, none. I pay cash, debit card or in some cases using a single phone number based bank transfer app that's ubiquitous in my home country. In no cases have I needed a vendor-specific app to do this. Are you telling me that you can't go to Starbucks and buy coffee without installing their crapware?
The purpose of POS apps is not just payment, but parallelization. A POS is a queue, which means customers have to wait in line to give their order. You've never had to stand in line in front of several indecisive people? POS apps provide the ability for you to conduct the entire transaction without getting in line, and indeed, place your order and then arrive just-in-time when its ready. I routinely order, and then arrive to pick up with zero wait. Hundreds of millions of Chinese who use WeChat for 'O2O' commerce like this and it is the ultimate in convenience.
For people with disabilities, POS apps are a god send. And they're especially great for this pandemic. The only problem is, there's no need they be "apps" that get installed.
> It is clearly the case now that security and privacy significantly suffers from the browser API surface.
Browser security in the Firefox and Chrome world has been more solid than the 'apps' world. I'll take the browser sandbox over the app sandbox any day. And the browser API surface hardly matters when third party cookies, which have been around since 1995, are still widely used for tracking, and the biggest bit of fingerprinting entropy -- your IP address -- is core to the internet itself. And again, these APIs won't matter for fingerprinting if they are behind permission requests, because they can't be automatically used by third party ad networks.
Now excuse me, I have to give back to a meeting on that App Store reviewed Zoom app to conduct my meetings. I have nothing to worry about eh?
And still waiting for someone to give me an example of an app that makes a lot of money on the App Store through in app purchasing, that could probably make just as much money as a PWA if it weren’t for mobile Safari.
Fair, but I hope you agree that both are something we should care about. The privacy argument is generally the fingerprinting one.
> But the payment stack is also very complicated. It touches everything from the secure enclave up to the Merchant over the network.
Yes, but not at the actual level that the we process would have to deal with. There’s a huge difference between “can I have a credit card number” and “can I DMA” from the web process. (I would assume WebUSB does something saner than that, but it would still be copying a lot of bytes around security boundaries with parsing going on.)
> My computer has never, in at least the last 15 years, been infested by usage of Web APIs. Since the time of Firefox and Chrome taking over from IE4-IE6, I have been free of exploits. It's fair to say that the web is used by billions of people, and for the most part, large scale carnage using browser vectors has been limited.
Well yes, but of course such attacks are typically used against a dozen journalists in a repressive country, and not you, a Google engineer in what I would assume is a moderately comfortable situation in comparison ;)
> I don't think your conclusions are based on actual security researcher threat modeling, but more about an implicit bias against Web apps and towards native.
Bias towards native noted, bias towards security research also a thing I think I may have ;)
This is assuming we moved to a model where more permissions had to be requested rather than just allowed
Because the relevant issue is most certainly how people use it. People use web browsers to read their email. Why is what the RFCs say important to this?
>How about email apps such as Gmail or Yahoo mail?
So the answer is: It doesn't matter as those are not email apps. They are email frontends for a service that implements mail. If people think differently - it's their wording, but still a wrong one.
Chrome team has done a terrible job at understanding how less technical users interact with their browser and how to keep them secure.
My senior citizen support checklist is editing their Chrome shortcut to always launch without extensions, and block all new requests for notifications, location, camera, microphone, etc. (Switching browsers is better, but generally seniors prefer their computers don't change much, so I'll usually carry forward the browser they already have.)
Why you'd think debating the semantics of the word "email" is relevant to the discussion is beyond me. It makes me almost wonder if you are attempting to parody a certain type of pedantic technical person.
You're clearly wrong then. iOS already does something similar with location and doesn't suffer from this problem.
>It doesn’t take a VC to make an app, I made some starting in HS (with push, yes), and you can too. Be the change you wish to see.
That's actually kind of upsetting. On my other machines I do fix problems. The cost of volunteering to deal with apple's shitty phone is an overpriced machine where even the old used desktops are more expensive than the modern one I just built, the time it takes to learn a new language and an (IMO pretty crap) environment (GUI toolkit not withstanding,) the time it takes to maintain an app for a platform with constant API churn, and $100 a year for a developer license (nope, you can't use push notifications without paying this.)
Here's the change I want to see: people abandoning an abusive company. I'm buying a pinephone so that the next time I have a problem I can deal with it without having to buy the beater car equivalent of a computer (and spending as much.)