I wish there were an easy way to rotate the image back. I can use the inspector in dev tools and manually change the transform style that's applied, I suppose.

Maybe it was changed quickly, but I can't find anywhere that is says "No tracking". It specifically says "We don't track you around the internet." and "doesn't track you across sites" in the terms and about pages.

Also, you kind of have to "track" users to some extent for a site like this - otherwise it would be simply for someone to stuff votes.

The Plausible does count raw statistics without "tracking" specific users. That is just used for general website analytics. The first-party functional cookie that I am using (very similar to the auth login cookie) is used to prevent duplicate anonymous votes. Neither of these track the user and both are for on-site only. The functional cookie works much better than the fingerprint (actually less invasive too), but isn't full proof. You can switch browsers, go to incognito mode in some browsers, etc.. to bypass it, but it works for most casual users. Since it isn't election level polling, I figured it is fine. I do have an in memory rate limit to prevent excessive voting spam.

Are you rate limiting at the subnet/prefix level for IPv6?

Actually no, I'm rate limiting per individual IP address right now. Good catch... I should probably normalize IPv6 to /64. I was originally thinking about not blocking universities or large groups that share IPs, but I guess that is more of an IPv4 NAT concern. Thanks for pointing it out! I didn't really think about a user rotating through IPs. I didn't add the rate limiting on voting until I removed the fingerprint, so that is for sure a valid concern.

It could make sense to lightly rate limit at /48 in addition to /64 (this is generally the largest subnet size given out by ISPs), otherwise it will be easy for people to multiply your /64 rate limit by 65536.

Hey thanks for the recommendation. That makes sense. Layered rate limiting at both /64 and /48 with different thresholds. Appreciate the explanation, and I'll be adding this to the list! This is my first time dealing with a public facing app where this type of rate limiting is needed.

On the landing page, right underneath the "disagree" button it says "no tracking"

They aren't taking issue with Signal, per se... they are upset that people are sharing the whereabouts and movements of ICE officers. Signal just seems to be the medium-of-choice. And this just happens to give them a chance to declare Signal as "bad", since they can't spy on Signal en masse.

Most people have many devices: phones, tablets, laptops, etc... so this makes that stuff accessible from anywhere. And if you lose your device, or it dies, you don't lose all your data. On that note: self-hosting allows you to centralize your backups.

I do have backup storage, of course.

It's hard for me to imagine wanting to use a phone for anything other than making calls or sending SMS; that's what I've been doing for many years now and I see no reason to change. But if I did have a tablet or laptop, I could just sync the program to it and run it locally. Maybe using, for example, good old rsync.

And I can't imagine being away from "home base" on a laptop for long enough (or using it for anything critical enough) to really worry about how to achieve "centralized backups". I'd rather not transmit that data over the Internet when I could just connect the laptop physically to my backup storage when I got home.

> It's hard for me to imagine wanting to use a phone for anything other than making calls or sending SMS

Not even listening to music in the car? That is probably my #1 phone use case by far outside of the communications functions you mentioned. I run a Navidrome server at home, and while on the go my phone can stream any music I like from the home server (so I don't need to load it in advance). In theory one might store the music on one's phone of course, but I have more music than my phone will hold and it's very nice to be able to access whatever I want to listen to at will.

> Not even listening to music in the car?

I generally prefer to have access to all my senses on public transit, but there are any number of other portable devices I could use that store the music locally.

> I have more music than my phone will hold and it's very nice to be able to access whatever I want to listen to at will.

If I were going to choose from among that much music I might as well search the Internet anyway. An entry-level microSD the size of my thumbnail now holds a couple hundred CDs worth (at uncompressed CD quality; several times that for high-quality opus).

You seem to be an extreme outlier and probably not the target audience for such applications. No offense, but nobody is carrying around multiple devices when the one device we all have can do everything and do it better.

How come the connection is stable enough to be streaming on the go from the car? Or is there some serious caching happening?

MP3s are tiny. Just download + cache the n and n+1 song. On a modern 4g or 5g connection downloading an entire song takes seconds. Anytime a new song starts up, grab the n+1 song as soon as possible.

But aside from that, inside any metro area even a 200ms or so buffer would likely suffice for streaming music.

Yep, and OPUS files are even lighter. That's why I just sync a "currently listening" music folder with Syncthing and do not think about connection, caching and all that. (I have the rest reachable when I need it, of course.)

200ms and even n+1 won't cut it for a subway, a semi-basement pub, a tunnel, a train or an airplane trip, a hike, a countryside visit, etc.

well then you have a very niche use of your computing devices.

> The web simply dont offer the same experience and is not an alternative for argument sake.

The entire reason this is the case is because Apple and Google have intentionally prevented the web from offering the same experience. They've limited the APIs that web apps have access to and made them clumsy to use and "install". Web apps could easily compete with native, but that would limit their control over the app market and revenue.

There is absolutely some truth to this.

But we’re talking about extremely basic things. Simple pages that display data, like a bank website showing my transactions. And you know what? The simplest of sites seem to work awful on the web… because the web developers make bad sites. I have seen examples of sites that are smooth, functional, and beautiful. But most sites are not. They are bloated messes where the user experience seems to be 15th on the list of concerns.

To answer to the question: “why does the web suck on mobile” is almost entirely “because web developers make awful websites”.

Google has pushed web harder than any other company. They popularized the very concept of a web app, back when the public didn't have that notion. They pushed the concept of progressive web apps. They tried to push web components. They tried to throw Dart into the browser. Under their guidance JS has advanced very quickly as a language.

PWA's can do background sync, there's push notifications, badge icons, the kinds of things that allow websites to feel more like apps — on Android and not iOS.

Debatable.

The AJAX approach was pioneered by the Outlook web team ~1998 and semi-standardized as XMLHTTP in IE 5 (1999).

So a decade before Chrome was released.

Admittedly, Chrome did a lot to push forward web apps, but that was 100% in Google's self-interest given they were competing against thick client MS Office.

Which APIs are limited? I feel like almost every app I use could easily be a website. They don't seem to do anything especially fancy.

An actual list would be long, nuanced and vary by platform, but I'll offer a sampling.

For many things there's might be a basic API available, but when you dig a little deeper you find huge limitations. Geolocation is a great example of that. Sure, it's available. But you couldn't implement a navigation app, for example. Because you can't watch the location and get updates in the background. Not to mention that accuracy and update frequency can be severely reduced in a PWA vs a native app.

Other limited APIs include things like bluetooth, audio, NFC, notifications, file system access, sensors (proximity, light, etc), camera functionality.

Safari (and therefore Apple) doesn't support things like accelerometer/gyroscope access, battery status, vibration, network info.

You can't access things like the user's contacts or calendar. And we could argue over whether limiting access to stuff like this is a good or bad thing. But the fact is that this stuff is available in various ways to native apps, but not at all to web apps.

As an app developer, if the app is nothing but images and text and the full experience is just a series of json, it should be a website. Those kind of apps are the most boring to work on.

But our phones are more powerful than the computers that landed us on the moon and are packed full of sensors and connectivity. The web is incapable of matching a native app, if it is actually doing something interesting.

Outside of games, very few apps are doing anything interesting. The only reason for them to be apps at all seems to be to get a place on your Home Screen and to push notifications.

A website in your phone browser will not be able to see when you're leaving work (or a friend's house, vacation), calculate when you will be home, turn on your HVAC, raise your garage door, and unlock your door as you approach the door.

It also won't display the weather for the next few hours and your calendar on the same screen whenever you open up your phone without being an extremely bothersome action every time.

We have "netbanking" which works but its slightly less convenient, has some features left out and so on

> This has strong vibes of “If only Linus Torvalds had charged for Linux, he would have been a rich man today.”. It does not work that way.

Not at all similar. Linus explicitly made his software free. Romero didn't _intentionally_ exclude the copyright notice, and had no explicit intention of making it free.

> It’s not “ironic”, it’s completely expected. If it was only an old black-and-white movie, still subject to copyright, today the movie would be a historical footnote at best.

"completely expected" is quite a stretch. Simply making it public domain wouldn't be enough. It still has to be a good movie. I'm sure there are countless other public domain black-and-white movies that no one has ever heard of.

>I'm sure there are countless other public domain black-and-white movies that no one has ever heard of.

See: MST3K and RiffTrax

This is a few years old now:

> The article was updated on June 26, 2023, to include LocationIQ per the provider's request.

There are a few more options now (Stadia, Geocodio, among others). And I'm surprised this doesn't include MapBox, which surely existed then and has (comparatively) reasonable prices.

I'm really surprised I don't see more tech-savvy people talking about SilverBullet (https://silverbullet.md). It's not perfect, but very "hackable" and being actively developed. It's the best self-hostable note taking app I've found so far.

If SilverBullet were into acquiring more users (they may not be), they could use some major help with their site design.

When I visit the SilverBullet link, I get a wall of text. And at the very top is a warning about versions and a link to migrating your data between versions, which leads to another extensive wall of text with various code and configuration examples.

Many people, even busy tech savvy people, are going to shy away from this.

To be honest, it looks kind of interesting to my inner nerd, but I think I'll stick with my "directory of plaintext Markdown files" that I've moved between apps as they've come and gone.

I was using this for a while and really loving it, however the dev just recently decided to undertake a rewrite into Lua which breaks all existing scripts, and changed how the online/offline paradigm works, which made me feel a bit skittish about whether it is going to be a stable long-term solution. I am really rooting for Zef here though and hope it settles into a good place soon!

I like SilverBullet a lot; it's similar in philosophy to Obsidian. The biggest issue I had using it as a daily driver is that it's a website; there's no dedicated app. I like to have Obsidian hotkeyed as a toggle on cmd-' for instant access. As a Firefox user on macOS, I couldn't figure out a way to do that with SilverBullet, even with HammerSpoon scripting.

I just found out about SilverBullet and it looks promising, but I'm also worried about the lack of a dedicated app for the same reason as you. The developer mentions installing it as a WPA in the demo video, have you tried that? Seems like it could solve the shortcut problem.

As i understand it, it has no encryption build in. Maybe thats the reason.

I did not know it and so I had a look. While it looks promising, it does not have a install section on how to set it up as a systemd service, just docker...

That makes it a hard pass for me.

> It's pretty clear they (and Google, to a lesser extent) don't want web apps to be on the same level as native apps.

Ironically the reality here is backwards: for a very long time iOS apps could _only_ send declarative push alerts. Only since iOS 10 were you able to use a UNNotificationServiceExtension to customize the content on-device. That extension has very strict resource and CPU limits and is terminated if it violates them. Even when you do have this extension you still need to send a declarative payload in case the on-client code fails, exactly the same as Declarative Web Push requires.

> And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.

There's a big difference between running some native code and spinning up an entire JS virtual machine and worker environment to (effectively) modify some JSON. In fact, worker boot up speed is a recognized problem to the extent that there's an entire API to handle situations where a network response would load quicker than a Service Worker might:

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

Years ago I actually tried spinning up a JSContext in a notification extension out of curiosity and the extension was immediately killed for exceeding resource limits. May well not be the case today but the logic still makes sense to me.

Apple is no saint and has done plenty of negative things for web apps. But in this specific instance they're making the right call, IMO: requiring backup notification content for when client-side code fails is sensible.

> Ironically the reality here is backwards:

Maybe you quoted the wrong the thing? but there's no irony here, and it's definitely not backwards in reality: Apple and Google have both severely limited what PWAs can do such that they are vastly inferior to native apps. It would very difficult to argue otherwise.

> There's a big difference between running some native code and spinning up an entire JS virtual machine and worker environment to (effectively) modify some JSON

Presumably React Native apps do something to that extent? Or, if they don't, whatever optimization they use could certainly be applied "under-the-hood" to PWAs.

> Presumably React Native apps do something to that extent?

Not in the background they don't, no.

> Or, if they don't, whatever optimization they use

They don't have one. There is no optimization they can do to run JS in the background. Push notifications in a React Native app either use native code or rely on declarative payloads sent from the server.

The big difference, as always with web apps, is intent and consent.

Installing an app is a strong signal that the user actually wants/needs it. The level of consent is much higher right out of the gate. With web apps on the other hand, the user can be swept away by a redirect, accidental tap, maliciously captured tap (think a transparent element covering the whole page), etc. There’s a much higher chance that users never intended to end up where they’re at and don’t actually want anything from the app.

Following this train of thought, it stands to reason to have a looser policy with apps. If there’s a way to install web apps with the same level of consent (PWA listings in an App Store for example), standards could be loosened when users come through that route, but for navigating to any random web address things should be more tight.

The user already has to explicitly "install" a PWA on iOS. See dfabulich's comment in this same thread for how overly complicated and convoluted that process is currently. So there's a pretty good argument that installing a PWA actually require much, much MORE intent than a native app from the app store.

Similarly, the user needs to consent to notifications (among other things) just as they do for native apps.

> So there's a pretty good argument that installing a PWA actually require much, much MORE intent than a native app from the app store

As it should because native apps go through an approval process to vet them.

Mozilla seems to be in favor as well: https://github.com/mozilla/standards-positions/pull/1190 (and funnily enough, a comment on this PR agrees with you in that background work might not be a significant factor in terms of energy consumption, but they still think this is a better design than the original Web Push spec).

Also, interestingly, in the original Web Push spec, they did think that energy consumption was enough of a concern that they implemented a quota system:

> Activating a service worker to deliver a push message can result in increased resource usage, particularly of the battery. Different browsers have different schemes for handling this, there is currently no standard mechanism. Firefox allows a limited number (quota) of push messages to be sent to an application, although Push messages that generate notifications are exempt from this limit. The limit is refreshed each time the site is visited. In Chrome there are no limits.

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

Anyway, let's put a defensive hat on for a moment, and assume we're dealing with malicious actors (and OF COURSE we're going to be dealing with malicious actors, this is the internet, come on).

> Surely this wasn't the only option to "protect user privacy and battery life".

First off, I notice you are confident that this wasn't the only option (there's never only one option, so the statement as it stands can't be falsified), but you don't actually _provide_ any alternative ideas.

> Native apps can handle push subscriptions without this sort of flag.

Native apps require a push token to send notifications, which can be revoked. If/when a native app abuses the user trust, it's easy to also ban the entire app, or ban the entire developer account in the worst case scenario. Even that often doesn't stop bad actors, but it does give some tools to the defenders to work with.

If I am running an abusive web app, I can spin up two dozen clones before breakfast when a particular domain gets blacklisted, and there is no way to ban me (that I know of).

>> Allowing websites to remotely wake up a device for silent background work is a privacy violation and expends energy.

> This _may_ be true in some cases, but it isn't inherently true. I'm sure there are many use cases for this that are NOT a privacy violation. And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.

I'd love to see a heuristic that can be automatically applied to an incoming push notification to determine whether or not it's going to cause a privacy violation or excessive energy use.

In fact, maybe we can use the same heuristic with my geolocation API - after all, while some requests to the API _may_ be malicious, most of them aren't - surely there is no need to add safety guardrails that make malicious requests impossible or at least more difficult - we could just tell the computer to recognize and ignore evil requests, and only allow the good requests, right?

But, maybe you're right, and none of these are concerns to worry about - the main reason is to just make developer's life harder (though in that case, wouldn't the easiest solution be not to bother implementing any of this API at all?)

Thanks for engaging in good faith and for the detailed response (I didn't downvote any of your posts fwiw).

> I never suggested energy consumption wasn't a concern. I said any code that runs expends energy.

I don't think anyone would argue otherwise.

> So to pretend it's a concern only for PWAs is silly. It's a concern for both web and native apps alike.

I think you're ignoring the fact that running it for PWA's requires spinning up the entire browser engine in the background to run the ServiceWorker. That's considerably heavier than the minimal amount of native code required for a native app's notification extension. It's not the same cost/benefit calculation.

> So it's not really possible to address this broadly-defined privacy issue. Maybe it's buried in a Github discussion somewhere, but it's certainly not addressed in this blog post - they just say there's a privacy issue, and that's that.

Ok, but you're handwaving any potential privacy/energy issues away out of hand, and suggesting they are simply a smoke screen, and any and all discussion that I am sure went on over the course of arguments over the W3C spec as a nefarious cover. Again... from that point of view, I don't understand why you think anybody would even bother defining and implementing _any_ of this, if that was the goal?

> I can't speak to the vague idea of what a "privacy violation" is without understanding what the specific concern is. Is it geolocation? IP address? Fingerprinting? Regardless, iOS already uses a heuristic for native apps, so why can't a similar heuristic be used for web apps?

Right, you can't speak to it because it's too vaguely defined - so how can a computer universally and accurately judge the same thing without a precise definition?

And, unless I am mistaken, there IS no automatic heuristic for native apps either. I personally don't think it's even possible to define one, because there's no way to universally judge from the shape and content of a message whether it's benign or not, just like you can't judge from simply seeing an SQL statement like "DELETE x FROM y WHERE z" whether it's a valid request that should be processed, or a malicious one that should be denied - it all depends on a ton of context - and you DON'T have the same context between a web notification and a native notification.

> That's quite the straw man, considering Service Workers can't even access the geolocation API.

Sure, I am exaggerating for illustration. My point is there is no way to just handwave the complexity away with "there should be a magic heuristic that can distinguish good requests from bad requests"

> But also, the geolocation API requires explicit user consent.

Push notifications also prompt for user consent. Watch me pop up a request "Accept my push notifications from spacexlottery.com for a chance to win 1000 DOGE from Elon Musk!" and see how many acceptances I get. And that's the most trivial idea that comes to mind - a real gray or black hat would come up with a dozen more plausible options in 30 seconds, and a dozen ways to exploit access.

> But I'll ask again (and this is really my main beef with all this): why is this totally fine for native apps but not for web apps?

Because if I pull this with a native app, I'll get my app (and maybe my developer account) banned, probably sooner than later (and even so there's still a ton of scam/clone apps on app stores, because the reward is much greater than cost, and real black hats don't care about getting their accounts banned all that much).

If I pull this with a web app, there's nothing to ban... maybe a domain name, but those are infinitely available.

> So associate push notifications with a specific account in some way, similarly to how native apps work.

Sure, and...

1. What account do web developers use for sending notifications to Chrome, Mozilla, Opera, Konqueror, Ladybird users if they want to implement the notifications spec?

2. Is this a free developer account? Then there's no more friction than having no account.

3. Is this a paid developer account? I can just imagine the uproar :)

> My personal opinion - as I mentioned previous - is that it's because Apple (and Google, to a lesser extent) want to maintain as much control over the mobile app market as possible.

Fair enough opinion to hold, for sure. But, you know, companies are made of people, and people who work on things like browsers or new specs like this tend to be idealistic, I would suspect.

It's easy to see the world as a place full of evil bastards (and often enough it is). Even so, I'd say tech / open source / open standards is something that is a great achievement of humanity, which wouldn't exist without people wanting to help each other and fight for a better future. And often times, the people building these things do need to also consider the fact that yes, the internet _is_ also full of evil bastards who will gladly abuse the things they build against every single user.

> Thanks for engaging in good faith and for the detailed response (I didn't downvote any of your posts fwiw).

And you as well!

> I think you're ignoring the fact that running it for PWA's requires spinning up the entire browser engine in the background to run the ServiceWorker. That's considerably heavier than the minimal amount of native code required for a native app's notification extension. It's not the same cost/benefit calculation.

Is it "considerably heavier", though? And to what extent? I keep seeing this argument thrown around, but without any real numbers or data to back it up.

And I'm not sure what is meant exactly by "entire browser engine" (definitions vary), but you certainly don't need to spin up all the resources associated with a full-fledged browser. And much of the resources involved can be shared across many service workers and web apps.

> Ok, but you're handwaving any potential privacy/energy issues away out of hand, and suggesting they are simply a smoke screen, and any and all discussion that I am sure went on over the course of arguments over the W3C spec as a nefarious cover. Again... from that point of view, I don't understand why you think anybody would even bother defining and implementing _any_ of this, if that was the goal?

I don't mean to hand-wave them away at all. Of course these issues exist. But they also exist in native apps. For some reason they can be addressed and mitigated there, but they can't be for web apps?

> Right, you can't speak to it because it's too vaguely defined - so how can a computer universally and accurately judge the same thing without a precise definition?

I'm not saying it _isn't_ defined (or definable) _at all_. Just that this blog post doesn't define it or mention anything about the specific privacy issues.

> And, unless I am mistaken, there IS no automatic heuristic for native apps either.

I was referring to "energy consumption" heuristics, not privacy heuristics. Another commenter (afavour) mentioned that the UNNotificationServiceExtension has "very strict resource and CPU limits" that will kill a background process that exceeds them. That's entirely possible for a web app.

> My point is there is no way to just handwave the complexity away with "there should be a magic heuristic that can distinguish good requests from bad requests"

Again, I'm saying heuristics exists for native apps (as I mentioned above) and they can be applied to web apps as well.

And there's already heuristics in place for some "bad actions", as mentioned in the blog post: "if an event handler doesn’t show the user visible notification for any reason we revoke its push subscription".

They're certainly not all-encompassing, but they can certainly address "energy" concerns and some subset of bad actors.

> Push notifications also prompt for user consent. Watch me pop up a request "Accept my push notifications from spacexlottery.com for a chance to win 1000 DOGE from Elon Musk!"[...]

So you're suggesting that you can "trick" the user into giving permission? Native apps can (and do!) do this as well. So I'm not sure how this is any different for web apps.

> If I pull this with a web app, there's nothing to ban... maybe a domain name, but those are infinitely available.

But changing the domain name that would require the user to continually "reinstall" the web app over and over with each new domain, and re-approve push notifications for those domains each time. So I think banning domain names would actually be quite effective.

> But, you know, companies are made of people, and people who work on things like browsers or new specs like this tend to be idealistic, I would suspect.

Yes, but the things they work on are often limited in scope by management, which sometimes want to maintain monopolies over certain aspects of their products. This isn't some conspiracy theory - we actively see Apple and Google doing this all over the place. Forcing all payments through their platform is a perfect example. I'm sure many of the folks that work on these things would love to open up payments and allow people to install apps not gated by Apple. But that doesn't mean they can go ahead and unilaterally do that.

> It's easy to see the world as a place full of evil bastards (and often enough it is). Even so [...]

Well this I 100% agree with. But that's never stopped us from making progress before.

That's not even a remotely good takeaway from this. The paper is specifically focused on the "yellowish nodules", ultimately diagnosed as xanthelasma. It's not meant to be a thorough assessment of the guy's health. It doesn't imply anything about other ailments or lack thereof.