It's a bit of an annoyance when products talk a lot about "privacy" and "security", but never once mention what sort of threat model they are private/secure against.
Then add in something like a bespoke (unvetted?) communication protocol on top and my eyes really start to roll.
The people who really want privacy & security enough to be willing to buy something like this will want a lot more detail than what is offered here.
There’s a gigantic difference between someone who has experience designing and building complex systems to be secure and private… and someone who thinks “how hard can this be? There’s gotta be a market for it!”
I remember this story. The FBI created cell phone business targeting criminals. They got criminals to believe it was a secure network all while listening in.
(judgement aside, just facts) There's a lot of that going on with the FBI, including bot nets / marketplaces that they commandeer. How long do you let it continue? It's a fantastic way to gather intelligence, and the risk that a market player may be LE adds more peril for the players engaging in it.
> This project is funded through NGI0 Entrust, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.
Yep, and I followed all of those. I still have absolutely no idea who is designing, running, building mikrophone or the project.
It’s great to know it’s not funded by DPRK, but that wasn’t my point. There’s a difference between it being built by an undergrad student and moxie marlinspike.
As someone who has worked in cybersecurity for decades, it's remarkable to see how security concerns are finally permeating everyday life. We could always predict that the explosion of connected devices would dramatically expand the threat model, but witnessing it unfold in society is something else entirely.
This extends beyond just technology: it's now embedded in politics, conflicts, and nearly every aspect of life.
It's also important to note that it's not just the sheer number of devices challenging cybersecurity, but the dynamic nature of cloud security. For instance, Apple's recent innovations around hybrid AI computation highlight how cloud security is evolving alongside technological advancements.
Unfortunately, I’m not convinced the dialog is connected to actual improvements - this project is somewhat of a perfect example.
I remember the boom of “privacy first” products that launched after the Snowden leaks, but they were all money grabs by folks who probably moved on to blockchain later and now AI.
I agree it’s wild how much of a common topic it is. I do miss the days when it was smart curious folks tinkering around.. but so goes every young field.
> ...but never once mention what sort of threat model they are private/secure against.
You know, they're Secure(TM)! Against Threats(TM)! Buy me if you're scared of Threats(TM)!
Threat modeling ("Secure from who? Under what conditions?") sort of stuff just doesn't seem to be a thing that's taught these days outside certain weird circles. And certainly something this project hasn't touched on in the slightest. But, yes, I was having to keep my eyeballs constrained too.
As much as it pains me, I think the most "generally secure phone" out there, for at least the sort of threat models this phone handwaves at (journalists, human rights activists) is a recent (last generation or two) iPhone with Lockdown enabled - and then shut down nightly, and carried shut down through any sort of sensitive environments. I would be inclined to go with an iPhone SE3, moreso than one of the mainline devices, simply for fingerprint scanning versus the FaceID stuff. You can't "point a phone at me" and unlock it with my fingerprint, but you can with FaceID in a wide enough range of situations to be concerning. Set a longer than usual PIN/passphrase, and be careful where you enter it.
As far as I understand the boot process, Apple has largely fixed a lot of the "before first unlock" type attacks with their secure enclave. They fixed that rather well after the battle with the FBI, and seem to have continued hardening and improving that process (hence my recommendation for the latest generation or two of device - there are changes in the boot security flows every now and then, and I assume they matter, at some point).
Then Lockdown, as near as I can tell, does a very fine job of simply closing the common attack points used. Most of the "good" attacks on iPhone users (at least the ones I know of...) are through the various "texting-esque" endpoints with weird image formats, or a browser based Javascript/JIT exploit, and Lockdown does a fine job of simply refusing most of the paths these use. Weird image formats simply aren't rendered. URLs in text messages aren't accessed and previewed. The Javascript engine removes all JIT capabilities, WebRTC, WebGL, and other "suitably complex that it's probably exploitable" sort of features.
It's not perfect, but were I an individual who believed I was under actual threat for this sort of stuff, I'd 100% use a secured iPhone (possibly with some of the Mobile Device Management features configured by a trusted person to disable the USB port and such things) over a random device like this. Sorry, open JTAG ports means it's "comically insecure" against anyone with local access and the time to bother doing anything with it.
And of course, don't keep location services on, don't install a ton of apps, etc. The usual if you're concerned about any of this.
I don't like that this is the state of the world of secure computing, but it certainly seems to be it, to me.
> You know, they're Secure(TM)! Against Threats(TM)!
This is thought provoking because I get your sentiment against
half-baked ideas of "secure" and "threat", but then you start talking
about cameras, fingerprint readers and boot processes...
These have nothing to do with phones as I see them. For me a secure
phone is the minimum viable device to make a voice communication (and
perhaps short text messages at a stretch).
So what's going on here is woolly ideas about function. If we define
a "phone" as a multi-purpose personal computer, address book, secure
storage device, video player, film camera etc, then it's going to have
very different security parameters than a simple "telephone".
So we can't talk about threats and security until we have talked about
function. As we define (or rather fail to define) a 'phone' today it
has almost no functional boundaries, and so there's no model around
which to define security.
The minimal RISC-V device outlined in the article looks like the kind
of thing that could be customised to constrain functionality in such a
way as to add security. It obtains that possibility by giving control
to the end user around what not to include.
Er, no, that would be locked-down GrapheneOS, on a Pixel.
There's a multitude of reasons - but here's the biggest one: Apple's Lockdown mode is all or nothing. You can't selectively enable certain features that you may truly depend upon. On the other hand, GrapheneOS allows you to selectively disable individual security features that may be too overbearing. It would be far easier to daily drive a GrapheneOS Pixel than an iPhone in Lockdown, for that reason alone.
My threat model includes a few things, but one of them is that I don't want my data available to advertisers.
GrapheneOS sort of supports that, but I found that it's nearly useless as a daily driver when set up that way. Even with Google Play Services installed in a sandbox, GPS stuff breaks, the camera is flaky, and third party apps don't work reliably. Also, the remaining built-in apps have huge gaps (no backup, no synchronized notes, etc).
Worse, I'm not convinced that sandboxing it helps privacy that much. Without it installed, the phone had multi-day battery life. With it, it dropped to whatever Google was advertising (30 hours?).
Anyway, iOS without lockdown seems to be much more secure (by my criteria) than my GrapheneOS Pixel phone was in practice. Also, I can use all the apps that are essentially mandatory around here.
I haven't experienced things breaking, but it is slightly slower (very slow if indoors) to get a GPS lock, because by default even location requests through Google's API are re-routed to the system service, which uses standard GPS/SUPL/PSDS rather than hoovered-up Wi-Fi SSIDs. You can optionally enable Google's location service if you want faster results.
I'm not sure, all of the recent Pixels were on the Cellebrite leak list as accessible without brute-force even while cold. Of course, the recent iPhones were too. Maybe there is no solution, or maybe Cellebrite is lying a little bit with their ads.
Cellebrite has a separate category for GrapheneOS and the most recent leaks indicated up-to-date GrapheneOS was invulnerable to all attacks, whereas the latest iPhones were vulnerable to AFU attacks.
I'm genuinely curious - what issues have you run into with Lockdown? I've been using it enabled for the times I have been carrying an iOS device (vs my preferred flip phone), and I've yet to run into anything I consider a deal breaker.
I can't get animated gifs in MMS/texting threads. Oh darn. Doesn't bother me, they're usually content free fluff anyway.
WebGL being disabled means I can't use that one guy's awesome website on my phone - except, if I want to, I can disable Lockdown on a per-site basis for trusted sites (which then allows those things to work again).
... I can't get Facetime calls from random numbers? That's never been a problem for me one way or another, and, good.
I do occasionally run into websites that use some image format that doesn't render, and if I really care, I can disable Lockdown on the per-site basis there too, but I usually don't bother.
I'm just curious as to what the actual issues you've found with it are. I turned it on in a beta and haven't found any reason to turn it off since then.
The reason I use an iPhone instead of a Graphene device is that Graphene does not support sufficient device attestation to run Microsoft MDM, which means I can't get to my work calendar.
>As far as I understand the boot process, Apple has largely fixed a lot of the "before first unlock" type attacks with their secure enclave. They fixed that rather well after the battle with the FBI, and seem to have continued hardening and improving that process (hence my recommendation for the latest generation or two of device - there are changes in the boot security flows every now and then, and I assume they matter, at some point).
It's worth pointing out that even the latest iPhones are vulnerable after first unlock (AFU), which means if your phone gets seized and you don't have time to turn it off, they can get a full dump of your phone.
And this is a good reason to keep your smartphone turned off regularly.
I really don't have a great answer. I'm aware Graphene offers some substantial benefits too, but it's also somewhat harder for a non-technical user to use. Unfortunately, when the attacker has unlimited physical access, a device can and will fall, given time and resources.
One of the amusing things I thought about with acquiring a "secure" iPhone was that you should just buy it from a random Walmart in the middle of nowhere in America.
The supply chain is so wide and vast, and even if they did tamper with it, the iPhone is basically the only phone out there that multiple third parties have ran through CT scanners, X-ray machines, and silicon R/E just to show off the tech inside the phone like a bunch of nerds for clicks, meaning you have lots of good reference material to check against for any potential tampering of your own acquisition.
nitpick: SS7 is used at the core network between telecom companies. Whatever happens at the RAN/RAT layer (ie. 5G vs 2G) has nothing to do with it.
There's still security gains to be had from using LTE, but if mossad wants to hijack your 2fa codes by using a SS7 exploit, thats not going to protect you.
Well, yes and no to the telco core networks. I’m sure you know but for the record - getting access to the SS7 outside telecom companies is easy and fairly affordable (15-20k€/month). That and voice/sms services (vs. e2e encrypted data over virtual networks) grants access to SS7 exploits one under the threat model discussed earlier would want to protect against.
Lockdown mode also does disable 2G[1], although personally it'd have been great to have a 2G/3G toggle per SIM the way they do the other per SIM options.
My pet peeve on open-source, *-focused hardware: it should start with an artistic sketch and a mockup, not the final board and a shell wrapped around as an afterthought.
Valve[1] reportedly made over 100 mockups before settling on the final shape, most of them representing shapes only. Apple[2] had at least five iterations of nearly indistinguishable mockups for one of iPhone models that were discovered by fans.
It is certainly possible to build a radio equipment by starting from a block diagram and installation into enclosure, but that's development process for low volume technical instruments which measure of utility is electronic performance. A consumer product should look and feel good in hand, even when it's dead.
As someone that builds hardware all the time, your opinion is actually quite a common bias. The Idea that physical design (and aesthetics were important to Steve Jobs) can somehow reliably define the final technical form-factor is naive, and often leads to impractical products or vaporware.
Usually it is the common mistake that creates every camera that overheats, usb-c port that snaps off, or power adapter the size of a brick. Apple could have made the new iPad battery last another 2 hours, or make it 1.7mm thinner... They made it thinner, and provided less value to consumers in newer products.
In general, one MUST transition through every stage of the TRL or are bound to repeat the process from the start again at some point. Part of design revisions is figuring out whats possible (including physical volume constraints) with current technology, and whats appropriate in the projected market.
Notably, the physical volume of a battery is a physics constraint, and most of the mass of your iPhone is the battery (Steves team miniaturized everything else to reach the form it ultimately became.) The battery type is a requirement set by the desired function of the hardware, and chips slowly optimize for a given role (hence the trend of things getting slightly smaller/more-efficient, but compared to the battery volume it is negligible.)
Almost every business I've seen that prioritized the injection molded box first, has not survived to product launch.
One could disagree with physics, but then again most engineers will simply abandon that project. =3
I don't mean to teach fish how to swim, but - what I meant to say is, just, packaging, enclosure design, weight distribution, durability, etc shouldn't be - starting enclosure design AFTER final PCBA ought to be wrong.
I am, e.g. completely fine with cheap generic ready made enclosures[1][2][3] for low volume handhelds, and do understand that reality is reality, done is better than perfect, real designers ship, etc., I mean no offense to hardware rockstars either, and with that said, I really think I can say more higher priority to final form factor can be safely applied to projects like [4] and [5], despite obvious cliff between your and my qualifications.
In general, most prototypes are initially designed as a massive sprawling 2D development mess (from satellites to cellphones they are all the same.) After the key functions are verified/validated, than the unneeded resources are refined/removed through the optimization process.
Finally, the first physical PCB is reformed into whatever custom enclosure the marketer/designers defined. With the caveat that they understand the volumetric requirements for the device internals. Again, prior to dropping $60k on a plastic container mold, the design must first clear emissions pre-testing and certification documentation.
There is a reason hardware startups fail at a rate >5 times higher than service companies (1:63 hardware startups live past 3 years).
I would highly recommend taking a Design For Manufacturability course, or find a qualified Contract Manufacturer to handle the product gruesome details.
Most products I see now are pad-printed store-branded generic products from China. Usually nothing wrong with that kind of import trade, but fundamentally this is not a product design process.
Tip, no one is ever an expert with unknowns, but experience and standards help guide decisions on avoiding expensive mistakes... like handing your team an impossible assignment.
I wouldn’t call it a pet peeve but I understand where you’re coming from with this: but I think the main reason for it is electronic engineers, with little-to-no product design or even mechanical design/CAD background. IMO it’s a shame: it’s sort of like the open source hardware version of the “Blender before it got good UX” problem.
This is like, barely risc-v. As far as I can tell, there's a risc-v management micro, an esp32 that I'm not easily finding a part number for so may as well be Tenscilica, and an app processor that's ARM based. I don't understand the GPU chip if you have the app processor, and I don't understand the management micro if you have custom ESP32 firmware. And a lot of SoMs have WiFi + Bluetooth on board. So I also don't understand the ESP32. This really feels like it could be a card-edge SOM, battery, HMI, and modem. As per usual I find this project needlessly complicated and buzzwordy.
I was just wrapping my head around on how do they even run linux on the RISC-V microcontroller they use. Turns out there is a separate ARM for application processor.
Yeah. As I'm sure you're aware, you can get Linux capable RV. I mean you can build mmu-less as well but there's plenty of I think it's M extension cores out there. This isn't that. This is a design that happens to use at least one RV core and happens to be capable of hosting a modem card. It's not a RISC-V mobile phone.
From what I can tell, the RISC-V processor handles all of the phone functionality in a way that's almost entirely decoupled from the app-module/smartphone features. The phone part has its own firmware and drives the screen separately from the app-module. They added a green indicator light to show when the RISC-V "core" is using the screen vs when the app-module is.
The graphics processor is probably just for when the RISC-V core takes over the screen, as well.
What's the purpose though? You can put your own code on the app processor too. I don't know Android kernel dev but presumably with aosp you can do whatever the RV core does either in the A class core or using one of the many SoMs with built-in M class cores.
> an esp32 that I'm not easily finding a part number for so may as well be Tenscilica
On their dev board it's the usual esp32-wroom. They also say their esp32 firmware needs esp-idf 4.2, which doesn't support any of the risc-v esp32. So it is xtensa.
I agree that everything could be done with the esp32 alone (well, an wrover with extra RAM) but this project seems to be just a guy experimenting and having fun! Although I can see how someone might be cynical regarding this project being deliberately complicated/overengineered just to extract more money from the nlnet fund.
Great for experimentation, but that's where it should end. If this is a cash grab or anyone is seriously considering buying it I think better products do or could exist. They'd be easier -> cheaper to design, maintain, source and assemble. 3 chips to do what's already built into the SoM connector is unideal.
The concept of a RISC-V based "assemble it yourself" phone is solid enough - there have been the PiPhone concepts based around a Pi Zero for long enough, and while I don't think they're terribly usable, they're also a fun looking little project.
But then they throw the ElipticCP concept on top, and sort of handwave it being "secure" if you're talking to someone else who is using a similar device, or similar capabilities, or such. And, unfortunately, there's not a lot of information about that I'm seeing (or, that which there is seems rather vague and handwaving).
> The security of the whole system is not compromised even though none of these modules is trusted, because all sensitive data is encrypted by the central MCU before sending it to a communication module. Secure communication uses a protocol EllipticCP originally designed for this project. It provides end-to-end encryption and an additional anonymizing layer based on the principle of onion routing. In order for a security protocol to function to its full extent, the end recipient in the communication channel also needs to use mikroPhone or some other phone with comparable security performances (in other words, both communication parties must be secure enough).
There's a lot of words in here that sound good, but there's a serious lack of details, and then when you go to build the phone, you have open JTAG ports to the device.
So I'm not really sure what threat model they're dealing with exactly. "People who can build their own hardware and firmware, who work in investigative journalism or human rights activists, who have iron clad control over their hardware, who want to talk to other people with identical hardware," maybe? It seems designed to counter remote threats only, and without a lot more details as to what it's doing, it's hard to say if it is or isn't doing that competently. I don't have the time right now to go dig through their firmware to see, unfortunately.
If it weren't a build it yourself sort of thing ("Here's the schematics, go get boards fabricated!") it would trip my honeypot sensors ("Secure Phones!" being more government ops than anything actually useful, IMO), but... it's not that, fairly obviously?
Dunno. I doubt it would work on any US carriers, they're all VoLTE only now. :/
Tbh I would accept anything usable without being bound neither to Google nor Apple. Like a Linux phone but with usable apps which is quite important.
For example Samsung gets free MP3 player and more important, background-running voice recorder, which is extremely important for me, but was impossible to find on OnePlus One.
Better yet, GrapheneOS allows you you sandbox Google's crap if you need or want it. Very useful when needing to use a proprietary app that requires it.
Jolla's Sailfish is another alternative. Linux, quite a few native apps and an Android emulation layer that makes it easy to use most F-Droid and Play Store applications.
As an owner and occasionally serious user of the above device, I can say that, no, it is not usable as a phone by any definition that includes portability. This is due to extreme bulk and still terrible battery life, even before we get to the experience of using PureOS and Gnome for your phone OS.
However, the kill switches are super cool and would be practical if the device were.
> The security of the whole system is not compromised even though none of these modules is trusted, because all sensitive data is encrypted by the central MCU before sending it to a communication module.
No way. You need to decrypt that stuff before sending it to the communication modules (BT, WiFi, cellular, display) and you get them unencrypted from the same.
If the communication modules can decrypt the stream themselves, then eavesdropping will happen there inside.
Why is this being pitched as a complete solution? There's no concrete explanation why it's more secure, just open source software = secure while rolling it's own stuff; and there's baffling component choices that completely conflict with each other. A color 400x840 screen is not needed for a "simple" phone, and having any possibility of redundant BT/WiFi radios is a baffling oversight.
There's 2 different ideas here, and instead of splitting them up into their own discrete projects that can excel at both ideas, they are turned into 1 mediocre project. Also, exposing JTAG in your final product and forgetting about physical security aren't good looks either.
Note that esp32 (and esp8266) use proprietary, closed-source network stacks[0]
It's not a important in this project as there is a separate "main" MCU, but having radio module with closed-source software, active radios, and which you pass unencrypted data through (like bluetooth audio) might concern some people.
(The SIM module is likely closed-source too, but hopefully it's impact is much more limited - if you care about privacy, you would not send any data over cell phone networks unencrypted)
less a criticism (as this is a fantastic project) and more a general comment about security protocols. The protocol (https://mikrophone.net/ecp.html) for privacy appears to require another MikroPhone device on the other side to communicate with.
the cryptographic backdoors I have encountered in my work were in closed loop systems where having a standards based interface to facilitate separate or independent implementations would have foiled the schemes, as replicating the sabotage in another project would have been far more complex.
the first student project is building this, the next really interesting one is reasoning about that security protocol.
the ideal protocol described provides good forward secrecy, and speculatively if I were looking for implementation sabotage I would look for where the padding nulls were used instead of bytes of the nonce to reduce its entropy to something brute-forcible, and off hand as far as threads to pull, whether the parity bit on the key could reduce the search space by %50 as either even or odd.
from a design perspective, if it only talks to copies of itself, why add the complexity of a new protocol? from a mass interception perspective, the "don't roll your own crypto" cliché is probably one of the most successful psyops of all time and I don't think it's a useful admonition in this case, but imo the question of "why" for a new protocol is the most interesting one.
I am glad that these sorts of projects exist. Even if the implementation may not be the greatest it at least provides an option which is not under the thumb of Google, Apple and others.. and it can always be improved over time.
However, I do wish there were some videos and photos of the completed products
> Mostly I care about phone calls, texting, and web browsing.
"Easy, Easy, Brutally Difficult."
If all you want is phone and text, there's no shortage of cheaper flip phone/candybar phones out there that handle it, though I will caution you that older versions of KaiOS, at least, struggle badly with handling any sort of modern text quantities (a few hundred messages on a phone on a KaiOS 2.x device lagged it badly enough that it stopped alerting me to new messages or phone calls, and I had to trim it down regularly, though even then it struggled).
I'm a fan of the Sonim stuff, it runs Android Go, and is properly stout.
Web browsing, though. That's hard. If you want a simple phone, your best bet is to carry a tablet or laptop for that sort of thing, and just hotspot off the phone if/when needed. Most current featurephones have a thing called a web browser, and it ranges from "almost useless" to "literally can't render the modern web." That's before you sort out using it on what is typically a 320x240 pixel display. You're way better off just carrying something different for that need.
Isn't that the other way around? I thought voice is usually the most complicated to implement, especially in 4G/5G which uses modified SIP/RTP. Mic and speaker has to work too. Web browsing OTOH at bare minimum require just simulated PPP over AT command interface, touchscreen, and Chromium.
If you're building your own cell modem, then, probably.
In terms of "finding hardware that can do the following things," pretty much any cell phone sold will support voice and text - though some don't do a great job with MMS. The web browser requires orders of magnitude more resources than voice/text, though. A Nokia from 20 years ago, with... I actually can't find how much RAM or storage, had no problems with voice or text. Wouldn't run a browser at all, though.
I was admittedly of the impression that most of the voice work was handled by the baseband, though. I've not built my own phones, unfortunately. I just use some basic flip phones for mobile use.
As recently as the Samsung Galaxy S7, Pinephone, etc., voice calls are done with high-level commands too. All you have to do is get the soundcard mixer settings right. Figuring out the correct settings is tricky but once you have them it's plain sailing.
Web browsers have a very broad interface with the underlying system.
Speaking from experience: getting calls and text working is much easier than getting a browser going in a new environment.
People, including a lot of very tenured web developers, radically underestimate how big browsers are in surface area now.
Any of WebGL, WebRTC, the MediaStreams, Web Audio or WebGPU by themselves are enormous, and on mobile SoCs will rely heavily on device specific drivers to accelerate their functions, or the battery runs out in 5 minutes.
Firefox depends on many many parts of the operating system. Calls and texts, not so much. Starting from scratch, a kernel and little else, getting calls and texts working is easy compared to getting Firefox ported.
This looks really cool! I don’t know if this more of a feature phone or a smart phone though. Would like to see pictures of completed builds and what they can do.
Looking at the hardware, it's likely to be a "mostly usable interface to a cell modem." So, SMS, audio. No idea if it can handle MMS or not. And anything beyond that is iffy.
They've got some interesting concepts for a separate application processor that can route to the screen, but... right now, consider it the sort of project to build if you don't actually need to talk to anyone with any reliability.
Current status section mentions "3d printable phone case designed in FreeCAD", but there don't seem to be corresponding file. I think the project is practically in breadboard stage.
Neo900 is dead. Unfortunately. It was always on shaky ground (the nature of a hardware project) but what seems to have killed it was PayPal withholding its funds for long enough to take the wind out of key people's sails. PayPal just decided to abruptly lock out the project account one day after accruing a substantial number of down-payments, and refused to give the funds back for around a year. By the time some progress started being made again, the funds were no longer enough and the project was at that point based on seriously obsolete hardware (as opposed to the regular kind of obsolete most hardware projects have to work with).
The problem is the hardware, not the software. Also, what you want as a paranoid person is your baseband not part of the SoC running your computer - this project hear does that, Jolla and others are using standard Android SoCs.
Jolla added libhybris to make it easy to use Android hardware adaptations - which at that time was needed to get a phone out (ste, which the first Jolla phone was supposed to be based on, decided to get out of the phone chip business during the prototyping phase, and that was the last vendor offering proper Linux drivers). I never was much of a fan of that as you just pull in way too much uncontrollable crap - unfortunately it works good enough that a lot of other projects then also jumped on that, instead of reviving a focus of doing proper Linux drivers (something I was worried might happen when the libhybris development started).
I'd argue software is the main problem. If you want to make a new smartphone OS, just target a pixel or something. The driver + kernel stack as pretty close to as open as you'll find anywhere. The hardware is flagship-grade, updated every year, and shipping now.
I've had zero luck putting a non-Android daily driver OS on it though. I'll define daily driver as "all of this works tolerably well":
Phone, SMS/MMS, web browser, podcasts, navigation, music player and camera.
Heck, drop the camera requirement for version one, and then you're down to "video, audio, GPS and phone stuff works".
Jolla's Sailfish OS is used as a daily driver by a small niche in EU, probably tens of thousands of users taking into consideration download and update traffic.
It's definitely usable as a daily driver. There are some rough edges if you only want to use native applications and want to avoid Android applications, which go through an emulation layer. But it's still pretty nice! Things like offline mapping work really well.
You can, by using the libhybris hardware abstraction layer I've mentioned. It is relatively simple, though still requires understanding of how low level stuff works. The main problems there are graphics and modem, both of which typically are not open drivers - and with that you then pull in half of your typical android system into your regular linux distribution just to get the hardware working.
If you don't care about the modem and graphics acceleration (or, in same cases, graphics output at all) you should be able to get it booting with the available kernel relatively easily.
Camera also tends to be not tends to be not that much of an issue - typically there's enough in the available kernel that you can get a gstreamer pipeline running, and then just have to figure out how to make it not look completely shit.
And after all that you still end up having a device with the baseband sitting on your SoC.
It's a bit of an annoyance when products talk a lot about "privacy" and "security", but never once mention what sort of threat model they are private/secure against.
Then add in something like a bespoke (unvetted?) communication protocol on top and my eyes really start to roll.
The people who really want privacy & security enough to be willing to buy something like this will want a lot more detail than what is offered here.
Or _who_ is leading this project.
There’s a gigantic difference between someone who has experience designing and building complex systems to be secure and private… and someone who thinks “how hard can this be? There’s gotta be a market for it!”
I can’t tell which one this is
How the FBI's fake cell phone company put criminals into real jail cells
https://www.npr.org/2024/05/31/1197959218/fbi-phone-company-...
https://www.theverge.com/2024/5/23/24163389/joseph-cox-dark-...
I remember this story. The FBI created cell phone business targeting criminals. They got criminals to believe it was a secure network all while listening in.
There is a distinct difference between a publicly offered MikroPhone and a phone swapped between criminals. Not every phone is some honeypot.
Dark Wire by Joseph Cox covers the whole story
https://www.amazon.com/Dark-Wire-Incredible-Largest-Operatio...
It was a real conundrum for law enforcement agencies because at some point they had to stop facilitating crime and start exposing it.
(judgement aside, just facts) There's a lot of that going on with the FBI, including bot nets / marketplaces that they commandeer. How long do you let it continue? It's a fantastic way to gather intelligence, and the risk that a market player may be LE adds more peril for the players engaging in it.
Look at the bottom of the page and you will see
> This project is funded through NGI0 Entrust, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.
with links and everything.
Yep, and I followed all of those. I still have absolutely no idea who is designing, running, building mikrophone or the project.
It’s great to know it’s not funded by DPRK, but that wasn’t my point. There’s a difference between it being built by an undergrad student and moxie marlinspike.
As someone who has worked in cybersecurity for decades, it's remarkable to see how security concerns are finally permeating everyday life. We could always predict that the explosion of connected devices would dramatically expand the threat model, but witnessing it unfold in society is something else entirely.
This extends beyond just technology: it's now embedded in politics, conflicts, and nearly every aspect of life.
It's also important to note that it's not just the sheer number of devices challenging cybersecurity, but the dynamic nature of cloud security. For instance, Apple's recent innovations around hybrid AI computation highlight how cloud security is evolving alongside technological advancements.
Unfortunately, I’m not convinced the dialog is connected to actual improvements - this project is somewhat of a perfect example.
I remember the boom of “privacy first” products that launched after the Snowden leaks, but they were all money grabs by folks who probably moved on to blockchain later and now AI.
I agree it’s wild how much of a common topic it is. I do miss the days when it was smart curious folks tinkering around.. but so goes every young field.
> ...but never once mention what sort of threat model they are private/secure against.
You know, they're Secure(TM)! Against Threats(TM)! Buy me if you're scared of Threats(TM)!
Threat modeling ("Secure from who? Under what conditions?") sort of stuff just doesn't seem to be a thing that's taught these days outside certain weird circles. And certainly something this project hasn't touched on in the slightest. But, yes, I was having to keep my eyeballs constrained too.
As much as it pains me, I think the most "generally secure phone" out there, for at least the sort of threat models this phone handwaves at (journalists, human rights activists) is a recent (last generation or two) iPhone with Lockdown enabled - and then shut down nightly, and carried shut down through any sort of sensitive environments. I would be inclined to go with an iPhone SE3, moreso than one of the mainline devices, simply for fingerprint scanning versus the FaceID stuff. You can't "point a phone at me" and unlock it with my fingerprint, but you can with FaceID in a wide enough range of situations to be concerning. Set a longer than usual PIN/passphrase, and be careful where you enter it.
As far as I understand the boot process, Apple has largely fixed a lot of the "before first unlock" type attacks with their secure enclave. They fixed that rather well after the battle with the FBI, and seem to have continued hardening and improving that process (hence my recommendation for the latest generation or two of device - there are changes in the boot security flows every now and then, and I assume they matter, at some point).
Then Lockdown, as near as I can tell, does a very fine job of simply closing the common attack points used. Most of the "good" attacks on iPhone users (at least the ones I know of...) are through the various "texting-esque" endpoints with weird image formats, or a browser based Javascript/JIT exploit, and Lockdown does a fine job of simply refusing most of the paths these use. Weird image formats simply aren't rendered. URLs in text messages aren't accessed and previewed. The Javascript engine removes all JIT capabilities, WebRTC, WebGL, and other "suitably complex that it's probably exploitable" sort of features.
It's not perfect, but were I an individual who believed I was under actual threat for this sort of stuff, I'd 100% use a secured iPhone (possibly with some of the Mobile Device Management features configured by a trusted person to disable the USB port and such things) over a random device like this. Sorry, open JTAG ports means it's "comically insecure" against anyone with local access and the time to bother doing anything with it.
And of course, don't keep location services on, don't install a ton of apps, etc. The usual if you're concerned about any of this.
I don't like that this is the state of the world of secure computing, but it certainly seems to be it, to me.
> You know, they're Secure(TM)! Against Threats(TM)!
This is thought provoking because I get your sentiment against half-baked ideas of "secure" and "threat", but then you start talking about cameras, fingerprint readers and boot processes...
These have nothing to do with phones as I see them. For me a secure phone is the minimum viable device to make a voice communication (and perhaps short text messages at a stretch).
So what's going on here is woolly ideas about function. If we define a "phone" as a multi-purpose personal computer, address book, secure storage device, video player, film camera etc, then it's going to have very different security parameters than a simple "telephone".
So we can't talk about threats and security until we have talked about function. As we define (or rather fail to define) a 'phone' today it has almost no functional boundaries, and so there's no model around which to define security.
The minimal RISC-V device outlined in the article looks like the kind of thing that could be customised to constrain functionality in such a way as to add security. It obtains that possibility by giving control to the end user around what not to include.
Er, no, that would be locked-down GrapheneOS, on a Pixel.
There's a multitude of reasons - but here's the biggest one: Apple's Lockdown mode is all or nothing. You can't selectively enable certain features that you may truly depend upon. On the other hand, GrapheneOS allows you to selectively disable individual security features that may be too overbearing. It would be far easier to daily drive a GrapheneOS Pixel than an iPhone in Lockdown, for that reason alone.
My threat model includes a few things, but one of them is that I don't want my data available to advertisers.
GrapheneOS sort of supports that, but I found that it's nearly useless as a daily driver when set up that way. Even with Google Play Services installed in a sandbox, GPS stuff breaks, the camera is flaky, and third party apps don't work reliably. Also, the remaining built-in apps have huge gaps (no backup, no synchronized notes, etc).
Worse, I'm not convinced that sandboxing it helps privacy that much. Without it installed, the phone had multi-day battery life. With it, it dropped to whatever Google was advertising (30 hours?).
Anyway, iOS without lockdown seems to be much more secure (by my criteria) than my GrapheneOS Pixel phone was in practice. Also, I can use all the apps that are essentially mandatory around here.
Which apps weren't working for you?
> GPS stuff breaks
I haven't experienced things breaking, but it is slightly slower (very slow if indoors) to get a GPS lock, because by default even location requests through Google's API are re-routed to the system service, which uses standard GPS/SUPL/PSDS rather than hoovered-up Wi-Fi SSIDs. You can optionally enable Google's location service if you want faster results.
I'm not sure, all of the recent Pixels were on the Cellebrite leak list as accessible without brute-force even while cold. Of course, the recent iPhones were too. Maybe there is no solution, or maybe Cellebrite is lying a little bit with their ads.
Cellebrite has a separate category for GrapheneOS and the most recent leaks indicated up-to-date GrapheneOS was invulnerable to all attacks, whereas the latest iPhones were vulnerable to AFU attacks.
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
I'm genuinely curious - what issues have you run into with Lockdown? I've been using it enabled for the times I have been carrying an iOS device (vs my preferred flip phone), and I've yet to run into anything I consider a deal breaker.
I can't get animated gifs in MMS/texting threads. Oh darn. Doesn't bother me, they're usually content free fluff anyway.
WebGL being disabled means I can't use that one guy's awesome website on my phone - except, if I want to, I can disable Lockdown on a per-site basis for trusted sites (which then allows those things to work again).
... I can't get Facetime calls from random numbers? That's never been a problem for me one way or another, and, good.
I do occasionally run into websites that use some image format that doesn't render, and if I really care, I can disable Lockdown on the per-site basis there too, but I usually don't bother.
I'm just curious as to what the actual issues you've found with it are. I turned it on in a beta and haven't found any reason to turn it off since then.
The reason I use an iPhone instead of a Graphene device is that Graphene does not support sufficient device attestation to run Microsoft MDM, which means I can't get to my work calendar.
>As far as I understand the boot process, Apple has largely fixed a lot of the "before first unlock" type attacks with their secure enclave. They fixed that rather well after the battle with the FBI, and seem to have continued hardening and improving that process (hence my recommendation for the latest generation or two of device - there are changes in the boot security flows every now and then, and I assume they matter, at some point).
It's worth pointing out that even the latest iPhones are vulnerable after first unlock (AFU), which means if your phone gets seized and you don't have time to turn it off, they can get a full dump of your phone.
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
And this is a good reason to keep your smartphone turned off regularly.
I really don't have a great answer. I'm aware Graphene offers some substantial benefits too, but it's also somewhat harder for a non-technical user to use. Unfortunately, when the attacker has unlimited physical access, a device can and will fall, given time and resources.
It is very difficult to protect against AFU attacks, because any remote 0-click can work for AFU unlocks.
One of the amusing things I thought about with acquiring a "secure" iPhone was that you should just buy it from a random Walmart in the middle of nowhere in America.
The supply chain is so wide and vast, and even if they did tamper with it, the iPhone is basically the only phone out there that multiple third parties have ran through CT scanners, X-ray machines, and silicon R/E just to show off the tech inside the phone like a bunch of nerds for clicks, meaning you have lots of good reference material to check against for any potential tampering of your own acquisition.
This. And no 2G/3G to protect against SS7 threats. 4G/5G only can be quite limiting but in this threat model you want SS7 attacks out.
nitpick: SS7 is used at the core network between telecom companies. Whatever happens at the RAN/RAT layer (ie. 5G vs 2G) has nothing to do with it.
There's still security gains to be had from using LTE, but if mossad wants to hijack your 2fa codes by using a SS7 exploit, thats not going to protect you.
Well, yes and no to the telco core networks. I’m sure you know but for the record - getting access to the SS7 outside telecom companies is easy and fairly affordable (15-20k€/month). That and voice/sms services (vs. e2e encrypted data over virtual networks) grants access to SS7 exploits one under the threat model discussed earlier would want to protect against.
Lockdown mode also does disable 2G[1], although personally it'd have been great to have a 2G/3G toggle per SIM the way they do the other per SIM options.
[1] https://support.apple.com/en-us/105120
Depends on your use case but.. just only use WiFi and never put a (e)SIM in it.
[dead]
My pet peeve on open-source, *-focused hardware: it should start with an artistic sketch and a mockup, not the final board and a shell wrapped around as an afterthought.
Valve[1] reportedly made over 100 mockups before settling on the final shape, most of them representing shapes only. Apple[2] had at least five iterations of nearly indistinguishable mockups for one of iPhone models that were discovered by fans.
It is certainly possible to build a radio equipment by starting from a block diagram and installation into enclosure, but that's development process for low volume technical instruments which measure of utility is electronic performance. A consumer product should look and feel good in hand, even when it's dead.
1: https://www.rockpapershotgun.com/valves-steam-deck-prototype...
2: https://www.youtube.com/watch?v=GXAsLCAbNGY
As someone that builds hardware all the time, your opinion is actually quite a common bias. The Idea that physical design (and aesthetics were important to Steve Jobs) can somehow reliably define the final technical form-factor is naive, and often leads to impractical products or vaporware.
Usually it is the common mistake that creates every camera that overheats, usb-c port that snaps off, or power adapter the size of a brick. Apple could have made the new iPad battery last another 2 hours, or make it 1.7mm thinner... They made it thinner, and provided less value to consumers in newer products.
In general, one MUST transition through every stage of the TRL or are bound to repeat the process from the start again at some point. Part of design revisions is figuring out whats possible (including physical volume constraints) with current technology, and whats appropriate in the projected market.
https://en.wikipedia.org/wiki/Technology_readiness_level
Notably, the physical volume of a battery is a physics constraint, and most of the mass of your iPhone is the battery (Steves team miniaturized everything else to reach the form it ultimately became.) The battery type is a requirement set by the desired function of the hardware, and chips slowly optimize for a given role (hence the trend of things getting slightly smaller/more-efficient, but compared to the battery volume it is negligible.)
Almost every business I've seen that prioritized the injection molded box first, has not survived to product launch.
One could disagree with physics, but then again most engineers will simply abandon that project. =3
I don't mean to teach fish how to swim, but - what I meant to say is, just, packaging, enclosure design, weight distribution, durability, etc shouldn't be - starting enclosure design AFTER final PCBA ought to be wrong.
I am, e.g. completely fine with cheap generic ready made enclosures[1][2][3] for low volume handhelds, and do understand that reality is reality, done is better than perfect, real designers ship, etc., I mean no offense to hardware rockstars either, and with that said, I really think I can say more higher priority to final form factor can be safely applied to projects like [4] and [5], despite obvious cliff between your and my qualifications.
1: https://uk.rs-online.com/web/p/hand-held-enclosures/1981369
2: https://www.takachi-enclosure.com/products/LC
3: https://www.aliexpress.com/item/1005006805827217.html
4: https://mikrophone.net/phone_big.png
5: https://mntre.com/media/reform_images/jacquelines-reform-ope...
In general, most prototypes are initially designed as a massive sprawling 2D development mess (from satellites to cellphones they are all the same.) After the key functions are verified/validated, than the unneeded resources are refined/removed through the optimization process.
Finally, the first physical PCB is reformed into whatever custom enclosure the marketer/designers defined. With the caveat that they understand the volumetric requirements for the device internals. Again, prior to dropping $60k on a plastic container mold, the design must first clear emissions pre-testing and certification documentation.
There is a reason hardware startups fail at a rate >5 times higher than service companies (1:63 hardware startups live past 3 years).
I would highly recommend taking a Design For Manufacturability course, or find a qualified Contract Manufacturer to handle the product gruesome details.
Most products I see now are pad-printed store-branded generic products from China. Usually nothing wrong with that kind of import trade, but fundamentally this is not a product design process.
Tip, no one is ever an expert with unknowns, but experience and standards help guide decisions on avoiding expensive mistakes... like handing your team an impossible assignment.
Best of luck, and be kind to your engineers =3
I wouldn’t call it a pet peeve but I understand where you’re coming from with this: but I think the main reason for it is electronic engineers, with little-to-no product design or even mechanical design/CAD background. IMO it’s a shame: it’s sort of like the open source hardware version of the “Blender before it got good UX” problem.
This is like, barely risc-v. As far as I can tell, there's a risc-v management micro, an esp32 that I'm not easily finding a part number for so may as well be Tenscilica, and an app processor that's ARM based. I don't understand the GPU chip if you have the app processor, and I don't understand the management micro if you have custom ESP32 firmware. And a lot of SoMs have WiFi + Bluetooth on board. So I also don't understand the ESP32. This really feels like it could be a card-edge SOM, battery, HMI, and modem. As per usual I find this project needlessly complicated and buzzwordy.
I was just wrapping my head around on how do they even run linux on the RISC-V microcontroller they use. Turns out there is a separate ARM for application processor.
Yeah. As I'm sure you're aware, you can get Linux capable RV. I mean you can build mmu-less as well but there's plenty of I think it's M extension cores out there. This isn't that. This is a design that happens to use at least one RV core and happens to be capable of hosting a modem card. It's not a RISC-V mobile phone.
From what I can tell, the RISC-V processor handles all of the phone functionality in a way that's almost entirely decoupled from the app-module/smartphone features. The phone part has its own firmware and drives the screen separately from the app-module. They added a green indicator light to show when the RISC-V "core" is using the screen vs when the app-module is.
The graphics processor is probably just for when the RISC-V core takes over the screen, as well.
What's the purpose though? You can put your own code on the app processor too. I don't know Android kernel dev but presumably with aosp you can do whatever the RV core does either in the A class core or using one of the many SoMs with built-in M class cores.
> an esp32 that I'm not easily finding a part number for so may as well be Tenscilica
On their dev board it's the usual esp32-wroom. They also say their esp32 firmware needs esp-idf 4.2, which doesn't support any of the risc-v esp32. So it is xtensa.
I agree that everything could be done with the esp32 alone (well, an wrover with extra RAM) but this project seems to be just a guy experimenting and having fun! Although I can see how someone might be cynical regarding this project being deliberately complicated/overengineered just to extract more money from the nlnet fund.
Great for experimentation, but that's where it should end. If this is a cash grab or anyone is seriously considering buying it I think better products do or could exist. They'd be easier -> cheaper to design, maintain, source and assemble. 3 chips to do what's already built into the SoM connector is unideal.
Hm. I'm not sure what to make of this, really.
The concept of a RISC-V based "assemble it yourself" phone is solid enough - there have been the PiPhone concepts based around a Pi Zero for long enough, and while I don't think they're terribly usable, they're also a fun looking little project.
But then they throw the ElipticCP concept on top, and sort of handwave it being "secure" if you're talking to someone else who is using a similar device, or similar capabilities, or such. And, unfortunately, there's not a lot of information about that I'm seeing (or, that which there is seems rather vague and handwaving).
https://mikrophone.net/about.html
> The security of the whole system is not compromised even though none of these modules is trusted, because all sensitive data is encrypted by the central MCU before sending it to a communication module. Secure communication uses a protocol EllipticCP originally designed for this project. It provides end-to-end encryption and an additional anonymizing layer based on the principle of onion routing. In order for a security protocol to function to its full extent, the end recipient in the communication channel also needs to use mikroPhone or some other phone with comparable security performances (in other words, both communication parties must be secure enough).
There's a lot of words in here that sound good, but there's a serious lack of details, and then when you go to build the phone, you have open JTAG ports to the device.
So I'm not really sure what threat model they're dealing with exactly. "People who can build their own hardware and firmware, who work in investigative journalism or human rights activists, who have iron clad control over their hardware, who want to talk to other people with identical hardware," maybe? It seems designed to counter remote threats only, and without a lot more details as to what it's doing, it's hard to say if it is or isn't doing that competently. I don't have the time right now to go dig through their firmware to see, unfortunately.
If it weren't a build it yourself sort of thing ("Here's the schematics, go get boards fabricated!") it would trip my honeypot sensors ("Secure Phones!" being more government ops than anything actually useful, IMO), but... it's not that, fairly obviously?
Dunno. I doubt it would work on any US carriers, they're all VoLTE only now. :/
Only kinda related, but I've been excited to try Genode OS on the PinePhone https://genode.org/documentation/release-notes/22.08 for a very different take on a secure mobile os
It can be runs in a VM on at least x86_64 too, which is useful for people wanting to experiment but who don't have a pinephone handy. :)
Tbh I would accept anything usable without being bound neither to Google nor Apple. Like a Linux phone but with usable apps which is quite important.
For example Samsung gets free MP3 player and more important, background-running voice recorder, which is extremely important for me, but was impossible to find on OnePlus One.
You should try GrapheneOS
It is basically Android with all the crap from Google removed.
Better yet, GrapheneOS allows you you sandbox Google's crap if you need or want it. Very useful when needing to use a proprietary app that requires it.
+1 Graphene works great
Jolla's Sailfish is another alternative. Linux, quite a few native apps and an Android emulation layer that makes it easy to use most F-Droid and Play Store applications.
Is Librem 5 not such a device?
As an owner and occasionally serious user of the above device, I can say that, no, it is not usable as a phone by any definition that includes portability. This is due to extreme bulk and still terrible battery life, even before we get to the experience of using PureOS and Gnome for your phone OS.
However, the kill switches are super cool and would be practical if the device were.
And it can run Android apps with Waydroid.
> The security of the whole system is not compromised even though none of these modules is trusted, because all sensitive data is encrypted by the central MCU before sending it to a communication module.
No way. You need to decrypt that stuff before sending it to the communication modules (BT, WiFi, cellular, display) and you get them unencrypted from the same.
If the communication modules can decrypt the stream themselves, then eavesdropping will happen there inside.
Why is this being pitched as a complete solution? There's no concrete explanation why it's more secure, just open source software = secure while rolling it's own stuff; and there's baffling component choices that completely conflict with each other. A color 400x840 screen is not needed for a "simple" phone, and having any possibility of redundant BT/WiFi radios is a baffling oversight.
There's 2 different ideas here, and instead of splitting them up into their own discrete projects that can excel at both ideas, they are turned into 1 mediocre project. Also, exposing JTAG in your final product and forgetting about physical security aren't good looks either.
Are all the needed software drivers open source? Or will this phone end up by using blobs, just like all other devices?
> just like all other devices
Except Pinephone and Librem 5, which have all free drivers.
Why downvotes? Only firmware is closed on both devices.
Note that esp32 (and esp8266) use proprietary, closed-source network stacks[0]
It's not a important in this project as there is a separate "main" MCU, but having radio module with closed-source software, active radios, and which you pass unencrypted data through (like bluetooth audio) might concern some people.
(The SIM module is likely closed-source too, but hopefully it's impact is much more limited - if you care about privacy, you would not send any data over cell phone networks unencrypted)
[0] https://github.com/espressif/esp32-wifi-lib/issues/1
less a criticism (as this is a fantastic project) and more a general comment about security protocols. The protocol (https://mikrophone.net/ecp.html) for privacy appears to require another MikroPhone device on the other side to communicate with.
the cryptographic backdoors I have encountered in my work were in closed loop systems where having a standards based interface to facilitate separate or independent implementations would have foiled the schemes, as replicating the sabotage in another project would have been far more complex.
the first student project is building this, the next really interesting one is reasoning about that security protocol.
the ideal protocol described provides good forward secrecy, and speculatively if I were looking for implementation sabotage I would look for where the padding nulls were used instead of bytes of the nonce to reduce its entropy to something brute-forcible, and off hand as far as threads to pull, whether the parity bit on the key could reduce the search space by %50 as either even or odd.
from a design perspective, if it only talks to copies of itself, why add the complexity of a new protocol? from a mass interception perspective, the "don't roll your own crypto" cliché is probably one of the most successful psyops of all time and I don't think it's a useful admonition in this case, but imo the question of "why" for a new protocol is the most interesting one.
I am glad that these sorts of projects exist. Even if the implementation may not be the greatest it at least provides an option which is not under the thumb of Google, Apple and others.. and it can always be improved over time.
However, I do wish there were some videos and photos of the completed products
Nothing stops you from buying one of those "granny phones" with big buttons and basic functionality. No traces of Google and Apple on them either.
It's like suggesting to live in cave. A smartphone can do much, much more than a feature phone.
> Software licensed under the GPLv2
Good for you, you get a cookie. Get back to me when you have a RYF certification and we’ll talk sales.
What is the cost for the hardware BoM?
Also curious why someone is motivated? Pretty great, would love a 3rd alternative option to Apple and Android.
Mostly I care about phone calls, texting, and web browsing.
> Mostly I care about phone calls, texting, and web browsing.
"Easy, Easy, Brutally Difficult."
If all you want is phone and text, there's no shortage of cheaper flip phone/candybar phones out there that handle it, though I will caution you that older versions of KaiOS, at least, struggle badly with handling any sort of modern text quantities (a few hundred messages on a phone on a KaiOS 2.x device lagged it badly enough that it stopped alerting me to new messages or phone calls, and I had to trim it down regularly, though even then it struggled).
I'm a fan of the Sonim stuff, it runs Android Go, and is properly stout.
Web browsing, though. That's hard. If you want a simple phone, your best bet is to carry a tablet or laptop for that sort of thing, and just hotspot off the phone if/when needed. Most current featurephones have a thing called a web browser, and it ranges from "almost useless" to "literally can't render the modern web." That's before you sort out using it on what is typically a 320x240 pixel display. You're way better off just carrying something different for that need.
Isn't that the other way around? I thought voice is usually the most complicated to implement, especially in 4G/5G which uses modified SIP/RTP. Mic and speaker has to work too. Web browsing OTOH at bare minimum require just simulated PPP over AT command interface, touchscreen, and Chromium.
If you're building your own cell modem, then, probably.
In terms of "finding hardware that can do the following things," pretty much any cell phone sold will support voice and text - though some don't do a great job with MMS. The web browser requires orders of magnitude more resources than voice/text, though. A Nokia from 20 years ago, with... I actually can't find how much RAM or storage, had no problems with voice or text. Wouldn't run a browser at all, though.
I was admittedly of the impression that most of the voice work was handled by the baseband, though. I've not built my own phones, unfortunately. I just use some basic flip phones for mobile use.
As recently as the Samsung Galaxy S7, Pinephone, etc., voice calls are done with high-level commands too. All you have to do is get the soundcard mixer settings right. Figuring out the correct settings is tricky but once you have them it's plain sailing.
Web browsers have a very broad interface with the underlying system.
Speaking from experience: getting calls and text working is much easier than getting a browser going in a new environment.
People, including a lot of very tenured web developers, radically underestimate how big browsers are in surface area now.
Any of WebGL, WebRTC, the MediaStreams, Web Audio or WebGPU by themselves are enormous, and on mobile SoCs will rely heavily on device specific drivers to accelerate their functions, or the battery runs out in 5 minutes.
> Web browsers have a very broad interface with the underlying system.
What do you mean? My Librem 5 just runs desktop Firefox since day one. Calls and texts were a problem initially though.
Firefox depends on many many parts of the operating system. Calls and texts, not so much. Starting from scratch, a kernel and little else, getting calls and texts working is easy compared to getting Firefox ported.
This looks really cool! I don’t know if this more of a feature phone or a smart phone though. Would like to see pictures of completed builds and what they can do.
Looking at the hardware, it's likely to be a "mostly usable interface to a cell modem." So, SMS, audio. No idea if it can handle MMS or not. And anything beyond that is iffy.
They've got some interesting concepts for a separate application processor that can route to the screen, but... right now, consider it the sort of project to build if you don't actually need to talk to anyone with any reliability.
Current status section mentions "3d printable phone case designed in FreeCAD", but there don't seem to be corresponding file. I think the project is practically in breadboard stage.
The main processor is a very low-performance microcontroller, so even "featurephone" might be ambitious.
Ah, another privacy-oriented phone project. As if the Pine-, Libre-, Jolla-, Neo900- etc. etc. endeavours weren't successful enough.
I was wondering - what is the status of those projects?
And because they are (mostly?) open source, why not start with one of them?
Neo900 is dead. Unfortunately. It was always on shaky ground (the nature of a hardware project) but what seems to have killed it was PayPal withholding its funds for long enough to take the wind out of key people's sails. PayPal just decided to abruptly lock out the project account one day after accruing a substantial number of down-payments, and refused to give the funds back for around a year. By the time some progress started being made again, the funds were no longer enough and the project was at that point based on seriously obsolete hardware (as opposed to the regular kind of obsolete most hardware projects have to work with).
Why do people trust PayPal with their futures? It's also Neo900's fault - everyone knows by now what PayPal does.
Why are paypal allowed to do this with impunity? You're not. I' not. Why are they allowed to break both the law and the social contract?
The problem is the hardware, not the software. Also, what you want as a paranoid person is your baseband not part of the SoC running your computer - this project hear does that, Jolla and others are using standard Android SoCs.
Jolla added libhybris to make it easy to use Android hardware adaptations - which at that time was needed to get a phone out (ste, which the first Jolla phone was supposed to be based on, decided to get out of the phone chip business during the prototyping phase, and that was the last vendor offering proper Linux drivers). I never was much of a fan of that as you just pull in way too much uncontrollable crap - unfortunately it works good enough that a lot of other projects then also jumped on that, instead of reviving a focus of doing proper Linux drivers (something I was worried might happen when the libhybris development started).
I'd argue software is the main problem. If you want to make a new smartphone OS, just target a pixel or something. The driver + kernel stack as pretty close to as open as you'll find anywhere. The hardware is flagship-grade, updated every year, and shipping now.
I've had zero luck putting a non-Android daily driver OS on it though. I'll define daily driver as "all of this works tolerably well":
Phone, SMS/MMS, web browser, podcasts, navigation, music player and camera.
Heck, drop the camera requirement for version one, and then you're down to "video, audio, GPS and phone stuff works".
Jolla's Sailfish OS is used as a daily driver by a small niche in EU, probably tens of thousands of users taking into consideration download and update traffic.
It's definitely usable as a daily driver. There are some rough edges if you only want to use native applications and want to avoid Android applications, which go through an emulation layer. But it's still pretty nice! Things like offline mapping work really well.
You can, by using the libhybris hardware abstraction layer I've mentioned. It is relatively simple, though still requires understanding of how low level stuff works. The main problems there are graphics and modem, both of which typically are not open drivers - and with that you then pull in half of your typical android system into your regular linux distribution just to get the hardware working.
If you don't care about the modem and graphics acceleration (or, in same cases, graphics output at all) you should be able to get it booting with the available kernel relatively easily.
Camera also tends to be not tends to be not that much of an issue - typically there's enough in the available kernel that you can get a gstreamer pipeline running, and then just have to figure out how to make it not look completely shit.
And after all that you still end up having a device with the baseband sitting on your SoC.
PinePhone development seems to be kicking along ok?
Genode (a secure OS in development for years) seems to be working decently well with it:
• https://genode.org
• https://genodians.org/nfeske/2024-02-15-fosdem-aftermath
... though most people are running various Linux distros from what I remember.
You traded the Bluesmobile for this?