Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)CI
Posts
0
Comments
1,103
Joined
2 yr. ago

  • This answer is very different depending upon your life circumstances.

    A single person with fixed income, is different than a two income household with children. I'm not saying they can't both reach the same conclusion, just at their circumstances justify different choices being valid.

    There's also your technical proficiency, and pain tolerance for saving money.

    For example, you could eliminate all external services, self-host everything, and then configure an S3 object storage provider for critical cold storage backups. That might also require you spending a bit more upfront to expand your NAS storage capacity.

    While that may save you a bunch of money in the long term, it will definitely cost you a lot of time and effort.

    What's convenient for you? What can you not afford to lose access to? What's your budget? How much time do you have to manage different solutions?

    Those aren't questions for you to provide me answers for, just some of the considerations that will impact different people's answer to this question.

  • Fusion reactors are incredibly complicated.... This is a research reactor, with the goal of figuring out how to create sustainable fusion for real world uses by 2050.

    This is not a performative action for a determinative outcome, this is aspirational and has no guarantee of achieving its goals, which is good. This type of research and science needs to be funded, even when it may fail.

    Maybe this will spurn competition between powers to accelerate their own fusion reactor research, and create a virtuous cycle that accelerates this technology becoming a major source of green energy in the near, or medium-term, future.

  • Permanently Deleted

    Jump
  • Maybe I'm missing something here, but OnStar is a 3rd party service, so it makes sense they would have a bolt-on device that can be removed without too much concern for the rest of the car's functionality.

    Also, isn't a TCU something that controls a car's drivetrain and transmission?

    Edit: nevermind, just searched and found telematic control unit. Interesting, thanks for the info, I might look into this more if I have more time later.

  • Permanently Deleted

    Jump
  • I unintentionally fibbed, because one thing I do have a bit of experience with is aftermarket car stereos, including double-DIN android units.

    Granted, I haven't tried to install one in a 2024 car, but a lot of modern infotainment systems can't just be ripped out and replaced with aftermarket unit and retain the car's original functionality, if it can be removed at all without breaking, or removing your access to core functions, like climate control, etc.

    Here's a picture of the interior of one of the cars in question, a 2024 Mazda CX-90

    You're not popping a double DIN in there, and even if you did remove the screen, I'm betting the actual infotainment system boards are inside the dash somewhere installed in a mounted panel box, and they aren't just going to pop out and be replaceable like your standard head unit.

    Another photo, this one from the linked article:

  • Permanently Deleted

    Jump
  • I might regret not searching about this before running my mouth here, but I would assume most automotive manufacturers, in 2024, are soldering the wwan modules onto the main board of the infotainment system for cost, and to prevent user removal of their subscription vector.

    I would also assume most manufacturers who are converting standard automotive features into paid subscription services that dubiously rely on SaaS backends, are NOT also designing isolated architectures that separate the IoT infotainment system from the car's critical systems like drive control, transmission, brakes, etc. I'm guessing most at least have CAN bus connections linking them together.

    But I don't know enough about cars and automotive systems to even pretend being knowledgeable. So, if anyone here is actually well versed on this subject (and not just searching forums before replying to me), please tell me I'm wrong, and how so.

    Seriously, I want to be wrong about this.

  • What if I told you I work in information security, and your not impressing me, or tripping me up, by using terms like defense in depth and attack chains, nor am I confused and unable see through your misrepresenting Graphene's threat model to imply it only matters for high threat risk individuals.

    Just because I said I don't have enough low level understanding of Android development to refute those devs write-ups on Android browser security, doesn't mean I'm coming here without a professionally informed understanding of security, and all the terms you keep throwing out to muddy the issue.

    So, I'll leave it there. I will take my professional knowledge and experiences, along with my judgment on which sources I incorporate into my broader understanding of this situation, and agree to disagree with your analysis and conclusions.

  • Extensions are another vector. But putting that aside, because I agree ads are a much larger threat:

    https://github.com/uazo/cromite

    Cromite a Bromite fork with ad blocking and privacy enhancements; take back your browser!

    Also, Mulch lets you pick your DNS provider. So even if you don't already have system, or network, wide ad blocking, it's not like you're deluged in ads.

    Again, I'm not saying no one should use Gecko based browsers, I'm just repeating what developers of respected hardened security ROMs have written about. Actually, that's not true, I'm taking a softer approach as the GrapheneOS wiki/FAQ says NOT to use Gecko based browsers.

  • It's like you're arguing because you like to argue, and can't admit that you're wrong. So you keep finding new ways to qualify your response in the hopes that I forget what this is even about.

    Chromium is significantly more secure than Firefox Gecko on Android. That is according to the developers of probably the two most well regarded hardened Android ROMs.

    One of which, Graphene, even advises completely avoiding Gecko based browsers.

    Which is what I said in my original comment, well, the part about relative security.

    You've also claimed that at most, a malicious android application can only harm battery life and cause network issues, which is objectively false. I'm honestly kind of confused why you even said that, but whatever.

    I never said no one should use Firefox based browsers on Android, I just said they weren't as secure and that user should understand the risks associated with them.

    But what I'm most confused and perplexed by, is your insistence that only high risk individuals should be concerned with using a browser that comes with, at minimum, double the attack service they're exposed to when browsing the web.

    Again, that is per the GrapheneOS wiki/FAQ.

    I mean, we're not talking about some hardcore and incredibly inconvenient levels of unnecessary OPSEC for the sake of OPSEC, we're talking about a browser.

    Tell you what, if you post a link to your GitHub showing me the hardened Android ROM that you develop, or heavily contribute to, I would be happy to revise my opinion on your credibility versus those developers.

  • Right, so if Gecko based browsers can cause that kind of security concern on Graphene, what does that mean for people using Android ROMs that are not hardened, or, OEM variants that do not receive regular security updates?

    Any app installed by a user that takes advantage of an active and unpatched CVE, can do all sorts of actions to compromise an entire phone, or critical parts of it. Are you saying that's not the case?

    The difference between a compromised app, and a browser, is that even a "safe" Firefox install is used to browse a near infinite possibility of websites, any number of which might be running an active campaign targeting unpatched Android vulnerabilities.

    It sounds like you're saying that despite Firefox Geckos significantly larger attack surface, the fact that Chromium doesn't eliminate all risk, means there's no difference.

  • Avoid Gecko-based browsers like Firefox as they're currently much more vulnerable to exploitation and inherently add a huge amount of attack surface. Gecko doesn't have a WebView implementation (GeckoView is not a WebView implementation), so it has to be used alongside the Chromium-based WebView rather than instead of Chromium, which means having the remote attack surface of two separate browser engines instead of only one. Firefox / Gecko also bypass or cripple a fair bit of the upstream and GrapheneOS hardening work for apps. Worst of all, Firefox does not have internal sandboxing on Android.

    https://grapheneos.org/usage#web-browsing

    That sounds like the exposed attack surface is a lot more than just whatever sites are running under your Firefox process.

    But what do I know, I'm not a developer of security-hardened Android forks, so I just have to pick which randos on the internet I choose to believe. When the developers of DivestOS and GrapheneOS both have lengthy write-ups on why chromium base browsers are significantly more secure, I'm going to believe them because I don't have the low level technical knowledge to refute what they're saying.

  • Pretty sure I told you where you could find more information, as well as pointing out that the default browser on Graphene is a hardened Chromium browser, not Firefox Gecko.

    But okay, here, I can even do that little bit of searching for you:

    https://divestos.org/pages/browsers

  • What is per-site process isolation?

    Per-site process isolation is a powerful security feature that seeks to limit exposure of a malicious website/script abusing a security vulnerability. Firefox calls per-site process isolation Fission and is enabled by default on desktop. Fission is not yet enabled by default on Android, and when manually enabled it results in a severely degraded/broken experience. Furthermore Firefox on Android does not take advantage of Android's isolatedProcess flag for completely confining application services. Standalone Chromium based browsers strictly isolate websites to their own process.

    https://divestos.org/pages/browsers

    Source: The developer of Mull, Mulch, & DivestOS

  • Projectivy launcher, problem solved adequately duct taped.

    Stop connecting your TVs directly to the internet, I don't care what OS it's running. The trend is clear with TV manufacturers, and if your current TV OS doesn't yet inject ads into your streaming box's HDMI stream, why risk it updating? Because that's coming soon enough, and I imagine what it does, an update requiring your TV to have internet connection won't be far behind.

  • It's not a hard problem to solve. Raccoons are incredibly smart, and if you stop feeding him, they'll eventually disperse. In the meantime, it's kind of a cute oafish story.

    Feeding a wild raccoon isn't going to make it forget how to scavenge, or take care of itself. If you live in a remote area, probably not doing any long-term damage to their wild habits, aside from this one feeding ground they will have to move on from.

    Apart from her not having a game plan for getting around a raccoon bum rush, the biggest concern I would have would be that raccoons are a reservoir species for rabies in the PNW.

    Not sure when exactly this raccoon party fully kicked off, but their breeding season is spring and summer, which I believe coincides with a spike in rabies transmission...so....that's not ideal.

  • This always gets downvoted, because it's a painful truth, but Chromium on Android is significantly more secure than Firefox.

    There is a reason why the default included browser on GrapheneOS, Vanadium, is a Chromium fork.

    So I'm sorry, until Firefox on Android catches up to Chromium, another Firefox fork isn't going to make the impact on the ecosystem that you think it is.

    I'm not saying you can't or shouldn't use Firefox forks on Android, I'm saying do so being aware of their limitations relative to Chromium forks, such as Cromite, or Mulch, the latter being the same dev as Mull. That same dev also has a lengthy write-up going over the technical details of why Chromium is more secure than Firefox on Android.

    This has nothing to do with desktop browser engines, this is specifically and exclusively in regards to Android browsers