Aha, thanks for posting this, was a bit dismayed that I didn’t see that in the release. Now I see it was a misunderstanding so will wait until December to be disappointed. Well, no, I’m disappointed that I’ve been able to do this on my thinkpad for years and have had to fiddle with awkward compromises like accubattery if I want to reduce wear on my phone battery.
Anyone happen to know which release the audio sharing feature is scheduled for? Missed that one too.
Thanks, that’s a significant detail. It also seems like Bluetooth 5.4 adds nothing relevant to my expected use cases: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/whats-new-in-bluetooth-v5-4-an-overview
Is there such a thing as a particularly good PCIE -> m.2 E key adapter or are they all pretty much equivalent? Specifically, are some antennae better than others or they’re pretty much simple enough devices that they’re going to be equivalent if they’re remotely aiming at the same spec?
Unfortunately, it seems like Intel may be a bad bet in terms of use as an AP:
Intel cards are only usable as access points either in the 2.4 GHz band or (very rarely) on channel 36. This hardware restriction is stemming from the fact that they don’t have the circuitry required for reacting to radar pulses, and therefore rely on the “proper” access point to tell them about radars.
Also it needs a USB header on my motherboard as apparently the BT aspect is based on that bus. So perhaps I’d be better off with a fully USB adapter, I wonder if there is a downside to that approach… Edit: PCIE is the way to go
One thing that would be useful to understand is the distinction between CMR and SMR
More detail / similar concepts if you’re not a video person: https://www.centerforbuilding.org/blog/we-we-cant-build-family-sized-apartments-in-north-america
Next time I look for a small laptop to have handy one thing I’m going to be sure to prioritise is: how much battery does it use while suspended? I’d really like to not need to have it switch to hibernate after 30m of sleep or w/e and ideally just plug it in overnight like a phone.
Thanks, cancelled for now. I’ll keep an eye out for ways to contribute as we get more organised.
Big fan of that one, been using it for years.
Do you know about the one for healthcare on the 25th?
They published this in Popular Mechanics in 1912, we’ve been ignoring this for a long time:
The furnaces of the world are now burning about 2,000,000,000 tons of coal a year,” the article reads. “When this is burned, uniting with oxygen, it adds about 7,000,000,000 tons of carbon dioxide to the atmosphere yearly. This tends to make the air a more effective blanket for the earth and to raise its temperature. The effect may be considerable in a few centuries.
Also, this Wikipedia article has a good summary on the overall arc of our understanding: https://en.wikipedia.org/wiki/History_of_climate_change_science
The app, in the scenario where we’re trusting the author/store, is only part of the surface to the extent it’s exposed to a potentially malicious payload. eg. a trusted solitaire game using a vulnerable API doesn’t exacerbate that vulnerability because it doesn’t expose it to untrusted input whereas a PDF viewer would because the PDF could be coming from anywhere…
Really appreciate you taking the time to write that. I have a sense of most of that (“defense in depth” and “threat model” are good lenses to think about such things through for sure!) but what I was trying to get a better grasp on was how much risk from automated attack was a normal person without worries of an “advanced persistent threat” taking on by using a device past EOL. Like you say, “Quantifying how much of a difference it makes is not trivial” so I feel less conflicted to know that you’re comfortable with your dad taking that risk.
I would think that the main thing at stake for a typical user isn’t just browsing history or email though but rather identity theft since a successful attacker can use the device to get through 2FA.
It seems like the attack surface is limited to RF (bluetooth/wifi can be turned off if one is willing to make that compromise), app install (many just use a small selection of well-trusted apps), and messaging/browser which are regularly updated if the device is properly configured. Apps that aren’t pulling in random untrusted content are far less of an attack vector (eg. one’s bank app isn’t connecting to everything, just to the bank, pinterest is hopefully escaping user content, etc.)
Based on helpful details at the other thread (eg. Project Mainline, baseband isolation) I’m beginning to form the opinion that it is not unreasonably foolhardy for someone to continue to use an unsupported device if they are willing to make the compromises necessary to limit their exposure. Which wouldn’t necessarily mean “giving up bluetooth entirely”, just not using it when you’re in bluetooth range of an untrustworthy party eg. if you just use your headset to make zoom calls at home and are fine not having it on the subway.
Thanks for the reply. Definitely appreciate the point that lacklustre updates mean we need to pay attention even if we’re vaguely covered by our vendor. I think you’ve convinced me to subscribe to CVEs for android too, I’ve only had alerts for my browser. Really too bad they don’t make smaller Pixels.
I don’t think they are things that can be fixed on the app level?
Indeed not. So I’m trying to better understand how vulnerabilities at the system level are exploited. It seems like the attack surface is limited to RF (bluetooth/wifi can be turned off if one is willing to make that compromise), app install (many just use a small selection of well-trusted apps), and messaging/browser which are regularly updated if the device is properly configured.
Based on this thread I’m beginning to form the opinion that it is not unreasonably foolhardy for someone to continue to use an unsupported device if they are willing to make the compromises necessary to limit their attack surface.
Thanks, that’s encouraging and very relevant. Looks like it was introduced in Android 10 and aside from “Project Mainline” is referred to as “modular system components”: https://source.android.com/docs/core/ota/modular-system
Can you shed more light on what someone would be risking by continuing to use an EOL device? You say you don’t advise it, but it’d be helpful to elaborate on why.
It seems like the increased vulnerability would be relatively limited: I presume the browser and messaging are by far the most common vectors and those would be as up to date as ever but I can see how exploiting an unpatched vuln there on an unsupported device could have more impact as it would give more options for privilege escalation.
Otherwise it’d be something RF based. Aside from widely publicised things like BlueBorne (that we should be keeping an eye out for anyway), is it a reasonable concern that there are identify theft rings employing people with modified hardware wandering around subway systems trying to exfiltrate credentials from devices with specific vulnerable basebands? Seems like Android also offers some defence in depth there that’d make it unlikely enough to ensure it wouldn’t be worth their while?
There are a few technologically disinterested people in my life that I advise (as is no doubt the case for many here) and I don’t know how strongly to push for them to get new devices once theirs fall out of support. Most of them are quite content with what they’re using and are not in the habit of installing apps (and will reliably ask me first) so they really would be replacing the device solely for the updates. In some cases it’s not only the time and effort to decide on a replacement and get things transferred over but the expense can also be a burden. So I don’t want to raise the alarm lightly.
Good point! And ya, when I open umatrix on a comment thread I see a whole menagerie of instances serving me images as I guess that goes for the profile image too.
But I find that somehow less concerning as they just know “someone at this IP viewed this thread containing these images” than “the user at this IP wrote this comment (or post)”.
Hmmm, but if DMs allow images and they work like this, a user with their own instance who wants to know which IP wrote a comment could perhaps send a message to the author with a unique image…
Aren’t you sorta trusting whoever wrote any package you install with root? I mean, you should have that attitude anyhow as packages have a huge attack surface so privilege escalation bugs are way more common than remote execution but still, flatpak and snap at least offer a bit of a sandbox which might improve…
I’ve enjoyed runbox.com for years but don’t think they offer catch-all, at least not when I last checked. You might look at mxroute.com, I heard about it later and might have gone with them first and they somehow seem more likely to support that
Good. This law is ridiculous and I’m glad it won’t give the result they intended. Being able to link to things freely is a very basic part of the web, we really shouldn’t mess with that. And Facebook is a ridiculous place to get news from so it may have ancillary benefits as well in terms of maybe slightly improving public discourse and encouraging people onto other platforms with more transparency around their content weighting and data use practices.
Oh man, that inflation will get ya, back in the day it was only $20: https://www.youtube.com/watch?v=iH6kUCqIfD4