Your PR was not ignored, and the author explained why they could not merge it as-is.
After your PR got closed you explained how to create the patchset from kernel.org sources which is the right approach, maybe that happened in other commits?
If it couldn't be merged as-is that is completely understandable, but why close it then? Why not say "can you tame this back?" instead the response was "this will break things and maybe you added malware".
The project maintainer may not want to keep PRs open that are not acceptable as is.
There is zero functional difference between holding the PR open indefinitely (and many times follow-up just never happens) and closing the PR until changes are made and where a new PR is then opened.
This isn't true though. There's may be no functional difference for the receiver/merger/maintainer but there's a large difference for the submitter - this kind of approach can often be the demotivational difference between finishing and abandoning branch work.
Sure, 95% of such PRs might never go anywhere, but with the contribution pool being that small, is there a strong reason to shrink it further?
I get that maintainers have a lot on their shoulders & expecting them to be perfect receivers of outside contrib is expecting a lot, but it's also why there's so much on their shoulders.
First things first: I never implied (or wanted to imply) that you were introducing malware in that patchset, just that you could introduce it and I wouldn't be able to find that in a PR so big. Sorry if that came out wrong.
Still, that 3.18.140 kernel is ancient, it's not worth doing anything with it unless we find a bug that prevents something from working. Especially since there _is_ a mainline effort, and there's a 6.0 based tree that has most of the things working already except for some bugs with the nand and audio.
And that's the reason why there hasn't been a new release lately, because I hadn't had a lot of time, and because I'm spending all my little remaining energy on trying to get the userspace working with mainline.
For those who may not know, the userspace acts as a sort of bridge between the baseband and the Pinephone, by proxying stuff between them (that's how you can hijack some things and implement voice calls and SMS). When moving to mainline, there's certain devices that cease to exist, some others needs adapting, and I'm taking the time to try and get openqti to be more flexible and out of the box support different audio settings for different models, different flash configurations (for those modems which don't have a dedicated user data partition etc)
I feel you should get more encouragement here. Thanks for your great work. You did a lot. Yes, the whole state of mobile is frustrating, but here is someone improving things. If our governments weren't the corrupt authoritarian shitheads they are, these kinds of trojan horses should be illegal.
Respectfully, you really, seriously need to work on your communication skills. You seem to be doing good work and I respect that (I use Mull, for one), but... you systematically sound fairly aggressive and complaining about everybody. Just for that I wouldn't want to contribute to any of your projects, and I wouldn't want to depend too much on them either (who knows who you will piss off next and where your projects will go).
For instance, let's look at what you describe here as "my PR was fixing a ton of stuff but it was ignored and closed".
First, the title of your PR is "Make the kernel less awful"... really? How would you feel if I opened a PR saying "Make DivestOS suck a little less, but let's be honest, it will still be a piece of shit after that"?
Not even mentioning that you say "Untested, but shouldn't require more than a handful drop/reverts". So you just come and drop a huge PR that you haven't tested, and then you complain that others don't pick it up?
Before closing your PR, the maintainer said:
> Don't get me wrong, it's impressive, but there's no way I'm going to merge this. You can't send someone 424 patches to a repo and expect them to stop everything they're doing for a month and checking them one by one in case just one of them fucks up the entire system (or contains some kind of malicious code), even less so on a 3.18.140 kernel that originally comes from Qualcomm.
That is very fair, and I would not call that "being ignored" at all.
Keep up the good work, and learn to communicate in a constructive way!
I think most people agree that such an ancient kernel is awful and can understand the comical take of that title.
No where have I claimed their project is bad.
> So you just come and drop a huge PR that you haven't tested
I actually wrote a response to this in this thread, but the parent comment was deleted.
tl;dr I had actually compared it to match kernel, for the original Google Pixel, and fixed it like matching so it was actually quite likely to work.
> I think most people agree that such an ancient kernel is awful and can understand the comical take of that title.
I did not find it comical at all, and I thought you were a jerk. And I have read many messages from you in different places (HN, the /e/ forums, git repos, etc), and every single time, I think you are a jerk.
Also my post above has a score of +17 (honestly I never get that many upvotes here), so I wouldn't think that most people think your PR was comical.
You can choose to ignore this and keep believing that most people find you funny, or you can try to reflect on it and possibly improve your communication skills.
I don't really care, to be honest. I just wouldn't want to work with you given how you communicate online.
You literally used the word "comical" in the previous post. English is not my language, but if I search for a definition, I get: "comical: arousing or provoking laughter".
> I think how you seek me out each time to call me names is.
I agree, it is actually funny, because I don't look for you. As I said, I don't want to be related to DivestOS because you seem toxic. I don't even know or recognize your usernames on the different forums, but somehow I seem to recognize your style ("That person is a bit of a jerk - wait, is it the DivestOS author, again?").
Also I wouldn't say I "seek you out each time to call you names", it's the second time in quite a while (unless there was a third and I had not even realized it was you again?).
> You literally used the word "comical" in the previous post. English is not my language, but if I search for a definition, I get: "comical: arousing or provoking laughter".
One can make an attempt at humour without the whole audience necessarily finding it funny. I was not confused by SubzeroCarnage's wording at all.
You call them out for lacking communication skills and being offensive, but if anything you're the one with lacking English comprehenshion, lashing out because of a misunderstanding on your part.
Sure, maybe :-). Would you mind explaining it to me, then? It went like this:
They said:
> I think most people [...] can understand the comical take of that title.
I said:
> I did not find it comical at all
To which they answered:
> I never claimed to be funny
To which I answered that their previous message literally said "the title I wrote was comical".
As you mentioned, I am "lacking English comprehenshion". Can you explain to me how saying "I wrote a comical sentence" does not imply "claiming to be funny"?
Note: it's not a free software baseband FW as you'd expect from that being said.
What the PinePhone does is using a low end Qualcomm SoC as the modem (which has a CPU core and all, and runs a stripped-down Android in the stock configuration).
This just replaces that part which you can already edit on your own Android phone, but doesn't touch the actual modem bits at all, which remain the provided binary.
Still, I believe having full control on the firmware of the phone modem is at least as important as having root on the phone - otherwise, the firmware can say "location off? no problem!" while continuing to get GPS position locks + transmit the position inside UDP packets that won't be visible to the CPU running the android kernel and communicating to the firmware.
EDIT: actually, you are partly wrong when you say "This just replaces that part which you can already edit on your own Android phone": many android phones use a modem module to have certification in different markets.
So you can't replace the modem firmware on most android phones I'm familiar with.
Don't be confused by the modem using adb and fastboot like the android phones: it has its own software stack, and runs its own OS a bit like Intel ME or AMD PSP on PCs.
Modern LTE/5G provides pretty accurate location out of the box without GPS so if you really wanted to hide you would really need to just shut off the entire modem. Fortunately, the PinePhone has hardware switches to do this!
Following the discussion on illegal cell tracking where several comments mentioned the firmware can be a problem, here's a link to a free-software firmware.
I believe this is important, because on Android the firmware controls the network connection (and GPS, etc). It has its own embedded Linux, flash and CPU so even if you have root and run a firewall on android, it can send packets that will not be visible to the android kernel.
Most firmware have adb and fastboot, which can be used to replace what's running there by something you can recompile and audit. If you don't like it, you can also restore the initial firmware, for ex: https://github.com/Biktorgj/quectel_eg25_recovery
It's pretty interesting to see the added features this replacement userland provides when considering the tenacity of the TLAs in slurping up the data of citizens and non-citizens alike. It's capabilities like these that freak me out when considering similar stacks like the rPI GPU blobs and intel management engine/SGX.
I don't expect with the public failure of Clipper that they simply gave up on the capability to run clandestine code on your hardware, I think they just changed tactics.
Totally feasible. Or, hey, put it on an SBC, use it as an incoming SMS proxy with a dedicated SIM so you can recieve 2FA SMS without need of having the SIM and a phone with you.
You must have a SIM in the laptop at home (that's a "2FA mule") but you can use the WiFi on the phone. That helps also in other scenarios.
The last time I was in Australia I had a dual SIM phone. I put an Australian SIM in the second slot and used it for calls within the country and for data. SMS from my country didn't reach me or cost an absurd amount, can't remember. The point is that I was out of reach of 2FA SMSes and I couldn't use one of my credit cards online. Of course their customer service told me that I could switch my account to my Australian number but that never worked, it's probably a common move in scams and identity thefts. A 2FA mule would have saved me somewhat, as in some remote areas there was only voice, if lucky, and data was so slow to be useless and WiFi doesn't exist in the middle of nowhere.
Anyway, would have I left my primary SIM at home and be unreachable on my way to and from the airport? Probably not.
2FA on SMS should die. Unfortunately it's very convenient for companies. There is little setup and they can send an SMS to any random customer with little friction on customer side. No app to install, nothing.
For circuit-switched voice, 3G/4G dongles have undocumented commands to enable an audio-only virtual serial port that sends/receives raw audio data to the host (and you control the call via good old AT commands).
For VoWiFi/VoLTE it's just SIP with custom auth (involving the SIM card, so you need to be able to talk to it - most modems provide a way to send/receive raw APDUs to the card) on a dedicated APN so you just need to implement support for this custom auth in any SIP client (Linphone?).
Nothing really. I think you have to do something to make sure USB audio is routed right (I think its in their wiki). Other than that, it would work just fine!
What is the actual risk of closed baseband with it's own cpu? Does it have access to the same memory as the OS kernel? If so, is it not possible to design SoCs/boards that have dedicated memory for the baseband so that the main OS can treat the baseband and data in its memory as untrusted?
The risk is that the baseband could be implementing similar features that this userland adds to the "distro" running on the modem (call, data, and SMS recording), and these features could be driven by signals from the cell network. Unless you have a tap on the data egress path to the RF section, it would be difficult to know if data like this was being exfiltrated from your device as it completely bypasses the host's stack.
I am not sure I fully understand what you mean, but my question was that if all important data/metadata is encrypted when it leaves the hardware that is trusted then why does it matter if there was a hostile malware on the baseband hardware? A sibling comment mentioned the pinephone has only usb and i2c to the baseband, so barring 0 days over the USB, unless USB also means whatever the equivalent of DMA on mobile is, then it can't impact trusted code.
This is kind if like my home ISP router. I don't care if it is compromised because I don't manage it and I don't trust it with any of my important data or expose it directly to trusted devices.
But isn't all this something the carrier can do anyway on their side? What do they gain by controlling the modem that they can't already get just from their own equipment?
This expands the pool of actors beyond network operators. If you can just interact with the cell directly by sending signals to it, you can interfere with the cell without involving the network operator.
I wonder if it'd be possible, at this level, to create an E2EE voice connection between two devices.
I'm not familiar with the stack or the voice data stream through the hardware.
If code in the blob is responsible for encoding maybe it would still be possible to use a methodology similar to video mpeg where the raw data producer is aware of the blocking scheme and can formulate the data in a way that it is not compromised by encoding.
If the stream is encoded in userland I suppose it would be quite a bit easier.
Another feature this makes me ponder on is if perhaps you could send arbitrary data over the voice channel (if the above is possible, this should be). Since most providers these days provide unlimited voice, you could proxy your internet traffic to a second device located elsewhere and gain unlimited data, as well as perhaps reap the benefits of the steganographic nature of the channel.
I hope you realize you are describing dial-up internet? I could see having an automated dialer integrated with the OS do a decent job of masking the set up and tear down time of the connections, but it would have even slower data rates than the days of landlines, because cellular audio quality is much, much, much worse. And more importantly the jitter is significantly worse. Even sending faxes over cellular, or even wired VoIP fails regularly and that is an even slower data rate than would be acceptable for dial-up internet.
Also I haven’t looked it up but I assume the battery life of the pine phone while on a phone call is at most a few hours, compared to days for an active LTE connection.
Yeah, true. They've made some pretty impressive perceptual voice codecs that take very little data, and using that as the carrier for transmitting data would eat into that quite a bit more. Though, I find steganographic methods quite fascinating and often catch myself pondering ways to exchange data privately where efficiency is a small aspect of the overall goal of the communication channel. I suppose "thought experiment" is a good description.
The most effective/efficient way to do E2EE voice is definitely to use an app that supports voice and transfers via the data channel.
It has had different phone numbers before, but we always ended up having some issue with some app where the it (correctly) thought the number was invalid, wouldn't allow you to reply etc.
So I settled with two easy to remember numbers: +22 33 44 55 66 77 for normal user<-->modem communication and +22 33 44 55 66 78 for Cell Broadcast message relays
This is just the user-space aspect of the modem, it still has a 40MB proprietary firmware blob that does all the fun stuff.
Also running long end-of-life and insecure Linux 3.18: https://github.com/the-modem-distro/quectel_eg25_kernel/blob...
I submitted a PR with my CVE auto-patcher which fixed many issues including numerous modem related ones which was ignored and closed: https://github.com/the-modem-distro/quectel_eg25_kernel/pull...
Your PR was not ignored, and the author explained why they could not merge it as-is.
After your PR got closed you explained how to create the patchset from kernel.org sources which is the right approach, maybe that happened in other commits?
If it couldn't be merged as-is that is completely understandable, but why close it then? Why not say "can you tame this back?" instead the response was "this will break things and maybe you added malware".
The project maintainer may not want to keep PRs open that are not acceptable as is.
There is zero functional difference between holding the PR open indefinitely (and many times follow-up just never happens) and closing the PR until changes are made and where a new PR is then opened.
> There is zero functional difference
This isn't true though. There's may be no functional difference for the receiver/merger/maintainer but there's a large difference for the submitter - this kind of approach can often be the demotivational difference between finishing and abandoning branch work.
Sure, 95% of such PRs might never go anywhere, but with the contribution pool being that small, is there a strong reason to shrink it further?
I get that maintainers have a lot on their shoulders & expecting them to be perfect receivers of outside contrib is expecting a lot, but it's also why there's so much on their shoulders.
First things first: I never implied (or wanted to imply) that you were introducing malware in that patchset, just that you could introduce it and I wouldn't be able to find that in a PR so big. Sorry if that came out wrong.
Still, that 3.18.140 kernel is ancient, it's not worth doing anything with it unless we find a bug that prevents something from working. Especially since there _is_ a mainline effort, and there's a 6.0 based tree that has most of the things working already except for some bugs with the nand and audio.
And that's the reason why there hasn't been a new release lately, because I hadn't had a lot of time, and because I'm spending all my little remaining energy on trying to get the userspace working with mainline.
For those who may not know, the userspace acts as a sort of bridge between the baseband and the Pinephone, by proxying stuff between them (that's how you can hijack some things and implement voice calls and SMS). When moving to mainline, there's certain devices that cease to exist, some others needs adapting, and I'm taking the time to try and get openqti to be more flexible and out of the box support different audio settings for different models, different flash configurations (for those modems which don't have a dedicated user data partition etc)
I appreciate the reply, happy to hear mainline efforts progressing too. :)
I feel you should get more encouragement here. Thanks for your great work. You did a lot. Yes, the whole state of mobile is frustrating, but here is someone improving things. If our governments weren't the corrupt authoritarian shitheads they are, these kinds of trojan horses should be illegal.
Respectfully, you really, seriously need to work on your communication skills. You seem to be doing good work and I respect that (I use Mull, for one), but... you systematically sound fairly aggressive and complaining about everybody. Just for that I wouldn't want to contribute to any of your projects, and I wouldn't want to depend too much on them either (who knows who you will piss off next and where your projects will go).
For instance, let's look at what you describe here as "my PR was fixing a ton of stuff but it was ignored and closed".
First, the title of your PR is "Make the kernel less awful"... really? How would you feel if I opened a PR saying "Make DivestOS suck a little less, but let's be honest, it will still be a piece of shit after that"?
Not even mentioning that you say "Untested, but shouldn't require more than a handful drop/reverts". So you just come and drop a huge PR that you haven't tested, and then you complain that others don't pick it up?
Before closing your PR, the maintainer said:
> Don't get me wrong, it's impressive, but there's no way I'm going to merge this. You can't send someone 424 patches to a repo and expect them to stop everything they're doing for a month and checking them one by one in case just one of them fucks up the entire system (or contains some kind of malicious code), even less so on a 3.18.140 kernel that originally comes from Qualcomm.
That is very fair, and I would not call that "being ignored" at all.
Keep up the good work, and learn to communicate in a constructive way!
Btw this is a great case for Chatgpt.
I am also aggressive over the internet. I don't know why. I'm so chill IRL.
Ive learned to copypaste my message and ask chatgpt to make it nice, but not eliminate the point.
I don't copypaste what it says, but I do find sentences that are nice, but still make my point. Its sooo good.
That is an interesting take indeed. And I respect the fact that you realized that you sound aggressive online and took action.
I will actually think about that: English is not my first language, and I feel like I sometimes unwillingly sound aggressive.
> awful
I think most people agree that such an ancient kernel is awful and can understand the comical take of that title. No where have I claimed their project is bad.
> So you just come and drop a huge PR that you haven't tested
I actually wrote a response to this in this thread, but the parent comment was deleted.
tl;dr I had actually compared it to match kernel, for the original Google Pixel, and fixed it like matching so it was actually quite likely to work.
> I think most people agree that such an ancient kernel is awful and can understand the comical take of that title.
I did not find it comical at all, and I thought you were a jerk. And I have read many messages from you in different places (HN, the /e/ forums, git repos, etc), and every single time, I think you are a jerk.
Also my post above has a score of +17 (honestly I never get that many upvotes here), so I wouldn't think that most people think your PR was comical.
You can choose to ignore this and keep believing that most people find you funny, or you can try to reflect on it and possibly improve your communication skills.
I don't really care, to be honest. I just wouldn't want to work with you given how you communicate online.
I never claimed to be funny, but I think how you seek me out each time to call me names is.
> I never claimed to be funny
You literally used the word "comical" in the previous post. English is not my language, but if I search for a definition, I get: "comical: arousing or provoking laughter".
> I think how you seek me out each time to call me names is.
I agree, it is actually funny, because I don't look for you. As I said, I don't want to be related to DivestOS because you seem toxic. I don't even know or recognize your usernames on the different forums, but somehow I seem to recognize your style ("That person is a bit of a jerk - wait, is it the DivestOS author, again?").
Also I wouldn't say I "seek you out each time to call you names", it's the second time in quite a while (unless there was a third and I had not even realized it was you again?).
> > I never claimed to be funny
> You literally used the word "comical" in the previous post. English is not my language, but if I search for a definition, I get: "comical: arousing or provoking laughter".
One can make an attempt at humour without the whole audience necessarily finding it funny. I was not confused by SubzeroCarnage's wording at all.
You call them out for lacking communication skills and being offensive, but if anything you're the one with lacking English comprehenshion, lashing out because of a misunderstanding on your part.
Sure, maybe :-). Would you mind explaining it to me, then? It went like this:
They said:
> I think most people [...] can understand the comical take of that title.
I said:
> I did not find it comical at all
To which they answered:
> I never claimed to be funny
To which I answered that their previous message literally said "the title I wrote was comical".
As you mentioned, I am "lacking English comprehenshion". Can you explain to me how saying "I wrote a comical sentence" does not imply "claiming to be funny"?
There's such a thing as unfunny comedians.
Note: it's not a free software baseband FW as you'd expect from that being said.
What the PinePhone does is using a low end Qualcomm SoC as the modem (which has a CPU core and all, and runs a stripped-down Android in the stock configuration).
This just replaces that part which you can already edit on your own Android phone, but doesn't touch the actual modem bits at all, which remain the provided binary.
You're right and I'm wrong!
I'm currently editing my summary to clarify.
Still, I believe having full control on the firmware of the phone modem is at least as important as having root on the phone - otherwise, the firmware can say "location off? no problem!" while continuing to get GPS position locks + transmit the position inside UDP packets that won't be visible to the CPU running the android kernel and communicating to the firmware.
EDIT: actually, you are partly wrong when you say "This just replaces that part which you can already edit on your own Android phone": many android phones use a modem module to have certification in different markets.
So you can't replace the modem firmware on most android phones I'm familiar with.
Don't be confused by the modem using adb and fastboot like the android phones: it has its own software stack, and runs its own OS a bit like Intel ME or AMD PSP on PCs.
Modern LTE/5G provides pretty accurate location out of the box without GPS so if you really wanted to hide you would really need to just shut off the entire modem. Fortunately, the PinePhone has hardware switches to do this!
> you can't replace the modem firmware
you can, but the modem would refuse to load uncertified fw.
It isn't uncommon for vendors to ship with Qualcomm Secure Boot not enforcing.
Following the discussion on illegal cell tracking where several comments mentioned the firmware can be a problem, here's a link to a free-software firmware.
I believe this is important, because on Android the firmware controls the network connection (and GPS, etc). It has its own embedded Linux, flash and CPU so even if you have root and run a firewall on android, it can send packets that will not be visible to the android kernel.
Most firmware have adb and fastboot, which can be used to replace what's running there by something you can recompile and audit. If you don't like it, you can also restore the initial firmware, for ex: https://github.com/Biktorgj/quectel_eg25_recovery
EDIT: replaced baseband by firmware. I confused one for the other. For context as to why it matters, see https://news.ycombinator.com/item?id=36658078
oh no breaking the law!!! /s
It is a pretty big problem when the authorities break the law, why does this provoke a sarcastic response?
So it's fine if it's legal?
Show me the man and I'll show you the crime. - chief of Stalin's secret police
It's pretty interesting to see the added features this replacement userland provides when considering the tenacity of the TLAs in slurping up the data of citizens and non-citizens alike. It's capabilities like these that freak me out when considering similar stacks like the rPI GPU blobs and intel management engine/SGX.
I don't expect with the public failure of Clipper that they simply gave up on the capability to run clandestine code on your hardware, I think they just changed tactics.
It’s just the userspace, so you are not much closer to actual “free-software”.
Anything stopping us from throwing a mini pcie version of this modem into a laptop and using it as a speaker phone?
Common decency.
Totally feasible. Or, hey, put it on an SBC, use it as an incoming SMS proxy with a dedicated SIM so you can recieve 2FA SMS without need of having the SIM and a phone with you.
Wouldn't you still need the SIM? We're just talking about shoving a headless phone inside a slot on a laptop, aren't we?
You must have a SIM in the laptop at home (that's a "2FA mule") but you can use the WiFi on the phone. That helps also in other scenarios.
The last time I was in Australia I had a dual SIM phone. I put an Australian SIM in the second slot and used it for calls within the country and for data. SMS from my country didn't reach me or cost an absurd amount, can't remember. The point is that I was out of reach of 2FA SMSes and I couldn't use one of my credit cards online. Of course their customer service told me that I could switch my account to my Australian number but that never worked, it's probably a common move in scams and identity thefts. A 2FA mule would have saved me somewhat, as in some remote areas there was only voice, if lucky, and data was so slow to be useless and WiFi doesn't exist in the middle of nowhere.
Anyway, would have I left my primary SIM at home and be unreachable on my way to and from the airport? Probably not.
2FA on SMS should die. Unfortunately it's very convenient for companies. There is little setup and they can send an SMS to any random customer with little friction on customer side. No app to install, nothing.
Why is pc modem hardware so rare? I would love to use my laptop to make telephone calls directly but cannot find anything on Amazon that does this.
For circuit-switched voice, 3G/4G dongles have undocumented commands to enable an audio-only virtual serial port that sends/receives raw audio data to the host (and you control the call via good old AT commands).
For VoWiFi/VoLTE it's just SIP with custom auth (involving the SIM card, so you need to be able to talk to it - most modems provide a way to send/receive raw APDUs to the card) on a dedicated APN so you just need to implement support for this custom auth in any SIP client (Linphone?).
No, check modemmanager for devices that support this. Not sure if there is a frontend application for that though.
Nothing really. I think you have to do something to make sure USB audio is routed right (I think its in their wiki). Other than that, it would work just fine!
What is the actual risk of closed baseband with it's own cpu? Does it have access to the same memory as the OS kernel? If so, is it not possible to design SoCs/boards that have dedicated memory for the baseband so that the main OS can treat the baseband and data in its memory as untrusted?
The risk is that the baseband could be implementing similar features that this userland adds to the "distro" running on the modem (call, data, and SMS recording), and these features could be driven by signals from the cell network. Unless you have a tap on the data egress path to the RF section, it would be difficult to know if data like this was being exfiltrated from your device as it completely bypasses the host's stack.
Maybe we should also mention that the SIM talks to both.
Ignoring that (which we shouldn’t), if the CPU has an IOMMU it can completely isolate the modem from the rest of the system.
(“Completely” here is also ignoring denial of service and side channel attacks, like timing or the sim card.)
on the pinephone, the modem is connected to the application processor via usb and i2s (for audio)
no need for a frequently buggy iommu
I am not sure I fully understand what you mean, but my question was that if all important data/metadata is encrypted when it leaves the hardware that is trusted then why does it matter if there was a hostile malware on the baseband hardware? A sibling comment mentioned the pinephone has only usb and i2c to the baseband, so barring 0 days over the USB, unless USB also means whatever the equivalent of DMA on mobile is, then it can't impact trusted code.
This is kind if like my home ISP router. I don't care if it is compromised because I don't manage it and I don't trust it with any of my important data or expose it directly to trusted devices.
But isn't all this something the carrier can do anyway on their side? What do they gain by controlling the modem that they can't already get just from their own equipment?
This expands the pool of actors beyond network operators. If you can just interact with the cell directly by sending signals to it, you can interfere with the cell without involving the network operator.
I wonder if it'd be possible, at this level, to create an E2EE voice connection between two devices.
I'm not familiar with the stack or the voice data stream through the hardware.
If code in the blob is responsible for encoding maybe it would still be possible to use a methodology similar to video mpeg where the raw data producer is aware of the blocking scheme and can formulate the data in a way that it is not compromised by encoding.
If the stream is encoded in userland I suppose it would be quite a bit easier.
Another feature this makes me ponder on is if perhaps you could send arbitrary data over the voice channel (if the above is possible, this should be). Since most providers these days provide unlimited voice, you could proxy your internet traffic to a second device located elsewhere and gain unlimited data, as well as perhaps reap the benefits of the steganographic nature of the channel.
I hope you realize you are describing dial-up internet? I could see having an automated dialer integrated with the OS do a decent job of masking the set up and tear down time of the connections, but it would have even slower data rates than the days of landlines, because cellular audio quality is much, much, much worse. And more importantly the jitter is significantly worse. Even sending faxes over cellular, or even wired VoIP fails regularly and that is an even slower data rate than would be acceptable for dial-up internet.
Also I haven’t looked it up but I assume the battery life of the pine phone while on a phone call is at most a few hours, compared to days for an active LTE connection.
It’s a funny thought experiment though.
Yeah, true. They've made some pretty impressive perceptual voice codecs that take very little data, and using that as the carrier for transmitting data would eat into that quite a bit more. Though, I find steganographic methods quite fascinating and often catch myself pondering ways to exchange data privately where efficiency is a small aspect of the overall goal of the communication channel. I suppose "thought experiment" is a good description.
The most effective/efficient way to do E2EE voice is definitely to use an app that supports voice and transfers via the data channel.
Telco systems validate and may transcode voice data between phones, so the functionality is limited.
ZRTP may be of use. Not sure if it will survive reencoding.
> Modem will answer to the number: +22 33 44 55 66 77
+223 is the country code of Mali.
It has had different phone numbers before, but we always ended up having some issue with some app where the it (correctly) thought the number was invalid, wouldn't allow you to reply etc.
So I settled with two easy to remember numbers: +22 33 44 55 66 77 for normal user<-->modem communication and +22 33 44 55 66 78 for Cell Broadcast message relays