AML is a very benevolent specification.
It does not require handset providers to deliver very specific information, it only requires them to deliver the best location information available to the handset.
This is GNSS if it already has a fix, a WiFi location database if no GNSS coordinates are available, or a Cell-ID database.
If neither is available, a “null”-SMS should be sent to signal this to emergency-services.
This means, that the AML standard specifically gives the phone (and for a user-controlled phone therefore the user) full control over the procedure.
While privacy-friendly non-GNSS location services might be tricky for Purism, the user can be given a choice to use the freely-available location services of for example Mozilla for an emergency-only, if the user wishes not to transmit his location to said service providers in other situations.
All in all, this means, that this is a non-issue. AML is purely benevolent in any sense and can be implemented in full support of the specification without any privacy concerns.
Hence, as noted above, HTTPS is a better alternative, in that regard, where it is available (seemingly currently only Austria).
It was not clear to me whether a solution based on WiFi would be using the SSID (maximum length 32 bytes) or the underlying MAC address (BSSID) (length 6 bytes). The MAC address is in general going to be shorter than the SSID. The SSID will in any case be potentially highly non-unique. (Too many idiots don’t change the default.) So I would assume MAC addresses.
You can fit a bunch of MAC addresses in an SMS.
Scanning for WAPs could be a bit slow, particularly if the user has overridden the default beacon interval.
The carrier should take care of providing any information relating to, or based on, the tower (cell).
I have my suspicions that solutions based on WiFi could be horribly inaccurate. Let’s say Google drives past your house, records your SSID and MAC address from the beacon frame, puts it into its database. Then you move house to a location that either Google has not subsequently scanned or cannot detect the WAP from the street. You are at home and an emergency arises and you are unable to give your location. Your phone of course can see the WAP (whether or not it is associated with the WAP) and reports the WiFi details. So the cell info must override the WiFi-derived location when the two are wildly inconsistent.
In my view if such databases are to be created, they should be public (not secret) and you should be able to delete yourself and/or update yourself. However that is a problem for another day. (It is not obvious how you would prove your entitlement to maintain the database item.)
In the short term it might be good enough for the user of the phone to be allowed to configure the phone not to transmit WiFi info as part of the AML info. So the phone is compliant (has the “capability”) and the user is happy.
let’s look at this from another perspective … if emergency location information IS collected then how usefull is that information - it’s not likely you’ll have the same almost-fatal car accident in the same place each time of the year … unless you enjoy having your face smash into the frontal-airbag
I get a bit edgy when I see things like the following in the EU Directive
Member States may adopt specific provisions to entitle providers of electronic communications services to provide access to location data to emergency services without the prior consent of the user or subscriber concerned.
and the following from the spec
2.3 SMS invisibility
The AML SMS should not be seen by the caller and therefore should not appear in the SMS “sentbox” of the smartphone. This is to avoid … making the format of the message widely known.
Yeah right. If it is relying on security through obscurity then that is no comfort at all. (Possibly there are some major problems of potential abuse with the whole implementation.) I would ask for the exact opposite - please show me the SMS that was sent. If I am not completely incapacitated, it may be psychologically good to see that the SMS has been sent. It may inform me about the next course of action e.g. if I can see that the SMS was not sent or was sent but did not include position info.
I know that the whole thing is well motivated but governments also need to consider how much damage they have done to public trust.
Reading more of the spec, at the time it was written, AML doesn’t work with global roaming and should be disabled(!) when roamed. That seems to relate only to sending location info via SMS though i.e. maybe it is OK to keep enabled when roamed if in a country that supports location info via HTTPS, which I hope is a growing number of countries.
Some ‘Wifi to location’ services require that multiple Wifi MAC addresses be supplied. This is important as it can help to eliminate situations where an incorrect location is given because a Wifi router has been moved and its location has not been updated on the location server. This approach should be adopted for all AML locations based on Wifi.
On first reading, I saw that “Mozilla is currently evaluating its MLS service and terms and is not currently distributing API keys.”, and assumed this meant the Librem 5 was shut out of using it, but actually it looks like it could just use the GeoClue D-Bus service, which already has access to the Mozilla Location Service, so perhaps it’s not so difficult after all. Though, it doesn’t appear to support contributing data back to the database, and users are advised to install an Android app in order to contribute data if their location can’t be found.
I totally agree. I want to see any time my mobile sends a SMS. Would be funny seeing silent SMS or IMSI Catcher action at some time, but I guess that would be implemented in the non-free part of the phone
It is important to note, that AML does not use silent SMS, it uses standard SMS.
The standard however asks handset and OS producers to hide the SMS from users (i. e. not show them in the outbox), and gives 2 reasons for that:
Don’t confuse the user in the stress situation of an emergency
Don’t make the message format widely known to avoid abuse
I think both are somewhat valid reasons, even though I disagree with both.
Knowing an SMS has been sent won’t likely confuse or stress the user.
The message format is already widely known, and security by obscurity is a silly concept, that has rarely worked.
That said, since this are user SMS and originated by software running on the application processor, it is trivially possible to show them to the user; the obligation to hide them is a weak one and can be safely and legally bypassed.
Apart from that, the emergency centers already know your approximate location, because in almost all countries, network carriers are required by law to provide cell location data to emergency centers.
Since you originate a call, a silent SMS is not needed to gain said location information; it is by design available as soon as you hit the dial button when the phone starts sending data to the network.
The aspect for me that was truly ridiculous is that the very document that talked about keeping the format a secret actually documented the format.
In any case, you can’t expect phone providers (which Purism will hopefully soon be) to implement AML while keeping the format a secret from them, and once an open source provider implements it then the format is public and quasi-documented, whether “they” like it or not.
It occurs to me that maybe a better approach to AML via WiFi is to enhance the WiFi standard to include location information, either in the beacon frame or in another existing frame or in a frame specifically for location information. (I dare say that vendors can already do that by including proprietary Information Elements but that is exactly the solution that we don’t want.) The operator of the Access Point would have the option of disabling the transmission of location information.
The privacy implications would be less severe, as no massive database is needed, either secret or public, and you can opt out easily enough, and updates are handled more cheaply when an AP is moved.
I note in passing that a network of Cisco Access Points is capable of locating a given wireless client using triangulation on the Received Signal Strength Indication (RSSI) i.e. works the same as multiple cellular towers doing it but more accurately. I don’t know whether other vendors have the same functionality.
Doesn’t help if you are at home as I would guess that most people don’t have multiple Access Points (and if they do, the APs might be different makes/models that are not capable of cooperating in that way).
Sorry that I missed this one, as you pointed out and as chronology is important, just because I even rarely look in my back mirror, certainly less than 50%.
All mentioned here above is all right with me, but anyway i don’t want to rely on WiFi/triangulation only by knowing there is separate GNSS receiver that can be and maybe should be used as standalone unit when executing 112 or 911 call. What I purely suggested in my relatively poor English is that for partial privacy myself, and maybe some others, want to have Teseo-LIV3F {(supporting one of two frequencies that are utilized; one at 1575.42 MHz (10.23 MHz × 154) and second at 1227.60 MHz (10.23 MHz × 120)}, only capable of locating my position just by having emergency telephone call (either 112 or 911) when help needed or just lost somewhere in the desert or wood, for example, but still way away from any neighboring town, like in the middle of nowhere. I posted some of my AML thoughts here as well:
Maybe I am pushing too far, but this might be another strong difference that may count with/for Librem 5, because if you just count on WiFi, without saying here that this is not important option as well (just not my preferred approach to privacy), location advantages as such, as known and common system within cities, someone might be lost forever, as I see this when someone calls because of serious distress situation. Here is very recent video how only Galileo GNSS location system may save someone life even without neighboring tower to execute here discussed emergency call (at the first place), and without WiFi network for sure:
Again, I am just saying loud my wish/idea in which direction some developers might move towards with usage of Teseo-LIV3F (and future dual-frequency TeseoAPP family) module on Linux and not saying this is reachable as I don’t know.
It is not clear to me how the L5 will use WiFi for AML anyway.
Let’s say that Android phones use WiFi for AML by transmitting the MAC address of any detected WAPs to Google and Google looks up its database of all WAPs ever detected by Google and responds with location information for each WAP, which is then used (potentially after computation if there is more than one WAP) in the AML message (if it is better than the GNSS location information).
With the L5, that approach either doesn’t work at all or has unacceptable privacy implications.
That might be partly mitigated if the L5 stores location information with an SSID when the SSID is first associated. So if you are at home, or any other place that you commonly associate with the WiFi, there might be location information available. (My understanding is that in order to associate with the WiFi, the WiFi kill switch has to be in the “not killing” position, in which case the GNSS will by definition be enabled.)
My understanding is that GNSS does not work so well in some indoor locations and that is the main situation where you would want to use WiFi instead of GNSS. So you might have to enable the WiFi before wandering inside, at least the first time you associate.
The details of exact frequencies and the capabilities of the GNSS chip in the L5 are beyond my knowledge.
In a previous post (I would post a link, but I have been unable to find it) I saw a screenshot or a video of a phone-adapted GNOME Settings screen which had an option to enable Mozilla Location Services, apparently confirming the suspicion I had earlier in this thread.
I have nothing against Google specifically. Whatever I said about sending your implied location to Google for the purposes of WiFi lookup, also applies to sending your implied location to Mozilla for the purposes of WiFi lookup. At least for some users the privacy implications of that would be equally unacceptable. It just isn’t a good solution (although some users may be happy with that, particularly in an emergency situation).
What I meant was I saw a screenshot or a video in somebody else’s post in another thread.
Indeed. I did not mean to imply otherwise. I was just saying, regardless of any other ideas, it looks like the phone will have the ability to use Mozilla Location Services (MLS), and the software it is supplied with will probably use MLS when WiFi geolocation is required.
When making an emergency call, you have the option of having the kill switches positioned so that “cellular” is ON but “WiFi” is OFF. That doesn’t absolutely guarantee that WiFi info won’t be used (since the WiFi may have been “on” in the recent past and some information may have been gathered previously).
Whether you have the presence of mind in an emergency situation to manipulate kill switches is another question. Bear in mind that AML has, as one of its use cases, a situation where you become incapacitated and are unable to convey your location verbally. So stuffing around with kill switches may not be top of mind, or even possible.
Also, this is open source. If you want to control exactly how AML is implemented, that is always open to you.
I don’t know where you are located but QZSS is most useful in Japan, may be useful in Australia, may be useful in similar parts of the world (East Asia / Oceania).
I believe that the GNSS module is not plug-in. So you may not be able to upgrade it yourself and any future GNSS module may only come with a future version of the phone itself, if at all.
In short, Teseo-LIV3F works fine with QZSS and even though “is a Japanese regional communication service and positioning information for the mobile environment in the GPS L1C/A band. QZSS in conjunction with GPS signals provides GNSS augmentation service for the Pacific region covering Japan and Australia.” May be that the rest of the World will be covered by the same/similar technology (that may be used on Librem 5) with Galileo, I don’t know exactly how this will be managed. Dual-frequency TeseoAPP might be introduced with L5 v2 if necessary but I doubt there will be such need as Teseo-LIV3F supports 1.5 m CEP accuracy positioning.
