The strategy that MEV bots use is not a law. It is not even defined or endorsed by Ethereum standards, and arguably is not an intended feature of the network.
You could alternatively claim that the guys defined their own protocol which addressed market inefficiency (which MEV is). Imo it's insane to claim that a trading technique you invented should have zero risk, and any losses you take are an indication of theft.
What law says this? Technically, tokens are smart contracts, basically OOP classes with both data and behavior. They also by design have public methods which are meant to be triggered by anyone on the chain. It's not at all obvious that triggering these methods in an unexpected order or with unexpected data is breaking any laws whatsoever. It's bytecode anyway, so there's no human readable EULA's or explanations on what you're allowed to do with the token.
But you're not signing EULA's in order to participate in the network. Moreover, there are no real "laws / regulations" within the network either, specifying what you are or are not allowed to do. Ethereum standards merely determine how the software is supposed to work, but even then I'm sure Ethereum devs would oppose treating their docs as an agreement (because they don't offer any warranty, licensing or attestation). Moreover, there is an express goal to have a diverse set of software clients, so even developing your own software to be interoperable with existing standards can't be constructed as "an attack".
All this to say, I just fail to say how this can be constructed as "changing the terms of the transaction". There was no legal agreement between parties and no existing precedent to treat this as a malicious attack at all.
All I see is a Wall Street establishment pulling strings in order to protect their investment, by asking for a sudden government oversight in the system that was built with the express goal of not requiring any government oversight.
Android has different security guarantees compared to desktop/server Linux. E.g. people should expect that none of the installed software can hijack the phone completely and that most damage from malware should be mitigateable by uninstalling malicious app.
There were over a dozen of 0day exploits this year alone. Some used in water hole style attacks, so not even that targeted. And these are state of the art incidents which would have pwned even users with all the updates installed.
After the patch has been pushed out, exploits become progressively cheaper so letting users to postpone security updates is a crime.
Right. Session is stored either in cookies or in Local Storage. Both get cleared when you "clean cookies". If there is no device session, next time you're trying to log in, service will ask to show the second factor (so that hacker can't steal your account through finding the password on some other website).
Firefox didn't work, because person deleted session and didn't have second factor (nor backup auth methods). Chromium worked, because it still had device session.
I'm traveling and using TOR and VPNs just like everybody else and haven't faced any issues. There most definitely is a problem with communicating security/accessibility tradeoffs to the public though, so I'm not putting blame on the op here.
It's not user agent, it's session (cookies, localStorage) that they didn't have in Firefox, but still had in Chromium. And this isn't Google specific at all.
Clueless users: "Let me enable uber-secure mode, so nobody can hack me"
Clueless users next day: "Damn, I got locked out of my account, there are no alternative email addresses for recovery, I lost Ubikey and didn't save backup codes"
Most probably they've added MFA and lost it. Devices that have been authenticated already can be used with the bare login & password, but new sessions will ask for the MFA they can't access.
Well yeah. If the recovery process is weaker than regular authentication, that's what bad guys will use for account takeover. You don't want to lose Gmail because someone bruteforced your backup code?
AFAIK, there are exactly two ways to avoid getting phished. One is using physical security keys (not implemented everywhere and we can't expect everyone in the world to buy one). The second one is checking the domain you're in.
Please, do elaborate on what other ways of phishing preventions you have in minds.
The official repair shops that Apple Repair will guide you to should never ask for the pin, afaik. There is that mode for diagnostics which you need to approve, but you don't need to provide the pin - just unlock the phone and press approve button yourself.
Note that it uncritically accepts report from 2009 which according to company was meant to be risk modeling exercise. Authors outright dismiss everything either KPL or CapGemini has to say themselves and does not even try presenting mitigations that presumably have been put in place, changes in infrastructure since 2009 and other more contemporary reports.
From the security perspective both snaps and flatpaks are preferable to dep/rpm for browsers, email clients, office suite, document viewers and other stuff that is used to parse untrusted data often (due to [wip] sandboxing and auto update).
Snap packages are better maintained (more often with direct involvement of the app developer) and generally receive updates a bit earlier than flatpak. In both cases you need to pay attention who the app maintainer is and I'd argue that in case of unknown maintaners deb/rpm packages are safer choice.
You could alternatively claim that the guys defined their own protocol which addressed market inefficiency (which MEV is). Imo it's insane to claim that a trading technique you invented should have zero risk, and any losses you take are an indication of theft.