Then you're out of step with what users want these days.
Nothing wrong with that! But to take an example, when I hit a share button on a page I want to see the native share box, not some hideous iframed monstrosity that only works with Facebook. So I want Web Share. And I don't want to download an entire native app just so that I can receive a push alert when my food order is on the way, a web site works much better for that. So I'm happy that Web Push exists.
I get the nostalgia for the "simpler days", but web browers are essentially a universal OS these days. As both a user and a developer I'm quite happy with this.
In terms of development effort, maintaining a browser fork that merely disables these features seems pretty easy. If you think users would prefer that, why not make one?
I personally don't think it would take off, because I think most user attitudes range from "want these features" to "ambivalence". But if you're so certain, why not try?
Why does it require a fork? Having an advanced settings page with checkboxes for each of these web features seems straightforward and not overly confusing to normal users.
This, I have Safari Debug Mode on purely to disable all the annoyance. And with the current state of things there will likely never be an extension to do that.
Maintaining a fork that does that isn’t trivial, but it’s certainly doable by any one engineer.
However, maintaining such a fork is not the only prerequisite for it “taking off”. It may well be that my great uncle would love that feature - but how are you going to get his attention when several vendors are already spending millions of dollars in marketing/design/etc to influence which browser he uses?
> Then you're out of step with what users want these days.
Two things:
1. The person you respond to is also a user, no reason to dismiss their point of view
2. I don’t think browsers asked users for what they want! It’s a bit disingenuous to say “that’s what users want” when the communication is one way only.
Try talking to some developer relations people from the Google Web team, Mozzila, Microsoft etc. They're all very receptive to feature requests. It absolutely isn't a one way street.
I promise that I have never asked for a notification or a pop-up. They 'work' from the point of view of web sites and browser vendors, maybe more so than from the perspective of users.
I promise that I have never asked for a notification or a pop-up.
Very few people ask for a specific implementation of a feature unless they want you to clone something they've seen elsewhere. People don't do that.
In user focus groups I've been in though users have told me that they find it hard to know when they need to pay attention to something, or when they've been tagged in to something, or to know when a server side task has completed, or when a long-running webworker process has completed. All of those things are obvious use cases for some sort of notification, and when the feature has been implemented users both enable them and click on them.
Heck, I got a Google Calendar notification pop-up while I was writing this comment.
The problem is that you don't want notifications so you want them to be removed from browsers and then no one gets notifications even if they want them. That's not reasonable. The answer is that you need to be able to block them easily; to turn that feature off for yourself. This exists (in Chrome) - chrome://settings/content/notifications You can disable them for all sites. And yet you'd rather complain that they exist instead.
Turn off notifications by default so that people who need/want them (the minority) can get them from the relevant sites (the exceptions).
After that turn off stickies, floaters, modals, etc by default & those who wish to have their browsing experience assaulted into a 1 inch box can opt in.
Share API isn't needed for sharing content, copy and paste worked better than share api and it was around decades ago.
About what percent of push notification requests do you accept? I think my percentage is 0, and the number of requests is high tens if not hundreds. I don't trust browser notifications at all.
Opt-in rates are around 65%, open rate is between 1 and 10%, I suspect some percentage of those opt-in rates were unintentional or coerced and some percentage of those opens were click bate or accident. so <2.5% of notifications were desired.
I think it's safe to assume a significant portion of the opt-ins and notifications were desired-not.
Based on this information, I would consider notifications undesirable.
You consider them undesirable, but they are a critical feature for many applications.
Specifically, chat. More specifically... support agents providing live chat support. (And for that matter, end users interacting via chat appreciate push notifications on reply)
Without browser push notifications, there really isn’t a good alternative.
The fact that opt in rates are close to 50% is probably a good thing! It means that browsers aren’t using dark patterns to trick people in to opting into things they don’t want.
I would 100% agree with you if opting out were difficult. But at least Chrome’s implementation makes it very easy to decide which sites I want push notifications from, I really can’t think of any downside given the easy opt out.
Chat is probably one of the only functionalities that are still better served by an ad-hoc app
If you need notifications, just use a native app (or even a web one wrapped in a native app)
Anyway, most of these "features" are used because they are already there, remove them from the base install of the browser, distribute them as a plugin and make the devs consider that the feature could not be present and they will stop nagging the users begging for their attention
Any website I visit from mobile wants the permission to notify me, 99% of them don't if I visit from desktop
Let's say you're using some random website and want to talk to their sales or support team. How well do you think "download this app to chat with us" is going to go over?
Amazon and Alibaba are pure consumer plays with a mass audience. They deliberately hide the contact forms to force you through self-service UIs.
If you try the same thing with a B2B or other high-touch service, it's not going to end well for you.
Personally I get a terrific amount of value from interacting with my B2B customers through chats, video calls, and screenshares. The customers love it.
> Chat is probably one of the only functionalities that are still better served by an ad-hoc app
Yes, actually, IRC works better for chat, I think. Actually, it is probably true of some other stuff too, such as many kind of multiplayer games; you could use a telnet (or SSH) session.
This is not just about chat. Ever tried to build a cross-device synchronization without being able to push updates to clients? It sucks.
The user doesn't know that another user changed something until he opens the app and then the app has to fetch and integrate all updates since the last interaction with the app and the user has to wait until his app is ready.
Web apps are better because they are as much device-independent as apps can get nowadays.
Service Workers are the background service for web apps, but since users don't want those services to drain the battery unnecessarily, you have to use the Push API to trigger those background jobs.
So yes, if the app is the active app, you can do polling, WebSockets and all the like and have no problem. Background services are (rightfully) limited for web apps, but not even providing the Push API kills a lot of valid use cases. Firefox and Chrome both provide that API.
What do you mean by 'just Firefox'? Firefox, Chrome, Edge, Safari all support Progressive Web Apps in general.
Older browsers, on the other hand, might not be able to use offline features, but at least you can use the app in the traditional always-on mode.
For your comparison with Java: It is true, Java is very device-independent, but the deployment procedures are much more complicated than simply entering a URL.
I've never used a chat app that asked to send notifications. If they did ask, I would reject the request. I (correctly) assume the permission would be used to bombard me with irrelevant notification spam.
> Share API isn't needed for sharing content, copy and paste worked better than share api and it was around decades ago.
Most big websites have different URLs for the same content. When you're sharing a link, you want the canonical URL, which is neutral and universal, not the URL you're currently on, which might have a session ID, user preferences, scroll anchors, etc appended to it. The share button in your browser uses the canonical URL of the site (if provided), which looks nicer and works better.
Canonical URLs are part of the HTTP spec. URLs with session ids or user preferences are faulty and should be removed. Scroll anchors are useful to share.
Share button certainly doesn't work better; I find it so undependable that I intentionally avoid it.
I prefer copying the link to the page I'm on to share. No popups, native or otherwise.
Similarly, I like not having an app running so that you could just send me a text. Sms is bad for security, but great see sending short notifications. Almost better, as it is so limited.
FYI on Chrome/Brave Android, when you use 'share' button -> copy URL, it uses link rel=canonical meta tag if available (which generally doesn't have all FB tracking crap in the URL etc.)
The problem on mobile devices is that URL bar is single-line and has like 30 characters length and , while query string crap is sometimes several hundreds characters long. It's not every ergonomic.
But yeah I often copy the URL to "notepad" app before sharing and trim manually.
Yep unfortunately true. I recently saw an official document from local CDC in my home country. There were two URLs "find more info at" in the document:
This is also why most non power users will have chrome browsers loaded with tons of add-ons and basically let every site start sending notifications...
Except that with web push the block button is two taps away. Once I’ve given away my phone number that’s it, it can be sent to anyone, I can receive messages from anywhere.
Is this a thing that happens often? Used to, your phone number was in a publicly available book. Pretty sure we use legislation to block abuse of that kind.
Similarly, used to, my browser was not a bloated application capable of sending me messages. Such that there have been times just launching chrome I get notifications I didn't know my family were going to accidentally enable...
I still get more robo calls on landlines than on my cell. Conveniently, my cell is in a different area code from where I live, so even easy to spot the bad ones. And I have never gotten an unsolicited text. That wasn't a wrong number.
The most used feature in Microsoft Office is the Paste button in the toolbar:
> What we didn't know until we analyzed the data was that even though so many people do use CTRL+V and do use "Paste" on the context menu, the toolbar button for Paste still gets clicked more than any other button. The command is so incredibly popular that even though there are more efficient ways of using it, many people do prefer to click the toolbar button.
As soon as you put so much in the toolbar, people have to use a mouse. That they are still taking the most naturally used action shouldn't be surprising.
"As a user, I don't want this" seems like a reasonable claim.
"Then you don't know what other people want" doesn't seem like a reasonable response.
People want a lot of things - but only use what they can access. Additionally, people will deliberately choose to use broken/painful systems if they have to, in order to accomplish a broader goal. Finally, the vast majority of systems used by users are built because they are profitable to build/operate. In many (most?) cases, they are not profitable to the user in the same way that they are to their builder/operator.
From those simple observations, it seems like quite stretch to claim that anything that has many users is something that people want, and that they enjoy using.
"As a user I don't want this therefore no one else should have it either." is a bit less reasonable, and implies that you don't know what other users want or care about what they need.
> Then you're out of step with what users want these days.
"Developers" or average Joe's? Most people I know don't know what push notifications are. RSS? "Some kind of gov agency?". Sharing? "Facebook button!". And, no, they aren't idiots, they just don't care and see any of that. ;)
> "Developers" or average Joe's? Most people I know don't know what push notifications are. RSS? "Some kind of gov agency?". Sharing? "Facebook button!". And, no, they aren't idiots, they just don't care and see any of that. ;)
I think this leaves out a middle ground. The people who design web pages love this stuff, either business decision-makers (because they think it improves metrics) or programmers (because it's a cool way to implement the area of their technological expertise)—but you can be a techie, know exactly what all these things are, and not want them.
(RSS is a funny one to see on the list. It's practically ancient, and most browsers seem to have given up on integrating it—which is a shame, because it's a low-flash solution to a real problem and is user-centered and -controlled.)
All these things are why I have a custom user.js. I know most people here are web devs that get a kick out of this stuff, but I personally don't want most of the things described here. Most of them just seem like anti-features and/or security holes.
Wishing isn't the point for me. A lot of us were taught a particular security model, and then that changed silently, and now we might make bad decisions because of it.
I wish I could at least control these things. I'd like to turn them all off and see what happens to the modern web, and at least understand what I'm allowing when I turn them back on.
I think browser product teams are out of step with what users want these days. It is easy to confuse the browser ecosystem with users. Or even claim that the browser ecosystem is good for users, and therefore doing things to improve the ecosystem _is_ doing things the user wants. In truth, the user just wants to see the web page and have the browser get out of the way. You know who does that well? Native. Identity and payments are now _solved_ there. The web is still trying to figure out this out and probably never will. Too busy working on things that don't matter. Then something like AMP shows up, which actually builds _on_ the ecosystem, in _favor_ of the user experience, and people blow up about it. The browser ecosystem is sort of in a sad state, leadership wise.
Slightly off-topic perhaps, because I think you're making a general point, but although you may want the native shared box it only works for Safari users - https://caniuse.com/#search=web%20share%20api - with apparently very little appetite for it from other browser vendors. Maybe its time will come, but I think there are lots of issues with implementation.
Ok, a lot of these features requires the site to ask the user for permission to use them. What is the percentage of users giving permission for the usage? In my experience not that great even when asking for something that will definitely improve the user experience in that context of the site they are on.
If users don't really give you permissions to use these things it implies to me that users don't really want them.
I would strongly advocate for browsers to strengthen the UI prompt for notifications so pages can’t do it on load. In fact, Google is doing exactly that with Chrome and I think Firefox already has.
So, no, v1 wasn’t great. But we can improve on things.
I never liked the idea until I started using a browser based pomodoro timer and I enabled the desktop notifications, it's been a useful feature. Now, I'm wondering if there are other benefits I've been missing out on since I have always disabled desktop notifications by default.
Implementing notifications for a timer clock should be included in the wikipedia article about feature creep.
Not minding them too much since I disable them, but at some point it is just not worth it for all the anti-user practices notifications already allowed in my opinion. It just inflates functionality.
In 20 years, if we have even more powerful devices, we will complain about browsers taking ages to load again.
I don't really see the issue, as long as there's a security popup when a website requests notification permissions, and a way to just block everything except for a whitelist.
> Try to realistically justify any of those use cases listed and you’ll realize what a shill you sound like.
Wat? What part of the examples I gave are not realistic? I guess I live a fantasy life! Good to know. Are you arguing that there is zero use for push notifications beyond things advertising companies want? Because that’s out of step with pretty much every phone user I know.
What's wrong with native app? You can delete it when you are done with it, just like you can close a browser tab when you are done with the "entire" web app you downloaded.
No uBlock, no dev console, no network tab. Completely opaque. An install step just to order a pizza. Shareable URLs/deeplinks.
It's a freak of luck that we have the web, an app environment with a built-in dev console and actual customization. Just think how much it contrasts with the black box of native apps and with what large companies actually want. I'm in no rush to throw it away.
No need for ublock, the dev console is called your memory, your network tab is now something the entire os can understand, and you can even opportunistically block specific network calls.
Obfuscated javascript running in the console is no better than random apps, and webasm is going to make that even more opaque.
You are talking about features that are only needed for websites and why an app doesnt have those features, when they were directly bolted on to deal with the huge amount of complexity we've already handled in the OS.
On mobile its somewhat more fair, but the dev tools, adblock, and other items on mobile are almost always super compromised and locked down by the device manufacturer.
Amazon's app, at least on Android, is anyway so bad it's almost surreal. Massive lags without any indication of progress or indication that the app even accepted the input.
Now that I think of it, it feels like a bad website shipped as an app. Which it probably is.
Yes, but why should you need such a complicated system at all just to order a pizza, whether it needs an install step or not? A simple form, telephone call, etc would do.
Simple systems work great and are easy to implement when you're working with limited requirements. But the second you start to add new features, the system breaks down. How would a simple form or telephone call work if I wanted to know the status of the pizza or delivery driver's location?
I'd prefer not to give my number to them because then they can send me unsolicited "offers" all the time (just look at email) but I don't want to block them either because I still like their pizza.
The problem with native apps is they only work on platforms the developer supports. Web apps occasionally have this problem too, but native apps always have that problem.
An OS doesn't protect you from outside, it protects the system from apps and users
Imagine if your OS asked you if you would like to allocate a block of memory at address X everytime it does
That's what to a regular user the prompt means
They just click 'Yes Forever' and are done with it
But that's still an application settings, it has nothing to do with being an OS, browsers are mostly a system for distributing malware in the easiest of ways
At the cost of being as complex as a full OS, without any of the benefits
Wanna bet that if vendors started distributing naked browsers and the extra functionality (of course approved by W3C as standards) were bundled in plugins, which is entirely possible, half of those would linger there with zero downloads?
I don't understand what you mean by "In the browser everything is exposed to everyone by default". Browsers have a much more robust security and privacy model than normal OSes.
There's a difference between what features OSes have and which ones they are effectively using.
If you ran untrusted native apps with the same level of consideration that people run untrusted web sites, your identity would be stolen every 30 seconds. That is solid empirical evidence of a better security model.
People identities are stolen constantly by web apps, they just don't know
An app like Excel could steal my data, yes, but it is my willingness to give away all my connections to Facebook and let them spy my interactions that gave away my identity and also the identity of people that do not use Facebook, but are mentioned by me or my other contacts (for example my parents)
> native desktop app exposes a much larger attack surface
If we're talking about code executed as a result of, say, buffer overflow attacks, then the impact is the same both for the native app and for the browser. The latter, however, has way much more places where that overflow could happen! And they still happen, security updates for the browsers get pushed all the time.
(And we're not even talking about the world of XSS/CSRF attacks here! Those are pretty much exclusive to the browsers, and widen the attack surface tremendously.)
Not to mention that native apps can be properly reviewed and vetted by Linux distributions.
And have a tiny codebase compared to a browser. And even tinier compared to a browser + all the potentially hostile javascript, css, html, sng, png out there.
And run in native sandboxes or external sandboxes like firejail.
I have mixed feelings on this. On one hand, websites that should be just documents are turning into resource-intensive applications, which is frustrating. Generally I do not want most websites using these features.
On the other hand, the web as a runtime is one of the most universal platforms we have. If I run Slack in a browser, I sure do want it to be able to notify me! (Though I wish doing so felt more like the Electron app - I’d rather use my browser than Electron if the UX were similar enough. I already have a browser, I don’t need another per application!)
And as an occasional user of less popular mobile platforms (Ubuntu Touch, etc) a more featureful web runtime helps close the gap between those platforms and Android/iOS.
I do think it’d be better if these two use cases were more explicitly distinct than they are now, though.
If operating systems had ever provided security strong enough to run untrusted code, we wouldn't have needed to. It's really a failing of operating system security. Even today no operating system provides an application sandbox as strong and versatile as the browser.
Platforms have fallen back on walled gardens (app stores) with centralized control of all code execution to compensate for the deficiencies of their security models. I don't want a future where the only apps I can run have to be signed and approved by Apple ahead of time. The web is the escape hatch.
The whole security angle is an after-the-fact rationalization and the vast majority of users (not developers, users) never cared much about it - as anyone in the IT department of pretty much every company can tell you (again, users, not developers, not sysops, not admins, but regular end users).
The real reason we see so many web apps is that the decision on what technology to use for an application is largely something developers decide (with "developers" i do not only mean individuals but also companies and organizations that develop applications) and the web gives developers pretty much complete control over what is going on in their application, what the users can do and how, allows them to force everyone use the same version, allows realtime monitoring of how the users use their applications and provides the vendor locking tightest than the most obfuscated native application could have (since all the data is stored in the servers).
Security is just a very convenient excuse since a lot of people shut down their critical thinking whenever it comes up (my guess for why that happens is that since a lot of people have been shamed by supposedly security experts and even more people have mimicked that shaming, we ended up with everyone just shutting up whenever security is brought up to avoid looking like That Clueless One that would be shamed next - but that is just a guess).
But the real reason is the heavy control that web apps give to the developers and the vast majority of users do not really understand how biased against them that setup is.
Have you looked at the network traffic or behavior of most native apps? Continuous monitoring and cloud-based state are the norm everywhere, and for the same reasons.
Not all apps do that (in fact i cannot think of any desktop application that i have installed that does something like this - though if i could, it would get the boot) and because applications run locally it is possible to monitor and control their behavior (indeed, with a server you just don't know what is going on, but with a local app you can at least tell that something is going on).
Also, while the UI is far from ideal (at least on Windows), you can block individual applications from accessing the Internet. It should be much simpler than it is now, though.
What do you mean with stolen? Someone making something similar or making unlicensed copies? For the former i do not see how web apps prevent that and for the latter that only matters when the developer asks for money for each license, which is extremely rare with web apps anyway (the closest is subscriptions and rentals but that happens with desktop/native applications too, e.g. see Adobe and Autodesk). But even that is really a facet of the heavily developer biased control i mentioned that web apps provide.
But people still download and run apps every day. Some even prefer it. I doubt that the cause of this migration was due to security concerns -- since when are app developers particularly concerned about the quality of the security controls imposed on them? I suspect the shift was more due to ease of access, both by the user and for the developer, helped along by easier compatibility.
App developers care about the barrier to getting users to use their app. The barrier to getting a user to click on a weblink is much, much lower than the barrier to getting them to install an app.
This is one of the largest failings of the App Store providers. They should recognize this installation barrier and work towards fast and ephemeral app installs.
Right, but users can only use an app once it has been developed, and ultimately if the user needs an app, they will go with whatever format it's being distributed in. Then there's also the convenience factor — Gmail is a good example of this — where a web app is more convenient than a downloadable app that does the same thing, because it requires no installation or updates.
I would also suspect that most users haven't any clue of the security implications of using something in a browser versus using an app.
Well, my wife is an exception to that. She installs all kinds of crap apps on her phone.
And we got our phones through our daughter who works at Verizon, so when my wife moved from an Android to an iPhone they called me up and asked for my iCloud password which I, like a dumbass, gave them.
I just checked and I've got four more bullshit apps on my phone I need to delete :D
Sure, running untrusted code will never be 100% safe. But visiting a random website is 99% safe where running random .exe’s is 1% safe. Neither is perfect, but in practice, one is good enough for most situations and the other isn’t.
It counts whether the platform makes it easy to use and promotes it in a way so that average users actually use it.
If I create a native Windows app and link people the .exe to try it out, approximately 0% of people who run it are going to run it in a securely sandboxed way. If I create a web app and link people it to try it out, approximately 100% of people who run it are going to run it in a securely sandboxed way.
Furthermore, some people will specifically avoid trying out the .exe I send them because they don't trust me fully with everything on their computer. As a developer that wants to show off things I make, I don't want this obstacle to exist. If I make a web app instead, I know it's more likely people will try it out.
Virtual machines per app are a thing, but they have a lot of disadvantages (particularly resource consumption). Various sandboxes have existed for a long time, but I’m curious which ones you would point out that have survived anywhere near the scrutiny and attack surface that browsers have.
Is letting Google, Facebook or Apple control every aspect of our lives by sending them all our personal data, contacts and network information voluntary more secure?
I would rather run every application in its own VM under a different unprivileged user
P.s. the browser is the main attack vector on mobile, not only because it's so complex that bugs are everywhere, but mostly because web app security sucks
Browsers usually have fairly strong security models, since they are expected to constantly run untrusted code (which has nothing to do with web app security, FWIW). Apps rarely get this kind of scrutiny and often don't (Android) or can't (iOS) employ features that browsers can to do, such as multiple processes.
Many game engines do it as well, just think about DOOM mods
I think the point is that browsers are not as good as an OS as an application platform (given the limitations) but are as complex as an OS and have more bugs
The fact that mobile apps are terrible is not an excuse for having a terrible document protocol used for applications
Apple invented mobile apps as we know them today,but native apps in general have served people well for ages
We are at a point where a native app with some API is more maintainable than a browser app
Not even talking about the ecosystem and its fiascos, like npm corrupted libs used by millions without even looking at a single line of source code or the famous leftpad incident
It doesn't really matter where the weakness is, if it is exploitable
As Alan Kay once said "the web was made by amateurs at best"
Would it really be better if we didn't evolve the web, and we had more OS-specific unsandboxed applications and greater fragmentation between OSes (and a stronger incentive for everyone to stick to one OS, like Windows) instead?
Yes, OS-specific applications are good, and we should have more of them. By "sticking to one OS", and apps that follow the OS's conventions, users actually have a chance to develop expertise in those apps. But the web ensures that everyone stays an amateur.
While website capabilities have evolved, the web UI itself has regressed. No major UI paradigms have emerged from the web since the 90s (except tabs, arguably). URLs, bookmarks, cmd-F Find, and clicking on links still dominate, except they work worse now compared to the 90s, because of SPAs and lazy loading.
My point is that if the web didn't evolve, then Windows would have further cemented its position. If people made Windows apps instead of websites, then other operating systems and mobile wouldn't have taken off as much because fewer people would make multiple apps than the number of people in our world who made cross-platform web apps.
Also, all of those features that rkagerer complained about would be even more abusable, because in general, Windows apps don't have to ask for permissions to those things. I don't get how someone could complain that it's bad for a web app to be able to ask for permissions to their contacts, and would prefer to have a native app (that can get them silently by default).
Maybe you could replace "Windows" with "iOS" in this hypothetical, which would improve the permissions side of things, but I think it's likely that Windows was only supplantable in the first place because of the popularity of things being on the cross-platform web instead of on native Windows apps, and especially as someone without an iOS device, I'd be pretty sour if the effort on the web went purely into a locked-down non-open platform I didn't have. I think the way the web has approached being a universal open-source/open-standard app platform is extremely exciting. The fact that web app buttons look different than iOS/etc buttons is a small price compared to the benefits, and is the sort of thing that can probably be solved within the model once developers think it's important enough to. (I think modern frameworks and/or the web components standard will provide a good base to get more native-like experiences common in the web.)
No OS has "taken off" because of the web. Windows is as cemented on desktop as ever, and ChromeOS (the only post-web desktop OS of note) has a fraction of a percent marketshare.
iOS initially had a web-app-only developer story (the "sweet solution"), but the quality gap between web and native apps was so undeniable that Apple reversed course and shipped a native SDK. It would be no different today.
The quality gap is not about buttons that look different. It's that nothing behaves consistently. Every site does its own custom thing, so users are forced into the lowest common denominator of interactivity (click or tap).
Examples: Gmail has its own fake windows, context menus, dropdowns, drag and drop, key equivalents, etc. and they all fall apart as soon as you try to do anything nontrivial with them. And it's been like this for 15 years, so I don't see any cause for optimism on this front.
Chrome is open-source, cross-platform, built on open standards, securely sandboxes code run inside it, and it's interoperable with other web browsers. Considering operating systems and web browsers as app platforms, I think it's better and safer for people to use apps on app platforms that are built on open standards, that are able to freely run on many and free-and-open-source devices, and that securely sandbox apps so they don't have full access to people's data by default. (Android comes close to meeting these criteria, but my main complaints would be the difficulty in running Android apps on non-Android devices, the fact that apps are harder to run than visiting a URL, the lack of alternate implementations of the platform, Google's full control over the platform APIs, and Google's de-facto control over distributing apps.)
>Chrome is open-source, cross-platform, built on open standards, securely sandboxes code run inside it, and it's interoperable with other web browsers. Considering operating systems and web browsers as app platforms, I think it's better and safer for people to use apps on app platforms that are built on open standards, that are able to freely run on many and free-and-open-source devices, and that securely sandbox apps so they don't have full access to people's data by default. (Android comes close to meeting these criteria, but my main complaints would be the difficulty in running Android apps on non-Android devices, the fact that apps are harder to run than visiting a URL, the lack of alternate implementations of the platform, Google's full control over the platform APIs, and Google's de-facto control over distributing apps.)
A lot of your argument here is based on the assumption Google Chrome is open source software. Google Chrome is not open source, it's proprietary.
ISWYM but I'd be much, much happier if the browser functionality of mainly delivering text and images was kept separate from the application functionality of ... doing bloody everything.
I want to turn off the application side of things for my safety (and I do), but too many sites require it unnecessarily to do the most basic tasks of displaying static text and pictures.
I kind of wish major browsers would show a banner asking to enable JS, like they did for Flash and Java. This would discourage developers from using JS unless they really need it, and they'll think about graceful degradation.
But browsers won't, because they have nothing to gain from it; and it would be way too confusing for many users.
I think there are strong Gall's-Law, worse-is-better and business reasons why a proper GUI platform could never have crossed the chasm to universally cross-platform, on-demand delivery, with no single vendor owning it.
The web was originally conceived as an interactive hypermedia platform, not a “document transfer system”.
It's true that it has displaced things they were true document or file transfer systems (Gopher, FTP) because it subsumes those functionalities, but it wasn't ever just that.
"I have mixed feelings on this. On one hand, websites that should be just documents are turning into resource-intensive applications, which is frustrating."
I agree but I would be ok with them if they required explicit permission from the user before being allowed.
I don't mind the idea of notifications when I have a web page open in a tab. Like, sure if I receive a message while I'm looking at another tab, let me know!
But I was a bit shocked to discover that I was getting notifications from sites that I did not have open, then I realized that when I register for notifications the browser will continuously poll that site in the background, no matter whether I've browsed to that site in this session or not. That was when I decided I didn't want any notifications.
It's not even the interruption, but more the knowledge that my computer is casually making HTTP requests in the background, continuously, on a site I haven't even browsed to, that I don't feel comfortable with..
That's not actually how it works. What happens when you subscribe to notifications is that your browser gives the website instructions for it to send notifications to the browser vendor's notification service. Your browser only polls Mozilla's servers or Google's servers or Apple's servers and all notifications are relayed through that.
Even if it's opt-in, we still pay a price. Complexity has its costs.
It means my browser is more bigger and more complex. It broadens the attack surface exposed by my browser, perhaps even if I don't opt-in. It dilutes the efforts of the Firefox team. It introduces new ways for browsers to be subtly incompatible. It further raises the barrier to someone making a serious browser from scratch.
Also, are we guaranteed that these features will be opt-in? There were serious security issues with WebGL (predictably), and I don't think WebGL was opt-in.
WebGL was never opt-in and everybody familiar with GPU programming saw the issues coming from miles away. It was an idea that was about as stupid as Java applet sandboxing.
>This is an issue with that particular website's implementation, not something inherent to the browser or the API.
When that statement applies to 90% of pages out there, that argument gets more stale than cracker left out for the better part of a year.
That staleness, in fact, is why no one is encouraged to run blind unauthenticated proxies on the Internet anymore. Completely valid technology. Very problematic use case.
> This is an issue with that particular website's implementation
because the product manager thought my user session was engaging with the site for 2 seconds longer so it must be good.
I never said it was the browser or the API just acknowledging that it is a predictable gripe and not a feature, and yes enabled by the browser and APIs
The point is that just because you don't want most sites to use these features doesn't mean that no use exists. I just want to make sure I don't get nag notifications begging me to turn it on every time I visit a news site.
Notifications? I need those from my calendar app and chat app.
Badges? Messaging systems I use rarely but which are important.
Visibility? I want resource intensive apps to "sleep" when not in use.
USB? I want an Arduino web ide to be able to communicate with hardware.
Screen lock? I don't want the machine to go into sleep mode when I'm presenting a slide deck.
Key lock? I don't want the browser intercepting keystrokes in my word processor or SSH session.
Then turn them off. All these things landed because users _do_ use them. I 100% want web share, page visibility, usb, and native file system, for instance, because the browser has become a convenient replacement for a bunch of playgroup/PoC/testbed applications that I might have used 10 years ago.
Just like users "used" the toolbar API back in the Internet Explorer 6 days? Used as in they got the toolbar foisted on them while installing some crapware.
The notifications API is the same. How many of those "uses" are legitimate uses that users consciously want, and how many of them are misclicks or just clicking yes to dismiss the prompt so they can access the content they wanted in the first place?
In my case there's only one website I can think of where I want notifications from my browser: Slack. I can understand that some people might want them for e-mails, social networks, etc but even then that's only like a dozen or so websites. In contrast there more websites than that which use notifications for spammy/annoying/unnecessary purposes, and sadly some people do fall for them and then get their time wasted by these notifications.
In a perfect world where nobody would try to take advantage of people I would totally want web notifications to be a thing because there's basically no downside (websites won't try to use them for spam) and potential upsides.
In a world where it's not only legal but morally acceptable to take advantage of people, waste their time, stalk them, etc (there's a whole industry around this called "martech") I would happily sacrifice the few legitimate uses of web notifications if it means non-technical users can't accidentally opt-into crap and then have their time wasted by spam because they don't know how to opt-out.
First of all, that's backwards. These features had to land before anyone could use them. Users can't use them before they land, so they couldn't have landed because they were being used.
Second, how can you know if these features are widely used or not? There's been lots of technologies that have been added to web browsers over the years that weren't widely used, and were later removed.
There are people who want to be spied by social networks to have a pair of free shoes and post pictures of them online
It doesn't mean it's the right thing to do for society
Browsers have gone far beyond their purpose in an inorganic way
It's like if my alarm suddenly started making coffee, toasts, working as remote and the new planned feature was the ability to warm itself up and iron my shirts
And it would still be a fraction of what browsers do today
To clarify, most of these work by asking for permission first, and you can set them to "always deny" in the browser settings: chrome://settings/content
There are similar site content settings in any major browser.
There are a ton of features that browsers have added, and then tossed because no one used them. As well as features the browser vendors wish they could get rid of, but can't because too many sites made use of them.
So many sites ask you for notification permission on first visit in a very spammy way. Or, put their "share this" in a spammy/ad-like location. and i think that's the problem, web site owners being dumb and pushy.
If there is a site you really like, that you want to share, and would want to recieve pertinent updates from, if you so choose without being hounded to do so, aren't you happy the feature is there?
Do you mean the proprietary Apple push notifications in Safari? In this case I've only seen it ever once (as opposed to seeing the "normal" notifications on pretty much every shitty blogspam website) so it seems like the 100$ acts like a good filter against BS notifications.
I mean whatever Firefox does. I’ve never once gotten spam because sites can’t send you notifications unless you opt into them (so it’s more like a battery friendly super fast RSS replacement.)
As long as they are opt in, which most of them currently are, then I’m fine with it. I generally set my browser to blanket ban most of this functionality but I do occasionally override that on a site-by-site basis when it’s useful. I think this is a pretty good state of affairs, versus not even having the option at all
I like that push notifications on the browser exist (for e.g. Slack, WhatsApp), I just wish there were no popups for it--just an unintrusive button you could press to enable it.
That's quite easy to do in chrome. Open global settings then set web notifications to block. Then whitelist sites by clicking the lock icon in address bar.
While agree that most of these are highly invasive and certainly not a requirement, the Visibility API is actually a good thing. Apps which are running continuous scripts, like games, etc, may and should detect, when they are hidden (i.e. the tab they are in isn't the front most one) and pause. This is explicitely meant to preserve resources on the client machine and to benefit the user. On the other hand, there isn't much to gain from on the app's side, beyond receiving a notification to wake up and to possibly check for any updates that happened in the meantime to be applied.
FYI there is a firefox addon to block the visibility API I can now listen to the UK PM's coronavirus update on my phone with the screen locked, or while looking up something else.
Whoever invented that API forgot whose client the browser is. Mine.
Then you are doomed. ;-) (On mobile, it's your browser anyway that mutes any not currently on top and visible web sources, without any "help" by the particular website.)
I know this is an old topic now, but that's not true. I've installed a firefox plugin that disables the visibility API. Result - now youtube in a firefox tab keeps playing even with my screen locked.
Allow me the chance to try and change you mind just a little bit.
The web is one of the most open platforms that has ever existed — period. Since the dawn of the smart phone the web developer has heard the following request: "I need a native app because push messages!". Execs want them, users want them. They literally bang down your door asking for the damn things. Allowing the browser to handle push messages means you can keep your app on this amazing open platform instead of share cropping in some app store.
Yes, and not only permissions, but overrides, too. (For example, to specify that the battery level should always be reported as a user-defined constant, rather than the actual level, or to use a file instead of a camera (or vice versa) if the user wants to.)
Push notifications are good for messaging apps (including chat support, etc.). They're 100% opt-in and harmless.
Web Share is barely a thing. It's literally just a call to an already existing browser function and deprecates all the vendor-specific embeds in most sites (each FB, Twitter, etc. share button you see either uses this single-function API, or loads their huge blob of JavaScript on every page that has it - which do you prefer?).
As a user of Web messaging apps, I also like the Visibility API, because it allows the apps I use to stop rendering while in background and just queue up messages to render when I look at them. This allows the process running those tabs to basically go to sleep (even swapping sometimes) which increases battery life and performance.
The rest of the ones you listed, I agree, really shouldn't be in Web browsers.
For some things, it is not that simple. Let's take for example the Push API.
While there are very few web sites where you want them to send you notifications straight to your desktop, that API is also used to wake up your Service Workers, to let them receive information when they are not the currently active website and are therefore quite important to build things like chats or apps that sync over multiple devices.
AFAIK that Push API for Service Workers is not available on iOS yet, which is a major show stopper for Progressive Web Apps as there are many use cases where you would need something like that.
Web Share makes share buttons within web pages more useful and coherent. Just wish more apps would place themselves in that OS-wide menu. Idea: app that can add custom Share menu entries, process with scripts.
I share the concerns regarding features with extra high risk of leaking sensitive data. The operating system should control access for those who wish to disable such features; it doesn’t necessarily have to ask for each capability just because the option exists. Those would of course still need to trust the app’s own isolation for web pages if they for app features require access to e.g. file system or Bluetooth.
I think it's great that they exist. The problem is when they get used unnecessarily.
Push notifications are good when my Webmail tells me there's a new message or Gitlab tells me my tests passed.
Not so good when some crappy newspaper I visit for the first time asks me if I want be notified about all their clickbait articles all the time.
But with Brave it's pretty easy to disable JavaScript on a per-site basis, with "disabled" being the default. So all these things don't bother me anymore.
You actually got me an idea. It should be pretty easy to block many of those with a simple Tampermonkey script.
Gotta check over the weekend.
In JS you can't generally override host objects, but you can generally modify the functions they expose.
How about the upcoming "SMS Receiver API" and "Contacts API"? Those look absolutely terrifying, and as soon as Chrome implements it, every shitty ass newspaper that is currently refusing to display their articles in private browsing windows will refuse to display their articles unless you fork over your contact list.
Have you actually read anything about either of those APIs or are you just reacting to the names?
The Contacts API does not allow unrestricted access to your Contacts. It presents a picker for you to choose a contact.
The SMS Receiver API is not universal access to SMS messages, it is access to one specific message and only one that contains your domain name in the message text.
Both have very obvious utility to users. They don't look even vaguely terrifying.
Surely it was browser users who demanded such "features", right?
The browser I use the most does not do any of these things, but it does a nice job of dumping HTML tables to formatted text, which is something the modern graphical browsers cannot do..
I think having those capabilities is fine but I hate the endless notifications to use them from every damn web site! There should be a second and much more subtle notification system which does not obscure content or attract attention.
I imagine most sites would be fine with email notifications. In-browser notifications just motivate them to come up with more reasons to notify you. Dumb reasons.
Add service workers to the list. That's IMO the biggest atrocity allowed to go into the browser. There's currently a preference to disable this crap in Firefox.
I agree, I don't want it to do any of these things either (with the exception of prefers-color-scheme and prefers-reduced-motion, which I like; however, web pages that use only one colour should not set or care about the colour at all).
Some of these things though it may be useful to have, although should be set by the user, independently of the web page entirely; the web page should not be allowed to specify these things.
Specifically, the following things could be user commands (that the web page need not know or care about whether or not it is implemented or used): Picture-in-Picture, Keyboard Lock, Pointer Lock, AirPlay, Screen Orientation (although see below for some comments), camera selection (the user would also be allowed to specify a file instead of the camera, or the user can specify to use the camera where a file is expected too), Theme Color, Badging, Chrome Sender.
Screen Orientation and Presentation Mode: In presentation mode (selectable by the user), this is a "paged screen" media rather than a "continuous screen" media; in this case, the height of one page is known to CSS and JavaScripts (this should be reported as the visible height, even if it isn't entirely visible; in normal more, Infinity should always be reported rather than the correct height), and page breaks work. The width and height may be known too (although not of the entire screen, unless it is full screen mode), but the user would lock the screen orientation using the global screen orientation locking function, if that is what is wanted. If CSS is disabled, then of course this won't work, but that is OK, since if the CSS is disabled then presumably the user doesn't want it to work, so it is OK. For displaying on a separate screen, that may be a function of the operating system anyways, and not of the web browser.
Payment Request is simply a specific case of autofill. Forms could specify autofill IDs, which are more general than this anyways, and fully controllable by the user. Credential Management could also work like this, although using HTTP authentication rather than forms/cookies would seem a better idea to me.
For sharing, the user can just copy the URL by himself; the browser might (or might not) include sharing functions for URLs, or the user may use a separate program which implements this; it is irrelevant which way is done.
Service Workers: For sending forms when internet is not available, what I wanted is the ability to save form data locally to disk and recall it later (on the same or a different webpage), entirely under the user's control; the web page should not need to know or care about this.
Game Pad and Force Touch are probably fine, although, like the keyboard and mouse, should only be enabled when the user activates it.
There are many other things too I think should be done differently.
- Web MIDI - access digital keyboards/synthesizers. I believe in some browsers there's no prompt, unlike Web USB.
- Screen sharing via getDisplayMedia, analogous to getUserMedia for cameras.
- WebRTC, peer-to-peer connections.
- Security keys (WebAuthn), specific support for cheap ($10-$50 depending on features) devices that do second-factor login to websites. Importantly, these devices communicate with the browser about which site you're logging into, making for phishing-proof logins.
Web MIDI is really cool. I recently bought a new MIDI keyboard controller from Novation and was really impressed when I learned that the configuration tool can run entirely in the browser without requiring local installation. In Chrome, it displays a permission prompt.
A while back I wrote a screen sharer that uses WebRTC and Gun.js for signaling [0]. Nowadays you could use IPFS's JS lib to do this (or webtorrent even). Now if both people are behind a restrictive NAT or something, you do need a TURN server.
As another commenter points out you can signal however you like, but even if a signaling server was required, it'd still be peer to peer since peer to peer accurately describes how the packets are routed over the network.
Those and all other things listed on linked article are JavaScript-lang/engine things NOT related to browser itself. You could use such using Electron, literally "outside of browser"
Try disable JS in your browser OR try to use Links[0] browser — and lets see what you can do with a browser in 2020.
The article is about things you can do with a browser, not things you can do with a browser with JS disabled. I think it's accurate. Also, all these features require support from parts of the browser beyond the JS implementation. Also, Electron embeds a web browser. Also, the ability to do things with something other than a browser doesn't imply you can't do them with a browser.
This is like replying to "Places you can visit for a road trip" and saying "You can visit all these places by train, too, also let's see you go there in a car without the engine."
Worth noting is that "prefers-color-scheme" works in all major OSes at this point, mobile and desktop. If your site already has a dark theme, there is no reason at all not to be integrating it this way.
Even if you don't have a dark theme already, it's a huge value-add..... (@dang?)
I'm sure someone will call me a slowpoke on this, but one really cool thing that I didn't know about until recently was that you can also use this in images with srcset's, to display a darker image. For example, if you want to put the "Made with Bulma"[0] tag on your website, they offer a light and dark version, which you could use like this:
It's funny to me that dark themes seem to be the preferred theme type in online discussions, because in practice, most people I know prefer a light theme on a monitor set to high contrast and relatively low brightness in a well lit setting. I too prefer that, as it seems to reduce (eliminate?) my eyestrain after hours on the computer.
I think it depends a lot on age and level of eyesight. I've never once felt eye strain from looking at a dark theme, and if a room is even somewhat dark then a blindingly white screen gives me a headache. I can always fiddle with my brightness as needed for different situations, at least on my phone, but that's kind of a pain. On a desktop monitor it's usually a significantly bigger pain.
If you do not need coloured text on your web page (due to coloured diagrams, colour coding, etc) then please do not specify colours at all. (If you do need colours, then ensure that all of the colours are specified.)
I hate it when the font color is set but not the input background. On computers with dark themes this can result in black on black text. There are workarounds in Firefox and I use them but this cost me more time than necessary.
> If I have to adjust my monitor brightness to be okay with reading something there's a major issue.
Yes, but the issue is with your monitor brightness or your ambient lighting, not the content. I tune my monitor for use at night with the lights on and as a result, #000 on #FFF is perfectly comfortable at all times. There's rarely a good reason to use a PC in complete darkness and I can't think of any reasons to do it in your own home.
I think that's the key point there. Light themes are good in light, but bad in dark situations, and vice versa. "Most" people prefer light, because they use their computer mostly in the light. Many programmers etc. prefer dark because they use their computers late in the dark a lot.
These are basically two "modes" of use, but software has been treating this as a preference, rather than a mode switch.
Through a set up of PowerShell/Bash scripts, I now have global dark/light mode switches on all my devices and I feel like this is the first time I can really use them effectively in all situations. Light when there's light, dark when there isn't. I even switch on the train as it goes through a tunnel. IMO, this is how it should be used, not as a set-and-forget preference.
The problem with bright themes used like that is that "high" contrast is still not very high at all, unless you go for OLED technology - but then you'd want to use green-on-black anyway to minimize wear on the display elements.
Yes, it's such an obscure feature that many of the people who enable it don't even realize it... Ever since I added dark mode to gwern.net, I've been getting or seeing complaints about how my website is broken or 'defaults to black-on-white' (it doesn't). :(
I've had a similar thing where people were complaining our app was in English (it was for a Dutch company), apparently people get confused about the preferences they themselves have set.
In all seriousness, because people keep not realizing or forgetting, we're adding a 'theme switcher' little widget. I dislike the need, but lots of people genuinely like dark mode, and this seems to be the best compromise.
Problem with Push Notifications is not the feature, but its implementation. Browsers decided to throw a popup instead of displaying an indicator of availability when a page supports Push Notifications. Possibly for discoverability. I disable the feature because there is no way to avoid the interruption and still easily accept for say a Discourse forum that I do want notifications from.
Blaming all web pages for their implementations is pointless. Give up the fight and redesign the browser. Don’t remove the feature because you believed web designers would hold back on informing the browser of its web page’s capability until the user interacts with some element every web designer would create, differently.
Firfox recently changed this so that you have it can only be invoked from within a button click or equivalent event[0] - I _think_ Chrome is following suit.
I think this is because there's no rules on the internet (besides GDPR which is implemented with varying properness). Compare with iOS where developers are given clear rules and / or instructions, e.g. how they have to ease the user into notifications instead of just yeet a permissions dialog in their face.
I think a lot of websites have just poorly / sloppily implemented the push notifications. I mean if they were to end an article with a call-to-action to subscribe to notifications and/or the newsletter, it'd be a much more pleasant experience.
As it stands, I've disabled push notifications entirely (https://support.google.com/chrome/answer/3220216?co=GENIE.Pl...) and I've got a bookmarklet that will try and delete all sticky elements (including persistent headers, popups, greyed-out popup backgrounds, cookie banners, etc). One day I might turn that into an addon that automatically does it after a few seconds of loading a webpage, idk.
One day browsers may implement pop-up blockers again as well but this time for the inline ones. I believe Google had an addon where you could report these things.
I'm not sure about other browsers, but Firefox asks once per website that wants a push, and even that can be turned off.
What's fantastic about not even having the option? What's fantastic about having to pay $100/year or reinstall your apps once a week, in addition to having Apple MITM any notifications?
Battery life is the main reason for this it seems. It's not about "having the option" it's "if you give devs the option they will use it leading to an overall worse experience." Web push notifications can't possibly leverage the single low-power TCP connection that iOS (and Android with gplay) devices keep open.
Push notifications in the way that phones do it are necessarily platform and service specific.
You don't have to allow Apple to MITM your push notifications BTW. Just send a generic ping to your app, and when it wakes up pull the actual content from your server and display the notification.
What's fantastic about a vendor intentionally ignoring multiple standards, in favor of their own walled-garden? You might be ignoring the wishes of actual users when you say it's "fantastic."
As a user I don't want push notifications from websites.
I know there are some exceptions (like messengers), but really, those should be apps because Apples centralised push messaging system is better for my battery life.
I mean, I know why nation-state attackers love them - it's super easy to exploit them, and once you do, you have full access to everything in the user account (including all browser login sessions). But what's the advantage to users?
> I mean, I know why nation-state attackers love them - it's super easy to exploit them, and once you do, you have full access to everything in the user account (including all browser login sessions).
tl;dr: The exploitation was indeed done through apps. The OS itself is harder to exploit, but most apps are not as secure and provide the first foot-in-the-door for the attacker.
I am responding specifically to the claim that once you've exploited an app, you have full access to the user's entire account (which is true to some extent on desktop platforms, but not on mobile OSes by default). I left a comment elsewhere about the kind of attack you're talking about: https://news.ycombinator.com/item?id=22632756
I see. Indeed, I agree it is not super easy to access everything on the mobile.
But I am still convinced that having a myriad of different apps, most of which are developed without real regards to security, makes the attack surface much larger -- e.g. you are likely to find a popular exploitable app that already has legitimate access to user data (such as "all the time" location data, contacts, calendar, ...) - as NSO did with whatsapp.
browsers are truly a universal too and a great equalizer. not only do they enable open platforms, away from the walled gardens. they also provide a way to share software for 94% majority. But alas, people these days are fighting against browsers. heck a good portion of web developers out there don't know semantic html or what good it can do. they were raised in the SPA era. view source is now foreign to most people. or that html pages are automatically cached for offline is foreign to most people too. what a sad state of affairs.
This is a great list some of these APIs look pretty interesting and didn't know about them this is a great list.
Push notifications are becoming an irritation mainly because of their overuse. The number of sites where you go to them to have a look at one piece of information and you have to tell them no to push notifications is becoming quite an annoyance.
This was an example of where web developers really should've known better in advance. They literally coded an intentional new way for people to make popup ads, and it's the primary use of the web notifications API.
I regularly hear of complaints about spammy popups on people's computers, even when they don't "have the web browser open". And it turns out it's just stock Google Chrome, doing exactly what Google Chrome was designed to do: Pop up ads, that everyone has since started shipping ads through.
I believe Brave has them disabled by default or an option for it. It is a shame a good feature has been abused, but yes you are right it is to be expected.
Suggestion: add a rough indicator of what platforms support each feature. You could link to the relevant page on https://caniuse.com/ but even a very quick "Supported: Mobile Safari, Chrome on Desktop" sentence next to each one would be enormously useful.
The credential management api is super annoying. Many websites now have a very annoying sign in with google dialog whenever I visit them and there's no way I can find to disable it.
The Credential Management API is more like a API in to the browser's password manager. A page can save a username/password/token into secure storage (which the browser can sync to your other devices) and later retrieve it. This is nice because we don't have to rely on autofilling form field heuristics.
You're thinking of Google's One Tap, which is just a JS snippet that publishers include on their page, and has nothing to do with browser APIs. (The OP shows a screenshot of One Tap, which is confusing.)
These uBlock filters will make those sign up with Google popups go away entirely:
Some people want a laptop that can make waffles, wash and iron clothes, vacuum the carpet, paint walls, repair blacktop and work as a vibrator.
My needs are simple. I want a small, rock-solid, terminal that is dedicated to HIGHLY secure and federally guaranteed transactions on a publicly funded military grade network for: Banking, Bill Payment, Tax payments, Voting.
I do not want it to take photos, listen to me, show advertisments, play games, stream media, maps, start coffee machines, do email and chat, play audio/video files, draw graphics or change themes.
And any "browser" that can do these additional functions should be banned from connecting to the high security network under penalty of death.
In AwesomeWM (a linux window manager), we have APIs to lie to windows. Telling youtube it is in fullscreen mode when it isn't is very useful. A lot of websites have much better fullscreen / mobile modes.
What seperates psychological warfare from marketing?
If you pay attention to advertising for a week, you will be marginally educated on what the advertiser wants you to know about their products and services; this has some economic utility as you cannot buy what you don't know exists.
If you pay attention to psychological warfare for a week, first off you at bare minimum will not be happy or content as you are not buying if you are content or happy; they must torture you through mechanisms of persuation and manipulation in order to manufacture a desire. Once that is done, then they try to train you to have desirable habits to them; as a famous example McDonalds happy meals for kids creating obese adult customers 30 years later. If the food didn't have a serious downside (didn't literally injure you and make you depressed) you wouldn't come back to the restaraunt later for your momentary allevation of that depression\for a fix.
Now, Go try to find reliable information on Coronavirus. Which one of those is going on 99% of the time? The sales funnel is really training you to be the product for them.
The web is funded by marketers who engage in pyschological warfare for profit, no feature they will ever impliment is designed to make you happy, and technologists have tremendous profit motive to make up all sorts of excuses as to why this behaivour is acceptable when clearly it is destructive to both themselves and the web.
Browsers today are trying to become an operarting system so they have absolute conrtrol over the user experience and as they do that they are on a slow march towards building an unbelievably bloated application who's philosophy is to confuse, distract, and screw you at every turn all while managing your perception.
Case in point, it would take hours for me to research how to turn off all of those features as I don't need them and there's no mechanism in Firefox or Chrome to backup settings which those browsers reset randomly and intentionally.
So call these things what they are; at best, bloat, at worst, a stock pump and dump scheme combined with a tremendous waste of time.
I'm rather sad that for example Battery API is deprecated... possibly might need a browser-wide toggle, but still...
It can both be cool, and useful....mostly cool, though...
you could have a complete web desktop (there several web desktops, and even more "fake" ones, like windows93) that shows the status, or a webpage that switches to dark mode with minimal javascript and theming, when battery is low, or a low distraction writing environment for example, that still notifies you of low battery, etc...
more and more people are using battery-powered devices ;)
I really, really, really wish iOS allowed push notifications through Safari. So many PWA ideas I want to explore are instantly stifled by that omission.
Nearly all of these are supported by Firefox as well. Apple is slower at implementing Safari features, but most of the important ones work (prefers-color-scheme, for example).
I am concerned that the "dark mode" and "reduce motion" detection features can be used for browser & OS fingerprinting. Does anyone know if any countermeasures are in place against that?
I suppose you're doing what might be a resource intensive task and want to be sure you don't kill the battery.
Granted I get folks might feel a rando website that is resource intensive would be horrific, but maybe we're talking about some specific web app / use case.
Emergency tools could benefit from knowing if the device was about to die or not, like the Tinder SOS app, government emergency tools, etc. Imagine sending a quick POST request to save session state or whatever before it dies.
That has its own set of challenges -- now you have to design your game so that the battery indicator doesn't cover up an important part of the game. Also, what if the OS allows it to be configurable location/size, etc.
Thanks! I did not know about these before. It looks like a step in the right direction. Though what would be the next step? It seems like there would still the complexity of laying out all the controls/HUD (or other visual elements) in the game.
Mostly agreed. However, if the screen is split into the system area and document area, then the battery indicator could go in the system area, and the game need not know where it is; only the size of the document area needs to be known by the game (and not whether or not the system area is present, what it contains, etc).
Uncertain about USB, Bluetooth, Locks, Keyboard Lock, and Native File System.
I don't want my browser doing those things.