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

81–90 of 90 posts

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

#81

Post by 6SixTy »

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.

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

#82

Post by My2Cents276366 »

canadiantim wrote: post #26
p0w3n3d wrote: post #2

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.

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.

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

#83

Post by NotPractical »

hedora wrote: post #55
umbra07 wrote: post #30

Earlier quoted context omitted.

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…

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.

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

#84

Post by NotPractical »

aftbit wrote: post #62
umbra07 wrote: post #30

Earlier quoted context omitted.

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…

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

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

#85

Post by [deleted] »

saagarjha wrote: post #73
gruez wrote: post #39

Earlier quoted context omitted.

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

It is very difficult to protect against AFU attacks, because any remote 0-click can work for AFU unlocks.

[deleted]

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

#86

Post by justinclift »

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?

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.

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

#87

Post by vilvo »

gruez wrote: post #38
vilvo wrote: post #22

Earlier quoted context omitted.

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.

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

#88

Post by numpad0 »

Joel_Mckay wrote: post #52
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…

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

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

#89

Post by Joel_Mckay »

numpad0 wrote: post #88
Joel_Mckay wrote: post #52

Earlier quoted context omitted.

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…

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

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

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

#90

Post by Arch-TK »

mmooss wrote: post #25
Arch-TK wrote: post #24

Earlier quoted context omitted.

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

Why do people trust PayPal with their futures? It's also Neo900's fault - everyone knows by now what PayPal does.

Really 3 points:

* This was long ago enough that PayPal wasn't _quite_ as famous for its practices.

* In Europe people generally assume that companies big and small won't try to fuck you over because there are usually repercussions. Apparently American companies are exempt.

* When trying to get sizeable donations for a moonshot hardware project with high risk of failure it's ideal if donating didn't involve entering an IBAN. (Although I think kickstarter wasn't considered because the project was so niche that there was no chance of hitting a "milestone" in a reasonable time and the approach was to use funds as they came in order to allow the project to make steady progress. The idea being that people who were unconvinced earlier might become convinced later and you'd slowly attract enough support as you progress the project. I think the incident pre-dates crowd supply.)

Post reply on HN