[HN Gopher] MikroPhone: A privacy enhanced, simple and featured ...
___________________________________________________________________
MikroPhone: A privacy enhanced, simple and featured RISC-V mobile
phone
Author : voxadam
Score : 210 points
Date : 2024-10-03 15:41 UTC (1 days ago)
(HTM) web link (mikrophone.net)
(TXT) w3m dump (mikrophone.net)
| p0w3n3d wrote:
| 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.
| phasnox wrote:
| You should try GrapheneOS
|
| It is basically Android with all the crap from Google removed.
| nvllsvm wrote:
| 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.
| skeptrune wrote:
| +1 Graphene works great
| canadiantim wrote:
| Is Librem 5 not such a device?
| fsflover wrote:
| And it can run Android apps with Waydroid.
| nextos wrote:
| 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.
| metadat wrote:
| 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.
| Syonyk wrote:
| > _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.
| numpad0 wrote:
| 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.
| Syonyk wrote:
| 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.
| tonyg wrote:
| 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.
| fsflover wrote:
| > 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.
| tonyg wrote:
| 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.
| fidotron wrote:
| 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.
| kebokyo wrote:
| 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.
| jdietrich wrote:
| The main processor is a very low-performance microcontroller,
| so even "featurephone" might be ambitious.
| Syonyk wrote:
| 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.
| numpad0 wrote:
| 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.
| 10xalphadev wrote:
| Ah, another privacy-oriented phone project. As if the Pine-,
| Libre-, Jolla-, Neo900- etc. etc. endeavours weren't successful
| enough.
| mmooss wrote:
| I was wondering - what is the status of those projects?
|
| And because they are (mostly?) open source, why not start with
| one of them?
| Arch-TK wrote:
| 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).
| mmooss wrote:
| Why do people trust PayPal with their futures? It's also
| Neo900's fault - everyone knows by now what PayPal does.
| harry8 wrote:
| 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?
| finaard wrote:
| 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).
| hedora wrote:
| 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".
| finaard wrote:
| 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.
| nextos wrote:
| 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.
| Syonyk wrote:
| 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. :/
| ziddoap wrote:
| 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.
| Syonyk wrote:
| > _...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.
| vilvo wrote:
| 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.
| pushupentry1219 wrote:
| Depends on your use case but.. just only use WiFi and never
| put a (e)SIM in it.
| supriyo-biswas wrote:
| 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
| gruez wrote:
| 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.
| kotaKat wrote:
| 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.
| umbra07 wrote:
| 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.
| hedora wrote:
| 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.
| aftbit wrote:
| 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.
| Syonyk wrote:
| 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.
| stonogo wrote:
| 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.
| nonrandomstring wrote:
| > 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.
| gruez wrote:
| >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...
| Syonyk wrote:
| 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.
| saagarjha wrote:
| It is very difficult to protect against AFU attacks,
| because any remote 0-click can work for AFU unlocks.
| wepple wrote:
| 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
| lizknope wrote:
| 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.
| joemazerino wrote:
| There is a distinct difference between a publicly offered
| MikroPhone and a phone swapped between criminals. Not every
| phone is some honeypot.
| lazyeye wrote:
| 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.
| aksss wrote:
| (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.
| Valord wrote:
| 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.
| wepple wrote:
| 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.
| wslh wrote:
| 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.
| wepple wrote:
| 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.
| Neywiny wrote:
| 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.
| tredre3 wrote:
| > 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.
| Neywiny wrote:
| 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.
| mshockwave wrote:
| 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.
| Neywiny wrote:
| 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.
| entropicdrifter wrote:
| 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.
| Neywiny wrote:
| 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.
| numpad0 wrote:
| 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
| explodingwaffle wrote:
| 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.
| Joel_Mckay wrote:
| 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
| spencerflem wrote:
| 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
| justinclift wrote:
| 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. :)
| notorandit wrote:
| Are all the needed software drivers open source? Or will this
| phone end up by using blobs, just like all other devices?
| fsflover wrote:
| > just like all other devices
|
| Except Pinephone and Librem 5, which have all free drivers.
| fsflover wrote:
| Why downvotes? Only firmware is closed on both devices.
| pkphilip wrote:
| 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
| a5c11 wrote:
| 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.
| fsflover wrote:
| It's like suggesting to live in cave. A smartphone can do
| much, much more than a feature phone.
| notorandit wrote:
| > 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.
| teddyh wrote:
| > _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.
| teddyh wrote:
| You traded the Bluesmobile for this?
| theamk wrote:
| 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
| motohagiography wrote:
| 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" cliche
| 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.
| 6SixTy wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-04 23:02 UTC)