I've been trying uBO Lite myself for a few months, and anyone who uses YouTube will absolutely notice that it's worse at blocking. Lite tends to delay playback at the start of a video for as long as the blocked ads would've been, making the site feel slower, and once in a while an ad will slip past the blocker anyway.
I am not so sure if that is the light version. In my (outdated) Ungoogled Chromium which still has classic uBlock, YouTube videos also have delays or do stop playing completely after a few seconds. So I have switched to the FreeTube software to watch YouTube videos. I can recommend that.
Not the whole thing: a lot of the Windows org chart is still under Rajesh Jha in Experiences + Devices, or scattered around Azure with Scott Guthrie. But they've already been pushing Windows Copilot and Bing Ads and widgets, so I imagine the plan is more of the same.
It's not just the kids growing up now. I'm sure plenty of millennials who watched YouTube when AudioSwap was a thing will recognize "Dreamscape" by 009 Sound System:
Could you elaborate? AMD spun their fabrication arm off into GlobalFoundries a while back, and they seem to be doing okay. I thought that would be a good precedent for Intel divesting its fabs too, but I'd love to hear any counterpoints to that.
AMD spun off GlobalFoundries to save itself, and suffered greatly for many years afterward. Let's not pretend it was some kind of masterstroke done by a company that was firing smoothly on all cylinders.
Do a Google search for the stock price. AMD announced the spinoff in October 2008.
>if a Twitter user was logged in with a dongle but the attacker had access via social engeneered remote desktop access a dongle still could mean access to private data
It depends on the dongle. YubiKeys and similar devices require the user to physically touch/tap it to enable U2F auth, and it automatically powers down after a timeout to prevent remote desktop attacks.
I would hope Twitter already had this kind of setup, but their blog posts about this are all targeted at a more general audience, so I doubt we'll get that kind of detail anytime soon.
>It depends on the dongle. YubiKeys and similar devices require the user to physically touch/tap it to enable U2F auth, and it automatically powers down after a timeout to prevent remote desktop attacks.
How often is the tap needed? Is it needed on every action or 1/day or 1/month? It would stay valid via browser cookies valid for that period. If it's 1/day the employee might have tapped it in the morning, then went to lunch, then the attackers hit with the remote desktop attack.
Every time you login with a Yubikey you must tap it. It does not maintain its own session on the key or anything like that.
If the app maintains a session, then that depends on how long the app allows sessions/tokens to live for at that point. The Yubikey won't come into play until login is required again. So, I think you're getting at a different part of the security model at that point.
My point is that essentially all apps maintain a session and a remote desktop attack can make use of that session. So Yubikey doesn't really protect from remote desktop attacks.
Fair enough! I didn't comprehend the context well enough. Seems right though, the Yubikey won't protect sessions. At least I don't see any reason it would.
reply