I thought WebOS looked great and thought it was the only real chance we ever had for a 3 platform. Much of the UI we take for granted in mobile devices today came from WebOS (such as card based app switching and swiping to close). I would have loved to see what it could become, rather than relegating it to TVs. iOS wasn't what it is today back then. It was still pretty new itself, and lacking what most would say are very basic features today.
I often wonder what HP would look like today had Léo Apotheker not been such an awful fit. The damage 1 person can do in less than a year is astonishing. He even proposed selling off the PC division. WebOS was a fairly new acquisition and very well could have been the future, but he couldn't see any vision outside of software with his background. HP was built on hardware, they did't need to pivot that hard. It seems the stockholders agreed.
I think there is another side to this that was briefly mentioned in passing.
When people adopt these identities, it often comes with a community. In an increasingly lonely world, these identities are a fast track to a feeling of belonging. To give up the identity is to give up the community and be cast back out into the wilderness alone.
Since these communities are only held together by these shared identities, they tend to be rigid and fragile… especially online where people are often more one-dimensional.
I’m not sure what it does, but if you scroll all the way down in the app, you can report an issue, if the current conditions you’re seeing don’t match the forecast.
In many cases, it may be to fulfill rules associated with PCIDSS requirements, even if the company never sees the credit card. This all originates from consultants, and the consultants are engaged in security theater.
On the side of things, the risk of never needing your password is people tend to forget it.
Just the other week I was helping someone setup a TV and they thought they didn’t have an Amazon login, because they never needed to login. This was a Prime member.
1Password defaults to having users reauthenticate every 2 weeks. I do find this a bit annoying, but I find the occasional reminder of my password to be a necessity evil. Even doing it every 2 weeks for years, there are some days I have trouble bringing it to the front of my mind. And that would mean a hidden piece of paper somewhere with the password written down in case it’s forgotten. As I get older I should accept the idea that I should have these emergency systems in place if my mind does go, but it makes me uncomfortable.
It's a good point on password usability. Signal app periodically prompts you for the encryption PIN to make sure you don't forget it.
I think this should be handled out of band of the login process. Similar to "is xxx still your phone number?" -- companies could do periodic password hygiene and freshness checks.
Context matters. Companies forget that people are trying to get something important done, and blocking them for other attention is a huge frustration.
> Signal app periodically prompts you for the encryption PIN to make sure you don't forget it.
At least Signal does not block the app until you enter the PIN. WhatsApp forces you to enter it before you can reach your messages, which not only is annoying when you're in a hurry, but also forces you to type the PIN even when you're in a place where it might be seen by someone else.
On the other hand, on Signal it's possible to leave the warning forever at the bottom of the screen without acknowledging it and typing the PIN, which kind of defeats its purpose.
Apps need to treat these experiences more critically. I had a similar forced re-auth with Gaia when i was offline, losing my maps.
So here I am, lost, trying to find my way using a downloaded map, and the app won't let me in.
These are no longer casual entertainment experiences we are dealing with. Many of these apps are central to carrying on with life. And they are introducing new and unanticipated failure modes.
Our work SSO is set to 12/24 hours in most places which seems like a decent compromise. Auth once a day
In a corporate environment, ideally your workstation password is tied to SSO and you have a short but reasonable lockscreen timeout where you need to re-type your password.
Was there a period where it was good? I tried in back around 2001 or 2002 and it produced a mess. I swore it off and figured it wouldn’t be around long. Here we are over 20 years later hearing that it’s too error-ridden to use.
These days something like MusicBrainz is effectively a legacy system. So few people buy CDs anymore that there's not a lot of interest in maintaining it. It's fairly hard to even find a computer with an optical disk reader these days, especially if you are looking at laptops.
> I'm sure phones are just as stimulating for some.
This is one of my big objections do 2FA. My work has been pushing it hard, and from a security perspective, I get it. However, it’s all via an Authenticator app on the phone. We can no longer set down our phones and simply work. To start working, and periodically throughout the day, we are now forced to pickup our phones to authenticate. This invites the chance to see other notifications, check and app quickly, or more generally, break flow as we have to switch to another device and back again.
You should try a CLI-based workflow for 2FA. As long as you can exfiltrate the secret (and you often can by pretending you can't scan QR codes), then you can use oathtool to generate passcodes.
1. use 'pass' to save the secret: 'pass edit work.secret' <enter it and quit>
2. use oathtool to generate 2fa given a secret:
'
#!/bin/bash
oathtool -b --totp "`pass show $1.secret`" >&1
'
use it like '2fa work'
If you have 'xsel' you can even do
'oathtool -b --totp "`pass show $1.secret`" | xsel -ib'
Even if you only have the QR code, you can download the image or screenshot it and then extract the secret without ever having to use a smartphone by using zbarimg and then manually extracting the secret from the URI:
If you have some 2FA that you need to enter 10 times per day, then you can also add a global shortcut to automatically paste it. Of course, this undermines the "second device" security. Some PC password managers also support 2FA, e.g. https://github.com/paolostivanin/OTPClient ( sudo apt install otpclient )
Works great if you have xfce4-screenshooter, gxmessage, and zbarimg installed. It allows you to draw a box around a screen region, screenshots it, decodes it via zbarimg, and pipes the output into a dialog box with copyable text.
Heh, I use pass like this; but it's on my (Pine)Phone, so it doesn't solve the parent's original problem ;-)
Although the nice thing about CLI workflows is that I can easily run it by SSHing into my phone (just make sure you set up GPG so the passphrase prompt will appear in your terminal, and not as a popup on the phone!)
My company also uses MS auth + 2fa for everything. Even signing into corporate G-suite :-). But I do not like the Microsoft Authenticator - I previously had issues where it would not show the number - and I was able to switch to a different TOTP provider. It’s a bit buried in the menus but possible
In my union contract we have language that requires the employer to provide us with a hardware 2FA token for just this reason. I and some of my coworkers don't use smartphones, and we didn't want to be obligated to use one for work.
"So long as [employer's] access management vendor... supports the use of physical two-factor authentication devices (for example, a YubiKey), [employer] shall make such devices available to Employees upon their submission of a request for the device."
I've worked in places that wanted to push cell phone apps on the team for auth and we also pushed for hardware tokens. It worked extremely well. The concerns we had were mainly centered on privacy since the app wanted location/camera access and apps can (or at least at the time could) get a ton of data from your device without requesting any permission at all like getting a list of every app you have installed, or data from sensors like the accelerometer, gyroscope, compass, barometer, thermometer, etc.
I'm old enough to have lived through the era of standalone authenticators. The downsides of that approach are also numerous.
I understand where you're coming from though, and I think this is where OS features like Focus Modes come into play.
When I'm in a "Work" mode, I literally don't see notifications from most of my apps. They don't show up in the notification center, or on app icon badges, or anywhere.
This takes a few minutes to set up, but once it's in place, it's fantastic. I also do this for other aspects of my life: Photography, Research, etc. When I'm in those modes, I don't want to see anything except for the apps that are specific to what I'm doing. It's worth the effort of setting this up IMO, and extends far beyond just work.
Hmm. I wonder if there would be a market for a super simple TOTP authentication device with an e-paper display. Kind of like those RSA tokens with the LCDs, but more modern and able to hold any number of TOTP credentials.
Getting the credentials loaded could be a bit of a pain without a camera for QR code scanning. Easiest solution would be via Bluetooth to a companion app, which you would probably want anyway for periodic time sync (likely wouldn't be worth it to embed a GNSS receiver just to update the time).
Probably be a pretty small market, but as a niche Kickstarter device? I could see a small but loyal customer base.
Sounds like a job for a second phone, one which you'd just be extra careful to only use for one purpose. It can be cheap as balls, but it will have a QR-compatible camera and whatever else we may have come to expect from such a device. :)
Make sure your GNSS receiver supports OSNMA, and be _extremely_ trusting of your battery-backed RTC and profoundly skeptical of time jumps over a certain magnitude.
GNSS spoofing is trivial now and it's an extremely useful way to manipulate a target device's idea of time, which breaks all sorts of things. (SSL certificate validity periods...)
I would love this, but only if it also successfully implemented a few disparate authentication protocols that essentially do the same things (prove identity) but are regrettably proprietary - like the de facto standard electronic ID in Sweden, BankID.
Yubikey does TOTP on-board, but you need to connect it to a phone or computer (no display or on-board power). It solves a different problem, where you want to have your TOTP credentials on a tamper resistant hardware security module. It doesn't solve the "don't want to carry around a phone for TOTP" problem.
This doesnt make sense. If you need a 2FA code then you are obviously using some device like a laptop already. Yubikey totally solves the "need a second personal device" problem.
they exist, in my country they are available as alternative to smartphone apps for identity auth. (ie you can choose between android, iphone, and TOTP LCD device.)
Have you tried a smart watch? The Duo 2FA app lets you add an arbitrary TFA code based authenticator with same QR code Google Authenticator supports and generate those from their Apple WatchOS [0] or Android WearOS apps. I have used it successfully for years, it's a huge reason I got an Apple Watch in fact. Now you'll have to configure your watch with a "work" focus mode that turns off all notifications and not install any fancy apps on the watch (do those still exist?), but it can free you from your phone.
Along the same lines the Meta Wayfarer[2] smart glasses lets you take slice of life photos and videos without needing to whip out your phone. You lose a ton of quality but stay in the moment more. The AI features are getting better so eventually you'll be able to use it for basic information lookup.
Thanks for sharing a potentially useful tool but I will not use it without a lot more details about how this browser extension secures the 2FA secrets from sketchy websites/ads.
Most trusted desktop password manager apps can manage and autofill OTPs in browsers as well, e.g. KeepassXC and 1password. (If you're making the tradeoff anyway, I think you may as well use a password manager you already trust with other secrets.)
First of all, I'm not a fan of constantly needing to re-authenticate.
But for your specific problem there is a simple solution that isn't particularly expensive. Buy a new phone. Install 2FA on it, and don't install anything else.
I imagine you've considered it already, but maybe your work would be willing to put the 2FA secret into something like 1Password, which you could access on your computer instead of your phone.
Defeats the purpose of 2FA though. I'd argue a cheap 2FA-only phone would be good, if they're struggling to touch their real phone without being consumed by distractions.
Isn't that just remembering two passwords instead of one? And isn't two passwords instead of one basically the same as remembering one very long password?
For that matter, how do they prevent you from using the same password for both?
I posted another comment explaining why 1Password Vault with both a password and a OTP code is still secure, but in short it does not defeat the purpose. Your vault's are protected and in the situation where someone gets access to your vault it's most likely to be full access to your computer at which point they have other viable methods to get access to a specific service you use.
No the two factors are something you have and something you know. Not something you have and another thing you have. In this case decrypting the vault requires two factors.
In my view the factors are attach vectors. If i wrote both my token and my pass down on a single sticky note, it's 1FA. If i have them on two stickies stored in two locations, it's 2FA.
Though i have no idea, that's just how i internalized it over the years. In your 1Pass example, it's a single attack vector (the password of my 1pass) to compromising both the token and the password of the product/server/thing.
In the spirit of the idea, it would be the attack vector imo. So behind locked doors, buildings, safes, etc.
Eg a hacker can access my computer, even have a clipboard/keylogger on my machine, and have a difficult finding my token if it's on my phone. They need to attack my phone and my computer.
Having them both in your unlocked 1Password vault means if someone walks by your computer they can access your account. A single location with both of your "2FA". If they had a keylogger installed on your machine, they only need your single 1Pass password to breach your "2FA".
Granted i imagine that a Phone TOTP would still be a concern with a keylogger on your PC, since you still enter it on your compromised machine. Still more difficult than the having the totp key though, of course.
I carried 2 phones for many years. It was more trouble than it’s worth. Especially these days. Working from home, my only work use of the phone is for the Authenticator app.
If it's Authenticator you can use bitwarden from your browser, that's what I do. If you're using a custom app or something different then yeah it's annoying
I see some evidence that yubikeys are used somewhere in the organization, but not sure where or how.
The only information we were sent to get this all setup was specifically for a phone. The portal that exists to add devices only appears to support phones.
I have a co-worker who simply tried to use Authy instead of MS Authenticator and it didn’t work. There is a lot of bureaucracy that typically makes it not worth the fight.
I use MS Authenticator for work too. It doesn't do standard TOTP, at least not for Entra. The QR codes don't contain the secret. IDK that anyone has been able to exfiltrate a secret and generate codes with a third party app.
I personally use an Android emulator on my laptop, which achieves the same goal. It saves and restores state automatically for quick startup.
Ever since I disabled all the notifications on my phone my life has been happier. It won't work for everyone (50% of the time it doesn't even work for me), but I can't help but write this anecdote here.
1Password can be your 2fa and autofill those fields. It has a built in scanner which will look at your screen and read the QR code on the screen (no separate device needed).
Two Factor doesn't mean 2 devices.
Two factor generally has been thought of as "something you know, and something you have."
Let's do a quick threat model on putting both passwords and MFA tokens in a 1password vault.
1Password employees a recovery key + password login by default, and logging into a vault requires you to either have a device with the encrypted vault on it and your password, or have knowledge of your password and knowledge of your recovery key (normally in a file which makes it something you have) essentially traditional 2fa needed to log into a new device.
If someone steals your phone with 1password installed - they need your 1password to be able to access your credentials on the physical device. At that point they already have both your factors - your phone (have) and your password (know) - still protected by 2fa.
If someone manages to fully root your computer, they could wait until you unlock your vault and then extract your credentials. However, if you use traditional 2fa on a separate device - then they can just wait until you log into the target app, and then ride your session and get the same level of access to the target. While there may be a small difference in level of effort or how long it takes, the same access level is possible, and the requirements are that they have very privileged access to your operating system. Someone rooting the device that you login to services is grants them "single factor" access to your services when you access them.
There is some subtle differences between these, but except for situations where you have very high privileged requirements, at which point you should be using yubikeys or standalone MFA devices, using 1Password with OTP and password is very comparable to using a separate device for MFA.
I'm a previous red teamer and currently a blue teamer.
Even doing nothing beyond the authentication, it is still requiring task switching, changes devices, waiting for codes, entering them, switching back. It’s very disruptive to any type of flow state.
While this seems like a lot, in some ways this is what user's expect. Push notifications should be coming all the time, assuming the system is on. Most users expect various maintenance services to run when the system idle so it doesn't interfere with their active use of the system. When users open apps like Weather (or view a widget), they expect it to already be up to date without having to manually refresh or wait for data to load when the app launches.
I'm sure some fat can be trimmed, and it may not all be user-centric, but a lot of this had to do with the expectations users have these days with the data being always up to date, instantly available, and proactive about alerting them to things they may want to know about, like rain coming to your area in 30 minutes.
One of my big pet peeves is when I pick up my phone in the morning, go to open an app, and it starts updating, so I need to wait for the download/install. It just had 8 hours on a charger to do that, and instead it seems to wait until it's taken off the charger and unlocked. With auto-updates on, I'd much rather this happen when placed on the charger and inactive, than actively in use and off the charger. The same can be said for a lot of things on the desktop.
This ends up mostly being a question of transparency and user control. Which then becomes a question of how much time/money to they invest in features for 1% of users? Now how much time do they invest in those same features when the 99% will stumble in there, turn a bunch of stuff off, then call support and ask why their weather widget isn't updating?
The article, then again, specifically talks also about telemetry.
The parent commenter conveniently chose to ignore them because of the Apple reality distortion field.
> fbs.smoot.apple.com - for crash reports, analytics, or user feedback.
> Which then becomes a question of how much time/money to they invest in features for 1% of users? Now how much time do they invest in those same features when the 99% will stumble in there, turn a bunch of stuff off, then call support and ask why their weather widget isn't updating?
The features I was referring to would be a control panel to list all the various remote calls to let uses micromanage what calls they wanted and which ones they didn’t.
Inside of those settings could be options to enable/disable telemetry, sure. But also push notifications, weather updates, virus definition updates, etc.
That's how it should be if all was fair, I feel like what we have here is a "dark pattern" whereby keeping all the telemetries opaque ... enables one to keep around the nasty sort of telemetry the company very much wishes to remain opaque.
This is a very valid criticism of my post and many that group "opinions" as if they come from a single source.
Here, the top-voted comment is OK with Apple software phoning home, but there's no evidence they are not equally OK with Microsoft software phoning home, so I'm contrasting this popular opinion with another popular opinion elsewhere.
Here's one example from a different user, where Microsoft is described as "the big daddy of spyware."
You don't see them if you're already paying for all Apple services.
But otherwise, you get constantly nagged to get iCloud and also sometimes for their media and gaming subscriptions
Finally, what people for some reason ignore: Apple has been an advertisement company ever since their app store became the majority share of their revenue.
51% are iPhone sales
9% are wearables and home device sales
8% are Mac sales
7% are iPad sales
A portion of the 25% that make up services and subscriptions is advertising, in addition to Apple Music, iCloud, Google’s search default payment (20B/yr), etc.
Apple makes less than 5% of its revenue from advertising
Oof, I meant to write "a majority share", not the.
I still believe that to be true, as you're splitting the advertisement revenue - in my opinion, all app store revenue is related to their advertisement business.
From my perspective, only counting the money that went into the advert itself is misleading, as the store itself is what the adverts are shown on.
If it was a more general advertisement network I'd agree with your splitting though.
I can see where you're coming from, but I still feel like you might be putting too much trust into how apple splits their revenue in documents as they're provided to the public.
I'm not saying that the numbers are false, but apple can ultimately freely choose how to categorize their revenue itself.
From my point of view, their advertising revenue inherently cannot be split from their app store revenue.
It's akin to me saying "I've only spent $50 on groceries yesterday", but omit that the actual cost was $100 because of added fees and taxes.
It's still technically correct, and a bookkeeper will categorize it as such, but it also incredibly misleading.
I hold that opinion because in the apple ecosystem, the customer journey doesn't end with the advertisement. Every successful capture inevitably ends with more revenue via their 30% cut.
And btw, I'm technically a shareholder too - though only in the low thousands (value, not #), so prolly a lot less then you ( • ‿ • )
I'd consider that a majority share, or would you say the term should only apply if it's over 50%? I considered it to be a majority share because it's a significant chunk of the total revenue and not just a minor footnote, but looking back, "a significant amount" would've probably been better
Plus, the ads for Apple are like “buy our cloud storage solution” and the ads for MS are like “10 foods to make you SEXY this summer!”
I’m not a fan of either, but one is significantly worse than the other
I guess you didn't read the article then, there are entries for telemetry. He even helpfully listed the official use case next to the domain name that was accessed.
You made the claim that apple didn't make any telemetry requests in response to someone pointing out the double standard for Apple.
Yes the person further up in this thread lists features other then telemetry, but that's literally the double standard. It's also did telemetry, just like windows does. Did you unironically think windows phones home only for telemetry, and not for various features too?
Because the article you're commenting on lists telemetry requests.
Honestly I would say “working as expected” for like 99% of Microsoft’s telemetry. I think the only difference is that I fucking hate hate hate OneDrive and so I’m gonna be more upset about the fact that Windows uses it. iCloud does not bother me so I don’t complain about it.
Apple has been involved in all the same government spying programs as Microsoft. They do not offer any services or products with E2E encryption that they do not control the key too.
It is not. It is real E2E. Or at least, here is my evidence (and before you balk at a chatgpt link, the links to the sources are also in there). What do you have?
AFAIK, if you can't get a previous device to authenticate your new device, you will indeed lose your chat history. However, I have several devices that can always authenticate for new ones, so I can't verify this empirically.
As the other person stated, in theory yes, but in practice, if you are an "Apple ecosystem" participant, you usually have another Apple device available that you can auth on.
No Apple can unlock your phone with the master key they used to generate your phone hardware enclave key. This is how the FBI has pressured them in the past to unlock devices.
The exact section is "Root Cryptographic Keys," here is the key passage:
```
A randomly generated UID is fused into the SoC at manufacturing time. Starting with A9 SoCs, the UID is generated by the Secure Enclave TRNG during manufacturing and written to the fuses using a software process that runs entirely in the Secure Enclave. This process protects the UID from being visible outside the device during manufacturing and therefore isn’t available for access or storage by Apple or any of its suppliers.
```
> They do not offer any services or products with E2E encryption that they do not control the key too.
Are you saying that Apple still has the keys when Advanced Data Protection is turned on? And has access to the covered data even though they say the keys are only on the trusted devices?
> They do not offer any services or products with E2E encryption that they do not control the key too.
That’s way off the mark from reality. You can look at Advanced Data Protection. It’s not enabled by default for the sake of convenience, but it’s an option available to the users.
I don't have a story but Little Snitch is the kind of tool most corporate users don't need, but that many malicious actors love to use. Sort of like running nmap on your computer, yeah there are legitimate reasons to do so, but you will get a call from IT if you try it.
I jokingly told a coworker to try nmap when he was trying to figure out a port to use for something legitimate. He was on the phone with the security team seemingly within 90 seconds. I was actually pretty impressed.
Apple ships to satisfy the 80%. 3rd party devs generally fill the needs of the 20% in various ways.
This is no different with Linux. How many Linux users use a desktop environment as-is without any plugins or tweaks? How many Arch users don’t have a single package from the AUR?
There are tools like Little Snitch on macOS to monitor and block all kind of network traffic.
The problem is that you have to tweak it the wrong way. Products you buy should not invade your privacy by default.
Note that this holds for many other products too. So if you don't mind Apple invading your privacy, you should not complain about Meta, Google, your car, etc.
Should push really be going through Apple on a laptop? I kind of understand it on a phone (although users should be able to switch push providers if they want to eg use open source software that apple won't allow) but on a Laptop there's no reason to not just have the application manage the toasts/sockets itself.
Oh it's much more than that. Lots of 3rd party software vendors making macOS-only apps use Apple's CloudKit for state sync, all that data is stored by Apple.
Regular users don’t think of push notifications as something that needs to go through some central server owned by Apple. If Alice sends Bob a message, shouldn’t that require only their phones to communicate with one another, without some third party?
This would mean, that every app notification needs to contact a different server. Lets say you have 20 Apps that send notifications. 20 different connections would work in the background to fetch updates instead of 1.
Privacy vise this is an issue and the reason that messangers like signal and matrix would use their own services on android. However this reduced battery runtime by a good margin and android and ios get more aggressiv at killing background tasks each os iteration.
To make things worse, push notifications for matrix and signal where unrealiable, because manufacturers like oneplus, oppo and some others where killing all the background tasks against specification to win the influencer battery tests.
In the Alice and Bob scenario, what happens if Bob’s phone is off or doesn’t have a single when Alice sends the message? Does the message just get dropped? Does Alice’s phone keep trying forever to send the message until it gets a response back that Bob got it? How long does it try before giving up? What happens if Alice and Bob are far apart and the phones can’t directly talk, how does Alice in LA send a message to Bob in NY without a 3rd party to relay the message?
If regular users don’t think about these things, it’s because they’ve never thought about these ideas at all. If they did, and they are able to think, they should come to the conclusion that a 3rd party is necessary in some form.
Is there mobile push technology which is actually fundamentally push, all the way down to the transport layer? Like open socket, listening for incoming packets only, no notifications-> no traffic?
I was under the impression it was all polling if you go down far enough, but at least because of central registration the phone only needs to poll one single pubsub service instead of a separate server per subscription.
Yes, sms is "actually push" all the way down to the transport layer.
As far as I know, this is still what push notifications are built upon for an idle/sleeping device.
Carrier infrastructure knows which tower you last connected to, instructs that specific tower to broadcast a message telling your phone to wake up and fetch the remaining 80% of the notification content (the sms bit is usually just enough for your device to learn the UUIDs of the notifications)
> As far as I know, this is still what push notifications are built upon for an idle/sleeping device.
I thought so too, but can't find any evidence for it anymore, all I can find is mentions of the phone keeping a TCP connection alive and then some device driver level tweaks to make that power efficient. I think the older GSM-specific wakeup mechanism might have died when iPhones stopped being carrier-specific.
iOS or Android push notifications (can) use SMS for notifying the client that a new message is available ? That’s lovely. Do you have any links or any keywords to find more ? All I can find online is that iOS uses TCP (XMPP in fact :o TIL. )
It wasn't really SMS, it was another message type riding on top of the same lower-level protocol called SS7. But it seems that's no longer in use and it's all just TCP/IP now.
(Said differently, the radio firmware got good enough that it doesn't need a special "wake up" packet anymore, it can recognize a packet to itself in a low power state.)
No, Apple push cannot use SMS/Text. You need a cell modem to have working SMS/Text. Except the phone itself, most of the devices have no cell modem. Then Apple would need to keep a directory of all the cell phone numbers, because that is the way how the cell modem is addressed.
Both Apple and Google mobile notifications are long-lived TCP/IP sockets where the server writes bytes to the stream when it wants to wake up the phone.
The TCP/IP and protocol-specific handshake is started by the phone, but then the phone just waits to receive data. That counts as fundamentally push, all the way down to the transport layer.
In theory you could do that, that's how I had push set up on my Pinephone. Often the ssh connection that was used for it was still live after rtcwake came back up. It's kind of a moot point since the WiFi radio couldn't wake the CPU up on its own though.
> Is there mobile push technology which is actually fundamentally push, all the way down to the transport layer? Like open socket, listening for incoming packets only, no notifications-> no traffic?
That’s the end-to-end principle. Each host on the Internet is fully capable of listening on a socket and doing whatever its owner wants it to do.
The issue is when firewalls prevent incoming traffic, and when NAT prevents a host from even being on the internet. There’s not really a good reason for NAT with IPv6, but there are some good reasons for firewalls. They mostly boil down to human imperfection. The developers of one’s OS and software are imperfect, so the fact that a laptop sitting in Dallas can be probed by other computers in Frankfurt or Maseru thousands of times a second is an issue: a single bug will make one’s computer, and all its data, vulnerable. And users are imperfect, too. One might misconfigure one’s computer, and accidentally expose a service to the world.
There could be some approaches to mitigate these issues, but we’re probably stuck with firewalls forever. Which is really kind of sad.
Any push service works this way. The client contacts the server to be updated. The server gives a no data or a data response. The server cannot magically contact the client.
Well, the server could contact the client. The client would just need to be listening on a port/address that the server knows. Which is completely infeasible for 99.99% of end user devices.
The majority of end user devices are run from within private networks protected from the Internet. If you have connected to your cell provider, then in the majority the cell providers are running their own private networks. For one reason the IPv4 address space is limited as such, that there are no other possibilities. IPv4 is still the important protocol compared to IPv6. Second, it is that those providers, want to protect you. Some don't even allow cross communication.
If you devices are connected with Wifi, then there is the very same situation. There is almost no campus, commercial, and home network, that gives you public route-able IP addresses. I only know a view deployments were you get public route-able IP addresses at conferences like C3, EMF, and alike.
tl/dr: No, the end user devices is not easily to reach without additional infrastructure.
I think this is one of those many cases where how the technology works doesn't match the actual meaning of the English word, but for whatever reason the word has stuck.
For better or worse, a lot of things on the Internet now assume that only "servers" can accept incoming connections, and therefore anything that needs to be "sent" to clients needs to be done by making the client poll a server over and over. True P2P apps (with no intermediary server) are pretty rare now, for a variety of reasons: some good reasons, some stupid reasons.
I ran into a bug at work where an app would crash and I’d get prompted to submit a report. It would happen several times per day. I often question how many bug reports I should submit for the same issue, and how detailed I need to be with each one, if the information has already been sent. I probably sent at least 40, hoping they’d fix it just so they wouldn’t have to hear from me anymore. Some were professional and helpful, others were mostly empty other than the log they generated, and others were a bit unhinged where I simply vented my frustration over all the crashes. I don’t think it was ever fixed, I just eventually didn’t need that software anymore.
I submitted a bug report on Things To Get Me (an Amazon wishlist alternative) on a holiday weekend, fully not expecting to hear anything until at least Monday. It wasn’t anything too major. Within the hour I not only had a response, but a change was pushed to prod after a little back and forth with the developer.
A couple years ago I signed up for write.as and the founder/ceo reached out to have video chat just to see how things were going or if there was anything I’d want to see in the future.
I often wonder what HP would look like today had Léo Apotheker not been such an awful fit. The damage 1 person can do in less than a year is astonishing. He even proposed selling off the PC division. WebOS was a fairly new acquisition and very well could have been the future, but he couldn't see any vision outside of software with his background. HP was built on hardware, they did't need to pivot that hard. It seems the stockholders agreed.
reply