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.
Here's what appeared on porn site xhamster.com once newer versions of Chromium got around to implementing the permission check (SFW-ish):
Especially in the porn industry where the end users are likely using incognito mode or a VPN.
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.
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.
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.
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.
Maybe you don't want things like videochat or paint programs or music learning apps to run in a browser, but lots of people do.
Imagine if Firefox said "we're not going to let any web page access the camera"... their market share would probably drop in half overnight.
I imagine other browsers probably do, too.
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.
It's not a great experience, mind, but it does work.
The three categories I would make are: text, static forms, and SPAs
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.
>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.
Regardless, I said my preference is to use web based email, that's all.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
from gi.repository import Gtk
Gtk.Window.__init__(self, title="Hello World")
self.button = Gtk.Button(label="Click Here")
def on_button_clicked(self, widget):
win = MyWindow()
<button onclick="alert('Hello World')">Click Here</button>
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.
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.
Users need to be protected against themselves as long as they can't take responsibility for their actions.
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.
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.
maybe 10% is enticing for those who create botnets
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).
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...
Is there a way to escalate that I'm not seeing? AFAI remember, all programming is done through status messages 11110000 and above.
Full Disclosure: I made a web synth and really want to be able to use midi to play with it.
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.)
The idea that "staggering few" is a negative disappoints, given it has almost always been the "staggering few" who've progressed humanity.
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..?)
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.
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.
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.
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.
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.
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.
Why have native apps at all?
Because web apps are crap, excuse my Swahili.
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.
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.
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.
This is assuming we moved to a model where more permissions had to be requested rather than just allowed
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.
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.
You only think from a developer’s perspective. What if you are the user receiving 50 notification requirement a day from a web browser?
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.
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.
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 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 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.
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.
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.)
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.
Their browser share dropped a little recently (https://gs.statcounter.com/browser-market-share). If that continues, it'll certainly irk them!
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?
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.
Apple is relevant today because they actually are focused on products, not profits. Sometimes it really is that simple.
On the other hand, which apps that make money via in app purchases would be viable and successful as web apps?
All of the APIs that Apple isn’t supporting wouldn’t help a single major revenue producing app move to the browser.
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.
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.
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:
The notion that Apple is not implementing the web push API for example, for privacy reasons, is stupid.
Seems fine to me?
On a more serious note though, in iOS 14 app developers are responsible for any SDK's their app uses including data egress.
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.
> 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.
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.
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).
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.
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 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.
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!
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 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.
The occasional tweet I may send is just an input field and a file upload maybe.
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.
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
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.)
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.
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.
Tastes vary, I suppose.
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.
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.
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.
Ignoring those two, you get damn near every major web app. All of Google's applications, Facebook, Twitter, etc. etc.
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 and uses some high level device features.
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.
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.
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.
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.
You have a lot more control over something that's running locally than something running serverside that simply using the client to harvest data.
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.
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.
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.
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.
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.
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.
> 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.
The number of hackernews threads calling out Apple for not supporting PWAs is just as insane.
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.
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.
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.
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.
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.
The price of a Safari user in the ad market is going down, and it’s exactly what should be happening. I’m very happy with Apple.
You can implement these APIs while at the same time requiring explicit permission from the user before a web application can use them. This preserves privacy while also giving users the option to have much more powerful web applications.
Apple doesn't want to implement these APIs because currently if you want access to these things on iOS, you need to go through their walled garden App Store, where they get a big chunk of any revenue you might make on such a service and can nerf competitors and all the other anti-competitive stuff they're doing.
Except on the long term that would have no effect in empowering users. We all know that when faced with a deluge of permission requests, or pressured by the fact that enough people have already accepted and it's the entry price to collaborate, people will just hit accept and be done with it.
They only need to get the foot in the door and then you'll find that plenty of stuff ends up conditioned on you giving them access. Every one of these APIs is a Trojan horse. Past experience just proves that they will be hijacked for purposes that don't do the user any favors.
Look no further than JS which is there to enrich the web to benefit users but 99% of it is garbage slid under the door to benefit site owners. That's because plenty of things that should work just fine without it are now tied into it, disable JS and the site experience breaks.
How is that any different from apps on the App Store?
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.
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:
Luckily you can have both, despite Apple wanting to pretend otherwise.
I have a bridge to sell you...
I think there are ways to get (a bit of) both. It's not simple though.
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.
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.
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.
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)
How can this be so when the web browser itself is a heavy client?
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.
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).
Mobile apps are increasingly sandboxed too, like websites, precisely because of that.
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.
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?
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.
> 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 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.
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.
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...
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.
thats a very good reason then for an app-store to enforce rules and code checking then, isnt it?
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.
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?
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.
from the page https://support.apple.com/en-gb/HT203033
However, I have to admit that displaying one icon per permission would not scale great when having a dozen of them.
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 get that in theory, web notifications are supposed to be valuable, but in practice its been nothing more than a constant annoyance for me.
Apple bros on HN: "Good! finally someone standing up to the BigTech abuse of privacy"
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.
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?
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?
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.
Note that Apple does not regularly exercise that ability…
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.
For instance, the Audio API. You can test it using OpenWPM  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?).
What's your point? Because one API can be used for something, Apple should let Safari be a free-for-all?
Apple forces you to use those. You have no choice, like on other platforms.
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.
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.
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!"
Is this a thing? Do people in demographics which are less appealing to advertisers also see more intrusive ads?
Those ads might be terrible chum bucket stuff, but they would not be intruding into your privacy.