> Keep track of which apps had been opened every month, only pay the subscriptions for the ones I’ve opened, and allow me to set monthly limits.
That turns app icons into land-mines though.
Idk what the happy medium is, but there's gotta be something between "buy this kids game once" and "pay $13 a month until he gets sick of it," and I don't think we've quite found one that's equitable for all parties yet.
A difficulty is that making the billing time more granular could reduce the landmine factor, but also would incentivize developers to keep users in the app for longer than necessary. We’ve already seen in social media that that incentive is… quite bad.
I guess it remains to be figured out. I dunno, maybe my framing is wrong, maybe development bounties are a better ongoing revenue stream or something.
I have a pool heater and an air conditioner, and I'm running both at the same time. They're fifty feet apart, but this thought crosses my mind constantly.
The sticker on the side of the doohickey in the video really gives the whole thing a feeling of "a dude makes these by hand in his garage." I looked up "AC pool heat exchanger" and lo and behold, the same company showed up as the first result:
I ask because I find Apple's wired EarPods to be less... selective than AirPods are—by that I mean they'll pick up more background noise whereas AirPods seem to only transmit my voice—but EarPods' clarity exceeds AirPods if you grab the mic and hold it next to your mouth, which you obviously can't do with AirPods.
Unencrypted sensitive data in an email is a really bad idea. I hope they never do that.
Although what I would really like, and think is long overdue, is an extension to email that normalises encryption and sender verification. It's ridiculous that email can be spoofed like that. (The same is even more true for phone numbers.)
Indeed. We really either need email to get decent, user-friendly encryption and verification, or replace email with a new, ubiquitous, decentralized, system that has first class support for encryption.
I have a laundry list of other issues I'd like fixed in email, but I'd be happy just to get end to end encryption and sender verification.
Is it really? Who can read it today? Your email provider and theirs? Gmail won't deliver messages without TLS any more, so everyone supports it or they're effectively kicked out of email.
Well, the email providers. And that could easily include Google without you even realising.
It's true that email isn't quite as insecure as it used to be (it was once compared to shouting your message at someone and expecting them to shout it in the right direction until it reached the intended recipient), but there are still many things missing compared to other forms of direct messaging, and there's good reason why many people and organisations don't want it used to send sensitive information.
For things like financial records, I would not want plain PDF in the email. I think it needs encryption for confidentiality.
I am geeky enough to use PGP or S/MIME if they had the option, but I can definitely see how vendors would see this as too fringe with retail customers. I would not like the typical "secure email" which is nothing more than a volatile link back into yet another website.
Hmm, yeah some people feel that plain emails are not secure for sensitive information. As a result, some banks provide a "secure email" box that's usually PITA to use.
It'd be great if there's a unified API for all financial institutes to provide sensitive info (statements, tax forms etc.) and you just need to run a software tool to download them once in a while or when you need it.
> Why can’t I set up Windows or MacOS like that? I know the answer I just find the answer annoying.
I wish I still cared about this. I had intended to build an iPXE boot menu via a small web service that would act as a windows install XML template editor/selector, but I never got around to doing it after learning enough web dev to pull it off.
I built a few similar things that worked inside of WinPE, but the slowness of waiting for it to boot was always what drove me to do as much config as possible in the PXE boot menu—you can get into that in seconds versus minutes for the PE.
I used to install Windows a lot, and found a lot of tech around it to be a little too opinionated. SMS/WDS were just too legacy-leaning and Microsoft Enterprise-flavored. FOG was a little too heavy-handed (though very good). Glazier excited me but I never actually used it to determine if it has the flexibility I wanted...
But I digress. OS installs should be a lot easier and faster to accept your configuration preferences and get to work when the goal is "erase this machine and reinstall" than they are even today.
Built out a (i)PXE build system for Windows at an /old job/
It would chain load the iPXE binary from the network, then call out to a HTTP end-point with "?mac={macaddress}" so we could identify it. Then it would auto-pull from git, or generate (and push into git) a config, which would load the WinPE image over the network, and launch a powershell script. All of which would talk back to the HTTP endpoint throughout.
Because we tracked it all with a Slackbot on every execution.
Fun hack, certutil.exe has the ability to do HTTP/S requests, so we would leverage that to "live off the land", even though we could integrate any binary into the image outselves.
That was the point as I read it. Payload signature verification is a good and sometimes desirable alternative to transport encryption when the payload itself isn't secret.
Highly-cacheable resources like game and OS updates are often intentionally delivered over http as signed payloads to facilitate middlebox caching.
