HHad3

Unfortunately, with secrets in the OS env, you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident.

The env and more importantly what populates it should be secure, but security works best in layers. Sanitizing the env after loading it is a nicer middleground, k8s-style secrets materialized to files work best and are conceptually close enough to the OS env.

That is complete nonsense and not how switched networks work.

Is this LLM slop? One cannot truncate RSA signatures and still check them. The sample hook code is nonsense, it lacks an address to hook (and would break Enigma‘s self-checks). The sentence structure and all lower-case looks like a bad prompt attempt to hide LLM usage.

That's including the enterprise premium for software, hardware support, and licenses. Building this in-house using open source software (e.g. Ceph) on OEM hardware will be cheaper by an order of magnitude.

You of course need people to maintain it -- the $300k turnkey solution might be the better option depending on current staff.

I would welcome if this global legislative push would end up in a more open app ecosystem for iOS overall.

BrowserEngineKit is a thin wrapper over XPC and iOS' extension system. The system would be so much better to develop for if XPC was an open API, and JIT for isolated sub-processes was permitted without Apple's blessing.

* Messengers could have separate sub-processes for preprocessing untrusted inputs -- iMessage already does this, third-party messengers are single-process and cannot.

* Applications could isolate unstable components for better user experience and crash recovery.

* Emulators, e.g. for retro systems, would benefit from speedy emulation.

* WASM would become useful in iOS.

* Browser could use XPC without special-purpose API wrappers such as BrowserEngineKit.

But alas, all of this would make it easier to load code that runs at native speed into an iOS app after a store review happened, and as we all know that'll be the end of the world.

You can update SEP firmware, but only by providing your PIN. This is why iOS prompts for you PIN again before updating.

This still effectively prevents Apple from adding backdoor to be installed on phones the user can no longer access.

They might just as well send any other .reg file that runs a program (e.g. by creating an autoboot entry, COM server, service, ...) that bricks devices.

Apple unfortunately declared XPC to be a private API on iOS, whereas on macOS it is the foundation for sandboxing custom services.

I found no way to sandbox things beyond the sandboxes provided by iOS extension points (which are mostly XPC under the hood, but with no control options for the app).

Apple makes heavy use of XPC to sandbox iMessage services, but on iOS that remains an Apple-only feature.

Not storing raw HTML might be a last resort to avoid these kinds of bugs in other software, but a good amount of things need to go wrong for them to happen in the first place. The issue is that your data is rendered outside of your software and known-good environment, so all bets are off.

You could as well have triggered a bug in some LaTeX engine that happened to be configured to allow arbitrary shell command execution.

Another strategy to defend against these issue you describe would be to not let developers access raw production data in the first place, but always anonymize it first, or remove internet access from machines accessing production data. (How sensitive is the data in your users table? Could a developer's test script accidentally send emails to your live users?)

I was about to send a rational response to explain how furries are just a bunch of LGBTQ folks (though maybe we met different ones), but then I briefly looked at your HN comments history and decided not to. I hope that not too much of the younger generation has to deal with your bigotry, so I also wish you good luck with them.

Hi Gigachad!

Is there a policy on using portrait photos of oneself at your company? Then the profile photos should indeed be changed, because they're not photos of oneself, but drawings of cartoonish animals.

Otherwise there is no issue here but your understanding of subcultures and these three members of your team. I invite you to talk to them directly, mention the sex thing, and watch hilarity ensue.

> I've tried to bring this up with management but have been told they don't see any issues and I should drop it.

They probably value their contribution to the company over potential misunderstandings should these developers come into contact with customers via Teams. Management might not know what furries are. They might have googled it and found it to be benign. They also might have reacted that way due to the way you presented the issue, or interact with management or your team in general. It's impossible to tell from your post alone.

> Am I overreacting here?

Yes, but that is understandable if you believe that it's a sex thing.

> Is this normal in a corporate environment? I get that with remote work, things have become more casual, but not too sure if this is too far.

Depends on the company. Some may have policies on profile pictures, none of those will explicitly ban furry avatar pictures.

Good luck with the younger generation, Gigachad!