Cophone – Mobile work phones running in the cloud
cophone.io
cophone.io
My name is Tudor and I am the maker of cophone. With cophone you can have your private virtual smartphone running in the cloud, complete with a phone number so you can use it just as you use your physical smartphone. And it works from your browser! Although cophone mainly targets companies, private individuals are welcome! At the moment only US phone numbers (+1...) are available, but more country codes are coming soon. Also having multiple numbers is in the pipeline!
Signal app works - just choose "Call" instead of "Text" when verifying your number. You CAN receive text messages, but some apps that require you to receive one in order to register might still NOT work (i.e. Whatsapp). That's because they might not recognize cophone numbers as mobile numbers so you'll never receive the challenge message. Main desktop browsers are supported. Chrome on Android also works but on IPhone there're still some issues, esp on older iOS versions. I'm working on it!
Cophone is marked as beta because I haven't tested it at scale and there are still some rough edges.
I am exploring having a freeware version with a common, shared phone number and an extension for each user. So you'd dial +123456789 followed by #098765 to get connected via PSTN with a cophone user - let me know what you think of this.
I'd love to get your feedback! Don't hold back if you have a feature request or something doesn't work as expected for you!
If you'd like a deluxe tour please reach out (tudor at cophone dot io) and I'll be happy to show you around!
From the link: "Where do the applications in the App Lounge come from? App Lounge can be used to install Native as well as Progressive Web Apps (PWAs) from a single interface. Apps are managed differently depending on their source. Applications from the Google Play Store are fetched using the Google Play API. Progressive Web Apps (PWAs) and Open Source Apps from F-Droid are fetched using the CleanAPK API (more info on the CleanAPK is covered below). App lounge allows you to filter apps by Open Source, PWAs, or just show all apps."
You say elsewhere you provide virtual phone numbers. If this is the case, you cannot use it for SMS-based 2FA reliably. Sometimes you will receive codes, but most of them won’t be delivered.
on a serious note, this is unfortunately what scammers like to use, it would be prudent to lock it down before scammers put you in the middle of a legal cases. I have a long story, I tell people about scammmers, but in the case, please be careful. Grandma is getting conned by these telephone virtual numbers.
You can access the virtual smartphone from a browser running in a physical smartphone. Unfortunately not all smartphones/browsers support it.
I see App Lounge in the screenshot so I assume the VM's are running /e/. Have you tried installing any of the MDM's out there like AirWatch or InTune?
As a thought exercise, how about some light abuse. What would happen if I rammed a couple TB of BitTorrent data through that VM. Maybe used it as seedbox. Or maybe a proxy so I can access a streaming service.
It feels like you're really trying to sell the phone part, and that the Android VM is a means to an end. However, this is just a random phone number that I suspect isn't portable. So if I stop using your service I can't take the number with me. So why wouldn't I get a Skype number for $6.50/month, Skype to Phone for $3.50/month, and then use the web.skype.com page to make all the phone calls I want. Or you can do what I do and use jmp.chat for phone calls and SMS and have it all routed to the XMPP client of your choice (as long as that client supports all the needed features).
> I assume the VM's are running /e/. Yes.
> Have you tried installing any of the MDM's out there like AirWatch or InTune? No, I haven't tried. Cophone is very new and because of this lacks some functionality or app support.
> What would happen if I rammed a couple TB of BitTorrent data through that VM. Maybe used it as seedbox. Or maybe a proxy so I can access a streaming service.
Any tool can be abused. I have some bandwidth checks in place and some monitoring. More sophisticated abuse prevention is under development.
> why wouldn't I get a Skype number...
It's not just about the number, it's the whole package. Think BYOD but without the hassle of mixing work and private data. These devices could be supplied by your employer, with all the apps and number(s) that you need from day 1.
I really like the concept and I think it could be the future of corporate access in a way, but I'm trying to look at this through a security lens. I think my main concern with this would be around potential unauthorized access and the impact that might have on an organization. If my target market for this is enterprise clients, I would go to great lengths to ensure that the only person who could access this virtual phone, is the user that's intended to access it.
I'll try to keep this short, but here are some ideas I think would really boost adoption and practicality:
1. IP Whitelisting In the portal, users should be able to add a VPN gateway IP or users home IP to an allowlist at the very least.
2. Zero Trust integration The goal here is to be able to enforce device/user identity restrictions in a way that only certain devices/users have access to their virtual smartphone.
3. Management Plane With the above in mind, it might make sense to have IT/Management configure the whitelisting/user certificates for ZTNA in a management portal, so there is separation of duties here.
With the above feature requests in place, I would then add a 3rd line item on the pricing page for "Enterprise Pricing" with a "Contact us for a quote" option.
For my use case, and I think others may have a similar use case, I would like to use this for my MFA applications and various other internal applications, but if there's no way to restrict access to an individual user, this is essentially a huge security risk from a business standpoint.
Hope you find this useful!
Indeed risk mitigation is crucial for companies. Your points are really good, I think they struck a good balance between functionality and security.
One other thing that I am considering, since it is a popular request, is to provide an app that can be installed on a physical device. The device would basically act as a proxy for the cophone's notifications but in addition would also notify the user about potential unauthorized accesses.
> 3rd line item ...
Totally! Thanks!
> use this for my MFA applications and various other internal applications
This!
By your pictures this is /e/OS, a system which hasn't had the browser/WebView updated in 7+ months, is consistently 2 months behind the ASB, is 1 year behind the PSB, and has a PDF viewer with an engine from January 2016.
That is 196 known security issues in the browser, hundreds in the OS, and another 60 in the PDF viewer.
I document these issues and many more here: https://divestos.org/misc/e.txt
If this really is /e/, you seriously need to address this.
Go rebase on an actual production OS like GrapheneOS, my DivestOS, or CalyxOS.
So, question for Cophone, do these phones have a "real" number, or a virtual number? And, perhaps a follow-up, are these VMs with a virtual network stack, or are they physical devices with a real physical SIM/eSIM/modem with screen sharing?
[^1]: This sounds nefarious, but we essentially partnered with a lot of retailers, and needed to interact with their customer service and operations departments who were a long way organisationally from those who signed the partnership contracts, and with little scope for deeper integrations. The lowest friction option was to pretend to be a completely normal customer rather than explain our special case setup every time. Fun fact, this is why we used a gender-neutral name on the postal address, so that anyone from our company could call up and claim to be the recipient.
It's a little sad that there isn't a good solution for this yet though.
https://kozubik.com/items/2famule/
(sorry about the bad SSL cert - I stopped caring after acme.sh blew up)
I'm curious, why not just serve plain HTTP at that point? It makes little difference to the viewer.
Or buy a "real" SSL cert that I don't need to fiddle with every few months.
I think there are some browsers that won't even connect to HTTP/80 without a warning ?
This is probably possible to do, but probably hard to get right, and still requires having a device reliably available to receive calls, and has limited scale (what happens if there are multiple calls at the same time?). This is why it would have been great to be able to buy this as a service.
https://clerk.chat offers the ability to receive SMS on genuine non-VOIP numbers. They are ridiculously bad at pretty much everything – terrible communication, terrible customer support, terrible reliability, terrible UX, etc. – but they can actually do this where other VOIP-based providers like Twilio can’t. They may be your least worst option.
Another option that’s available is to set up an Android phone with https://ifttt.com and a genuine phone plan. Then get IFTTT to forward any SMS it receives to whatever service you need. There are open-source apps that do similar things as well – the sibling comment mentions a similar solution. It’s a pain to maintain though.
I’d love it if there were a better solution out there, but I haven’t found one yet. Basically the only thing I need is a genuine phone number that will forward SMS on to a web hook.
We are hugely frustrated with providers insisting on SMS as a 2nd factor for commercial use because we value employee PII and feel they should not need to seed data brokers just do log into enterprise platforms.
We are looking for a solution at scale for SMS 2FA that, according to the national number registry and KYC/anti-fraud checks, is a "real" mobile SMS number.
We've found hardware devices that take from 4 to 32 SIM cards and are heading in that direction which seems ... nuts.
But, we value employee privacy and these days when even your accounting firms' privacy policy say they're selling your contact info upstream, we want to give employees a way to log in without compromising themselves.
Also, to anyone here running a B2B SaaS that offers TOTP instead of SMS, thank you.
In addition to TOTP 2FA (our main service), we also started to offer 2FA via SMS via _physical SIM cards_ hosted in a data center in Germany (we are a German company) as every other solution we tried (Twilio + seemingly 50+ other, non-physical SIM card-based, options by now) was simply not working reliable.
We have been talking to Twilio et al and a lot of telcos, carriers, ISP, providers and seemingly everyone in between: there simply is no easy and reliable solution to this. :(
In our tests the best reliability we could reach for national and international senders&receivers on VOIP-based numbers was only every around 80%. We are still looking for other options, and specially non-VOIP options that are actually affordable, but so far we can only offer a German number (+49). This number however, is way, way more reliable than anything we have seen from others.
We currently support forwarding SMS to an email address, and webhooks for incoming notifications are in the works.
Can you get a cellular connection over a wire?
That is, instead of having 500 little radios connecting to one or two nearby towers, can you negotiate a direct connection to the tower and use the entire cellular stack except for the PHY ?
The only solution that seems to work is old school SIM card hosting in a SIM bank. In some narrow cases, e.g. sender is in the country and receiver is in the same country, you might have pretty good (95%+) reliability of receiving critical SMS (A2P traffic), but still far away from what you'd call reliable.
I’ll bet it’s possible, just not organizationally possible…
I’ll bet there are $80k Agilent / R&S rigs that can wire to a tower and do the entire cellular stack except for the PHY…
Would love to see pictures of such a connection in practice.
But the real problem here isn't technical, it's a business/legal issue: the carriers and their regulators are trying to minimize (or at least, reduce) the ability for bad actors to operate large numbers of "cell phones" at minimal cost/complexity.
So everything that could be done (technically) to make this work is, in practice, prevented by those business/legal considerations.
Open source stacks are already or basically on the verge of being obsolete in most of the world's telco networks if you want to actually use them. They are incredibly cool and a huge undertaking but no one is saying they are practical for actual usage, and that's ignoring the clear illegality of broadcasting with such firmware.
Osmocom and others like FreeCalypso only work on very old devices with TI Calypso chipsets.
It solves all of their terrible new a2p 10dlc issues and would be genuinely useful.
Actually, there are all kinds of ways to solve their 10dlc problems and make their platform useful (again) for something other than spam but … that would be a boring and useful service and not customer engagement at scale.
Why they are dying out? Because they are not that easy to source, maintain, scale or achieve super high reliability with them. Also, hard to offer a high availability option when the phone network only (well, in most cases) accepts one device per phone number.
Edito: Additionally, important to note is that most SIM cards can only be used for a prolonged time in that providers phone network. You e.g. can not buy US SIMS, ship them to the EU and host them there. T-Mobile US (and others) cut you off after (usually) 2 months of roaming.
Some cool stuff on aliexpress with 128 SIM card slots and 8 or 16 gsm radios where you can program your choice of imei.
As a Canadian with crappy cellular coverage, I’ve dreamt of having a couple French SIM cards that I could mail to France every so often so it looked while I wasn’t 100% roaming just to have a cheap unlimited data plan with cheaper int’l calling.
1. I guess it depends on your providers/region. From all three German mobile network providers (Telekom, Vodafone, o2) you can get up to three SIM-Cards for the same number.
2. The VoIP provider Sipgate (sorry again German) gives you as much SIM-Cards and eSIMs as you like (In exchange for money of course). You can route mobile as well as land line numbers to a VoIP-Phone, -Client or mobile phones. They can all ring in parallel.
3. Many years ago, I saw a presentation on a CCC event. (Sadly I can't find a video of it just now.) It was from a guy who documented how he became a mobile provider. He wasn't just reselling, because his numbers terminated in his own Asterisk server! So maybe, people looking for the best solution, should look into how to become a virtual mobile provider.
Our ops team had a physical phone for this, but it lived in a desk drawer somewhere and that didn't scale as the team grew and became distributed.
I think what Twilio or others could do is offer non-VOIP, genuine, etc, numbers on the condition that the company and use-case is vetted and the usage is audited. A little like getting an EV SSL certificate, you'd give valid points of contact, undergo basic vetting of the company, perhaps even limit the count of numbers you can contact and require human review for increasing that quota.
Maybe this would be too hard, arguably EV SSL failed because it wasn't strict enough. Or maybe I'm misunderstanding why VOIP/automated numbers are so easy to identify, I assumed it was because they were higher risk in this way and that this sort of auditing would circumvent the need for that, but maybe there's another reason.
How can this be determined? I'd imagine that only those with direct access to the "which number belongs to which provider" database could see that a given number belongs to $comapniesKnownToOfferTraditionalPhysicalService versus $comapnyKnownToOnlyDoVOIP can know this for sure? It it just that some companies with this access are selling a "we'll look that up for you" service? Or is it simpler and i'm just over thinking it?
Twilio API has a simple lookup function (call over curl) to see provider and type of number. Also shows subscribers name (usually).
I have this in a shell script and look up numbers all the time:
/usr/local/bin/curl -s -X GET "https://lookups.twilio.com/v1/PhoneNumbers/$number?Type=carrier&Type=caller-name" -u $accountsid:$authtoken | /usr/local/bin/jq '.'Sure, some operators operate only physical or only virtual, but others (like Google) operate both.
I asked how Twilio obtains the information.
Right now, I carry around two cell phones - work and personal. My use case for my work device is surprisingly limited. I basically need it for notifications and 2FA. For anything serious, I switch to my laptop. However, I _really_ need that work phone.
BYOD/Shared devices is a thing at many companies, but that comes with it's own host of issues. Most notably, I don't want a corporate MDM on my personal phone. I also want to be able to let my family use my personal phone without worrying about breaking.
This virtual device, effectively lets me carry a single device while having nice, clear boundaries. As long as notifications come through well, this could effectively replace my need to carry a work phone.
Indeed, this is something that I have learned from the comments here: that cophone needs to forward the notifications from the virtual smartphone to the physical one(s). Will put it on high priority!
I would expect this service to eventually offer an enterprise feature. Having my employer fully control a VM does not break any data barriers.
I personally wouldn’t want this to be browser only. I would enjoy it being device bound with a key.
That's an intriguing idea! Will have to look into it!
It'd be nice if iPhones had something similar. Not sure how anyone is supposed to use them for work when it comes to apps like WhatsApp and Signal. Or even less work stuff like dealing with recruiters, real estate agents and online dating where you might end up sharing primary contact details with people you don't want to hear from a few weeks later.
How did you get an Indial group, what T&C did you sign up to?
Does host know you terminate and originate phone from this service?
Do you have to make a statutory declaration about EMS geolocation?
What's your STIR/SHAKEN/SPAMACT requirements?
Do you have KYC and AML licencing?
Are you actually a registered telco, and have common carrier licencing?
Do you have a warrant canary?
I'm not trying to white-ant you. If you go into widespread use, I'm sure these will be asked. Different economies have different regulators and rules.
Up until the latest AI wave, Twilio was almost in every thread about a new service!
https://www.twilio.com/labs/twimlets
I use the "Forward" one for calls.
For SMS, it used to be not too complicated - I would host a file directly on Twilio (using a Twilio bin) to forward the SMS to another number.
Recently, sending out SMS's has become a lot more complicated due to compliance (Twilio wants to make sure you don't spam people - but the burden on small developers was just too much for me, after ~2-3 months of back and forth emailing with them to get approved)
I've switched my SMS forwarding to use https://pushover.net/ . I use Twilio's hosted nodejs platform to get the incoming SMS message, and use Pushover's API.
It's potentially brittle-ish overall (lots of pieces) but it's also been working for years.
A native mobile app that would let me just get calls and sms for my hosted Twilio phone numbers is really what I'm asking for... :-)
I'm a bit locked in for now (and am dreading transferring all the numbers I've accumulated) but yeah. Thanks for the perspective
In some countries even phone carriers may offer SIP trunking for individuals. But most often they work with a handful of resellers, who in turn have smaller and smaller companies as their clients. So, if you only need to support a small volume of calls you'd find that your prices per connection or per minute are higher.
Similar to sending email, telephony is a business of volume. The more call you make the less your prices are going to be. I worked in telephony space for a few years, and it's a fascinating industry.
It's just an XMPP gateway, so you can use any XMPP capable chat client or gateway you want. XMPP isn't the worlds best protocol, but it works fine.
Practically, it is best to have a work phone with a removable battery you take out when nott working and use for no other purpose. Ideally, smartphones are not fit for any purpose that involves sensitive and highly impactful (you get fired, jailed, divorced,etc...) purposes.
But for me, I could actually use this if I am ever forced to use a mobile phone. Even for personal use, i am struggling painfully with android x86 in a vm! I like the product.
I'm not surprised people don't understand the value of something like Cophone. It doesn't mean the value isn't there. It just means they probably don't spend enough time dealing with software testing issues to see the potential.
This looks like a classic solution in search of a problem.
One use could be to run something like whatsapp to have a virtual US presence if in another country, or maybe have a business number separate from your personal number and use whatsapp web interface to read/send messages.
I have a work and personal phone. For many reasons, it's very difficult to merge everything onto a single device. Further, I really don't need to do much "phone" stuff with my work phone. It's mostly a glorified pager, 2FA, and occasional Slack/Email. Anything serious gets a sit-down on my computer.
This would effectively let me carry a full-isolated, properly segmented work phone without having to carry two devices.
If your employer mandated use of a dedicated work phone in the first place, why on earth would they allow you to use this product to do that?
That’s the thing about this. It creates very clear and strong boundaries which are easily enforceable.
It lets me have a work phone on my personal phone without giving my employer any meaningful access to my personal phone.
That's not a made up use case; I think there are a lot of businesses that fit that description.
I'd prefer to have a virtual machine on the phone where I could isolate apps etc. Would be nice with a second phone number tied to that virtual machine, maybe a sip one could work.
But since that doesn't seem to materialize I'm playing with the idea to have an old phone at home and remote into it using VPN+VNC or something from my real phone. Would work in theory but last I experimented with it the experience was pretty bad.
Commercially, I would suggest that you white label this at a heavily discounted wholesale rate to VOIP providers. They have existing channels and user base that should allow you to scale without huge marketing investment, and once one or two of them bring your service onboard the rest should buy in. Alternatively, just sell it out to a larger player and move on.
That's great input! This is all very fresh so I'm still building connections. I have to admit Voip providers were not on my list but it totally makes sense.
What can you do on a phone emulator running on some server and accessed from your browser that you can't just...do directly on the browser?
a) how is this different from Canonical's Anbox in the cloud offering?
b) could I use this to run banking apps that won't run in my phone (mainly due to the unlocked bootloader)?
b) This is a really good point! I don't know atm, I'll have to look into it.
> Something went wrong. If you forgot your password, you can reset it.
When I try to reset it I get a link and the link leads to an empty page.
Any idea what can be the issue?
2.0b62168b.chunk.js:1 Uncaught SyntaxError: Unexpected token '<' main.b556c503.chunk.js:1 Uncaught SyntaxError: Unexpected token '<' manifest.json:1 Manifest: Line: 1, column: 1, Syntax error.
Thank you!
Why is there a difference?
Who is determining bad VOIP from good VOIP?
Are there steps you can, or are, taking to work on having your numbers legitimized?
Where are you sourcing your numbers?
I'll take my questions off the air :). Thanks!
I don't know :(
> Are there steps you can, or are, taking to work on having your numbers legitimized?
Sourcing the phone numbers from a company with a reputation to defend - Twilio - is the main method.
> Where are you sourcing your numbers?
Twilio
Which they aren’t.
Your bank then decides not to send codes to non mobile numbers but it’s not because it is a twilio number per se…
This would've been something nice to have at that time - I would be able to, without having two phones, have personal and work related Whatsapp numbers on seperate places (but still accessible when needed).
Some numbers are shared with others, just disable it on my phone and the other person enables it to start receiving incoming calls.
I really don’t see the business case for paying $10/$15 per month.
All bets off with Cophone.
Most companies don't care about anything but price. The rest is largely theatre, particularly outside the tightly-regulated sectors like healthcare and banking.
Even the US DOD is using the cloud for email storage.
It's not unreasonable to see a solution like this evolve into an on-premise hosted solution.
The cloud definitely is someone else's computer.
If I need the company laptop to access my virtual smartphone, then what's the point? At that point I might as well just use the laptop to do what I need to do. Which defeats the purpose, because it's not mobile.
Also you cannot lose your work phone as you would with a physical one. Which might be interesting for your employer if you handle sensitive data.
The longer term plan is to also provide an app that you could install and therefore achieve the same mobility. This would be the only work app you would have to install on your personal mobile phone in order to access your work phone. This is still in brainstorming phase.
It's a really elegant solution IMO.
Probably there are also people who'd like to get rid of their smartphone entirely so this pose as a solution to the ever growing dependency on such devices, be it exclusive bank or other apps, some forms of verification and others.
Admittedly I didn't look into it much but I assume we're talking about physical devices, which likely holds true by the cost of the subscription as well as the considerable challenge of misrepresenting a virtual device for a real one, in which case the service looses any actual appeal.