Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

mikrophone.net

Post reply on HN
Print view View original

51–60 of 90 posts

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#51

Post by finaard »

mmooss wrote: post #17
10xalphadev wrote: post #5

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?

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).

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#52

Post by Joel_Mckay »

numpad0 wrote: post #20

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 i…

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

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#53

Post by fidotron »

tonyg wrote: post #40
numpad0 wrote: post #12

Earlier quoted context omitted.

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.

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 g…

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.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#54

Post by lizknope »

wepple wrote: post #49
ziddoap wrote: post #11

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 offere…

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.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#55

Post by hedora »

umbra07 wrote: post #30
Syonyk wrote: post #18

Earlier quoted context omitted.

> ...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, ye…

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 tha…

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.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#56

Post by theamk »

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

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#57

Post by Valord »

wepple wrote: post #49
ziddoap wrote: post #11

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 offere…

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

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.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#58

Post by hedora »

finaard wrote: post #51
mmooss wrote: post #17

Earlier quoted context omitted.

I was wondering - what is the status of those projects? And because they are (mostly?) open source, why not start with one of them?

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, deci…

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".

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#59

Post by finaard »

hedora wrote: post #58
finaard wrote: post #51

Earlier quoted context omitted.

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, deci…

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 br…

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.

Re: MikroPhone: A privacy enhanced, simple and featured RISC-V mobile phone

#60

Post by wepple »

Valord wrote: post #57
wepple wrote: post #49

Earlier quoted context omitted.

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

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.

Post reply on HN