Do you mean the AML standard should be amended so that the recipient of the location data should perform the database lookup/API call? Yes, that would be a good solution, if sufficient influence could be applied to get it implemented. (Mind you, SMS messages have limited length, so it might not be entirely practical.)
1 Like
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.
1 Like
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 
1 Like
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.
3 Likes
I get that, but it seems the EU regulation eventually requiring this functionality in new phones is a little more prescriptive than AML itself.
Some databases record both SSID and BSSID, others just BSSID. The AML Specifications & Requirements document makes note of the problems of relying on just one BSSID:
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 
1 Like
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.
1 Like
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.
1 Like
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).
1 Like
Edited the fist post.
Court of Justice of the EU rules that SIM-less calls to 112 should be located.
Also on EENA website.
1 Like
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.
NOTE: United States: Info to be included soon.
@kieran, @amosbatto, please note:
âThe open services are realized by using the signals at L1, E5a and E5b, whether data or pilot. Several combinations are also possible, such as a dual frequency service based on using L1 and E5a (for best ionospheric error cancellation) or single frequency services (at L1, E5a, E5b or E5a and E5b together) in which case the ionospheric error is removed using a model, and even triple frequency services using all the signal together (L1, E5a and E5b), which can be exploited for very precise, centimetric applications.â
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.
1 Like
@kieran, you are kind person, and all of this is above may head too but we are aware of few facts:
â we may take this .ppt from Rohde & Schwarz USA, Inc. as basic GNSS Signal reference/overview and try to simplify our understanding of free/open positioning services by focusing here just on QZSS and Galileo,
â we know that Cooperation Agreement relative to Satellite Navigation Applications between Japan and EU was established on March 8, 2017,
â we know that the âUS FCC granted in part a request from the European Commission for a waiver of the FCC rules so that devices in the United States may access specific signals transmitted by Galileoâ,
â we know that Librem 5 is still not on the List of products that support the QZSS (requirement for Giteki Mark),
â for information purposes only here is the List of public safety solution providers created by the EENA staff in June 2019 that involve some Linux solutions as well,
â we are aware of upcoming opportunities for innovative applications ideas: âthe âKick-start Activityâ is ESAâs new funding scheme launched in 2017. Activities will be funded at 75%, with ESA providing up to âŹ60,000 per contractâ even though Purism is not directly eligible to it, maybe is useful here to be aware of such for eventual future cooperation/compatibility,
â not to forget to look at future Linux Foundation events.
This is just some random food for thought (and nothing else), related to current or future L5 GNSS chip (as STMicroelectronics actively cooperate with Galileo), that somehow explains, IMHO, why is it to make AML, besides Emergency Warning Services (EWS), for new smartphones mandatory.
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.
Advanced Mobile Location when calling emergency services ?
Youâve already touched on some of the ideas that I was pondering.
I also suggested in Advanced Mobile Location when calling emergency services that it would be better if the WiFi standard were extended to allow a WAP to broadcast its physical location.
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.
1 Like
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.