alek-cape

Joined 8 months ago

Karma

Submissions

Member since

Feb 25

Recent submissions

I thought access to IMEI and IMSI was pretty heavily restricted starting with Android 10. Graphene [1] makes a few extra restrictions beyond AOSP [2], but it's been around for a while now.

To get access to IMEI and IMSI, you need to either be a carrier app, allowlisted, or grant the `READ_PRIVILEGED_PHONE_STATE` permission.

Unless Chrome is running at a system level in AOSP or some OEM specific firmware, I wouldn't expect it to have `READ_PRIVILEGED_PHONE_STATE`

[1] - https://grapheneos.org/faq#hardware-identifiers

[2] - https://source.android.com/docs/core/connect/device-identifi...

Comment · 8 months ago

Appreciate it, and totally understand the need for it.

Glad to see we won't run into it again, and that our workaround wasn't a problem.

Comment · 8 months ago

We don't own eNodeBs/gNodeBs (the RAN). We operate as an MVNO. It is worth calling out that we operate as a full MVNO though, which is different from many MVNOs in the US currently, who tend to fall on the lighter end of the MVNO spectrum.

The primary difference is we run our own mobile core entirely.

Can you elaborate on the hops question? Not sure I quite understand what you're asking since there are a few ways to interpret "hops".

Comment · 8 months ago

It's probably worth calling out that this is an experimental feature, and we are happy to get any and all feedback on things we can build out around them.

They are real numbers, not VOIP. That can matter depending on what they are used for and if the entity you are expecting a message from blocks sending to VOIP numbers.

The numbers don't rotate like our identifier rotation. They are yours. You can choose to delete a secondary number in the app, and if you have less than two, create a new one after 30 days.

Comment · 8 months ago

John's account was throttled since it's new. Posting this on his behalf. ----

You're right that you don't need to do those things, but I would argue that my background made me uniquely situated to understand and care about these problems deeply enough to spend years of my life building a company in response.

I say "Cape is not a honeypot" a lot just so I don't appear to be mincing words. If you want to delve deeper on how we treat customer data, a couple of good resources are our privacy policy: https://www.cape.co/privacy-summary

And our trust page: https://trust.cape.co/

You can also check out our blog for a bunch of posts on specific features we've built, etc.