Because it's a UK fine. The "monopoly" is driven by Apple making very good products for a long period of time and the UK putting its money almost anywhere but into people who might invent the next iPhone-like thing and make people's lives better worldwide.
Why? You probably know just how long these cases take, so it is not like all other countries are now going to do the same.
If that's the case then using their total profit seems the only proper measure. What it says is that these companies lose these cases but it's so infrequent that they can just price it in. It's a cost of doing business.
If we were to fine Tim Cook 1000$ for doing something that paid him 1M would that have the 'effect' of keeping him from doing that again?
Countries with similar laws might very well consider doing the same after reviewing the case and considering how well it matches their own situation.
Other than that I agree with you - the fine doesn't make much of a difference unless the risk becomes so significant that it effectively threatens the jobs of people not to address it, and it will only threaten jobs if it becomes more expensive to continue ignoring these laws than paying fines if/when individual countries take them to court.
Limiting it to App Store profit doesn’t make sense. The App Store is not an independent corporation (although it’d be great if some regulator forced it to be!) Apple makes the decisions about its behavior.
The Model Y has been iteratively improved since its introduction like any other product, and remains the best selling car in its class in most western markets.
This argument makes about as much sense as saying Apple hasn’t released a new phone since 2007.
That is very very variable. In the last five years, raw lithium carbonate world market prices have been swinging from $10/kg to >$70/kg and back. So right now LiFePo is getting cheaper, but if lithium explodes in price again, battery prices will rise too.
Not only have you cherry picked anecdotes to support this, but you don’t have a counter factual, e.g. maybe someone who survives until 95 on junk food would have lived until 105 on healthy food.
These fabs don’t evaporate the water though, they use it as process water, and then treat it to wastewater standards before discharging to the municipal wastewater system.
Assuming the municipality recycles their wastewater, which they would do in any drought prone region, this water will become clean water again.
I read they either dump it into a local river while monitoring it or back to water treatment plant. Some datacenters have started reusing water but for some reason using it more than once is not appealing. Definitely the biggest problem is it’s not always a closed system and dumping it into a river potentially damages the river and makes the area lose their water. A percentage of the water is also lost via evaporation.
It’s definitely not a closed system unless the water from the waste water treatment plant is pumped back upstream of the source of the municipal water which is not how most of these work.
There’s little relationship between the net income of a company and what is an appropriate bug bounty, especially a company as diversified as alphabet.
I think that perspective mostly exists amongst the chronically online. I don’t see it much in the real world.
All EVs depreciate quickly, Tesla isn’t unique in this regard.
The reason is simply that the market is currently higher income earning early adopters. That customer base is willing to pay the premium for the newest model, and upgrades quickly when newer models come out.
This results in a large of supply of 3 year old vehicles, but not much demand.
In time we’ll see used EVs depreciate at rates more similar to ICE vehicles, as mainstream buyers, who view EVs as a car rather than a tech product, enter the market.
> The reason is simply that the market is currently higher income earning early adopters.
I'm not sure this has a basis in reality. There is no supporting evidence for it.
On the contrary, there is evidence that both Musk's favorability rating[1] and Tesla's brand reputation[2][3] have nosedived over the last few years and especially after Jan 2025.
If you want to claim an income-value-market cause, you'll have to provide more compelling evidence.
Maybe you missed it, but there was a whole period in the Spring when people were in the real world protesting in front of actual Tesla dealerships. These were people like my parents, who don't even have social media, yet they were dragging themselves and their protest signs to the local Tesla dealerships every weekend. People got so mad they were setting Teslas on fire! When people are so pissed they're firebombing dealerships, you can't pretend it's just online murmurings.
A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys.
I also think client certificates is a better solution. However, it does not have to be single per-user.
For example, a service that you register an account on can issue a certificate to you; you could use it directly or you could use that certificate to issue another certificate to yourself, with a different key, and storing the private key of the original certificate on a separate computer that is not connected to the internet, making it less likely to compromise (if the certificate actually used is compromised, it could be revoked and you can issue a new one to yourself).
If the service defines an extension for the authorization granted by the certificate, then you could issue a certificate to yourself that has an extension to restrict the authorization, therefore allowing partial delegation of authorization. (Some operation would be authorized only if all of the certificates in the chain authorize that operation.)
The partial delegation of authorization can also be used to issue certificates to others, perhaps for a limited time (by setting the expiry date). For example, if one service can access another service to do some operation on your behalf, you can issue a certificate to the first service (this is one case where a client issues a certificate to a server), with the limited authorization that is required, and then that first service will use that certificate to authenticate with the second service, to do the operation.
A service that wants someone to be able to use their account from another service to log in to their own one can also do so (although usually this should not be required, since someone might not want the other service).
The private keys can optionally be passworded for additional security, and the server doesn't know nor care about this. (Passworded private keys is probably not useful for server certificates, but it is useful for client certificates.)
The use of mutual TLS authentication has other security benefit as well.
Having a single certificate makes it trivial to implement cross-website tracking. FIDO2 (and by extension Passkeys) prevent this by having a unique key for every (origin, username) combination.
Also, having a single cert shared across multiple hardware tokens is a security risk, as it becomes impossible to distinguish the tokens or revoke only a single one of them.
The vast majority of users treat their set of passkeys as a unit anyway, so there’s no scenario when a single token would need to be revoked in isolation. A breach of one passkey can only occur from breaching the password manager itself, in which case all passkeys are exposed, so there’s no security benefit to having per site passkeys.
Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
perhaps this a good moment for you to engage in some reflection and consider that perhaps some people have put more thought in to "how do we replace passwords" than you did in making a single hacker news comment?
you:
> A single per-user client certificate is a cleaner solution, without the vendor lock in problem, since there’s no need for real time synchronisation of an evolving set of passkeys.
reply:
> Having a single certificate makes it trivial to implement cross-website tracking.
you:
> Users who truly need that ability can create multiple certificates, and synchronise them as appropriate.
well, indeed! perhaps designing a system to support multiple certificates with synchronisation, so that we're not forcing ever user to be trackable by every single website, would be a good idea.
some sort of keys to enable one's passage in to a website?
this is a cancer on this website, and certainly one I'm also suffering from, despite being quite aware of it - real life things are usually pretty complicated and just because I know enough to make a random guess at a solution, it doesn't mean people who have put way thought in to the problem have done a bad job or missed by brilliant insight.
If not, you’re comparing apples to oranges.