> A rationale for this is presented in Appendix A Strength of Memorized Secrets.
The relevant part of which reads:
> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...
>
> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.
I'm surprised Apple supports custom email domains to any extent. Apple is a consumer electronics company. Hosted email on custom domains is very distinctly not a typical consumer behavior.
It fits in great with the privacy narrative Apple has been pushing for and marketing for a while now. With their announcement of focusing on services, I think it makes perfect sense. Definitely not an easy problem for them to tackle, especially with what must be decades of legacy systems and various relays (Mac.com, Me.com, iCloud.com, ...).
For as long as iCloud existed, people have been clamoring for custom domains. I think it might have been possible back in the iTools or MobileMe days? Maybe I'm mis-remembering.
Me, I've experimented with migrating some of my domains from self-hosted to iCloud+, simply for the ease of management and reducing the headache from SPF, DKIM, DMARC, etc. It turns out I have a spurious DNS record that was causing all my headaches, which I had forgotten to remove from older experiments, and I didn't need to migrate to solve this.
In either case, it's a nice convenience feature. Despite the trend, and the HN-think, Apple DOES do things for power-users sometimes.
I suspect it is because Google suite threatens Apple’s office web offering.
Offering custom domains for personal can link up to office documents and this can make its way into business use.
For small businesses already standardizing on Mac hardware, it’s natural they should want to get the privacy and in-ecosystem utility of an apple version of Gsuite.
They have been moving to services, but all of their other services are distinctly mass consumer oriented; e.g. TV+, Music streaming, Fitness+ videos, Arcade, News+, iCloud photo backup, Card
Could you not argue the same thing for almost any code used by almost any piece of software closer to the metal?
e.g. someone manages to slip malicious code into Chrome/Chromium which eventually makes its way out to every Electron app/most browsers, or something gets injected into Windows/macOS/Linux, etc.
>Could you not argue the same thing for almost any code used by almost any piece of software closer to the metal?
You could. But if you haven't trusted all/most of your passwords to any single app, you wont have a problem with them being exposed when that particular piece of software is compromised.
Even if someone compromises your OS itself, you'll only lose the passwords you typed in while you were using it compromised. And that's if it does captures thoses, and if it sends them to some remote endpoint, and if it's not caught soon, and so on.
With a password manager compromised, on the other hand, you could loose anything you've put it in, all at once.
The likelihood of malicious code making its way into a browser extension in production is way, WAY higher than it is for something like Chrome or Windows.
On one hand, yes software supply chain vulns are getting difficult to maintain conceptually total coverage of while also maintaining a pleasant environment for developers to productive in.
On the other hand, yes there eventually is a trust point somewhere. A spiral of upstream what-ifs isn't productive IMO, I agree.
I _bought_ 1P way before it was a service. I continued to pay for upgrades. I don't want a subscription, and I don't want to be forced into their black-box syncing. I've been migrating to the free software pass [0].
There is no reason for it to be a web service. Why should I pay for their cloud when I already have access to storage on three clouds, two of which they used to support, but have now removed from their software, just so they can force me to pay them every month? Oh man, it makes me mad.
In NYC at least, electric supply charges are distinct line items from electric delivery charges. Consumers do have the option of choosing who supplies their electricity (e.g. namely if you want to buy your electricity from a green source). But the local monopoly is always entitled to charge you for the service of actually delivering said electricity to you.
Both charges fluctuate from month to month. When I still lived in Indiana, the local monopoly lumped together supply and delivery charges into a single line item which, interestingly enough, was significantly lower than what I pay for just delivery now.
The following prices are for roughly April.
NYC (ConEd) delivery charge is ~$18/month + ~$0.123/kWh. Supply is usually something like ~$0.115/kWh.
Indiana (Duke Energy) total cost (including both supply and delivery) was ~$9/month + ~$0.115/kWh.
It's the same in California. The problem is that the delivery charges are also calculated per kWh (so, the cost of delivering a single unit of electricity to your house). But what happens when the net electricity delivered is zero?
You could argue that customers should be charged for both the electricity delivered to their house and the electricity taken away from their house, since they are using the grid and other expensive infrastructure for both. However you are now disincentivising people from installing solar and giving back their excess power.
Thanks, this is the detail I was missing. Net billing for delivery makes zero sense. I think the reasonable solution is to bill the consumption direction only.
The Switch was always sold at a profit relative to its hardware component and manufacturing costs, yet Nintendo charges 30% platform fees just like Apple (and Microsoft.) PS4 and PS5 (disc model) are currently sold at a profit, and Sony continues to charge the same platform fees.
Nintendo (like Apple) needs to recoup R&D and software development costs, and their business model is based on charging platform fees.
It's completely unsurprising that Apple's gaming handheld uses a similar walled garden/platform fee business model similar to Nintendo's.
> Note that the ASF does not pay for software development on any Apache projects; we rely on volunteers for all of our project coding work. The ASF focuses on providing the technical, legal, and community infrastructure for like-minded communities; we trust that healthy project communities will build their own software products.
I fully agree. I cannot stress how much I appreciate how Apple TV is the only mainstream video hardware that is completely ad free.
Yes it's pricey (in comparison to other video streaming hardware), but Apple doesn't try to monetize the end user and for that I will pay Apple their $179 to avoid being showered with ads by smart TV OSes, Roku, Google TV, Amazon Fire devices, etc.
I've had my Vizio TV (P55-F1, 2019 model; a mid range model) for about 2.5 years now. Image/sound quality is great. But the annoyances and overall mediocrity of the OS and its updates [0] made me just disconnect the TV from the internet and fully switch over to using an Apple TV for all consumption rather than using the native Vizio OS.
[0]: The OS is terrible and the remote randomly stops working sometimes. Sometimes the TV would take tens of seconds to turn on, but then other times it was near instant.
Every single update since I've gotten the TV seems to make the TV even slower/more laggy. There was even an update about two years back where the Youtube app's volume was inexplicably an order of magnitude lower than every other input's volume (e.g. a volume of 100/100 on the Youtube app ended up being equivalent to a volume of 10/100 for all other apps/inputs). It took Vizio 1-3 months to fix it.
Unblockable ads on the home screen and genuinely multi-hundred millisecond response times on the app launcher infuriated me.
Just don't bother with it. Disconnect the tv from the internet and get a dedicated streaming device. The apps and OS will almost certainly be better than what's on the TV
yeah I had all kinds of issues casting to the vizio smartcast thing. it's their built in chromecast implementation I guess. I had to routinely power cycle the tv, sometimes by unplugging it.
reset the tv and didn't connect it to wifi. Connected a dedicated chromecast. Works 100x better.
I'm ready to do the same thing with my Vizio. The worst part about these updates is they happen without any regard for what I'm doing.
I'll have Netflix or Hulu open. Next, the TV will update, close my app, and take me to the startup screen advertising something like "We have Apple TV now!". Or, it will update and go to a blank screen which requires me to physically power off the TV because it's stuck. The remote is useless in this case since it clearly doesn't power down, but put it into sleep mode.
Does Vizio actually make the YouTube app? Why is it Vizio's responsibility to fix? I can see YT prioritizing this app's dev time waaaaaay lower than other devices. If the stats don't justify it, no PM at a FAANG is going to let their team work it.
I think most go with Android so they don't have to think about it and can roll out quickly. I'd be willing to guess that everyone wishes they could do what Apple did, but instead just roll out crap hardware with crap software ontop of the OS they didn't make.
> A rationale for this is presented in Appendix A Strength of Memorized Secrets.
The relevant part of which reads:
> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...
>
> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.