Things you can do with a browser in 2020 | Hacker News Reader

Things you can do with a browser in 2020

github.com

698 pointstherealmarv382 comments

As a user, so many of these I wish did NOT exist. E.g: Push Notifications, Banners, Web Share, Contacts, Page Visibility, Badging.

Uncertain about USB, Bluetooth, Locks, Keyboard Lock, and Native File System.

I don't want my browser doing those things.

At least with the push notifications I can get notified about my stuff.

On the iPhone they require paying apple $100 a year which almost ensures most will be ads.

Could you use an existing solution such as pushover [0]?

[0] https://pushover.net/

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.)

Consider that different users have different needs, and almost all features listed are opt-in.

except you have to opt out of them all before you can consume that 1 website's content

hm I wonder if there is a chrome extension for that

> except you have to opt out of them all before you can consume that 1 website's content

This is an issue with that particular website's implementation, not something inherent to the browser or the API.

>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

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.

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.

It's almost like we shouldn't have tortured a document transfer system until it was able to run full-on applications.

It's just the amorphousness of life seeping in. People want more things in more contexts, which will always expand scope of the things they use.

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.

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.

The two main App Store providers already have products that provide fast, ephemeral app installs: Safari and Chrome.

I think it's great that they don't do a good job there, because it gives a big advantage to a cross-platform open-source open-standards alternative.

Though Android does try to address this with Google Play Instant (https://developer.android.com/topic/google-play-instant). I've never encountered it in the wild though.

Users care about security (at least a lot). That's why they don't install every random app that they could.

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

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

> the browser is the main attack vector on mobile

Citation needed. Browser-based attacks are difficult to come by, because it's just easier to attack an application instead.

>Citation needed. Browser-based attacks are difficult to come by, because it's just easier to attack an application instead.

You require a citation then make an assertion with with no supporting source.

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.

OS constantly execute untrusted code as well.

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"

> It's really a failing of operating system security

Please stop the gaslighting. Virtual machines and sandboxes existed decades before browsers.

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.

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.

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.

There is an another interesting property of web applications: the can't be stolen. I guess, this could also be a reason of their ubiquity.

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.

> If operating systems had ever provided security strong enough to run untrusted code

The browser hasn't either. See all the recent intel bugs and how many can be exploited from javascript.

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.

Depends if you dockerise...

I agree, it's better, but the idea that you can just happily run whatever in the browser and it's all fine isn't quite true either.

But it is a lot better now than it used to be.

When it comes down to it - why am I exposed to untrusted code if what I'm trying to do, for the most part, is just browse and read info?

Perhaps we should separate browsers-as-app-platforms from browsers-as-readers.

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.

If Wine got a tenth of the effort that goes toward Firefox, the whole Windows lock-in issue would have been solved ages ago.

As opposed to a strong incentive to stick to Chrome?

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.

That's a huge false dichotomy.

Yes. OS-specific native apps are generally a much better experience for the user.

The browser is such a great place as far as running an application goes almost universally.

I remember when applications had to be tied to the OS, does it run on unix, linux, some other OS, or hardware... what a pain.

If it is a web app it probabbly works most places.

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 that is more about how whomever wants to offer a site wants to offer their content, not the browser itself.

> I remember when applications had to be tied to the OS, does it run on unix, linux, some other OS, or hardware... what a pain.

And now many are tied to one or two browsers.

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 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.

For rando browsing on the web, yeah they aren't great.

On the other hand for say a corporate web application where my only users really do want them ... they're AWESOME.

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.

> Have you actually read anything about either of those APIs or are you just reacting to the names?

I admit, this is exactly what I did :(

appreciate the info

Kudos for owning up to it! We all do it from time to time.

It should be possible to turn off these features with a browser extension/plugin.

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.

If they were OSes they would have a kernel and user land

You would have ring0 and ring3

You could decide what to install or what remove

In the browser everything is exposed to everyone by default

More than an OS is a disaster waiting to happen

> In the browser everything is exposed to everyone by default

Several critical or potential annoying functions have opt-in prompts by default, unlike your typical desktop OS.

It makes no difference whatsoever

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?

Despite the idiotic downvotes, you are absolutely right.

Browsers are terrible. No other applications or OS components are so monolithic expose the same attack surface.

What? Running a native desktop app exposes a much larger attack surface than opening a webpage.

> 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.

what about the software that opens that web page?

kernel = browser, user land = web apps

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.

False.

For starters, browsers can only implement sandboxing thanks to the OS facilities, otherwise it would be impossible.

And that is modern ones. 5 years ago some browsers were still a security nightmare with not even multiprocess separation.

Five years ago was 2015. Chrome has had multiprocess and sandboxing for a lot longer than that.

And if you had read carefully I said some browsers.

In 2015 Firefox still did not have multiprocessing. IE did not either, and it was massively used back then.

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.

This is a classic false sense of security

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)

That's the real danger

The difference is that nobody runs untrusted binary apps.

If we wanted to do so, then the "run" operation on an executable would be different.

There is no difference, and in fact, OS have more features and capabilities to make running untrusted code safe.

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.

Native apps can siphon out much more info off your mobile than websites can.

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.

I think the point is that these features are masked from the user (especially on mobile) when performed in a native app vs a website.

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.

Just like native mobile browsers.

Regular users aren't plugging their devices into a host computer to access dev tools into their mobile browser.

Also no ctrl+f find.

One of the many reasons I use Amazon via browser and not app. Also open link in new window so you don't lose state, compare easily and much much more.

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.

Sorry, for a minute I though you were describing mobile browsers.

Mobile browsers are neutered but still way ahead of native apps on this spectrum.

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.

The problem with the modern web is it is becoming only the platform Google chooses...

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.

Here's some stats: https://www.businessofapps.com/marketplace/push-notification...

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

Why is that?

I guess we all know the answer

> Any website I visit from mobile wants the permission to notify me

Strange, I don’t think I’ve ever seen a permission prompt on mobile. Chrome, iOS

> 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.

I guess you're trying to be sarcastic, but it's not working

Actually I am not trying to be sarcastic.

Then I'm sorry and I mostly agree.

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?

That's what email, phone or support tickets are for...

My experience with this kind of services has always been lame and I strongly believe only bad businesses use them

For example the two larger e-commerce sites in the world,Amazon and Alibaba don't use them

If they were a major improvement, they would.

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.

> If you try the same thing with a B2B or other high-touch service, it's not going to end well for you.

In my experience B2B businesses call you, they want to talk to someone, not to a chat bot.

My biggest complain is in fact that I have to take phone calls because clients refuse to use other means of communication.

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.

In whhat way a web app is better in this regards?

Most app that need to push updates to the client do it by having a background service talking to the update server or polling for updates

You can even do it via HTTP(S) if every other protocol is blocked by a firewall or a corporate proxy

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.

> Web apps are better because they are as much device-independent as apps can get nowadays

They are actually not really.

If you can't run a modern browser on your platform, you're out of luck.

I think the real "as much device-independent as it can get nowadays" is just Firefox

On the major platforms Java is as much as device independent as the web

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.

> What do you mean by 'just Firefox'? Firefox, Chrome, Edge, Safari all support Progressive Web Apps in general.

Chrome runs only on Windows/Mac/Android (Linux if you allow proprietary software on your distro)

Safari is only Windows/Mac/iOS

Firefox runs on many more platforms, but unfortunately its market share is low

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.

You only need to rely on one application to make push notifications worthwhile.

I get browser push notifications from gmail and facebook. I block everything else, but I'd be pissed if I didn't get those notifications.

So that's one good use case for Push Notifications. It would take about 10 minutes of browsing to find 10 bad ones.

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.

I find the browser notifications useful for discourse forums. There are some stuffs that I would like to be notified but not by email.

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.

Is it not standard practice for browsers to prompt about push notifications? When I see the prompt I choose no, and don't ever see notifications.

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.

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.

> Almost better, as it is so limited.

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...

> Is this a thing that happens often? Used to, your phone number was in a publicly available book.

When you could only call that number. Messaging is pretty different.

And sure it happens! Phone numbers are (nearly) immutable. It's a valuable piece of personal information. Your web push ID is... not.

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.

I’ve gotten plenty, just for a counter-anecdote. In fact I received one today!

From who? This is literally against the law in the states. You reply stop, and if they don't, you can report them.

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.)

Much better than directly copying the URL.

Or you could just trim the URL yourself.

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.

Even worse is chrome on android now. You have to copy the url, re-paste it and then edit. You don't have immediate access to the url you are on.

Which is a behaviour I observed in most power users, but none in the non-power user group.

I don't think most non-power user even want to try to trim that stuff, because they don't know what can be trimmed and what can't.

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:

file:///C:/Users/blabla/something.pdf

httpx://who.int/something?fbclid=<200-hundred-chars>

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...

Not far enough, why can't websites notify me via semaphore, or signal fires!?

> I prefer copying the link to the page I'm on to share. No popups, native or otherwise.

I tend to agree, but this puts us both in the 5% of internet users who know how to do that. (And no, I'm not celebrating that low number.)

Sadly, agreed. Shame that it is moving this way.

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.

https://docs.microsoft.com/en-us/archive/blogs/jensenh/no-di...

You and I use Ctrl-V, but the vast majority of users want something a lot more visual.

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.

Everything in Office can be navigated using the keyboard...

This is such an important realization.

I, too, personally wish most of those features didn't exist. But I acknowledge that I am in the minority.

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.

Look up Chrome Feature Policies.

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.

"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" is reasonable.

"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.)

It wouldn't surprise me if user control is the problem most services have with RSS

I'd be shocked if typical users understood what push notifications are, or even what those social network links for sharing things do.

Sometimes there are counters on those sharing links, and a tiny portion of visitors seem to click them.

> 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.

How are feature requests from web developers to browser vendors evidence that browser vendors are paying attention to the desires of end users?

The evidence is that the end users use these things when they're implemented in browsers and web developers adopt them in their apps.

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.

This is how notifications work in Firefox and Chrome today. The site prompts you to allow notifications. If you do nothing, they are not enabled.

By default, the user gets notified that the site wants to send notifications.

> They're all very receptive to feature requests.

I think that's part of the problem.

Being receptive to hearing them is very different to actually implementing them.

Voted most insightful comment.

Exactly. Default browser settings ≠ user preference.

Default browser settings = what the browser developer believes will best server the browser developer's interests.

And because of that only megacorp is capable of developing web browser for "free".

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.

> Then you're out of step with what users want these days.

We hear this pretty often without any evidence. He is a user, you are a user, that makes two opinions.

I think the reality that companies set the rules and people just swallow what they get because alternatives require huge efforts.

We also heard that users want large tiles that are all over their desktop with zero functionality.

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.

> fork?

Because it runs contrary to maintainer’s interests?

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.

Pretty sure that exists in Firefox

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?

>when I hit a share button on a page

Why would the share button be on a page? Surely this should be a native browser/OS function (as implemented km android, for instance)

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.

No, it works on Chrome on Android too, so that’s the vast majority of mobile uses covered.

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.

> But to take an example, when I hit a share button on a page..

You have already lost me, I do not believe I have ever done this, or wanted to do it

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.

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 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

There's a Coffee API for that. Uses the covfefe protocol.

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.

Couldn't find it offhand (on mobile), but here's some research on api usage https://almanac.httparchive.org/en/2019/javascript

The httparchive could provide insights on any api afaik.

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.

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.

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.

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.

I don't agree, I leave a video on, switch tabs to read something else, and now it stops. There is no way to get it to keep playing and switch tabs.

Just open a new window and leave the tab with the video on top of that window. (It hasn't to be always tabs only.)

Doesn't work on mobiles.

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.

It is most definitely the page doing the muting.

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.

God no, sites shouldn't be told whether I'm looking at them or not.

The native file system access mentioned near the bottom sounds like a massive security hole

I want useful programs that happen to run in a browser to do these things, after asking my permission.

I don't want every random local news paper or internet chum site prompting me for every permission under the sun every visit.

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.

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

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.

@include *

@run-at document-start

navigator.something.someMethod = () => {} // noop

https://www.tampermonkey.net/documentation.php

Browsers need better and more usable permissions (and less leakage). Every API that's added is another attack vector.

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.)

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.

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.

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.

> I don't want my browser doing those things.

Your browser should let you decide whether you give websites access to this functionality?

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?

When I implement this that's how I think anyway.

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..

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.

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.

To me this sounds even worse.

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.

uMatrix does that and also takes that to the next level, at least on Firefox.

I'm pretty sure you can set your browser to reject all push notifications.

I'd add to this list Payment Request API, it's akin to DRM.

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.

A few things that aren't mentioned:

- 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.

Is WebRTC really peer-to-peer if you need a server?

The server is for convenience.

If you can handle signaling in another way, you're free to do so.

When I played around with WebRTC the first time, I did it by copying the signaling data via TextAreas and WhatsApp.

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.

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.

0 - https://myscreen.live

I wish the FUD about UPnP would finally calm down so we can finally have at least some P2P connections without the need for a rendezvous sever.

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 few things that aren't mentioned:

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.

[0] https://en.wikipedia.org/wiki/Links_(web_browser)

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."

(I am a links user, btw.)

Electron embeds a HTML-render + JS-engine != web browser

Electron is essentially just a version of chrome. If electron can do it, chrome can do it, and there is no way to say that chrome is not a browser.

Electron is essentially just a version of Chromium, NOT Chrome.

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?)

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). :(

Huh... It's weird to me that someone who has that enabled on their OS (even if they didn't realize it) would be upset about it on a website.

That's silly of them. The only problem I've noticed is that images are inverted when they shouldn't be (e.g. on hover or the enlarged view).

I enjoy the prefers-color-scheme support!

Looks like we need prefers-prefers-color-scheme

But then what happens when they forget opting into the opting in?!

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.

hey gwern, I personally really appreciate the dark mode support.

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.

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.

I've always heard that you should use an off-white or off-black, and that CSS like #000 or #FFF for backgrounds is a no-no.

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.

There's no real consensus. Try this site: https://contrastrebellion.com/

Sure, but there's a whole spectrum between slightly darker grey on slightly lighter grey, and straight up #FFF on #000 or vice versa.

If I have to adjust my monitor brightness to be okay with reading something there's a major issue.

> 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.

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.

Or just use whatever colors you like and replace displays when necessary.

I spend way too many hours using a monitor to let it's lifecycle determine what color-scheme I'll spend those hours looking at.

> on a monitor set to high contrast and relatively low brightness in a well lit setting

That's 3 pretty big assumptions :)

Sure, in that situation light mode is great, but if I'm browsing HN on my laptop at night in bed in the dark, I would definitely prefer dark mode.

> in a well lit setting

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.

It's also completely broken when using GTK themes with Firefox installed with snap.

Fascinating, they're still Win95's ability to customize color schemes.

I think you a word.

Indeed. For the record, that word was 'behind'.

Even Windows 3 and possibly earlier editions allowed way more theme customization than a simple choice between light or dark.

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:

  <picture>
    <source srcset="made-with-bulma__dark.png" media="(prefers-color-scheme: dark)">
    <img alt="Made with bulma" src="made-with-bulma" width="128" height="24">
  </picture>

This will automatically replace with the image src when the srcset criteria is met, but keep all the other tags!

[0]https://bulma.io/made-with-bulma/

I hadn’t known exactly what srcset did until reading this, thank you!

This list doesn't include the Screen Capture API.

https://www.w3.org/TR/screen-capture/

https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capt...

https://www.webrtc-experiment.com/getDisplayMedia/

> Browsers can register push notifications

Oh yes I didn't notice EVERY PAGE on the planet asking me for that.

(After asking me for e-mail newsletter signup and cookie consent.)

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.

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.

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.

0 - https://developer.mozilla.org/en-US/docs/Web/API/Push_API

Yeah, and this works somewhat but sites just listen for the events on every element and trigger the popup then.

For anyone wondering how well supported these features are globally (from caniuse):

prefers-color-scheme: 80.85%

prefers-reduced-motion: 84.05%

Payment Request API: 90.06%

Web Share API: 49.25%

Push API: 78.57%

Service Workers: 94.42%

Web/native app install banners: 68.19%

Get Installed Related Apps API: Not launched, 0%

WebXR: 61.83%

Picture-in-Picture: 85.01%

Media Session API: 66.31%

Chrome Sender API: 64.75%

AirPlay: Unknown

Force Touch API: 55.74%

AR Quick Look: Unknown

GamePad API: 95.18%

WebUSB API: 65.27%

Web Bluetooth API: 68.6%

Web Locks API: 67.43%

Keyboard Lock: 30.47%

Generic Sensor API: 67.43%

Credential Management API: 70.86%

Clipboard API: 70.86%

Presentation API: 15.24% full support, 80.14% partial

Screen Orientation API: 76.16%

getUserMedia camera selection: 93.48%

Pointer Lock (Mouse Lock): 55.06%

Theme Color: 37.39%

Vibration API: 77.13%

Web Coffee API: Unknown

Battery Status API: 72.36%

Page Visibility API: 97.44%

Web Speech API: 92.88%

The web coffee API is a troll FYI. There is no covfefe protocol.

I had no idea the Web Coffee API was so mature.

Why is this even an API?

Seems like a joke API rather than something actually useful.

Go click the link in the github repo, it's actually very cool

Seems like this snowballed:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418

"418 I'm a teapot"

Never going to covfefe you up

> Use covfefe protocol to start coffee machines.

I should have known, but I wasn't paying attention.

I'm slightly disappointed that clicking on it didn't just return a HTTP 418 error, but was nontheless satisfied with the result.

I thought I knew of all the APIs, but that one surprised me. Hadn't realized how well done it was...

Subtle.

... and Safari still holding out on web push - this lack is a reason many native apps get written.

I’m not sure why I read this in a negative tone, this is fantastic.

It’s why there are no self hostable chat apps.

A better option would be for users to be able to select alternate push servers.

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."

I'm only speaking as a user.

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.

If you don't need that, you can cmd-comma and disable that.

But there's no such an easy way to enable a feature you need, but which wasn't implemented.

I do not want an opt out, I do not want it.

I _do_ _not_ want it.

I do not want it to be expected.

I do not want it to be assumed.

I do not want to have to configure anything.

_I DO NOT WANT IT_

So, you're fine with it to be off by default?

Ok, but your preference isn't everyone else's! You can disable the pop-up asking you for push notifications on all relevant browsers, afaik.

What's fantastic about native apps?

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).

Not on mobile.

https://www.ft.com/content/4da1117e-756c-11e9-be7d-6d846537a... (and google "pegasus nso whatsapp" for more)

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.

Sure, true. Mobile browsers also tend not to support all these features, so on mobile, I don't object to a native app.

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.

And thank the lord for that.

https://whatwebcando.today

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.

There's a lot of those APIs that are awesome for corporate web apps ... but brutal on the web.

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.

Each link already goes to MDN, which has its own rough chart of browser support

I clicked the Web Credentials link, and was disappointed to be redirected to google's docs :P

https://developer.mozilla.org/en-US/docs/Web/API/Credential_...

Ah. Well at least some of them go to MDN...

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:

  ||accounts.google.com/gsi/iframe/select?*ux_mode=popup$all
  ||smartlock.google.com

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.

Very simple.

Why should a browser be allowed to check for device battery life? That seems wayyy off limits

They can reduce something that is good but not when your battery is low.

It has been deprecated because of privacy concerns, so it will probably be removed from browsers soon.

This article needs a complement: Things you can't do with a browser in 2020.

Picture-in-Picture works great for Facebook videos, FB stops playing videos when the window is not focused, so this feature it's amazing :D

It's a hack that shouldn't even be necessary. It's none of FB's business whether its window is focussed.

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.

(disclaimer, I am one of the dev)

Mount and Unmount a VHD File in Windows Explorer via a Right-Click

https://www.howtogeek.com/51174/mount-and-unmount-a-vhd-file...

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 ;)

IIRC I think it was because it was used to fingerprint browsers

> a webpage that switches to dark mode with minimal javascript and theming, when battery is low

Please don't arbitrarily change the theme of the website I'm using based on my battery level.

> a low distraction writing environment for example, that still notifies you of low battery

My system does this.

> Please don't arbitrarily change the theme of the website I'm using based on my battery level.

Yeah, just base your theme off of the dark mode setting. Then if the _system_ changes to dark mode when battery is low, your app can follow suite.

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.

Is there no alternative way?

You can ask your users to download a third party app like PushBullet, but that's very lame and unprofessional.

More like a "things Chrome can do in 2020".

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 like the Intersection Observer:

https://developer.mozilla.org/en-US/docs/Web/API/Intersectio...

I fell for the coffee API It was half believable because of the teapot statue code.

Of course this one goes where you'd expect... https://github.com/luruke/browser-2020#web-coffee-api

See also, from yesterday: "The reckless, infinite scope of web browsers"

https://news.ycombinator.com/item?id=22615894

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 think prefers-color-scheme was actually held up for a while due to fingerprinting concerns.

Additionally, here is a list of what browsers will be able to do:

https://goo.gle/fugu-api-tracker

So, uh, https://github.com/luruke/browser-2020#web-coffee-api

I think WebUSB is all but dead. See: https://news.ycombinator.com/item?id=22228879

It is very much not dead and is used for educational products all the time.

We use it ourselves for our internal ecommerce backend system.

We made our own WebUSB Postage Scales and Label Printer that enables 1-click creation of consignment labels.

We pull weights from the postage scales and chuck raw ZPL over the wire to the Label Printer.

Being able to skip the bugs in operating system printing queues is amazing.

Demo:

https://vimeo.com/334547755/c387957a25

It's also used to flash Android devices too.

I haven’t tried it, but WebUSB has been used for loading custom operating systems while hacking Nintendo Switches: https://webcfw.sdsetup.com/

Web Coffee API link tells you everything you need to know.

no, it doesn't tell me why there isn't a Web Team API ;p

*Tea, not Team

Surprised to find out covfefe is an actual protocol.

The documentation goes in much more detail.

If you'd have told me in 2010 that this would be the state of the art of the web in 2020, I'd have been sorely disappointed...

personal opinion -- almost all of these features are really cool to me as a user and a developer.

just shows, everyone's got an opinion.

Why, what were you expecting?

This is an excellent resource to have when problem solving or brainstorming solutions.

Anyone know if something like this exists for Android and iOS?

Who seriously thought the Battery Status API was a good idea? Someone thought this was useful enough to write a spec for it...

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.

Even so, I think battery API is not the proper way to do it. Some sort of interrupt command (like UNIX has) may be better.

Agreed. Maybe only useful for laptops used as 'kiosks' (launching directly to app without a window manager)?

Fullscreen games providing a battery indicator is always nice.

Seems legit, although that should probably be the OSes job to overlay that

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.

I was imagining a pop-up saying "your battery is getting low"

> now you have to design your game so that the battery indicator doesn't cover up an important part of the game

You should not be able to do that; It's a feature that you cannot do that.

? You should not be able to re-layout your visual elements in the game if the battery indicator hides it?

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).

Sounds like a job for safe area insets.

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.

Well, it's not going to fix the layout for you, but it'll ensure that it won't end up under a curve of the screen or behind some UI protrusion.

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.

Sigh. I fell for the Web Coffee API link. I saw mention of a covfefe protocol and was excited to read about it.

I did the same. I was hoping for an HTCPCP-like W3C specification that I had somehow missed.

Payments API is lit. Didn't realize I could do it from the browser!

Hahahaha. There's an amazing flattering IR photo of me in there :)

Wow "Web Coffee API" - something I didn't know I needed

I guess we can apply Greenspun's rule to modern browsers:

"Any sufficiently complicated browser contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of operating system."

Can I create water, that I can feel?

Looking at these, I feel that browsers do way too many things than they should.

Yes, I and others commented on other threads about such thing.

things you could do, if the browser supported them

...love a bit of rick astley with my morning Covfefe....

The Web Coffee API (https://github.com/luruke/browser-2020#web-coffee-api) is my favorite of the bunch. I definitely recommend checking out the linked WHATWG documentation, as well as the relevant RFC for the HTTP protocol: https://tools.ietf.org/html/rfc2324

What can’t a browser do these days?

The Web Coffee API caught my attention, and was the first link I clicked through... Needless to say, I was not disappointed!

> What can’t a browser do these days?

Detect that you’re paying for bandwidth and not autoplay video.

Reply on news.ycombinator.com