301–310 of 365 posts
Earlier quoted context omitted.
Serious answer, don't use Safari. Use a browser that properly separates webpages into isolated processes so that this kind of cross-site read is not possible.
There’re no other browsers on iPhone. Every iPhone browser is a reskin of Safari. They’re in theory supposed to allow other browsers in the EU, but AFAIK it has not happened yet.
Earlier quoted context omitted.
> Individuals could choose a "secure" browser or browser mode that provides increased protection from such attacks or a "compatible" one that is less likely to break old websites. And then we get thousands of posts whining about Safari being broken because it is "not like Chrome" and developers moaning that their unsafe pet API is not supported. Web developers are never going to play ball.
idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browse…
I am not a web developer but I completely agree with you. To me, adding more complex points of failure in humongous piles of code that we absolutely need to run in a modern life is not a great risk assessment. It’s like we never learnt from the security issues with the JVM.
Earlier quoted context omitted.
idunno, as a professional web dev since 1998, I don't understand why Google, Apple and Mozilla are trying so hard to make the web browser like a complete OS (I technically understand why, I just think it's ridiculous). The amount of obscure APIs being added just boosts the surface area for vulnerabilities and makes low-resource web browsing nearly impossible. You either get "a web browser that works" or "a web browse…
Every web developer is fine with 10% of the feature set, it’s just a different 10% for each dev. I am regularly annoyed by the inconsistent browser support for Web MIDI, something 99% of web devs probably don’t care about at all. It would be easier to sandbox if there were fewer features of course, but in practice we rarely see exploits even in complicated low-level APIs like webgpu (which must be a nightmare to make…
I can't think of an analogy that doesn't come off crass.
I posit the likelihood the morass that is webgpu not having exploitable bugs approaches 0 approximately 25 seconds after the first public release of the code, if not months prior.
Its only when one of two things occur that publishing happens, basically: intelligent frustration, and "for the lols".
Someone hits a bug and gets pissed that the authors of the libraries blame everyone but the library authors. When working around the bug discover its not just a bug. Warn devs. Sometimes responsible disclosure means a quiet fix and then disclosure, but usually it means "here's the exploit they don't care ig"
If there's not enough curious people poking things, exploitable stuff could remain hidden too long.
This introduced me to the idea of load value predictors. Is Apple the only chip designer using these in commercially released microarchitecture?
The ARM ISA and also other ISAs with fixed-length instruction encoding are an exception. Because they have a fixed instruction length, typically of 32 bits, most constants cannot be embedded in the instruction encoding.
As a workaround, when programming for such ISAs, the constants are stored in constant pools that are close to the code for the function that will use them, and the load instructions load the constants using program-counter-relative addressing.
Frequently such constants must be reloaded from the constant pool, which allows the load value predictor to predict the value based on previous loads from the same relative address.
In contrast with the Apple ARM CPUs, for x86-64 CPUs it is very unlikely that a load value predictor can be worthwhile, because the constants are immediate values that are loaded directly into registers or are directly used as operands. There is no need for constants stored outside the function code, which may be reloaded multiple times, enabling prediction.
All fast CPUs can forward the stored data from the store buffer to subsequent loads from the same address, instead of waiting for the store to be completed in the external memory. This is not load value prediction.
Mark Twain
Earlier quoted context omitted.
I worked on a browser team when Spectre/Meltdown came out, and I can tell you that a big reason why Firefox and Chrome do such severe process isolation is exactly because these speculative attacks are almost impossible to entirely prevent. There were a number of other mitigations including hardening code emitted from C++ compilers and JS JITs, as well as attempts to limit high precision timers, but the browser vendor…
To add to this and to quote a friend who has more NDAs in regards to microarchitecture than I can count and thus shall remain nameless: "You can have a fast CPU or a secure CPU: Pick one". Pretty much everything a modern CPU does has side effects that are something that any sufficiently motivated attacker can find a way to use (most likely). While many are core specific (register rename, execution port usage for exam…
There are two times in a man's life when he should not speculate: when he can't afford it, and when he can. Mark Twain