As an EE, plenty of chips you can get are built-in computers. You’re not going to write code that you make your users run (what a support nightmare!). You build your chip and provide an API.
And as a user, do you really want to figure how to run someone else’s code? Or do you just want a self contained unit that you slap onto your board that you just control via API?
Think of chips as microservices.
Hardware engineering might be floor 1 of a building and microservices might be floor 19. Yes, they are very far apart, but one day, you realize that every floor has a bathroom. When you go down to floor 1, you might not know where the bathroom is but you know that it exists and how it will probably function. You are already 80% of the way there.
The shitter of microservices is JSON marshalling. The shitter of hardware is clock jitter.
So crazy to think about that all being done by hand back then.
Many a late night was spent in the library looking up those addresses and seeing if some where still available.
Embedded programming? Dealing with signals?! God forbid, man.
There’s just so much of everything! Terrifying! But fun!
React? Angular? Node? What happened to Notepad and Apache?
I’ve found that’s easier to build a simple UI by loading chromium + webapp than having to deal with the intricacies of multitarget crosscompiling.
As much as I'm starting to hate Qt, I can still have it up and taking to hardware in a few minutes. And the onscreen touchscreen keyboard is worth the money.
One of the devices I’m working on had to use rust (we were looking for some niche libraries, and we found that the C ones weren’t working, while the Rust ones did).
Building GUIs in rust is still a WIP, and I had to spend 2-3 days fixing libs and tweeking stuff to get to something that compiled but was very buggy.
Instead of losing more time on that I set chromium + apache on the thing, and built the GUI as a web app. The rust executable has a simple API with actix that works flawlessly.
In that case it was the perfect solution because I had to add an API for remote management anyway, but I found the approach quite nice to work with.
I can get a decently functional UI app working in native code with just the SDK for whatever platform it’s on, but try to use React and suddenly I’ve got a web of 200 dependencies, each more shady than the last. And that’s just for “hello, world”
Plus the JavaScript engine is single-threaded and insanely slow.. it’s gross. I’m guessing that one of these days app developers are collectively going to snap out of it and throw Node in the trash
As single-board devices get faster and cheaper by the week there's a flood of developers that have cut their teeth on Node/JS/React and they get something working on a Raspberry Pi and think "Yeah, embedded development is a piece of cake. I can do this."
And maybe they're right, because doing it all by scratch and cobbling together robot parts to make a system work is just really getting to be old.
I used to get annoyed at the RPi newbies but now I welcome it as job security because someone still needs to write the bootloader and drivers. And if you read StackOverflow/Reddit you'll see there's nobody teaching that anymore.
Then again, any company that takes firmware engineering seriously can make devices 5+ years before Moore's Law makes it feasible for others, so maybe there'll always be room for us.
You must be a Broadcom user. My sympathies. =)
But I totally hear you. I'm not as pessimistic because I tend to follow parts that the automotive sector uses (yeah, not great right now) and they typically don't put up with random Chinesium parts and code. And yeah, it seems more and more like everyone is just throwing Linux into the mix and hoping that some OSS developer and/or Otavio Salvador swoops in and fixes things up.
RISC-V may be a way out of this. Maybe. Or it will make things ten times worse.
Why not, out of curiosity?
Nothing wrong with Apache, but syntax highlighting would be nice to have in Notepad.
For self-learning, frontend is orders of magnitude more accessible.
Every single time I touch anything web-related I discover that the entire landscape has shifted, all the tools I used last time are now abandonware, and I have to figure out everything anew. It may be more accessible if you're starting from scratch, but it's a constant treadmill that you instantly fall off of as soon as you do anything else. And when something doesn't work? Good luck finding out what's happening in the countless layers on top of layers on top of layers.
Embedded has advanced a lot on this front, but for a lot if the industry, good luck finding anything but the original documentation.
That’s only the case if you use the small (tiny!) subset of parts that everyone uses.
If instead of using some nice and common stm32FXX MCU, you need to work with some obscure Renesas or Fujitsu for example, prepare for a world of pain.
The good thing with web stuff is that you can swap frameworks until one does what you want nicely, and leave it at that. You can’t really change the IC in your board just because the I2C module is doing something weird.
Treat MDN as documentation for registers. :)
I think you are exeggarating. Over last few years, there were no hard deprecations, except for AngularJS. Many tools, popular in past, went "maintanence mode" and receive mostly bug fixes, but these tools are still viable.
Then got into Arduino programming. There are tutorials for that online. Try communicating with other Chips like a Shift-Register, then something that uses a standard serial protocol (ex. I²C).
When you feel like you have a good grasp of the basics, I recommend getting a development board and doing the same there.
Most Microcontrollers (ARM Cortex Processors at least) are pretty similar: You get a datasheet and a User's Manual. The User's Manual describes a bunch memory addresses, which control the built-in peripherals. There are excellent descriptions of what value will give you what result, but it can be a bit daunting to get your head around it at first.
I recommend a chip that has a so called "Board support Package". I have experience with LPCOPEN. This will make things a bit easier, as you don't have to figure out each register address for each thing and can instead use functions like "Chip_TIMER_Enable(timer_t timer)".
There is a lot more to it, but once you get started, you usually always see the next step.
It's very doable with dedicated study and I'd argue it's one of the best ways to get your design ability to rise to the level of being able to build something from scratch, without reference to other code / searching google for answers.
"How does a USB keyboard work? by Ben Eater:
My strategy has been to get into 80s game consoles where assembly programming was expected but the platform is small and standard enough that I can use emulators with memory views/debuggers & see everything going on.
heck at the end I might even have a game!
I'm starting out on z80 since I have an MSX and I hope to move to Sega Megadrive/Genesis later since I hear nothing but good things about the motorola 68k. The z80 seems pretty easy to understand (though it's not always consistent).
It's worth checking the limitations of the video and sound hardware to see what you like as well. I'm partial to FM synthesis so Sega consoles make sense to me. 8-bit stuff is going to land you with really tough colour restrictions (often about 3 per 8x8 square, tops). You may want to start with the "16-bit" era, which generally used 4-bit colours (16 for the whole screen, easier to create assets for).
Programming is laying the bricks, the cables, etc. Basically doing the actual building.
Software engineering as in other engineering disciplines is more concerned with making sure everything actually works and fulfills certain standards of quality. The planning, design and architecture part of the work.
For the last decades the person doing the programming and engineering were usually the same, but they are more and more drifting apart with more engineering focused roles like software architect.
In much of the world engineer is also a protected title that requires formal education like with doctors or lawyers. The US is using it pretty inflationary.
Programming is more concerned how it's implemented on the specific hardware/language, and how its limitations and advantages play a role in the implementation.
You can know both, they intersect in a lot of places but, programming goes deeper, and software engineering goes higher.
My missing component was that there was no mind-to-mind feedback loop conveying this knowledge and experience gained by the coders back to the designers, from which it would inform the designers' future designs. (And there was no regular feedback about how well the design fit the problem and if the design required radical changes during coding and testing, although some of that is more an administrative concern than a technical one.) The "coders", by the way, were quite capable of designing their own programs - and did. I don't know why the firm had this subset of design-only'ers; they were smart and maybe the firm wanted to hang on to them and maybe "coding" roles were intended for brand new employees.
I feel like developer is the best name for what we do, it doesn't limit us to the act of coding and it doesn't make the presumption we're engineers (very few of us actually are).
Then again if I could choose I'd probably prefer computer programmer, it doesn't get confused with property developer and pretty specifically covers what we do.
Any good degree should be covering all the software lifecycle stuff and general information systems as a concept.
I guess there are definitely people out there that have no interest in the business side of things but I think theyre outliers.
But now that I think about it maybe I'm wrong, I know a lot of business product people and even other developers just assume I don't know anything about business. At least that's what's happened now working for an American company. Working for Aussie companies it's just assumed that were sort of business analysts as well.
That's where I draw the line.
https://www.bosch-sensortec.com/media/boschsensortec/downloa...
You might think an accelerometer just outputs acceleration data. I've used some that were purely analog; as an acceleration moved a mass, a strain gauge or piezo element flexed; the output wires were simply analog signals. But these excerpts:
> ...combines precise acceleration and angular rate measurement with intelligent on- chip motion-triggered interrupt features.
> The IMU provides highly accurate step counting, motion detection
> provides an intelligent power management system enabling motion-triggered always-on features to run inside the ultra-low power domain of the IMU
That ultra-low power domain of the IMU doesn't have dedicated logic to do step counting, it has a processor. The GPS IC has a processor. The power management IC is not just a voltage regulator, it contains a processor. The uSD card or UFS flash IC contains a processor. The camera sensors contain processors. The display controller contains a processor. Looking at a teardown, I can't see too many more ICs on a smartphone motherboard...oh, I suppose the noise-cancelling/speak to wake functions of the microphone ADC are probably also implemented by a processor. Some of those, depending on the manufacturer's vertical integration and the age of the device, are inside the SoC, but many of those functions that you might imagine to be hard-wired are actually running in firmware.
This is a good analogy, but not in your favor.
This is all part of the disease of modern computing where you program against a giant machine with a giant interface and you set a few config variables and have no idea or control over how it will work and your program winds up full of unintended behavior. See: game engines, gstreamer, web frameworks, browser API, HDMI modules, terminal emulators, shells (bash, etc).
The more components with a million eyes watching it, the more attention you can direct toward the rest.
I'm not convinced that this is true to a meaningful degree. It's certainly theoretically true.
However, we've now had a number of events where bad things were found in fundamental and popular OSS software, and those things existed for years or even decades before being found. And who knows how many more exist that haven't been found, or at least publicized, yet (and may never be).
I think the reality is that most devs aren't deeply examining the tools and libraries they use. How could we? We'd spend all of our time vetting software and little time writing it.
A human only has two ARMs.
That is an interesting perspective.
Well, arbitrary sandboxed code.
I agree that by today‘s standards, the APIs that code has access to seem excessive and are well worth trimming down, but some of them are vital to the network‘s internal operations (like OTA updating the list of preferred roaming partners), while others enable new use cases (like M-Pesa mobile payments).
For example, multi-IMSI SIM cards are, in my opinion, an ingenious solution enabling entirely new products and bringing much needed competition to an industry that had been pretty stagnant (international roaming). That would not possible without the SIM application toolkit.
Edit: yes, but I wonder how much trouble you'd get in putting this into a real phone?
https://www.aliexpress.com/item/32900944064.html?spm=a2g0o.d...
SIM cards are just Java Cards, after all – the secret sauce is the proprietary software running on them (the ones you've linked seem to come with an implementation of that pre-loaded) and of course the keys they hold.
Nobody keeps you from implementing all the SIM specifications in an open-source Java Card application, and I would in fact be very intrigued to see it happening ;) As far as I know, experimental/hobbyist GSM networks, like the ones running at some conferences, are still using proprietary SIM cards, and an open source implementation would be very interesting to study.
I've put test SIMs in plenty of real phones, before tossing them into an RF chamber to talk to the network simulator. The real network doesn't seem to care.
Even if you'd be using an actual IMSI (not recommended – this seems like a legally more gray area), you would just fail authentication with that provider's AuC and the network would not let you register in what would be the GSM equivalent to a device trying to connect to a Wi-Fi with the wrong password.
That should be the phone's job, not the SIM card.
> while others enable new use cases (like M-Pesa mobile payments)
That should be the phone's job, not the SIM card.
Maybe, but what would inevitably happen is for network operators to demand that only certified devices, or maybe basebands, be allowed on their networks.
SIMs are a big reason of GSMs (and its successors') success: Having a trusted computing device to allow for key management and a few other things inside an otherwise untrusted/sandboxed phone was the compromise.
I'm all for making the interfaces used less opaque and less prone to be used for shady purposes, but the concept of SIM cards is a net win for everyone, in my opinion.
> That should be the phone's job, not the SIM card. [applications]
If you have a smartphone, it is. Many people still don't own one.
USSD is an alternative and is starting to be deployed in many markets previously using SAT, but it seems much more cumbersome to use and is less secure too (no trusted client side storage and tied to the security of the underlying transport protocols).
There was already a battle between AT&T and people who dared connect phones they actually owned to the phone network, and it ended well for the general public and badly for AT&T. The cell network should not get to determine what people attach to it; it should just pass data back and forth.
(In an ideal world, the cell network would have absolutely nothing to do with phone numbers, either; it would just pass data, and phonecalls would always happen over encrypted channels to your actual phone-number provider.)
> the concept of SIM cards is a net win for everyone, in my opinion
Public/private key crypto doesn't require a card that can also do other secret operations. And it doesn't require a smartcard either.
I absolutely agree.
> And it doesn't require a smartcard either.
There are many good reasons why a counterparty does not trust you (fully) with a set of keys.
The biggest one is keys that allow financial transactions or billing events to happen: It makes the "I lost my password" defense for friendly fraud much less credible. Another can be to discourage sharing of a service (i.e. "account sharing").
Now there's two ways to keep "your" keys safe as a service provider: You build a fully locked down platform and only allow devices sold and made by you to attach to it (and play your content, use your phone network, transact on your payments network etc.), or you standardize the interface to the "key jail", keeping the rest of the device open and accessible to independent security research.
You can call such a tamper-proof device holding some issuer's private or symmetric key any way you want – functionally, it will be very similar to a smartcard.
The now reformed SBC/AT&T is doing something similar - only devices on this list[0] can connect to their VoLTE network. Without registering for VoLTE, the phones will not be able to connect to the network.
Even if a phone has full VoLTE compatiblity (the OnePlus 6 series, for example), if the manufacturer does not work with (read: pay) AT&T for certification, it will not be allowed on their network.
This is illegal under California SB822[1], which among other things prohibits the blocking of "nonharmful devices" on networks - but AT&T, along with the other major carriers, are currently acting like this doesn't exist until they're forced to by abide by it by a court of law.
[0] https://www.att.com/idpassets/images/support/wireless/Device...
[1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtm...
And when my current smartphone dies, I'll be joining the ranks of those who don't own one. I'm aware of two other people who are also moving back to dumb phones. I wonder if this is going to become more common as time goes by.
This is already the case.
I‘ve heard that in the US, some providers are still insisting on this (essentially a leftover practice from the pre-SIM days!), but at least in Europe I‘ve always been able to use any phone I like, even really obscure ones.
The carriers don't use technical measures to keep uncertified devices off their network. It's still usually a violation of the terms of service. And yes, that means that aftermarket PCIe-form-factor cell radio in your laptop is theoretically a problem unless that precise laptop + card combination has been certified.
My MVNO started being recognized incorrectly as being part of another network years ago, and apparently their engineers have been unable to reach anyone within Apple about the matter and get theem to apply what should be a trivial fix in their IMSI mapping table.
Even Google, a nearly $2T company, operates an MVNO ("Google Fi") that does not work properly on the iPhone, because Apple has not added Fi's GID to the correct list.
Jailbroken users can (in theory) add Fi's GID to T-Mobile's "carrier bundle," and things like Wi-Fi calling, 5G connectivity, etc will work instantly.
So right now, someone on Google Fi with an iPhone and someone on Google Fi with an Android phone can be standing next to each other, and the Android phone could have great signal while the iPhone has zero signal because T-Mobile has no coverage at that location.
I don't know if iPhones now support that; if they do, then there's no longer any technical reason iPhones couldn't have first-class support for Fi.
The carriers could still provide information about their network, via a standard API.
I'm talking about how this should work if designed well, not incremental steps to get there with non-cooperating entities.
I think that I've fantasized about this magical land with literally every system I've ever worked with in my entire career, including ones of my own design. I've come to suspect that utopia simply doesn't exist.
(Ironically, SIMs are falling short on this end quite a lot since they don't allow providing GPRS and MMS related configuration, which means that now we have SIMs and manual lists...)
Yes, I agree that SIMs being (moderately) smart helps them to just work in a new phone without any affiliation with the carrier.
It's not perfect, though – APN settings are annoyingly part of the OS when they should arguably be a SIM and baseband implementation detail like the SMSC, for example.
But a sandbox that has access to very sensitive data.
There are some notable exceptions, like the ability to initiate voice calls possibly without any user interaction, and I'm all in favor of removing those from the specifications. I'm not sure whether modern devices actually implement these.
The only remaining concern then is weak authentication key security, i.e. allowing unauthorized third parties to control SIM (and by extension phone) behavior, potentially without the operator's knowledge. This seems like a very similar concern to weak phone network signalling stack security (like being able to intercept SMS via SS7), which is an ongoing problem too.
If privacy is a concern, no device should be trusted. By device I mean anything that contains a chip.
What's worse, people might suspect their phone or PC might be leaking data to third parties, but they will be less suspecting about their TV, their fridge or their car. But since anything is becoming smart these days, one can assume that anything that runs out of electricity is a potential privacy problem.
I think some things are overblown and unjustified paranoia.
Other things? Justified paranoia.
Isn't that just setting the HAP (High Assurance Platform) bit in the ME blob to disable it after bring-up? For Intel platforms it is possible for the end-user to modify the firmware themselves in many cases. https://hackaday.com/tag/hap-bit/
Maybe something like a RISC-V core written to a FPGA by yourself is pretty safe.
* https://github.com/MiSTer-devel/Main_MiSTer/wiki
Combine retro with FPGA as you like(within the constraints of that development board).
Or waste Watts by using software emulation.
Mine is as an tutor on an evening college, casual writer and some dabbling into some embedded projects. For THIS use case my (very retro) Atari 520 ST with 4 MB Ram is totally working. Is it nuts? Yup, but i can be sure that no state trojan is monitoring my totally boring behaviour.
"Why does citizen #2743652 have internet/electricity service with no registered devices or online profiles?" *Does deep background check*
But every PC has a SMC which deals with things like power-on, WOL, etc
Such things are so scary but what can we do? For most of the ppl, they cannot prove something like that happened. For me, I might be able to prove it but I cannot easily do it without significant efforts.
People say this all the time but literally no one has been able to prove any kind of secretive listening-based advertising.
The best explanation is that either you or someone else in your household has searched for something related and now it's appearing in your ads, or actually more likely, advertisers are incredible at linking cookies to actual users, and it's enough if your friend searched for solar panels and then his interests were associated with you. Like, advertisers can figure out all your friends have solar panels but you don't - so they show you ads for them. It's far easier to do than listening and to your conversations covertly.
I've seen it with my parents. They will talk about it, not to their phones, but around their phones, and they'll start seeing ads for something they talked about.
I've always had that featured turned off (I have to press the button), and I don't notice it.
My wife also sees it with her iPhone with siri turned on. I talked to her about, for example, Jordan Peterson, and her phone starts blowing up with Jordan Peterson on Instagram.
I dont think it's pure coincidence.
And why did you talk to her about Jordan Peterson? Is it perhaps because you read an article about Jordan Peterson earlier? If so, I assume you both share the same IP at home - so she starts seeing things you viewed or browsed. Facebook owns Instagram too, so if you look at something on Instagram it's not that wild that your partner's Instagram starts showing her things that interest you - it's just association.
>>If you have "OK Google" or whatever it is turned on, it is indeed listening to you.
Sure, and that's what I meant in the first paragraph - no one has been able to prove that this feature is sending your voice to Google/apple/Amazon servers unless you trigger the key word. Recording and sending voice would create some trace and no one has been able to prove this exist. That's not me saying it doesn't exist, just that for what is supposedly wide spread phenomenon, we have no proof it's actually happening other than anecdotal stories which can be easily explained by other means.
I think you need to look into how pervasive and creepy ad network tracking is: https://www.nytimes.com/interactive/2019/12/20/opinion/locat...
People with anecdata about which ads they see, who think of cell phones as inscrutable magic: "No, they definitely are. I can't (won't) think of any other way they'd infer my interests in these topics. You can't see it happening because they are too smart."
I guess the financial incentive might be there for some shady ad network to do it, but that’s just so much risk to take on for such a tiny gain per infected phone..
1) YouTube can read minds and they know what you just thought about
2) with statistical data from literally billions of people it's not so weird to guess what you might be thinking about and show you a video about it.
Again, if they(your phone? Watch? Toaster?) were listening someone would have found some evidence by now, a trace of voice recordings being sent or even something that looks like it might be voice recordings. Yet we have zero. It's not happening, the much easier and much more probable explanation is that we're already tracked through every online service we ever touch, but also we are linked to people we live with or people we interact with, and for a company that possesses exabytes of data it can analyse it's easier to trawl that than try to sneak out voice recordings out of your phone.
It's basically common knowledge that if you turn on "hear me say OK Google" that it needs to always be listening to hear "OK Google". That's a green light to start parsing everything said all the time, which will be turned around for advertising. Because that's how Google makes money.
Expecting Google to use data to advertise isn't tinfoil?
Actual nlp parsing all audio, or even a tiny subset of devices, is far beyond Google's capabilities. It's not a trivial task to process.
Your phone locally has some extremely basic recognition for "ok google", after which selective actual nlp parsing takes place.
So long as they don't get caught, anyway, because that's all sorts of illegal. Especially at Google's scale. (I don't think Google does this… probably.)
From Wikipedia: Frequency illusion, also known as the Baader–Meinhof phenomenon or frequency bias, is a cognitive bias in which, after noticing something for the first time, there is a tendency to notice it more often, leading someone to believe that it has a high frequency of occurrence – a form of selection bias.
In a reversal of what you call business function, I'd consider it as my business to do what I want in my space when I want, how and where.
That shrinkwrapped pre-installed OS/Appstore is just another business sector, which the masses have been conditioned into accepting.
Convenient. But sometimes not, rather the opposite.
For example in many African countries, you have M-Pesa [1], which was at least initially entirely based on SAT.
Also, the API is somewhat limited. "Installing applications" here means "downloading code to the SIM card", which arguably has always been the phone provider's property.
It's definitely not possible to install apps on the application processor OS via SIM-OTA. That would be OS-based carrier profiles, which the OS vendor has deliberately implemented.
If so, any entity with a court order, can install anything it wants on your phone.
Alternatively, any entity it wants can use the sim itself to track beyond the norm...
It‘s not "any entity", though – the provider’s keys are needed to do this, and they can already do much of that tracking using other, network-side means.
If the signing keys are compromised, though, bad things can happen: https://www.srlabs.de/bites/rooting-sim-cards
I read something to this effect years ago and mentally filed it away as “huh, that’s interesting.” This article is the first time I’ve understood what it actually means in practice, and it’s an eye-opener.
But I agree – Java to JavaScript is not the best comparison. Maybe a better one would be C programs written for a Unix system vs. C on a microcontroller: Same language; vastly different instruction set, OS and hardware capabilities and APIs available.
Unlike C on microcontrollers, Java Card applications are hardware and OS agnostic, though!
It's a UICC not a SIM card anyway.
Is that equally true of SIM cards and eSIMs?
I'm in the process of setting up a new T-Mobile phone and they say they support eSIM but they are really pushing me to use a traditional SIM card. I've been wondering why they care.
https://www.engadget.com/2013-03-02-lightning-digital-ac-ada...
An eSim is essentially a virtualization solution with each eSim profile effectively running in a container which can be set up, deactivated, and deleted only by the profile manager.
The profile manager communicates with the provisioning infrastructure in an encrypted and authenticated way, so the profiles being loaded, i.e. their code (if any) and data, are as inaccessible as those on a physical SIM.
While active, an eSim profile has all the same capabilities as a physical SIM, including remotely loading Java applications, issuing proactive commands to communicate with the network, registering for event notifications about location changes and incoming/outgoing calls…
The Oracle JVM installer wizard isn't lying when it's saying that there is billions of devices running Java in the world :)
Without the keys of a legitimate eSim (i.e. those chaining up to a GSMA-approved vendor) you won‘t be able to inspect a profile even if you know the activation code.
http://www.arib.or.jp/english/html/overview/doc/STD-T63v9_50...
Generally speaking, the SIM interacts using both "proactive commands" (e.g. "send an SMS to this number) and event downloads (think "whenever the base station identifier changes, please let me know").
The former just refers to the latter for event downloading.
* "setting up a voice call to a number held by the UICC" - effectively allows turning the phone into a bug (although not a very stealthy one, since presumably the normal call UI would be shown).
* requesting the terminal to launch the browser corresponding to a URL - triggering exploits
* providing local information from the terminal to the UICC; -- depends on what exactly the card can request, doesn't look like much except location which is discussed below
* running an AT command -- depends on the AT commands available, but I don't expect anything ground breaking
* requesting the terminal to start an application on the terminal -- depends on what exactly can be triggered (e.g. if it can trigger an app install it'd be extremely concerning, already installed apps less so), but I think it's only launching or listing already installed carrier apps.
* requesting the terminal to report geographical location information to the UICC -- fine grained tracking. This is the most concerning for me, and I wonder how/if Android shows when/if that happens (or if it is allowed). I also wonder if this can be used even when the phone is in airplane mode (to collect data and upload it later).
The geographic location seems to be only network-based (i.e. this doesn't poll the phone for GPS data, but only accesses data available to the baseband).
Hopefully, the following requirement also covers flight mode implementations:
> Where location information or Network Measurement Results has been requested and no service is currently available, then the ME shall return TERMINAL RESPONSE (ME currently unable to process command - no service).
If both are the case, then this does not leak more to the network than it could just determine itself from signalling data. In any case, as many things in these specifications, it leaves quite a lot of wiggle room for implementation mistakes, genuine and otherwise.
As a historical note, there was a quite famous implementation of SIM-based positioning in Germany: One GSM provider implemented a "home zone" feature entirely on the SIM, by populating it with a database of cells that qualify for "home use"; this was then used to bill the landline rate rather than the (at the time quite expensive) mobile rate for outgoing calls.
Atmel AT90SC25672RU, 8-bit AVR, 256KB ROM, 72 KB EEPROM, 6 KB RAM, Between 20 & 30 MHz
https://media.defcon.org/DEF%20CON%2021/DEF%20CON%2021%20pre...
Here's a list (IMHO not exhaustive) of some apps put on EMV cards https://www.eftlab.com/knowledge-base/211-emv-aid-rid-pix/ - there are various identity card solutions both from governments and companies like Microsoft, there's https://en.wikipedia.org/wiki/OpenPGP_card , there's various solutions for store loyalty cards.
However, I don't consider this aspect as any risk to the user, since when using the standard payment card functionality your card payments already have no privacy or security whatsoever from the issuer of your card, from a technical perspective the issuer will (by design) see and manage (authorize, revoke, etc) all the transactions and the card + terminal is just one of the channels for sending cardholder-initiated transactions to them. It would be technically appropriate to treat it not as "your card" but "issuer's card" that the cardholder uses as a token to use when the merchant communicates with the issuer about the bill.
https://www.researchgate.net/figure/The-basic-architecture-o...
Wikipedia has the terms the FBI demanded, and to me they look like demands relating to software directly in iOS, not some other security chip[4].
>Apple is also under the eight ball with the threat of anti-trust regulation and are more incentivised than ever to make deals that turn down the heat on questionable business practices.
Questionable business practices impacting competition/monopoly, sure. But I don't see how a backdoor would make anyone think Apple has less of a monopoly.
>They lost all credibility as a "security focused" company with their crazy on-device image scanning scheme.
Apple publicly announced that in advance. That's different from a secret backdoor.
[1] https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_d...
[2] https://en.wikipedia.org/wiki/IPhone_5C
[3] https://apple.fandom.com/wiki/Secure_Enclave
[4] https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_d...
edit: the sim can tell the radio to turn on, when it wants to send a message.
It is a full blown computer, with direct access to the radio firmware, with no OS oversight.
The radio firmware can be updated remotely, too, and the OS only knows the modem is on, because the firmware tells it so.
The icon on your phone showing signal/on/off is displayed by the OS, after querying the firmware. The OS has no way to know if the radio is on or not.
However, that is a possibility for specific malicious firmware uploaded to some "phone of interest" to prevent its user from protecting themselves by turning on airplane mode.
One way would be to shut down the SIM as soon as it's activated, which would include proactive commands of any kind (like those the SIM uses to request sending an SMS from the phone/baseband).
Another would be to keep the baseband and SIM active, but to still deactivate the radio – in this the SIM might still be able to issue proactive commands, but without any network attachment, they would just fail.
Of course an implementation could also choose to briefly reattach to the network whenever it receives such a proactive command.
The only way to turn off a phone for sure is to remove the battery.
ha ha.
Can't wait to see what nefarious use cases that eSIMs can be used for then by our carrier then if your phone has one.
Maybe in the future, eSIMs will be the only SIM in your phone and it can't be removed, just reprogrammed by the carrier.
No thanks and no deal to eSIMs.
Yeah. They even run Java, that was the most surprising fact.
> Your carrier can upload and run arbitrary code without your consent or knowledge. They can do this at any time.
So what can this code do? Can my phone be compromised somehow?
Two words: Faraday bag.
Bag not cage (though the bag is technically a Faraday cage you aren't actually entering it as it's only big enough to hold your phone). A small faraday bag is available for ~20 on Amazon.
>They can do this at any time.
You can decide when you get updates and when you want to allow yourself to be tracked by whatever corporations, governments, and other actors that seek to track your movements. It's a false paradigm to suggest (like most people on this thread are doing) that you have no choice but to allow yourself to be tracked 24/7 or to go without a communication device. Keep your phone in a small shielded bag, remove it when you want to make calls, check your messages and are willing to divulge your location - its not rocket science.
Assuming the cage works perfectly (taking out the battery if possible seems a safer bet), the only thing you actually decide is when you get it out of the cage to use the device. However at that point the device can communicate and you cannot stop it from doing whatever it wants to. In other words: you decide you want to call, and if the thing decides it wants to update it might also do it at that point.
Great, get a big bag then.
The big iffy is that manufacturers were compromised (by the US afaik) in 2015 and all cards from then or earlier should be considered compromised.
Few carriers encrypted their OTA-keys before then. I know that some carriers did not send encrypted keys to manufacturers still in 2018.
Today, it's mostly Java Card implementations, meaning that the ISA and smartphone OS/runtime is abstracted away in any case.
A SIM card is a full blown computer with its own CPU and memory.
Your carrier can upload and run arbitrary code without your consent or knowledge. They can do this at any time.
This means that your "phone" is actually three different computers running in concert - the actual phone itself (iOS or Android or Symbian), the baseband processor running the baseband code, and the SIM card.