idnits 2.17.1 draft-zuniga-mac-address-randomization-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2020) is 1272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group JC. Zuniga 3 Internet-Draft SIGFOX 4 Intended status: Informational CJ. Bernardos 5 Expires: May 4, 2021 UC3M 6 A. Andersdotter 7 CENTR 8 October 31, 2020 10 MAC address randomization 11 draft-zuniga-mac-address-randomization-00 13 Abstract 15 Internet privacy has become a major concern over the past few years. 16 Users are becoming more aware that their online activity leaves a 17 vast digital footprint, that communications are not always properly 18 secured, and that their location and actions can be easily tracked. 19 One of the main factors for the location tracking issue is the wide 20 use of long-lasting identifiers, such as MAC addresses. 22 There have been several initiatives at the IETF and the IEEE 802 23 standards committees to overcome some of these privacy issues. This 24 document provides an overview of these activities, with the intention 25 to inform the technical community about them, and help coordinate 26 between present and futures standardization activities. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 4, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Background - MAC address usage . . . . . . . . . . . . . . . 3 65 4. MAC address randomization . . . . . . . . . . . . . . . . . . 4 66 5. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 67 802 meetings . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Recent MAC randomization activities at the IEEE 802 . . . . . 6 69 7. MAC randomization-related activities at the IETF . . . . . . 7 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 11.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 Internet privacy is becoming a huge concern, as more and more mobile 81 devices are getting directly (e.g., via cellular or Wi-Fi) or 82 indirectly (e.g., via a smartphone using Bluetooth) connected to the 83 Internet. This ubiquitous connectivity, together with not very 84 secure protocol stacks and the lack of proper education about privacy 85 make it very easy to track/monitor the location of users and/or 86 eavesdrop their physical and online activities. This is due to many 87 factors, such as the vast digital footprint that users leave on the 88 Internet, for instance sharing information on social networks, 89 cookies used by browsers and servers to provide a better navigation 90 experience, connectivity logs that allow tracking of a user's Layer-2 91 (L2/MAC) or Layer-3 (L3) address, web trackers, etc.; and/or the weak 92 (or even null in some cases) authentication and encryption mechanisms 93 used to secure communications. 95 This privacy concern affects all layers of the protocol stack, from 96 the lower layers involved in the actual access to the network (e.g., 97 the MAC/Layer-2 and Layer-3 addresses can be used to obtain the 98 location of a user) to higher layer protocol identifiers and user 99 applications [wifi_internet_privacy]. In particular, IEEE 802 MAC 100 addresses have historically been an easy target for tracking users 101 [wifi_tracking]. 103 There have been several initiatives at the IETF and the IEEE 802 104 standards committees to overcome some of these privacy issues. This 105 document provides an overview of these activities, with the intention 106 to inform the community and help coordinate between present and 107 futures standardization activities. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 The following terms are used in this document: 117 MAC: Medium Access Control 119 3. Background - MAC address usage 121 Most mobile devices used today are Wi-Fi enabled (i.e. they are 122 equipped with an IEEE 802.11 wireless local area network interface). 123 Wi-Fi interfaces, as any other kind of IEEE 802-based network 124 interface, like Ethernet (i.e. IEEE 802.3) have a Layer-2 address 125 also referred to as MAC address, which can be seen by anybody who can 126 receive the signal transmitted by the network interface. The format 127 of these addresses is shown in Figure 1. 129 Figure 1: IEEE 802 MAC Address Format (TBD) 131 MAC addresses can either be universally administered or locally 132 administered. Universally administered and locally administered 133 addresses are distinguished by setting the second-least-significant 134 bit of the most significant byte of the address (the U/L bit). 136 A universally administered address is uniquely assigned to a device 137 by its manufacturer. Most physical devices are provided with a 138 universally administered address, which is composed of two parts: (i) 139 the Organizationally Unique Identifier (OUI), which are the first 140 three octets in transmission order and identify the organization that 141 issued the identifier, and (ii) Network Interface Controller (NIC) 142 Specific, which are the following three octets, assigned by the 143 organization that manufactured the NIC, in such a way that the 144 resulting MAC address is globally unique. 146 Locally administered addresses override the burned-in address, and 147 they can either be set-up by the network administrator, or by the 148 Operating System (OS) of the device to which the address pertains. 149 However, as explained in further sections of this document, there are 150 new initiatives at the IEEE 802 and other organizations to specify 151 ways in which these locally administered addresses should be 152 assigned, depending on the use case. 154 4. MAC address randomization 156 Since universally administered MAC addresses are by definition 157 globally-unique, when a device uses this MAC address to transmit data 158 -especially over the air- it is relatively easy to track this device 159 by simple medium observation. Since a device is usually directly 160 associated to an individual, this poses a privacy concern 161 [link_layer_privacy]. 163 MAC addresses can be easily observed by a third party, such as a 164 passive device listening to communications in the same network. In 165 an 802.11 network, a station exposes its MAC address in two different 166 situations: 168 o While actively scanning for available networks, the MAC address is 169 used in the Probe Request frames sent by the device (aka IEEE 170 802.11 STA). 172 o Once associated to a given Access Point (AP), the MAC address is 173 used in frame transmission and reception, as one of the addresses 174 used in the address fields of an IEEE 802.11 frame. 176 One way to overcome this privacy concern is by using randomly 177 generated MAC addresses. As described in the previous section, the 178 IEEE 802 addressing includes one bit to specify if the hardware 179 address is locally or globally administered. This allows generating 180 local addresses without the need of any global coordination mechanism 181 to ensure that the generated address is still unique within the local 182 network. This feature can be used to generate random addresses, 183 which decouple the globally-unique identifier from the device and 184 therefore make it more difficult to track a user device from its MAC/ 185 L2 address [enhancing_location_privacy]. 187 5. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 802 188 meetings 190 As an outcome to the STRINT W3C/IAB Workshop [strint], on July 2014 a 191 Tutorial on Pervasive Surveillance of the Internet - Designing 192 Privacy into Internet Protocols was given at the IEEE 802 Plenary 193 meeting in San Diego [privacy_tutorial]. The Tutorial provided an 194 update on the recent developments regarding Internet privacy, the 195 actions that other SDOs such as IETF were taking, and guidelines that 196 were being followed when developing new Internet protocol 197 specifications (e.g. [RFC6973]). The Tutorial highlighted some 198 Privacy concerns applicable specifically to Link Layer technologies 199 and provided suggestions on how IEEE 802 could help addressing them. 201 Following the discussions and interest within the IEEE 802 community, 202 on 18 July 2014 the IEEE 802 Executive Committee (EC) created an IEEE 203 802 EC Privacy Recommendation Study Group (SG) [ieee_privacy_ecsg]. 204 The work and discussions from the group have generated multiple 205 outcomes, such as: 802E PAR: Recommended Practice for Privacy 206 Considerations for IEEE 802 Technologies [IEEE_802E], and the 802c 207 PAR: Standard for Local and Metropolitan Area Networks - Overview and 208 Architecture Amendment - Local Medium Access Control (MAC) Address 209 Usage [IEEE_802c]. 211 In order to test the effects of MAC address randomization, major 212 trials were conducted at the IETF and IEEE 802 meetings between 213 November 2014 and March 2015 - IETF91, IETF92 and IEEE 802 Plenary in 214 Berlin. The purpose of the experiments was to evaluate the use of 215 MAC address randomization from two different perspectives: (i) the 216 effect on the connectivity experience of the end-user, also checking 217 if applications and operating systems (OSs) were affected; and (ii) 218 the potential impact on the network infrastructure itself. Some of 219 the findings were published in [wifi_internet_privacy]. 221 During the experiments it was observed that the probability of 222 address duplication in a network with this characteristics is 223 negligible. The experiments also showed that other protocol 224 identifiers can be correlated and therefore be used to still track an 225 individual. Hence, effective privacy tools should not work in 226 isolation at a single layer, but they should be coordinated with 227 other privacy features at higher layers. 229 Since then, MAC randomization has further been implemented by mobile 230 operating systems to provide better privacy for mobile phone users 231 when connecting to public wireless networks [privacy_ios], 232 [privacy_windows], [privacy_android]. 234 6. Recent MAC randomization activities at the IEEE 802 236 Practical experiences of MAC randomization in live devices helped 237 researchers fine-tune their understanding of attacks against 238 randomization mechanisms [when_mac_randomization_fails]. At IEEE 239 802.11 these research experiences eventually formed the basis for a 240 specified mechanism introduced in the IEEE 802.11aq in 2018 which 241 randomize MAC addresses that recommends mechanisms to avoid pitfalls 242 [IEEE_802_11_aq]. 244 More recent developments include turning MAC randomization on in 245 mobile operating systems by default, which has an impact on the 246 ability of network operators to personalize or customize services 247 [rcm_user_experience_csd]. Therefore, follow-on work in the IEEE 248 802.11 mapped effects of potentially large uptake of randomized MAC 249 identifiers on a number of commonly offered operator services in 250 2019[rcm_tig_final_report]. In the summer of 2020 this work emanated 251 in two new standards projects with the purpose of developing 252 mechanisms that do not decrease user privacy and enable an optimal 253 user experience when the MAC address of a device in an Extended 254 Service Set is randomized or changes [rcm_user_experience_par] and 255 user privacy solutions applicable to IEEE Std 802.11 256 [rcm_privacy_par]. 258 The IEEE 802.1 working group has also published a specification that 259 defines a local MAC address space structure, known as the Structured 260 Local Address Plan (SLAP). This structure designates a range of 261 local MAC addresses for protocols using a Company ID (CID) assigned 262 by the IEEE Registration Authority. Another range of local MAC 263 addresses is designated for assignment by administrators. The 264 specification recommends a range of local MAC addresses for use by 265 IEEE 802 protocols [IEEE_802c]. 267 Finally, work within the IEEE 802.1 Security task group on privacy 268 recommendations for all IEEE 802 network technologies looked into 269 general recommendations on identifiers, reaching the conclusion that 270 temporary and transient identifiers are preferably in network 271 technology design if there are no compelling reasons of service 272 quality for a newly introduced identifier to be permanent. The IEEE 273 P802E: Recommended Practice for Privacy Considerations for IEEE 802 274 Technologies has passed sponsor ballot and is expected to be 275 finalized in the autumn of 2020 [IEEE_802E]. It will form part of 276 the basis for the review of user privacy solutions applicable to IEEE 277 Std 802.11 devices [rcm_privacy_csd]. 279 7. MAC randomization-related activities at the IETF 281 Several IP address assignment mechanisms such as the IPv6 stateless 282 autoconfiguration techniques (SLAAC) [RFC4862] generate the Interface 283 Identifier (IID) of the address from its MAC address (via EUI64), 284 which then becomes visible to all IPv6 communication peers. This 285 potentially allows for global tracking of a device at L3 from any 286 point on the Internet. Besides, the prefix part of the address 287 provides meaningful insights of the physical location of the device 288 in general, which together with the MAC address-based IID, makes it 289 easier to perform global device tracking. 291 There are some solutions that might mitigate this privacy threat, 292 such as the use of temporary addresses [RFC4191], the use of opaque 293 IIDs [RFC7217], [I-D.gont-6man-deprecate-eui64-based-addresses]. 294 Next, we briefly describe how these solutions work. 296 [RFC4191] identifies and describes the privacy issues associated with 297 embedding MAC stable addressing information into the IPv6 addresses 298 (as part of the IID) and describes some mechanisms to mitigate the 299 associated problems. The specification is meant for IPv6 nodes that 300 auto-configure IPv6 addresses based on the MAC address (EUI-64 301 mechanism). It defines how to create additional addresses (generally 302 known as "temporary addresses") based on a random interface 303 identifier for the purpose of initiating outgoing sessions. These 304 "random" or temporary addresses are meant to be used for a short 305 period of time (hours to days) and would then be deprecated. 306 Deprecated addresses can continue to be used for already established 307 connections, but are not used to initiate new connections. New 308 temporary addresses are generated periodically to replace temporary 309 addresses that expire. In order to do so, a node produces a sequence 310 of temporary global scope addresses from a sequence of interface 311 identifiers that appear to be random in the sense that it is 312 difficult for an outside observer to predict a future address (or 313 identifier) based on a current one, and it is difficult to determine 314 previous addresses (or identifiers) knowing only the present one. 315 The main problem with the temporary addresses is that they should not 316 be used by applications that listen for incoming connections (as 317 these are supposed to be waiting on permanent/well-known 318 identifiers). Besides, if a node changes network and comes back to a 319 previously visited one, the temporary addresses that the node would 320 use will be different, and this might be an issue in certain networks 321 where addresses are used for operational purposes (e.g., filtering or 322 authentication). [RFC7217], summarized next, partially addresses the 323 problems aforementioned. 325 [RFC7217] defines a method for generating IPv6 IIDs to be used with 326 IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 327 address configured using this method is stable within each subnet, 328 but the corresponding IID changes when the host moves from one 329 network to another. This method is meant to be an alternative to 330 generating Interface Identifiers based on MAC addresses, such that 331 the benefits of stable addresses can be achieved without sacrificing 332 the security and privacy of users. The method defined to generate 333 the IPv6 IID is based on computing a hash function which takes as 334 input information that is stable and associated to the interface 335 (e.g., MAC address or local interface identifier), stable information 336 associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6 337 prefix, and a secret key, plus some other additional information. 338 This basically ensures that a different IID is generated when any of 339 the input fields changes (such as the network or the prefix), but 340 that the IID is the same within each subnet. 342 In addition to the former documents, [I-D.ietf-dhc-mac-assign] 343 proposes an extension to DHCPv6 that allows a scalable approach to 344 link-layer address assignments where preassigned link-layer address 345 assignments (such as by a manufacturer) are not possible or 346 unnecessary. [I-D.ietf-dhc-slap-quadrant] proposes extensions to 347 DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to 348 indicate a preferred SLAP quadrant to the server, so that the server 349 may allocate MAC addresses in the quadrant requested by the relay or 350 client. 352 Not only MAC and IP addresses can be used for tracking purposes. 353 Some DHCP options carry unique identifiers. These identifiers can 354 enable device tracking even if the device administrator takes care of 355 randomizing other potential identifications like link-layer addresses 356 or IPv6 addresses. [RFC7844] introduces anonymity profiles, designed 357 for clients that wish to remain anonymous to the visited network. 358 The profiles provide guidelines on the composition of DHCP or DHCPv6 359 messages, designed to minimize disclosure of identifying information. 360 [RFC7844] also indicates that the link-layer address, IP address, and 361 DHCP identifier shall evolve in synchrony. 363 8. IANA Considerations 365 N/A. 367 9. Security Considerations 369 TBD. 371 10. Acknowledgments 373 TBD. 375 11. References 377 11.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 11.2. Informative References 386 [enhancing_location_privacy] 387 Gruteser, M. and D. Grunwald, "Enhancing location privacy 388 in wireless LAN through disposable interface identifiers: 389 a quantitative analysis", Mobile Networks and 390 Applications, vol. 10, no. 3, pp. 315-325 , 2005. 392 [I-D.gont-6man-deprecate-eui64-based-addresses] 393 Gont, F., Cooper, A., Thaler, D., and W. Will, 394 "Deprecating EUI-64 Based IPv6 Addresses", draft-gont- 395 6man-deprecate-eui64-based-addresses-00 (work in 396 progress), October 2013. 398 [I-D.ietf-dhc-mac-assign] 399 Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer 400 Addresses Assignment Mechanism for DHCPv6", draft-ietf- 401 dhc-mac-assign-09 (work in progress), September 2020. 403 [I-D.ietf-dhc-slap-quadrant] 404 Bernardos, C. and A. Mourad, "SLAP quadrant selection 405 option for DHCPv6", draft-ietf-dhc-slap-quadrant-12 (work 406 in progress), October 2020. 408 [IEEE_802_11_aq] 409 Group, 8. W. -. W. L. W., "IEEE 802.11aq-2018 - IEEE 410 Standard for Information technology--Telecommunications 411 and information exchange between systems Local and 412 metropolitan area networks--Specific requirements Part 11: 413 Wireless LAN Medium Access Control (MAC) and Physical 414 Layer (PHY) Specifications Amendment 5: Preassociation 415 Discovery", IEEE 802.11 , 2018. 417 [IEEE_802c] 418 architecture, 8. W. -. 8. L., "IEEE 802c-2017 - IEEE 419 Standard for Local and Metropolitan Area Networks:Overview 420 and Architecture--Amendment 2: Local Medium Access Control 421 (MAC) Address Usage", IEEE 802c , 2017. 423 [IEEE_802E] 424 architecture, 8. W. -. 8. L., "IEEE 802E-2020 - IEEE 425 Approved Draft Recommended Practice for Privacy 426 Considerations for IEEE 802 Technologies", IEEE 802E , 427 2020. 429 [ieee_privacy_ecsg] 430 IEEE 802 Privacy EC SG, "IEEE 802 EC Privacy 431 Recommendation Study Group", 432 . 434 [link_layer_privacy] 435 O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the 436 link layer", Contribution at W3C/IAB workshop on 437 Strengthening the Internet Against Pervasive Monitoring 438 (STRINT) , February 2014. 440 [privacy_android] 441 Google/Open Handset Alliance, "Android Privacy: MAC 442 Randomization", 443 . 446 [privacy_ios] 447 Apple, "Use private Wi-Fi addresses in iOS 14, iPadOS 14, 448 and watchOS 7", 449 . 451 [privacy_tutorial] 452 Cooper, A., Hardie, T., Zuniga, JC., Chen, L., and P. 453 O'Hanlon, "Tutorial on Pervasive Surveillance of the 454 Internet - Designing Privacy into Internet Protocols", 455 . 458 [privacy_windows] 459 Microsoft, "Windows: How to use random hardware 460 addresses", . 464 [rcm_privacy_csd] 465 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 466 Addresses Study Group CSD on user experience mechanisms", 467 doc.:IEEE 802.11-20/1346r1 , 2020. 469 [rcm_privacy_par] 470 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 471 Addresses Study Group PAR on privacy mechanisms", 472 doc.:IEEE 802.11-19/854r7 , 2020. 474 [rcm_tig_final_report] 475 TIG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 476 Addresses Topic Interest Group Report", doc.:IEEE 477 802.11-19/1442r9 , 2019. 479 [rcm_user_experience_csd] 480 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 481 Addresses Study Group CSD on user experience mechanisms", 482 doc.:IEEE 802.11-20/1117r3 , 2020. 484 [rcm_user_experience_par] 485 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 486 Addresses Study Group PAR on user experience mechanisms", 487 doc.:IEEE 802.11-20/742r5 , 2020. 489 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 490 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 491 November 2005, . 493 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 494 Address Autoconfiguration", RFC 4862, 495 DOI 10.17487/RFC4862, September 2007, 496 . 498 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 499 Morris, J., Hansen, M., and R. Smith, "Privacy 500 Considerations for Internet Protocols", RFC 6973, 501 DOI 10.17487/RFC6973, July 2013, 502 . 504 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 505 Interface Identifiers with IPv6 Stateless Address 506 Autoconfiguration (SLAAC)", RFC 7217, 507 DOI 10.17487/RFC7217, April 2014, 508 . 510 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 511 Profiles for DHCP Clients", RFC 7844, 512 DOI 10.17487/RFC7844, May 2016, 513 . 515 [strint] W3C/IAB, "A W3C/IAB workshop on Strengthening the Internet 516 Against Pervasive Monitoring (STRINT)", 517 . 519 [when_mac_randomization_fails] 520 Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown, 521 L., Riggins, C., Rye, E., and D. Brown, "A Study of MAC 522 Address Randomization in Mobile Devices and When it 523 Fails", arXiv:1703.02874v2 [cs.CR] , 2017. 525 [wifi_internet_privacy] 526 Bernardos, CJ., Zuniga, JC., and P. O'Hanlon, "Wi-Fi 527 Internet Connectivity and Privacy: Hiding your tracks on 528 the wireless Internet", Standards for Communications and 529 Networking (CSCN), 2015 IEEE Conference on , October 2015. 531 [wifi_tracking] 532 The Independent, "London's bins are tracking your 533 smartphone", . 537 Authors' Addresses 539 Juan Carlos Zuniga 540 SIGFOX 541 Montreal QC 542 Canada 544 Email: j.c.zuniga@ieee.org 546 Carlos J. Bernardos 547 Universidad Carlos III de Madrid 548 Av. Universidad, 30 549 Leganes, Madrid 28911 550 Spain 552 Phone: +34 91624 6236 553 Email: cjbc@it.uc3m.es 554 URI: http://www.it.uc3m.es/cjbc/ 555 Amelia Andersdotter 556 CENTR 557 Belliardstraat 20 (6th floor) 558 Brussels 1040 559 Belgium 561 Email: amelia@centr.org 562 URI: https://www.centr.org