Don’t have one yet but this phone is on a good trajectory for security. So that’s my wishlist. Sorry but fancy cameras and high resolution doesn’t do it for me. Let the other guys do that. They think all you do is watch movies and play games all day and need to do it faster every two years.
WIFI Calling and Texting (with cellular off)
Tethering (to laptop for instance) using USB or bluetooth.
Dynamic ISMI/IMEI
Optional ability:
A. Connect to the closest tower; default
B. Connect to a nearby tower of your choice, even if only 2 exist.
Secure texting that can interface with normal texting like iMessage does.
Modular modem that can be swapped out along with it’s ISMI number like a battery and plenty of available modules to go with it.
5G I think this only adds security in one place but loses it somewhere else compared to 4G.
I grok it. Firefox ESR on Mobian-Phosh has the controls, menus and address bar at the bottom in portrait, but moves them to the top when you rotate to landscape. I’d like that as default for everything in adwaita.
Can you explain how that works and which phone hardware / modem supplier has developed such technology? Is it similar to random generated Mac Address for obfuscation purposes?
It wouldn’t surprise me if it is generally not possible to change the IMSI - and even if you can change it, your mobile provider might notice if it has been changed, and thereby reject your registration on the mobile network.
Since we are talking about a hypothetical Librem 5vN, maybe it has an eSIM rather than a SIM, and that could add to the puzzle.
Bear in mind that in some jurisdictions it may be illegal to change the IMSI or the IMEI.
Under the battery - like the OpenPGP card - so you can’t fry the card by removing it while powered (from the battery).
Hmmm. Not sure about the space requirements there - and the SoC probably isn’t going to be up to the job of getting full speed out of an NVMe drive any time soon.
It would improve modularity and expandability though.
I think that’s “just” a firmware limitation even on the Librem 5v1.
However if the eMMC were really removed then the SD card reader could be interfaced via SD and would then become bootable with the current firmware.
Conversely, I’m pretty sure that NVMe booting is not currently possible - so that would need firmware development.
Or maybe just 8GB and be done with it. Going from 3GB to 4GB isn’t much of a jump.
PS Having plenty of experience running Raspberry Pi devices off uSD card, I wouldn’t be that keen to have my Librem 5 booting and running off uSD card.
NVMe drives use an M.2 connector but they use the PCIe pins on the M.2 connector that are probably not connected in the actual phone today and in any case the SoC may have limited support for PCIe. (So I’m not sure how many lanes you would get for your drive and whether the existing PCIe lanes are already in use for something else.)
There would also be theoretical concerns about giving an unknown device direct access to memory.
As it stands today, allowing an NVMe drive would mean 3 M.2 slots:
WiFi/BT card - uses SDIO pins on its M.2 slot
modem card - uses USB pins on its M.2 slot
NVMe drive - would theoretically use the PCIe pins on the M.2 slot
My concern about space is that even the smallest NVMe drive (and they do get somewhat more expensive at the smaller lengths) is quite a bit larger than an eMMC drive. Then you’ve got the overheads of the connector (whereas the eMMC drive would be a soldered-on chip).
Edit: But, yes, if you forced the customer to choose between modem and NVMe drive (but you connected both sets of pins to that M.2 slot), it might just be doable. Trouble is, I actually want to make calls on my phone … so this only really works if someone is absolutely determined to use only internet-based calling when within range of WiFi.
Then there’s also the power requirement of an NVMe drive …
I think thats a software issue, i fried my SIM once! It doesn’t fry the SD Card typically. When a remove is detected it needs to unpower the USB bus. Timing it right where whatever the first contact pin is that gets disconnected in either the SIM, or SD Card will become the input signal for a power off.
I think @dos was indicating that latest uboot can actually boot from the SD card (which in the Librem 5 appears as a USB drive). So that’s sorted. Up to a point. My understanding is that the boot ROM supports only a) boot from host over USB using uuu and b) boot from native SD (which in the Librem 5 means the eMMC drive). So booting from the SD card is dependent on a valid and working eMMC drive (but once the boot ROM loads uboot from the eMMC drive, uboot can then continue the boot from any technology for which support exists in uboot).
There may be no actual way of booting directly from a USB drive, much less from an NVMe drive.
Likewise, if the eMMC drive is removed from the design and the card reader interfaced directly via SD then you would now be able to boot only from the SD card (other than from a host via uuu) and you still wouldn’t be able to boot directly from a USB drive, much less from an NVMe drive.
Since we are blueskying about a hypothetical future Librem 5vN, that isn’t a fatal problem - but it adds to the difficulty and I leave it to your imagination as to how that might be hacked around, or otherwise.
Sorry I can’t help you with that. Yes it would be kind of like dynamic MAC.
It’s probably rare for legal reasons in some places. It’s perfectly okay for the cellular providers to not secure the protocols against ISMI catchers like they should have done with 5G. Oh but we can’t have the general public being untrrackable by allowing different phone identifiers even though that happens anyways on the internet with VPNs and TOR.
Hmmm… seems reminiscent of my experience with Pine64 products.
When I started using the Pinephone as a daily driver, it booted Mobian from the SD (it came with PMOS on the eMMC). If the SD was inserted, it booted Mobian, if not, it booted PMOS. At some point after that, something changed and I couldn’t boot the latest version of Mobian without first flashing a boot loader (I forget which one) to the eMMC. Boot behavior changed so that the user had to hold the volume down button during post to get it to boot from SD. The Pinephone mostly sits on a shelf now, with a dead modem. That’s OK, I like the L5 much better.
I also have a Pinebook Pro. It came with Manjaro on eMMC. It performs well, but I don’t really feel at home on the Arch base or KDE. I put Armbian on the SD and it very performant – it isn’t appreciably slower than running from the eMMC. I bought a ribbon cable, connector and NVMe drive, but haven’t installed it yet. I’ll need to take time to figure out how to install the required boot loader!
ARM is sorta strange. Maybe things will standardize a bit when we are all running RISC5.
to add to the bootable SD discussion, on phonesetup it could ask you to create a bootable linux recovery partition on the SD. That way jumpdrive or ssh is no longer needed and issues can be fixed right on the phone.
if the contents of the eMMC drive are really hosed then you won’t be able to boot from uSD card anyway (so Jumpdrive would still be needed - or at least more accurately uuu would still be needed)
some people actually want to boot from the uSD card (so the recovery “partition” would be on the eMMC drive) - that is, the roles would be swapped, which in no way invalidates your suggestion, just makes it more complicated
A couple items i thought about but more nice to have or in case none of my top 5 items are being considered:
secondary built in battery, keeps time when main battery is removed, main battery completely drains, or during ~month long shipping without main battery, two provide enough juice to keep the phone running while swapping the main battery - so say 2min runtime, three could even do voltage levelling during peak demand, or when charger is plugged into phone.
another configurable HKS switch, that could be used to turn GPS off, or turn notifications off etc…
I’m opposed to this from a troubleshooting standpoint. It’s nice to know that when I pull the battery there’s no power going anywhere and having another battery to pull, maintain, replace, seems like it would be more inconvenience than convenience to me.
Ok how about not a battery but a super capacitor? Something if you need to deplete the component you can say hold the power button for 40 seconds or some other process to ensure you can trouble shoot without power present?