HN user

obnauticus

424 karma
Posts2
Comments46
View on HN

Somewhat depends on your threat model. The relative value of an iCloud/aws/gDrive 0day is going to be higher than Nextcloud. If you’re in the category of people concerned about this type of breach, self-hosting a PHP web app and claiming it’s somehow safer wont save you either. For this risky population, neither solution works since attackers are willing to throw expensive exploits at your data in either scenario.

If you aren’t being specifically targeted, then you would care about low hanging fruits discovered by something like automated scanning. Not exposing your service to the internet does solve this assuming you’re confident in the stack which provides this isolation. But managing this stack and performing risk calculus here is actually where the security horse trading happens. I think most people aren’t safer managing this themselves — arguably they’re actually worse off.

I have high standards for the confidentiality of my data. I care about things like lateral movement and the massive attack surface that isolation tech to prevent such movement has. I also won’t design monitoring and alerting, ensure a patch state, or perform code audits on Nextcloud and all the isolation tech required to secure it to a comporable level of security. Because of this, I instead reason around the cost of exploitation. I want it to be higher than what I believe Nextcloud provides and I’d rather require an attacker to use an expensive 0day to extract my data off a cloud provider like Google versus a potentially cheap one against my own infra.

Agreed. The breakdown is indeed pretty poor IIRC.

Generally you use these disclosures to make directional decisions about infrastructure. The list of fixed and disclosed CVEs combined with the legacy PHP code base doesn’t really pass the security sniff test. You really wouldn’t know for sure without doing a full code audit.

I originally wanted to do this but the CVE history is a bit too colorful for something I’d want to trust as a “cloud replacement”:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nextcloud

A common misconception IMO is that running and owning your own infrastructure is somehow more secure. To that I lol, and I’m confident that the thousands of AWS/GCP/Azure/iCloud security engineers are all doing a more thorough job than you can. At the very very least they receive embargoed bugs which they often mitigate before the general public.

Can it? You still need a ton of very expensive infra, engineering, ops to manage all of this.

Waymo has clearly been playing the “but it’ll be cheaper” game for a long, long time now. It makes sense if you squint really hard and fudge some numbers about unit economics.

If the expected outcome is for it to be eventually cheaper, then why when I open the app does it costs almost twice as much as an Uber or Lyft? You’d think they would want to at least convince investors and train customers that the savings are real and they’re going to prove it by passing it on.

I think the title is missing a word:

“Alphabet _has to_ invest another $5B into Waymo”.

I’d like to remind everyone that it’s still a taxi business with taxi margins (best case).

I think the companies cited in this article might be weird to compare.

Apple is very RTO heavy because they’re an old school hardware company. Hardware work is easy to demand in office work because: (1) apple secrecy and prevention of leaks and (2) access to lab equipment. #2 likely holds true for spaceX as well.

Adding Microsoft to the mix is weird as nobody I know there actually RTOs.

I think people need to actually specifically measure which roles (senior? engineering?) in tech we are discussing RTO about here. I agree that for most software engineering it backfired. But if you’re an apple hardware engineer, there aren’t many places in town that’ll pay you as much so you’ll accept whatever horrible RTO hand you’re dealt. Companies apply these rules to everyone which is very, very stupid IMO.

I think the most interesting part about this being on the inside is the rationale behind RTO. It’s always the same citing culture, collaboration, or other fuzzy things. It is never quantitative. Are you telling me that the people making these decisions are doing so without data? I think that’s unlikely, it’s just that the data isn’t in their favor and execs are smart enough than to let remote versus not remote become yet another bargaining chip for an employee, let alone senior ones.

TLDR, I think senior vs not senior in tech is likely too much of a generalization. But the people with the actual data aren’t speaking up probably because discussing the results don’t benefit them.

Looks like their NPU (aka ANE) takes up about 1/3 of the die area of the GPU.

Would be interesting to see how much they’re _actually_ utilizing the NPU versus their GPU for AI workloads.

CHERI vs MTE is a bit of a nuanced topic. At least one part of the limiting factor for MTE is that you get a finite number of tag “color codes” which opens the opportunity for some form of probabilistic attacks. Of course this helps with defense in depth as it’s yet another layer of security, but it isn’t as strong of a prevention as a CHERI capability for example.

This page explains it pretty well: https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/

I really don’t understand what people are gaining from telling others what to do. Flexibility buys freedom for all employees to live the lifestyle they want. As long as it does not impact your goals or your employers goals I don’t really understand what the real issue is here.

If the shoe were on the other foot how would you feel if someone forced you to be remote?

I’ve worked on this specific problem you are describing but for other reasons.

The issue will be once someone breaks the secure enclave in the CCD, all of the video they produce will now be trustworthy. CCDs are pretty lightweight in general as most of the heavy lifting is meant to be offloaded to the ISP—so the on-die processing for the CCD is generally very lightweight and wouldn’t have buffers large enough to sign each frame. Also there is no standardized way of creating a secured MIPI connection. You can do some clever things to mitigate for this, but it is far from what I’ll call “best practice” and more along the lines of a bespoke solution.

Often times signature checking is fused in during provisioning. That is to say, if they had it enabled before there is a good chance they’re unable to disable it. You’ll probably need to find a vulnerability in the iMX8 bootROM which checks these fuse bits to bypass it.

You’d need to read the iMX8 docs to know for sure, but it does support full secure boot IIRC.

Edit: Yup this appears to be true.

“The public key is included in the final binary and a hash of the public key is programmed in the SoC, in One-Time Programmable e-fuses, for establishing the root of trust.”

See https://www.variscite.com/blog/i-mx8-secure-boot-made-easy-c...

I understand that there are huge interoperability and legacy requirements on the phone network. But for the sake of solving the biggest problem of Android to iPhone communication I think we can and should demand something which is actually modern (ie platform and carrier agnostic).

The problem with RCS is that the solution has been stuck in GSM consortium hell for over a decade.