-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(android): use device serial for deviceName
#4180
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
Terraform Cloud Plan Output
|
Performance Test ResultsTCP
UDP
|
@jasonboukheir Thanks for summarizing our options, that makes things much more clear! I'll link the customer to this PR for input on which method is best. To avoid privacy and data concerns that affect all customers, I'm thinking 3 or 4. |
I like the option 3. And I think we should not reuse Device Name for it but better we add a separate optional field for it that will be displayed in the portal. |
Option 4 would be more consistent with how we allow users to set their own The underlying use case here is being able to quickly filter thousands of Clients in the table view by some more unique identifier than the device's model number. It could be a serial in this case, but for other Clients it could be a MAC address, Firebase.installationId, etc. Keeping |
Edit: On second thought, we're still saving it, so I'll need to think about the privacy implications. |
@jasonboukheir Customer input is that they can set the field to a variable, so they can override to a value of their choosing. Let's go with Option (4) which prevents us from needing to request additional permissions. Keep in mind if the MDM config field is not set it will be |
Option 4 is a great fit for our use case; TinyMDM at least supports variables in the managed configuration interface, so we can populate the name with the serial number or whatever other variables me might want to in the future. If this isn't too complicated, Option 3 would work well as a default value, i.e., if no name is provided via the MDM configuration, you could call back to the serial number or at worst the model. TinyMDM indeed gives admins the option to pre-approve permissions that would otherwise be requested by the application. Thanks so much for the detailed write-up and options! |
Thank you for the feedback, everyone! Combo of (3) and (4) it is :) |
Testing it out with MDM. Looks like it works! There is another issue that is related to this #4181. We should make sure the tunnel is restarted when this mdm property changes as well. Merge this first, then I'll make sure to add the other property in that PR. |
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Fixes #4042
The serial number of the device is blocked behind a permission. There's a couple ways we can go about this:
(1) Ask the user to (optionally) grant the permission
When we show the grant VPN permission activity, we also mention the optional READ_PRIVILEGED_PHONE_STATE permission. Here, the user can decide to grant it or not, and if they decide not to, they can grant it in the future in the app settings. When the permission is not granted, the
deviceName
falls back to theBuild.MODEL
(2) Force the user to grant the permission
We keep asking them to grant the permission in the splash view.
deviceName
is always the serial number of the device.(3) Let MDM grant the permission
We don't provide a UI to grant the permission in the application. Instead, the
deviceName
is theBuild.MODEL
by default, unless advanced users or admins using MDM set the permission, in which case it's the serial number of the device.(4) Let MDM set a custom/override device name
This could be an alternative to (3) if it is easier for customers using MDM software to manage it this way. Though I doubt it...
Going with option (3) is safe, and the other options can be added incrementally in the future. However, it requires communicating to the customer that they should set this permission for the
deviceName
to be the serial of the device. That's not a problem yet, since the relevant customer is using MDM to manage the app; it's trivial to set this permission via that UI.If we did want to show this permission to the user, I think option (1) is most likely going to be better than option (2) in most cases.