Hacker Newsnew | past | comments | ask | show | jobs | submit | mgriepentrog's commentslogin

  Location: Oakland, CA
  Remote: Preferred
  Willing to relocate: No
  Technologies: Ruby/Rails, React/React Native, iOS/Objective-C, C/C++, Linux kernel, PostgreSQL, Docker, K8s
  Résumé/CV: https://drive.google.com/file/d/1dnRhpwK4a4ef-MlhPjajwTD4iahRp2N0/view?usp=sharing  
  Email: see resume
  LinkedIn: https://www.linkedin.com/in/mgriepentrog/
  GitHub: https://github.com/mgriepentrog
Full-stack engineer with experience across multiple domains looking for an individual contributor role. Systems/embedded: Linux kernel drivers, firmware development, wireless (with published systems research). Mobile: iOS native apps, React Native, Objective-C. Backend: Rails at scale (serving 1M+ devices), multi-tenant systems, CI/CD.

I enjoy root cause analysis, making data driven decisions, and improving developer experience (CI/CD, testing patterns, metrics). Comfortable tackling problems wherever they live in the stack and picking up whatever technologies are needed to ship. Previously engineering manager and technical lead with 11+ years of experience.


Apple introduced account-driven enrollments in 2021[1], which behaves similar to Android's work profile. Managed apps/data are kept in its own APFS volume, and MDM servers don't have access to anything outside of it. They also disallow system-wide commands like wipe device. The only caveat is you need managed Apple IDs[2] to use this enrollment flow, and I doubt many companies have set it up.

Regardless, MDM installed app visibility is limited to those users who opt-in to an organization managing their personal device, and isn't an effective way to broadly gather what apps a given person has installed. What's described in this post would work on any user/device, and there's no way to deny/opt-out of specific permissions.

[1] https://developer.apple.com/videos/play/wwdc2021/10136/ [2] https://support.apple.com/guide/apple-business-manager/use-m...


Yes I know about User Enrolment. The problem is the managed Apple IDs are a complete and total dealbreaker. So I'm not even considering this as an option.

The reason is that Apple demands that the UPN (the account ID) and the email address are the same. For us this is not the case (our UPN is our employee number as an email address, whereas our email address is just our name). And obviously we're not going to change this for ten thousand users because Apple wants to (most of which don't have Apple devices because we're a European company). Also, you have to manually decide what happens to each user that has already created an account with their corporate email address and what to do with the content they purchased on it. This is not feasible for a large corp. We have commented this to our Apple account manager for years and years but they simply don't care. If you work in this realm you probably know that Apple doesn't really care about things that matter for their corporate customers anyway. The consumer is their main client and it shows (unlike with Microsoft where it's the opposite).

So the whole account-driven enrolment (User Enrolment) as well as everything else depending on managed Apple IDs like DEP for Macs is completely out of the window.

The problem in my opinion is that I as an admin can simply query for example all the employees that have something like Grindr installed. Considering the current political climate in the US (or worse, the middle east where this can lead to a death sentence in some cases) it's obvious why this is super bad. And really, why should we be able to do this at all?


I'm working on implementing this for the company, and the annoying limitations on iOS is that you can't clone apps. If you want Gmail (as an example) as managed app, you can't have another Gmail as unmanaged app. While the company can't see inside the Gmail managed app (without the app itself explicitly providing that feature), the company can remove Gmail (and any local data inside the app) at any time.

Fun fact from the MDM implementation - the most private way (at least to the company policies) to have a company-connected device is to buy a separate phone and install company's MDM on it. On company provided devices, the company may locate company's assets at any time but doing so on a personal device is a privacy breach.


Yes, Apple hates the idea of work-badged apps that Android has. I have to admit, a lot of our users don't grok it either at first. However once they realise the benefits (the company has much less visibility, AND they can turn off the work section completely with the touch of a button) they usually come around pretty quickly.

The bad part of this is that apps have to specifically support the multiple profiles option, otherwise they can't be used for this.

And yes, I agree, that is the best way. We have the same restrictions for personal devices. Though I as an admin know we never use the locate functionality (and I know every person who has access to it).


Donyou know if account driven enrolment requires different phone numbers for the MDM managed apps and the personal ones? Specifically for the diaper app for example.


I don't believe they do, no. The numbers aren't all that important in terms of MDM. We don't even see the number if someone inserts a second private SIM in their company phone. We consider that personal information we shouldn't even know.


The statement that Rails is an "unserious" framework is not true. There are many multi-million/billion dollar companies built with Rails: Shopify, GitHub, Chime, Gusto, GitLab, and Basecamp/Hey, to name a few.

1. It does: https://github.com/Shopify/ruby-lsp

2. It does have a type system, just not a _static_ type system. You can declare/annotate methods using RBS/Sorbet, just like TypeScript.

3. I don't care what paradigm is being used if it solves my problem and I can be productive in it.

4. I wouldn't want to work with them either.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: