I've been using an app on my Android called KineStop. It definitely works.
I also recently picked up an EmeTerm wristband - it's basically a mini TENS machine for you wrist. I was super skeptical, but my sister recommended it so I tried it and it absolutely helps with (though doesn't always total eliminate) nausea I get from motion sickness. I'm not entirely sure how it works, but it seems like it may have an accelerometer and use that to decide when (and at what strength/duration?) to send a mild shock.
> Better Auth checked a lot of boxes right out of the gate: high code quality,
Maybe I have high standards, but I absolutely would not describe Better Auth as having "high code quality". It has certainly been improving, but when I first looked at this project it felt really rushed and thrown together, with little automated tests. There's was virtually no logging last I looked, so there's little options to monitor what's happening. I think they've added hooks now so you can "bring your own logging", I guess. And they finally added audit logs but that's only if you use their managed services.
Having said that, I actually use Better Auth, and I'm a huge fan despite those criticisms. I love that it's open source and extendable (there's a free 3rd-party audit logging addon, actually). It's super straight-forward to implement compared with similar products (Ory Kratos, Keycloak, etc). You don't even need a separate DB if you don't want - you can have it create tables in your existing database. And it _is_ improving quickly.
I don't really think this is fair. I haven't been to SFO in years, and I'm sure it's great. But I don't think PHL is nearly as bad as some people like to make it out to be. (To be honest, I think a lot of people just like to trash Philly.)
But it really depends on the terminal, too. I can never keep track of which terminal is which (other than international), but most of them are quite nice, with nice shops, art work, and restaurants (though, at the end of the day, nearly all airport food is mediocre).
As for "Security checkpoints are spread out, PreCheck is far and no Clear". There are 5 terminals and 6 security checkpoints. They are all quite close together, so I'm not sure why you think they are spread out. Especially compared to other major airports. You can easily walk from one to another. And they all sort of get you to the same basically place once you're past security. You can easily access any terminal, regardless of which entry you used.
It's true we don't have Clear, but personally I've never found it that useful. I've used it mostly in Denver (which, to be honest, I think is way less inviting than PHL!), but Clear has never gotten me through security any faster than PreCheck would have. Often times it's been slower! And I can't remember ever waiting longer than maybe 5 or 10 minutes to get through PreCheck at PHL.
There's a lot of things I hate about PHL, but I think your particular characterizations are unfair. Maybe it's been years since you've been through?
PHL has a verion of this ("Wingmate pass") that I use pretty frequently now! If I have a friend/family flying in/out I usually get one so I can meet them at the gate. It's very nice and convenient. I just wish they would let me use my Precheck, because I have to go through the "regular" security line and sometimes it's just too long and I don't bother.
This SFO version looks a bit nicer, though. You can apply 30 days out vs PHL's 7 days. And PHL makes me choose a specific entry gate when applying. So if you show up and that gate has a long line you can't just go through another gate that has a shorter line (at least that's what they tell you - in practice I've entered through different gates without any problems).
Both PHL and SFO won't notify you whether you are approved until midnight of the day you want to enter, which I find interesting. I guess that's some sort of security feature? I've never been denied, but it could be a hassle if you don't find out until the last minute that you were denied.
When this was DarkSky, the service was solid. I don't ever remember an outage. Ever since Apple bought them it's been extremely unreliable. I regularly get random 5xx errors from them. This is the first time I know of that they've acknowledged an outage. According to their System Status (https://developer.apple.com/system-status/) it's been down for almost 3 hours now.
Oddly, this other system status page: https://www.apple.com/support/systemstatus/ seems to think everything is OK. It's not really clear to me why they have different system status pages.
Android has a "Private Space" feature. As far as I can tell it's only a single extra profile you can create, but I think you can keep it "hidden" (at least in as much as you can't tell if it's been created without unlocking it).
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.
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.
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.
> 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.
> 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.
> 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.
> 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.
> 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:
I never suggested energy consumption wasn't a concern. I said any code that runs expends energy. So to pretend it's a concern only for PWAs is silly. It's a concern for both web and native apps alike. But (as I understand from other comments) native apps get some sort of quota on iOS, while web apps don't even get that option.
> 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.
I didn't suggest an alternative because: 1) the post says it was "necessary" implying there was no other option: "the original Web Push design made this necessary to protect user privacy and battery life." But more importantly: 2) they don't go into what those privacy options _are_, exactly. 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.
> 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
This isn't any different for web. Web app push notifications also require a token that can be revoked. The article even says "if an event handler doesn’t show the user visible notification for any reason we revoke its push subscription". So they do this already.
> 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).
So associate push notifications with a specific account in some way, similarly to how native apps work.
> 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.
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?
> 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?
That's quite the straw man, considering Service Workers can't even access the geolocation API. But also, the geolocation API requires explicit user consent. 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?
> 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?)
I don't think it's "just make developer's life harder". 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. All payments go through them. They can shut down any app (ahem, competition) they please for any number of vague reasons. If web apps can be built with the same capabilities as native apps they won't be able to maintain that monopoly.
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.
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.
I'm sure declarative web push is great. But most of this post sounds to me like they are trying to justify artificially restricting web push notification functionality on the web and offer an inferior solution instead. 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. Cynically, I believe this is so they can continue to maintain full control of the app market.
There's a lot of statements that are presented as facts, when in fact they are not.
For example:
> Therefore we require push subscriptions to set the userVisibleOnly flag to true. While this can be frustrating, the original Web Push design made this necessary to protect user privacy and battery life.
Surely this wasn't the only option to "protect user privacy and battery life". Native apps can handle push subscriptions without this sort of flag. It's frustrating because it's _meant_ to be frustrating so that users prefer native apps over web apps.
> 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.
And again: this is perfectly OK for a native app to do. How is it really any different to allow web apps to do it? Because Apple doesn't get to review every app to their ever-changing standards?
At the end of the day this just further divides the native app from the web app, such that it's impossible for the latter to compete with the former.
I also recently picked up an EmeTerm wristband - it's basically a mini TENS machine for you wrist. I was super skeptical, but my sister recommended it so I tried it and it absolutely helps with (though doesn't always total eliminate) nausea I get from motion sickness. I'm not entirely sure how it works, but it seems like it may have an accelerometer and use that to decide when (and at what strength/duration?) to send a mild shock.