Open Web Advocacy
open-web-advocacy.org
open-web-advocacy.org
Literally only one major player is lagging here.
I’ve heard Opus is supported, but not in Mkv (WebM) or Vorbis containers, making it a bit pointless.
A ton of media codecs. Apple is attached at the hip to the MPAA, and so they only implement standards that generate MPAA royalties such as MPEG and its descendants.
Web data storage is in pretty bad shape too. For a while WebSQL was totally broken in Safari, and they are years behind the state-of-the-art APIs.
Firefox doesn't support them either, and like Safari considers them harmful. And for good reasons that Google (who are the sole authors of these Chrome only non-standards) completely ignores.
Yes, they are being dealt with because Safari and Firefox are persistent. Chrome just releases them.
> where does it differ that much from normal apps
"Hey, we know that native apps are a nightmare for privacy and security, why would you oppose making the web more like native " isn't a good argument
Yes. And Bluetooth/USB etc. pierce that sandbox and communicate to devices outside the browser.
And no, you can't "fix it" with a simple "oh hey this page wants to access a device".
Hint: we can't successfully ignore prevent people from phishing sites and scammers, but sure, let's give an untrusted execution environment full access to everything.
> What can a native app possibly do that's such an egregious invasion of privacy that a webpage can't do
Webpage doesn't have full access to file systems (and Chrome wants to give full access to file systems), or to USB/Bluetooth/etc. (and Chrome wants to give full access to that), and...
Once again. "Hey, we know that native apps are a nightmare for privacy and security, why would you oppose making the web more like native " isn't a good argument".
Also, hint: native apps exist beyond mobile.
Also, hint on filesystems: even though they are encapsulated, that encapsulation differs greatly between systems, and having, say, full access to cloud files is just as bad.
You can disable commonly abused/exploited things like service workers and still use most websites just fine, while a webapp might depend on having that functionality enabled reducing your security when using websites and webapps.
> What can a native app possibly do that's such an egregious invasion of privacy that a webpage can't do?
Harvest your contacts? (unless that's changed)
Oh, and you owe them 30%.
Computing used to be free. This is loony tunes.
But it'll probably become moot soon anyway once EVC becomes mainstream, which is both royalty free and better performing than HEVC.
This is part of the ACCC's 5-year ongoing inquiry in Digital Platform Services.
[1] https://www.accc.gov.au/focus-areas/inquiries-ongoing/digita...
It applies to Google through Android. Amazon sells a Fire TV, which uses AOSP; but now Google's licensing forbids Amazon from also offering an Android TV product.
Perhaps Apple should face antitrust action, perhaps not, but the MS ruling doesn't really apply as Apple does not license their software. The ruling was meant to empower OEMs and Apple IS the OEM.
Operating Systems didn't always come with a browser. We used to have to go to a store and buy copies on floppy disk or get a copy from a friend or download from a BBS. Hell, sometimes we had to install TCP/IP support since it wasn't part of the OS. So when MS included a browser in Windows the groups that also made browsers cried foul. Downloading and installing software was a painful thing and a real barrier to adoption.
Don't get me wrong, I'm all in favor of enacting laws to protect freedom on the web platform. But the Microsoft fact pattern just doesn't apply.
1. Including a free competitor in a hot new market
2. Threatening hardware OEMs with financial penalties (not getting OEM copies of Windows) if they continued the practice of bundling the primary player's product (Netscape)
Back then, Web browsers were something you went to a brick and mortar store and paid good money for a disk to get. They weren't just handed out for free online. Microsoft flattened the competition in a market they were not previously in by leveraging their dominance in another market.
As a person who was on the internet since 1993, they were? Maybe if you wanted Netscape Gold with the editor, but I never paid for a browser and never remember any prompts urging me to do so or having to reinstall a shareware copy of anything.
Who did that? You could just grab an installer for netscape over FTP, IE came on every windows system by default, and if you really wanted a CD or floppy with a browser on it, your ISP would send you one. AOL CDs were sent to every mailbox in the country repeatedly and totally unsolicited and those contained browser installers. Nobody I've ever known went running to the store to buy a web browser and I know people who paid for pkzip
And how is having the same developer do it via a native application any different? Permission controls for browser can be managed the same way they are being managed for native apps. In fact, once a web app is allowed to register itself as an app, you will be able to centrally view permissions from your existing permission manager settings in your respective operating system.
If others read the section on Bluetooth it outlines how poor native protections are.
Full integration of web app settings into the OS is essential for users to be able to control their privacy.
When I create a document locally, or copy a photo from my camera to my computer, I'm responsible for how far it leaks, and it's fairly easy to manage and understand.
When I create similar data in a web app, I have no control over what happens to it.
How is "privacy worse on native"?
I think the key here is "trusted". That's the bit that needs work. Vendors need to work on their trust; our industry needs to work on its architectures and business models.
They can't evolve the way the latter did. "New API every year or we break your app" is not an option for the web.
As a user, what drives me crazy is the absence of "human interface guidelines" and sane local storage. On the other hand, I insist on the freedom to sideload.
As a developer, I pine for an application platform that is not a 30-year-old messy abstraction over a 50-year-old operating system. If it can help my layouts on a 5" vs 50" screen, all the better.
Permission dialogs are a small price to pay for enabling entire categories of applications! For example, consider WebMIDI: there are huge number of web apps that use the new standard, ranging from online DAWs to hardware device management tools (like the new Noise Engineering Imitor Versio firmware tool). It's clear as day that Apple declining to implement these standards is holding back the web, and leading to platform fragmentation.
Yes, let's prevent fingerprinting with privacy-protecting implementations, but apps should be able to use these awesome features with permission.
It's huge price to pay considering the number of permissions required, complexity of it all, and potential consequences when a frustrated user just clicks "yes" to all
Apple's not going to just drop in a change that makes you go through popup and notification hell.
I'm 100% certain Apple would give users control to enable or disable features on a per site/pwa basis.
A web app should wait until it needs Geolocation or whatever, before prompting you. It should always follow a user interaction. When you click to use some feature, then it prompts you for the permission.
Or an app could have some kind of introductory page where it lists the permissions that it will need, and you click each one that you want to give. Again you do this at your leisure, not upon page load.
Want service workers to perform background sync? Want push notifications? Sorry, you're out of luck on iOS.
It's a blatantly protectionist policy to make devs provide App Store apps, and it's harming the entire web platform.
No. Not even a little. I don't want these for my native apps. I turn them off for everything.
Once any feature, no matter how exotic, becomes part of "the web" it can never be removed from browsers ever, for the rest of time.
Either that policy must change, or we must be ultraconservative about accepting new "web standards". One or the other. Either choice has disadvantages, but we cannot choose neither.
Did adding location access, or Bluetooth access break the web for you?
Yes, and I'm glad they did.
The article at the top of this discussion is whining about the fact that Apple does this.
I fully disagree. The web platform will no longer be an open platform once Google is able to use it's standard suite of tactics to force everyone on iOS to switch over to Chrome.
As irritating as the iOS WebKit monopoly may be for a handful of web developers, it's the last line in the sand against Google's complete control of the web that forces them to at least try to involve standards bodies.
Apple can be your enemy in every other day and respect, but we all need to line up and support them in this one key area. The open web depends entirely on it.
Now they get to push whatever web feature they want by the web standards committee and is immediately available in Chrome, other Chromium Based browsers and Electron apps, with other browsers needing to implement them to keep up.
All along the ‘open web’ was the exchange from one behemoth to another. It is a two horse race between Google and Apple with Google winning and calling the shots - hence the web developers always supporting Chrome first and calling Safari ‘the new IE’ and telling everyone else using other non-Chromium browser just to switch to one via banners or messages.
This doesn't seem true. Where are the native quality experiences when using a PWA on Android? If it were Apple single-handedly holding things back, we should see plenty of these, right?
If you’re writing code intended only for Android, Apple’s influence in both cases is the same – irrelevant. Yet when you look at only the cases where Apple is irrelevant, people still overwhelmingly continue to choose native Android applications over PWAs. Blaming Apple for this doesn’t seem reasonable.
In the long run, having to install the native app is an inconvenience to those users and their next phone will be less limiting. Apple is famous for their creative destruction, but sticking to their native apps breaks their appetite for innovation.
Drifting in Space [1] has just been announced. After 30 years, the General Magic[2] concept is almost reality apart from the fluid integration of client and server. How can that happen on an iPhone if Apple locks the browser? In other words, sooner or later, they either have to open the browser or become irrelevant.
[1] https://news.ycombinator.com/item?id=30502978 [2] https://en.wikipedia.org/wiki/General_Magic
You could use capacitor in a web view to recycle most of the code.
In addition to making money for Apple and enhancing its platform control, native apps tend to be more power efficient, more responsive, and more consistent with Apple's UI guidelines – features which, in Apple's view at least, lead to a better user experience.
That being said, I personally hate it when web sites (e.g. reddit) demand that I install an app when I just want to use the web site.
“Look at all these alternative browsers you can use”
> points to Chromium variants.
Chromium variants are not an alternative, and I’m happy to perpetuate Safari on iOS if it means Apple keeps shafting ad-tech companies in service of my privacy.
> Analysts project Apple will make $5B off ads this year and $20B per year by 2024
On the other hand 80% of Google's revenue comes from online ads.
Do you really wish corporate control so much? Do you want to go through Apple review for your websites as well?
It's incredible how brand fanboyism clouds your minds - this isn't about engine competition, it's about making free web an equal player to golden cages of app stores.
You mean, like Chrome? Developed by the monopolistic American megacorp called Google?
Also, if PWA’s and Electron apps are your version of “equal to native” I’m going to have to strongly disagree.
Instead, you're defending Apple monopoly where they ban all competition, stagnate web development and make PWAs and other web-apps a non-viable possibility on their devices. All because... you don't like Chrome? Although you'd still have a full option of using Firefox, Safari or others? Why? Because someone else might DARE to use a product THEY prefer?
It's such a blatant lie about PWAs.
And thank god Safari and Mozilla don't implement dozens of Chrome-only non-standards.
Web Apps if allowed could provide equivalent (and sometimes much better) experiences than native.
But it’s a chicken and egg problem, and it’s mainly Apple holding it back.
It isn't, and it's also a near impossibility for the web.
> Web Apps if allowed could provide equivalent (and sometimes much better) experiences than native.
No. No, they couldn't.
Of course, you could say "but WebGL/Canvas/WebGPU", but then you're just building native apps with multiple extra steps.
WebGL / Canvas are web standards, no issue with using them.
Accessibility.
Show me how to reliably do 60 FPS on anything that causes re-layout. Example: animating an item added or removed from the list without hacks.
> WebGL / Canvas are web standards, no issue with using them.
1. Accessibility
2. These are basically native technologies. So, you're basically using native tech, with extra steps
3. Between WebGL, Canvas and upcoming WebGPU you have three incompatible technologies with a list of shortcomings longer than the equator
If you can point me why Slack, Teams, WhatsApp desktop, Telegram, etc need too much ram to render a simple list + chat and call that efficient, then I would believe you about web apps being good.
TweetDeck spikes to 22% CPU just to display a tooltip: https://twitter.com/dmitriid/status/1486629036520521734
Truly an amazing technology.
Edit: and yes, Slack consumes 17% of CPU power to display animated reactions on an M1 processor.
Remember, Firefox is not allowed to exist on Apple devices either.
This conflict of interest - browser privacy vs. Google’s ad business - is the single reason I now use Firefox [on desktop].
Many of those "standards" and APIs are emphatically not standards despite what Chrome's vast propaganda machine tells you.
That said I'm glad more people are starting to acknowledge this and bring it up in these discussions. Firefox is not really a counter to Chrome's dominance and WebKit only really still is due to Apple being too big to push around.
If I'm stuck choosing between those two evils, I'd sooner take Apple... then try to figure out what a better solution is than just "make Apple change because I don't like Safari".
That would seem to be a pretty strong argument _for_ browser choice in my opinion.
Even now on iOS Google's apps constantly "forget" my choice of browsers and try to push me to use Chrome for external links.
We don’t want this to be about personalities and want to focus on the problems at hand.
Happy to answer questions and I hope some of you will join us in advocating a better future for the web.
If you actually advocate for open web, where's Chrome on your website?
Chrome routinely releases its own internal APIs disguised as specs, calls them standards, ignores any and all concerns from both Safari and Firefox, and then proceeds to gaslight those two browser for not kowtowing themselves before Google's whims.
That said we want to make list of other things to target and fix, but they have to be well understood and documented. If you're willing to type this up in detail... which APIs, what the issues are, comments from the various browser teams involved and why they came to that conclusion (and it's really important to talk to the individuals that were actually involved in whatever spec you were talking about) and then post in the discord, I'm sure folks would be interested.
It's also really important to be specific as to why the behaviour is harmful to end consumers. We also need to order the issues in terms of priority and how damaging they are to the wider ecosystem.
Some issues with Google include equal WebAPK minting system on Android, and respecting a user's browser choice via Android or Google apps.
Finally, this is all volunteer work on people's weekends and producing detailed technical arguments about each of these topics is incredibly time-consuming.
Should be lots of updates to the website over the next few weeks, lots of people have volunteered, the web community is amazing.
It means you're not really focusing on the open web. You have a very specific, very narrow beef that you're pursuing.
And it's parroting Chrome's propaganda basically word-for-word both on the website and here in the comments.
> they have to be well understood and documented. If you're willing to type this up in detail...
In Discord, right?
You could start by actually looking around and figuring out these things yourself, too. Not just repeating Google's talking points.
Good starting point: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
Or maybe look at the status of the APIs you so ardently defend. Example, WebHID timeline: https://github.com/mozilla/standards-positions/issues/459#is...
etc.
> It's also really important to be specific as to why the behaviour is harmful to end consumers. We also need to order the issues in terms of priority and how damaging they are to the wider ecosystem.
You've already stated your priorities loud and clear
> and respecting a user's browser choice via Android or Google apps.
Yup, it's s good one. Since Google doesn't respect that and ignores all/most input on the non-standards it's pushing out at neck-breaking speed, you can see where it's going if you "allow browser choice on iOS"
We have a GitHub for more formal conversations and discord for chat.
We will tackle the major issues relating to browsers and web-apps that the vendors aren’t addressing.
Wanting Web Apps to work is not a narrow focus.
I have, instead, found the platforms most difficult to work with are 1. android for its heavy reliance on Java (which is not an appropriate language on plenty of embedded systems and on systems where efficiency means money), 2. windows for its poor system api and heavily restrictive marketplace, and 3. Apple for its heavily restrictive marketplace.
Note, though, that none of this has to do with the web and web-like technologies. There is nothing stopping React or similar App frameworks from being deployed on mobile devices.
And, for the record, there is legal precedent for app lockdowns like these. We don’t need more laws — we need to enforce the precedent we already have. Find a lawyer who can be convinced that Windows DirectX and ie are illegal tying arrangements… find a lawyer that could be convinced of the difference between Metal and OpenCL+OpenGL.
That’s why we have these problems; it’s a lack of understanding from the departments responsible for prosecuting these illegal tying arrangements.
Your comments about Apple are valid of course, but to convey more credibility and eliminate accusations of astroturfing, you probably should list some issues with all of the big players. I’m sure you can find many issues with Google, Facebook, Amazon, Microsoft, and others.
Citation needed. The web sandbox in most browsers is head-and-shoulders more secure than executing arbitrary native code.
Perhaps you meant "private." It's true that the web has developed something of a fingerprinting problem, but this can be solved with finer-grained capabilities-based permissions, as well as privacy-conscious implementations (e.g. bucketing).
The web was meant to be an information sharing platform. To share information means that there was standards to be built. From these standards, came the possibility to make things that works everywhere, which explains the popularity of web apps.
It may be tempting to push for more support in web standards, however the nature of the web platform give it vulnerabilities that wouldn’t exist in a native app.
A native app is a piece of code. You can analyse it through antivirus, and the executable stay the same unless you choose to update it. (Electron apps allow app maker to update automatically, but they are not native apps, the chrome browser embedded is native but the only website it can access is not). A web app use multiple devices and is more uncertain. Service workers fetch information from a website and on a remote server, and that code would arrive on your computer without you actually consenting or realizing it. What if my website get attacked and suddenly my web app is loading a Bluetooth api that could access a connected object, like my smart car, my health device or other potentially dangerous stuff?
Moreover, allowing alternative browser would allow developers to be less constrained by Apple, for the better, indeed, but also for the worst. If chrome decide to bring their chromium browser to iOS, Facebook could just delete it’s iOS app and put it as a chrome PWA, this would allow them to bypass the Apple Store restrictions.
Not sure if telling legislators about it will make it any better. They'll say competition laws already exist. It's enforcing them that's a problem. May be someone should team up with EFF and file a major anti-trust case against Apple.
We will be setting up our GitHub account to allow contributions if thats better.
Want WebMIDI? Want push notifications? Sorry, you can't have that on iOS, not with any browser.
Who exactly? they just created 6 tweets in 1 hour and now they are "web devs"? they shounds like PR people, probably mozilla?
This is fishy af
EDIT: The Register lists two specific developers who I don't think work at Google "plus others" so if it's Google they have gotten better at astroturfing since the Open Handset Alliance days of yore. It looks like they're lobbying the UK, and I don't think Google admits which lobbyists they pay outside of the US.
It’s been a huge amount of unpaid work, but the entire industry had been held back for so long we felt we had to do something.
People just assume that we’re funded because we’ve stuck a lot of effort in trying to fight anticompetitive behavior. If you read our content though you’ll see it’s not legal/PR nonsense.
Available on Twitter or discord for chat anytime!
Google's constant stream of web "standards" only they've implemented, AMP (which thankfully is starting to die), and Privacy Sandbox all fold into a plan to control the web.
You might not be paid by them, but please don't take on the "useful idiot" role of helping them control the web because you didn't understand the impact of what you were promoting.
Our aim is to remove barriers and we will fight any anti-competitive behaviour by any operating system or browser vendor but in a priority order.
Priorities are great to have, but yours are wrong and harmful. If you win, we all lose, and I fear you will come to understand it too late.
Safari only competes on one platform and that is MacOS.
If you read through our regulatory submission at https://open-web-advocacy.org/#where we run through this argument in detail.
It should also be important to note that blink is a fork of webkit which is a fork of khtml. There is nothing stoping competition within the chromium browsers as outlined in section 8 of the document.
We want Safari/webkit to succeed.
Google has used a litany of underhanded tactics to obliterate every single browser in an open space. Claiming opening up iOS to competing browsers would be helping Safari succeed is just ignoring history.
All of us are web devs, none of us writers or legal/policy people or are paid or affiliated with by any major company. We’re the opposite of paid, it’s taken a lot of time and effort, but no company was fighting this so unless we tried nothing would happen.
This is not funded by any company, it's a volunteer community effort.
Since when does application development equal web application development? this is a narrow-minded view.
> stalled innovation for the past 10 years and prevented Web Apps from taking off on mobile.
I may be in the minority but, as a user, web apps on mobile is the last thing I need. Also, as a developer web apps as a preferred way of developing for mobile is the last things I need.
> Web Apps if allowed can offer equivalent functionality with greater privacy and security for demanding use-cases.
This really needs some sources. To me, it reads like something akin to a snake oil ad piece right now.
I would bet in the future most apps are web apps, either JavaScript PWAs or WASM. The economics of cross platform development are too great. I think most users won't care, or may even appreciate this due to the size savings (a PWA today is almost always a lot smaller than a fat app on my experience).
As a developer, I would rather write web apps that can use standard web interfaces for camera/files/icons/notifications than having to learn all of the platform specific stuff, and as a bonus I'll get a lot of accessibility benefits for free.
That is speculation on user behalf, isn't it? I am a user and I care.
> ..than having to learn all of the platform specific stuff..
It is a rational argument. However, Chrome is a platform too. More and more of the web only works (well) in Chrome. More and more of the web is what Chrome says it is.
You care how an app is developed and delivered to your device?
The web offers a native experience in most cases, sometimes even better. Besides, giving PWAs more abilities doesn't remove native apps.
> More and more of the web is what Chrome says it is.
It's pretty ironic that you support Apple in locking down what you can do and apps you can run and what Safari supports, while blaming Chrome for being the dominant browser.
Why is that so shocking? The moment when users stop caring about how stuff works you get the very situation the article is complaining about.
>The web offers a native experience in most cases, sometimes even better. Besides, giving PWAs more abilities doesn't remove native apps.
Why are you telling me what my experience is like?
Do I think that you should have a fair chance at experiencing apps in your preferred way? Yes.
Do I think that your way is actually better based on the points made in this article? No.
People have been saying this since 2004 when I started working in mobile. Only difference was the tech that would make it happen, it was WAP then.
There will always be a place for native apps, be it on a phone or a computer.
I am glad for you that you don't need them. But we'd like to at least have the choice.
> snake oil
You dislike web apps, that's okay. But you sound prejudiced.
I am providing critique here, the burden of proof is on whoever wrote the bold claim that application development is web development (speculation) and it is a better way of development (speculation).
> I am glad for you that you don't need them. But we'd like to at least have the choice.
I would not have a gripe with the article if it were the only thing it alluded to.
Innovation being actively blocked today, includes streaming games and other apps, cloud hosted apps, etc. And we will never know how much innovation is being blocked if there is always a gatekeeper.
This innovation freeze isn't just about "web" technology. It is blocking whole business models today.
And there is no reason "web" technologies, when free to improve, can't acheive parity or near parity with native apps in the future, with regard to performance, security, aesthetics, etc.
"Web" is just a historical starting place, not an impediment to future capabilities.
But as a counterpoint to the rest, web technologies have been free to achieve said parity on the desktop for a long time now. Have they? Do they provide _better_ experience for the user? or do they neglect the user whenever they can in return for _faster_ and _easier_ cross-platform development and ability to leverage existing web developers?
For instance we have PHP (easy to learn, but weak typing, arguably unclear design philosophy) on one end of the spectrum, and Rocket for Rust (which enforces memory discipline to provide highly reliable concurrency and high performance) at the other end.