Earlier quoted context omitted.
If your machine is air gapped and/or not running random downloaded code, I think it is a possible reasonable option.
It's a tragedy that so many websites insist on having the ability to run random downloaded code on our systems to do basic things like displaying simple text and images. Things browsers are capable of with nothing but HTML. Google refuses to even show search results, a bunch of literal hyperlinks, without javascript being enabled.
New speculative attacks on Apple CPUs
151–160 of 365 posts
Re: New speculative attacks on Apple CPUs
#152Earlier quoted context omitted.
Forcing every website to adapt to a browser update is completely infeasible. > I can't imagine there are many sites passing significant amounts of data through this This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).
Why not a choice? 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.
Re: New speculative attacks on Apple CPUs
#153Re: New speculative attacks on Apple CPUs
#154I only bring it up because one of the reasons I use Safari with private browsing as a default is because, if I were to login to a site like Facebook in one tab, open a new private tab in the same window and try going to Facebook, it would not recognize that I had already logged in from the other tab. Chrome nor Firefox do that.
Re: New speculative attacks on Apple CPUs
#155The marketing culture for announcing hardware exploits is so strange to me. The norm seems to be getting a custom domain, logos, demos, an FAQ... why do all this instead of just reporting the exploit and releasing a paper?
Re: New speculative attacks on Apple CPUs
#156Apple released minor-version updates to both macOS and iOS the past few days, both containing several security fixes. Has anyone been able to confirm if they address these exploits?
Apple acknowledged the shared proof-of-concept and stated it plans to address the issues. However, at the time of writing, the flaws remain unmitigated.
"We want to thank the researchers for their collaboration as this proof of concept advances our understanding of these types of threats," Apple told BleepingComputer.
"Based on our analysis, we do not believe this issue poses an immediate risk to our users."
Re: New speculative attacks on Apple CPUs
#157Earlier quoted context omitted.
You're not getting a boost, you're avoiding a penalty. In some (but not all) cases you can avoid the penalty and the exploits by disabling SMT. Remember, SMT isn't twice as many cores, just twice as many half-cores. You'll be fine.
In my experience SMT is still faster for most workloads even with the mitigations.
Re: New speculative attacks on Apple CPUs
#158Earlier quoted context omitted.
Forcing every website to adapt to a browser update is completely infeasible. > I can't imagine there are many sites passing significant amounts of data through this This is actually a quite common mechanism for popup-based authentication (which is much more secure than iframe-based one, as users can verify where they're potentially entering their credentials).
Why not a choice? 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.
Re: New speculative attacks on Apple CPUs
#159Earlier quoted context omitted.
That's not a failure of Safari, it's required by window.open API semantics, in particular by the default Cross-Origin-Opener-Policy of "unsafe-none" [1]. By setting a different policy, sites can protect themselves against this. I guess technically browsers could open new windows in a new browsing context group regardless of this setting and relay the allowed types of messages via IPC (if any), but that would be a maj…
Other browsers do site isolation, why can’t Safari? (:
window.open, in some constellations, is an exception, because the opening and opened sites have an explicit communication facility available to them, unless at least one of the two explicitly opts out of it. As far as I'm aware, Safari also correctly implements that opt-out.
The only thing that Chrome and Firefox seem to be doing on top of that, as far as I understand, is to actually enforce process-per-site even for sites from the same "browsing context group" (i.e. all that can hold programmatic references to each other, e.g. via window.opener), which requires using IPC.
Re: New speculative attacks on Apple CPUs
#160Earlier quoted context omitted.
If your machine is air gapped and/or not running random downloaded code, I think it is a possible reasonable option.
It's a tragedy that so many websites insist on having the ability to run random downloaded code on our systems to do basic things like displaying simple text and images. Things browsers are capable of with nothing but HTML. Google refuses to even show search results, a bunch of literal hyperlinks, without javascript being enabled.