Companies

For vacation / touristing purposes, I did some travel. When leaving the comfort of EU/ETA-region cell phone mobile data changes into something tricky. Most telcos here in Finland offer you 15 GiB of roaming transfer per month inside EU/ETA. As I travelled into post-brexit UK, the gravity of current roaming agreements hit me. For those unaware (like me on London Heathrow airport): nothing works and if works, expect to pay per-GiB on gold bullions.

At hotel, free Wi-Fi was more than welcome addition to their service offering. With that I was able to figure out what the heck happened to my iPhone data and what measures could I take to enable it.

After weighing all the options, my solution was to purchase an eSIM. That's something I never even considered before. Being in "the spot" I just went for Holafly eSIM. I'm 99,9% sure their offering is not the best nor cheapest, their product simply was easily available. Their marketing must be superb!

List of options considered, but abandoned for different reasons included following:

• Not having data in my phone.
• Relying on public Wi-Fis. They were generally available in many sights and locations.
• Enabling non-EU/ETA data roaming on my subscription.
• Purchasing a prepaid SIM from nearby groceries store. They were generally available, not too expensive and easy to obtain.

This is what I paid with a credit card:

$19 USD. Living in Finland, the country most of the mobile stuff was invented at, the price for unlimited 5 day data was horrible. This is what Holafly delivered me via email:

A QR-code! What! Are eSIMs distributed as QR-codes? Really?
More googling revealed: yes, that's correct. An eSIM is essentially a QR-code.

Payload of above matrix barcode would be as follows:

LPA:1$h3a.prod.ondemandconnectivity.com$8083B8A60025B1BA0E92A460388592035501C61BB74516AB176BA714D64AD60B

Studying the topic more with eSIM Whitepaper - The what and how of Remote SIM Provisioning and How Does an eSIM Work? Acronym LPA from the QR-code stands for Local Profile Assistant. Most stuff encoded into a QR-code I've ever seen has some sort of classifier as the initial value, so having something there would be expected. Next section with $-signs contain a hostname to contact followed by a password to provide for a server answering to requests on mentioned hostname to issue details of my newly purchased subscription for my phone. Host h3a.prod.ondemandconnectivity.com translates into 91.240.72.102, property of Thales group.

After walking through iPhone new data profile wizard, this is what I ended up with:

For unknown reason, the name of my eSIM was "Travel". That's something that can be chosen and renamed, even. Taking a look into the settings of my Travel-profile reveals following:

Whoo! That's an Austrian telco 3 subscription. The name "Drei" is German and means three (3). There are number of subsidiaries on 3 or Hutchison 3G Enterprises S.A.R.L., in case you are unaware of such telco group.

Now that I had mobile data, the obvious first thing was to verify where my Internet exit-node was located at. It seemed, my IPv4-range 91.223.100.0/26 was operated by Nexthop AS from Norway. A closer look on their geo-feed at https://geofeed.wgtwo.com/geofeed.csv revealed two network ranges of /26 or 62 available addresses:

# prefix,country_code,region_code,city,postal
91.223.100.0/26,GB,ENG,London,EC2V
91.209.212.0/26,GB,ENG,London,EC2V

Ultimately I was happy. Everything worked well, my iPhone had data connection for maps, googling, mail and iMessage.

To summarize:

1. My iPhone is designed in California, USA and manufactured in China.
2. I purchased an eSIM from Holafly, a Spanish company.
3. I paid US dollars for the product on their website located in an UK server.
4. What I got delivered from the purchase was credentials to connect to a French server.
5. Response payload of from the French server was an Austrian mobile data subscription.
6. Subscription's public Internet exit was located at United Kingdom, operated by a Norwegian company.

That's what I call an international operation!

PS. If you can hack the above eSIM to work for you, please inform me. It's a pre-paid, so I won't be the one taking the loss.

Your and my data is leaked left and right all the time by organizations who at the time of you entering your precious PII (or Personally Identifiable Information) solemny swear to take really good care of it. Still they fail at it. By adapting the famous speech by John F. Kennedy: "Not because it is easy, but because it is hard." Even companies whose business is information security get hacked, or mis-configure their systems or human administrators fail at a minor thing causing major disasters, causing data to leak. Because it is very very hard to protect your data. Let alone companies whose business is not information security, they simply want to conduct their business on-line and not to focus in nurturing YOUR information. When a flaw in their system or procedures is found by malicious actors, data will be leaked.

I don't think this is about to change anytime soon. Unfortunately.

Back in 2020, a site called 123RF.com was pwned. How, or by whom is irrelevant. They failed protecting MY data. More details are available in Bleeping Computer article Popular stock photo service hit by data breach, 8.3M records for sale.

As anybody can expect, there are negative effects on such leaks. Today, such negativity manifests itself in my mailbox as follows:

A company, who has nothing to do with me is sending email to my unique 123RF-dedicated address, stating my attempt to request password recovery on their on-line service has failed. Ok, intersting. Not cool. However inconvenient this is to me, I fail to find the attacker's angle on this. By sending 8.3 million password recovery attempts to a public endpoint is a far fetch. They might by shear luck get access to somebody's account on the targeted site. Most likely not. But it's worth the try as it won't cost them anything and very easy to do.

This exact same has happened to me multiple times. An example from 2018 is my blog post DocuSign hacked: Fallout of leaked E-mail addresses. Given all the time and effort I put into creating mail system where I can have unique addresses to all possible use-cases it will be easy to identify the leaking source. Me and many others thought EU's GDPR was supposed to help every single Internet user with this, but still Wired is writing in their May 2022 article How GDPR Is Failing (sorry about the paywall, I'm a subscriber).

I'd like to end this by expressing my generic despair and agony not targeted towards anybody in particular while still targeted towards all stakeholders. It's a movie quote from the original -68 Planet of the Apes where at the end of the film Charlton Heston's character understands what had happened and how he ended up in that mess:

Ah, damn you! God damn you all to hell!

Couple days ago I got an email to a really old address of mine. I happen to own number of domains and most of them are connected to the mail system on my home Linux server. Many many years ago I stopped using a single email address for the simple reason that I couldn't identify to whom I had given that address to. This is a design flaw in archaic asynchronous messging methods like snail mail, telephone calls or SMTP. You simply don't know who is contacting you and where did they obtain your information from.

To defeat this design flaw I have an unique email address for every single service I ever hand my information to. That particular address in question pre-dates my system and is roughly 20 years old. So, no way of knowing who originally leaked it or how many times the address has been leaked. As I don't use it anywhere anymore, an email sent there is with 99,9% confidence junk.

Why I'm writing about that email is obvious, it had very interesting content. Sender claimed to be (a company?) called CafePress. Something I've never head of. Another reason why I kept investigating this maybe-spam was the subject of "Notice of FTC Settlement - 2019 Data Breach". Ok. Federal Trade Commission of USA was addressing me via CafePress. Really interesting!

First the technical ones. To deduce if this was spam or not, I always check the mail headers. This baby had both SPF and DKIM verified correctly. Both technical measures are pretty much a must for anybody to accept the incoming set of bytes. Well, also spammers know this and typically use Google or Microsoft as spam platforms via their free-of-charge mail offerings.

As technical details checked out, next the actual sending server. It originated to something called https://www.sparkpost.com/. Again, something I've never heard of. Ultimately this mail passed all techical checks. My thinking started leaning towards this being the Real Deal.

Email contents:

Dear Valued Customer,

We are contacting you about the 2019 breach of your information collected by the prior owners of CafePress. This notice is about that breach, which you may have already been notified of.

We recently reached a settlement with the Federal Trade Commission, the nation's consumer protection agency, to resolve issues related to the 2019 data breach, and to make sure CafePress keeps your information safe. What happened?

Before November 2019, CafePress didn't have reasonable practices to keep your information safe. When the company had a security breach, the following information about you may have been stolen: your email address, password, name, address, phone number, answers to your security questions, and the expiration date and last four digits of your credit card.

What you can do to protect yourself

Here are some steps to reduce the risk of identity theft and protect your information online:
<blah blah removed>

Sincerely,

Chris Klingebiel
General Manager, CafePress

Hm. Interesting.
Somebody in a company I've never heard of leaked my data in 2019 by a hack. Well, why did they have my information on the first place!

Googling the topic for more details:

Article Commission orders e-commerce platform to bolster data security and provide redress to small businesses is available on FTC.gov. It was legit after all!

Press release mentionded following: "Residual Pumpkin Entity, LLC, the former owner of CafePress, and PlanetArt, LLC, which bought CafePress in 2020". Whoa! Even more companies which I never heard of.

Some highlights:

According to the complaint, a hacker exploited the company’s security failures in February 2019 to access millions of email addresses and passwords with weak encryption; millions of unencrypted names, physical addresses, and security questions and answers; more than 180,000 unencrypted Social Security numbers; and tens of thousands of partial payment card numbers and expiration dates.

Obviously this CafePress (or whoever it is) didn't do much of a job for protecting their stolen/bought/downloaded-from-DarkNet -data. It's a good thing FTC gave them a slap-on-the-wrist -punishment as the company is clearly crooked. Why an earth didn't FTC do more follow up on the origins of the data? I'd definitely love to hear how this CafePress got my data into their hands. I didn't volunteer it, that's for sure!

Really puzzling case this. I suppose it speaks volumes about the modern state of Internet.

Back-in-the-day, roughly three years ago, I wrote a JavaScriptlet for breaking trough a press website's paywall. At the time I promised not to "piss" into their proverbial coffee pot and not publish updated versions of my hack. I kept my word. It was surprisingly easy! They didn't change a thing. Until now.

This particular ICT-media finally realized their client tell to contain mostly smart people with good computer skills. Just clicking a button on your shortcuts-bar of your chosen web browser after reading 5 articles was too easy. They finally went into full-blown hedgehog defense and enabled two measures:

1. Without authentication, your IPv4-address is tracked.
   • No cookies required
   • Doesn't care which browser on which computer you're using
   • There is a very small number of free-of-charge articles you can read per day. I'd say 5.
   • Unfortunately their AWS-setup doesn't have IPv6 enabled. With that I'd have much more IP-addresses at my disposal.
2. With authentication, the number of free-of-charge articles is limited. I'd guess to 10 of them.

For proper paywall breakage, lots of IPv4-addresses would be required. I do have some, but I'd rather not play this game anymore. I'll call it quits and stick with the headers of their RSS-feed. Obviously, they'll limit the feed into last 10 articles, but if you keep reading and accumulating the data 24/7, you'll get all of them.

Good job! One potential customer lost.

For number of reasons, instead of migration, I should write migraine. First is about moving from an old system into a new one. Latter is about medical condition causing severe headaches. In this case, there seems to be not much of a difference.

Google's own Make the switch to Google Analytics 4 -migration guide has 12 steps. Given complexity, the time I have to invest on this and lack of really diving into this, I probably missed most of them.

Going into GA4-console, I have this:

Clicking on Get Tagging Instructions, I'll get further information:

There is a snippet of JavaScript, which I can inject into this site.

<script async="" src="https://www.googletagmanager.com/gtag/js?id=G-859QZJED94"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-859QZJED94');
</script>

Note: My GA4-stream ID is G-859QZJED94. Make sure to use yours, not mine. As the stream ID cannot be a secret, it's ok to publish it here. The same ID can be found from HTML-code of this page.

To verify installation success, I went to GA4 portal, chose Reports and Realtime. It didn't take long, less than a minute, for that report to indicate user activity. Many other places keep saying "No data received from your website yet", "No data received in past 48 hours" or "Data collection isn’t active for your website". IMHO all of those are incorrect, as I do have stats. We'll see if I managed to do that right.

Quite close six years ago, I posted about my visit in Megazone. Now I got to go there again. This time there were more of us and we had a private game for the company.

Round 1

This was me getting the look and feel how this game worked.

Oh boy our team sucked! (Sorry my colleagues, not sorry.)
Obviously I was the best in our green team, but I ranked 11th out of 30. Looking at the scores, red team was way too good for us and blue team had couple guys better than me.

Round 2

I'm not exactly sure, but somehow this turned into a base defense. Other teams were convinced they had to rape our base and me and another member of my red team were almost constantly defending our base.

This turn of events ended me being 4th out of 32 players. Actually, not missing the 2nd position by too much.

Round 3

This round was full-on base defense 100% of the time. There were 5 or 6 players of our team doing base defense to our blue team. Way too many players on other teams were keen on getting their 2000 pts on our base.

Btw, I'm pretty sure we fended them on each attack wave.

Mentally I'd love to do more freeroaming than doing area defense. I didn't enjoy this kind of game that much so I simply gave up. I wasn't moving nearly as much as reasonable Laser Tag tactics dictates. Being stationary will result in a below medium score and position 18th out of 30.

Overall

I still can get my kick out of round 2 while zapping attackers on left and right. That was fun!
However, I'll be waiting for the release of Sniper Elite 5 next week, I know I will enjoy video gaming more than IRL gaming.

Since I started working with vacdec, something has been bugging me. I quite couldn't put my finger on it at first. As a reader asked me to decode some unix timestamps from CBOR payload into human-readable format, it hit me. The output needs to be easily understandable!

Now there exists a version with that capability (see: https://github.com/HQJaTu/vacdec for details).

Using Finnish government provided test data, this is the raw CBOR/JSON data:

{
  "1": "FI",
  "4": 1655413199,
  "6": 1623833669,
  "-260": {
    "1": {
      "v": [
        {
          "ci": "URN:UVCI:01:FI:DZYOJVJ6Y8MQKNEI95WBTOEIM#X",
          "co": "FI",
          "dn": 1,
          "dt": "2021-03-05",
          "is": "The Social Insurance Institution of Finland",
          "ma": "ORG-100001417",
          "mp": "EU/1/20/1525",
          "sd": 1,
          "tg": "840539006",
          "vp": "J07BX03"
        }
      ],
      "dob": "1967-02-01",
      "nam": {
        "fn": "Testaaja",
        "gn": "Matti Kari Yrjänä",
        "fnt": "TESTAAJA",
        "gnt": "MATTI<KARI<YRJAENAE"
      },
      "ver": "1.0.0"
    }
  }
}

Exactly the same with improved version for vacdec:

{
  "issuer": "Finland",
  "expiry:": "2022-06-16 20:59:59",
  "issued:": "2021-06-16 08:54:29",
  "Health certificate": {
    "1": {
      "Vaccination": [
        {
          "Unique Certificate Identifier: UVCI": "URN:UVCI:01:FI:DZYOJVJ6Y8MQKNEI95WBTOEIM#X",
          "Country of Vaccination": "Finland",
          "Dose Number": 1,
          "Date of Vaccination": "2021-03-05",
          "Certificate Issuer": "The Social Insurance Institution of Finland",
          "Marketing Authorization Holder / Manufacturer": "Janssen-Cilag International",
          "Medicinal product": "EU/1/20/1525: COVID-19 Vaccine Janssen",
          "Total Series of Doses": 1,
          "Targeted disease or agent": "COVID-19",
          "Vaccine or prophylaxis": "COVID-19 vaccines"
        }
      ],
      "Date of birth": "1967-02-01",
      "Name": {
        "Surname": "Testaaja",
        "Forename": "Matti Kari Yrjänä",
        "ICAO 9303 standardised surname": "TESTAAJA",
        "ICAO 9303 standardised forename": "MATTI<KARI<YRJAENAE"
      },
      "Version": "1.0.0"
    }
  }
}

Much easier on the eye. Raw data can still be displayed, but is not the default. Use switch --output-raw to get original result.

There are comments in my Python-code, but for those wanting to eyeball the specs themselves, go see https://github.com/ehn-dcc-development/ehn-dcc-schema and https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v1_en.pdf for exact details of CBOR header and payload fields. The certificate JSON-schema describes all used value-sets.

Note: Especially JSON-schema is a living thing. If you read this in the future, something might have changed.
Please, drop me a line when that happens.

There it is:

This update was promised on 8th September 2020, roughly an year ago. See: https://twitter.com/nokiamobile/status/1303384763705819157

As promised, there it is. And for iPhone user like me, taking a screenshot and sending it into processing via Gmail is nearly impossible. These same Nokia-guys used to make phones where every trivial thing required 5-8 button presses. Even if every generation of Android takes out my user experience, I still appreciate the fact they maintain and provide updates to these no-mandatory-Facebook -phones.

Keep it up!

If you live in EU, you most definitely have heard of COVID Passport.

Practically speaking, it is a PDF-file A4-sized when printed and can be folded into A6-pocket size. In Finland a sample would look like this:

What's eye-catching is the QR-code in the top right corner. As I'm into all kinds of nerdy stuff, I took a peek what's in it.

After reading some specs and brochures (like https://www.kanta.fi/en/covid-19-certificate) I started to tear this apart and deduced following:

• An A4 or the QR-code in it can be easily copied / duplicated
• Payload can be easily forged
• There is a claim: "The certificate has a code for verifying the authenticity"

My only question was: How is this sane! Why do they think this mechanism they designed makes sense?

QR-code

Data in QR-code is wrapped multiple times:

This CBOR Object Signing and Encryption (COSE) described in RFC 8152 was a new one for me.

Payload does contain very little of your personal information, but enough to be compared with your ID-card or passport. Also there is your vaccination, test and possible recovery from COVID statuses. Data structure can contain 1, 2 or 3 of those depending if you have been vaccinated or tested, or if you have recovered from the illness.

Python code

It's always about the details. So, I forked an existing git-repo and did some of my own tinkering. Results are at: https://github.com/HQJaTu/vacdec/tree/certificate-fetch

Original code by Mr. Hanno Böck could read QR-code and do some un-wrapping for it to reveal the payload. As I'm always interested in X.509, digital signatures and cryptography, I improved his code by incorporating the digital signature verification into it.

As CBOR/COSE was new for me, it took a while to get the thing working. In reality the most difficult part was to get my hands into the national public certificates to do some ECDSA signature verifying. It's really bizarre how that material is not made easily available.

Links:

• Swagger of DGC-gateway: https://eu-digital-green-certificates.github.io/dgc-gateway/
  • This is just for display-purposes, this demo isn't connected to any of the national back-ends
• Sample data for testing verification: https://github.com/eu-digital-green-certificates/dgc-testdata
  • All participating nations included
  • QR-codes and raw-text ready-to-be-base45-decoded
• Payload JSON_schema: https://github.com/ehn-dcc-development/ehn-dcc-schema/
  • Just to be clear, the payload is not JSON
  • However, CBOR is effectively binary JSON
• List of all production signature certificates: https://dgcg.covidbevis.se/tp/
  • Austrian back-end trust-list in JSON/CBOR: https://greencheck.gv.at/api/masterdata
  • Swedish back-end trust-list in CBOR: https://dgcg.covidbevis.se/tp/trust-list
  • The idea is for all national back-ends to contain everybody's signing certificate

Wallet

Mr. Philipp Trenz from Germany wrote a website to insert your QR-code into your Apple Wallet. Source is at https://github.com/philipptrenz/covidpass and the actual thing is at https://covidpass.eu/

Beautiful! Works perfectly.

Especially in Finland the government is having a vacation. After that they'll think about starting to make plans what to do next. Now thanks to Mr. Trenz every iOS user can have the COVID Certificate in their phones without government invovement.

Finally

Answers:

• Yes, duplication is possible, but not feasible in volume. You can get your hands into somebody else's certificate and can present a proof of vaccination, but verification will display the original name, not yours.
• Yes, there is even source code for creating the QR-code, so it's very easy to forge.
• Yes, the payload has a very strong elliptic curve signature in it. Any forged payloads won't verify.

Ultimately I was surprised how well designed the entire stack is. It's always nice to see my tax-money put into good use. I have nothing negative to say about the architecture or technologies used.

Bonus:
At very end of my project, I bumped into Mr. Mathias Panzenböck's code https://github.com/panzi/verify-ehc/. He has an excellent implementation of signature handling, much better than mine. Go check that out too.

What happens when IT-operations are run by incompetent idiots?

For reference, I've written about State of Ubisoft and failures with top level domain handling.

I'm an avid gamer. I play games on daily basis. It is not possible to avoid bumping into games by giant corporations like Activision or Ubisoft. They have existed since 80s, have the personnel, money and resources. They also keep publishing games I occasionally love playing.

How one accesses their games is via software called Ubisoft Connect:

You need to log into the software with your Ubisoft-account. As one will expect, creating such account requires you to verify your email address so, the commercial company can target their marketing towards you. No surprises there.

Based on my previous blog posts, you might guess my email isn't your average gmail.com or something similar. I have multiple domains in my portfolio and am using them as my email address. With Ubisoft, initially everything goes smoothly. At some point the idiots at Ubisoft decided, that I needed to re-verify my email. Sure thing. Let's do that. I kept clicking the Verify my email address -button on Ubisoft Connect for years. Nothing happened, though. I could click the button but the promised verification email never arrived.

In 2019 I had enough of this annoyance and approached Ubisoft support regarding the failure to deliver the email.

Their response was:

I would still advise you to use a regularly known e-mail domain such as G-mail, Yahoo, Hotmail or Outlook as they have been known to cause no problems.

Ok. They didn't like my own Linux box as mailserver.

Luckily Google Apps / G Suite / Google Workspace (whatever their name is this week) does support custom domains (Set up Gmail with your business address (@your-company)). I did that. Now they couldn't complain for my server to be non-standard or causing problems.

Still no joy.

As the operation was run by incompetent idiots, I could easily send and receive email back and forth with: Ubisoft support, Ubisoft Store and Ubisoft marketing-spam. The ONLY kind of emails I could not receive was their email address verification. Until Apri 23rd 2021. Some jack-ass saw the light and realized "Whoa! There exists TLDs which are longer than 4 characters!" In reality I guess they changed their email service provider into Amazon SES and were able to deliver the mails.

This in insane!

Privacy, especially your/mine/everybody's, has been an always actual topic ever since The Internet begun its commercial expansion in the beginning of 90s. Being an important topic, it has been thought everybody should have the right for privacy. In EU, the latest regulation is called on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, or General Data Protection Regulation. In California, USA they'd call it California Consumer Privacy Act.

Privacy protection gone wrong

Both above mentioned regulations have good intention. Forcing websites to bombard all of their users with stupid questions are a complete waste of bandwidth! Everybody is tired of seeing popups like this while surfing:

Somehow the good intention turned on itself. Literally nobody wants to make those choices before entering a site. There should be a setting in my browser and all those sites should read the setting and act on it without bothering me.

Mobile phone tracking

Meanwhile, your cell service provider is using your data and you won't be offered a set of checkboxes to tick.

As an example, Telia’s anonymized location data helps Finnish Government fight the coronavirus (April 2020). This corporation has a product called Crowd Insights. Anybody with a reasonable amount of money (actual price of the service is not known) can purchase location data of actual persons moving around a city. There is a brief investigation by Finnish Chancellor of Justice stating that the service is legal and won't divulge any protected data. The decision (unfortunately, only in Finnish) Paikannustietojen hyödyntäminen COVID-19 –epidemian hillinnässä states, the service's data is daily or hourly and while a reasonable accurate location of a mobile device can be obtained, if that location data doesn't identify a person, obviously, it's not protected by any laws.

On the topic of COVID-19, Future of Privacy Forum has published an article A Closer Look at Location Data: Privacy and Pandemics, where they raise points from ethics and privacy perspective of such tracking. A good read, that!

Application of mobile movement tracking

Here is one. A newspaper article titled "Puhelinten sijainti­tiedot paljastavat, kuinka ihmismassojen liikkuminen yöllisessä Helsingissä muuttui" (https://www.hs.fi/kaupunki/art-2000006698336.html):

For non-Finnish -speaking readers: this article is about movement of people in center of Helsinki. For a reference point, there is Crowd Insights data from September 2019, time before COVID-19. Movement data from pandemic is from September 5th, October 10th and 17th. To state the obvious: in 2019 between Saturday 9pm and Sunday 9am people moved a lot. What's also visible is how this global pandemic changed this behaviour. In September 2020 there were no strict regulations for night clubs and bars, which is clearly visible in the data.

Anyway, this is the kind of data of you walking around in your hometown streets, your mobile in pocket, can be easily gathered. Doing the same walk without a cell network -connect mobile device wouldn't show in that data set.

What! Are they tracking my movements via my cell phone?

Short: Yes.

Long: Yes. Your cell network provider knows every second to which cell tower all devices in their network are connected to. They also know the exact location of that identified cell tower. This coarse location information can be used by somebody or not.

Everybody knows the Hollywood movie cliché where a phone call is being tracked and somebody throws the frase "Keep them talking longer, we havent' got the trace yet!". In reality they'll know your location if your phone is turned on. It doesn't have to have an ongoing call or message being received. This is how all cell networks are designed and that's how they have always operated. They know your coarse location at all times. How exact a "coarse" location is, depends. Who has access to the location information is protected by multiple laws. The point is: they have the information. At all times.

Example illustration from 3GPP spec TR 23.912 Technical report on Super-Charger:

I'm skipping most the TLA (Three-Letter Acronyms) from the pic, but the main concept is having the car (with a phone in it) moving around the network. A HLR (or Home Location Register) will always keep track, on which BSS (note: I think it's called Radio Network Subsysten, RNS in UMTS and LTE) the mobile device talks to. This BSS (or RNS) will send updates on any jumping between the serving cells.

To simplify this further: Just replace the car with a phone in your pocket and this fully applies to people bar-hopping in center of Helsinki.

Database of cell towers

As the cell tower locations are the key component when pinpointing somebody's location, we need to know which cell towers exist and exact locations of those. Unfortunately telcos think that's a trade secret and won't release such information to general public. At the same time, from our phones we can see the identifier of the cell tower a phone is connected to and some hints to neighbouring cells. I wrote about iPhone field test mode couple years back. What a phone also has is a GPS pinpointing the exact location where a particual cell tower and couple of its friends are located at. When added with the information of, a phone typically connecting to the tower with best signal, it is possible to apply some logic. Further gathering couple of data points more, it is possible to calculate a coarse location of a cell tower your phone connects to.

Being an iPhone user, I'm sorry to say an iPhone is not technically suitable for such information gathering. Fortunately, an Android being much more open (to malware) is. Necessary interfaces exist in Android-system to query for cell tower information with an app like Tower Collector. This kind of software it is possible to create records of cell tower information and send them to OpenCelliD to be further processed and distributed to other interested parties.

OpenCelliD website contains an interactive map:

The above example is from my home town of Lappeenranta, Finland. What it depicts is approximation of a LTE cell tower location having following attributes:

• MCC: 244
• MNC: 91
• LAC: 37322
• CID: 7984918

MCC and MNC indicate the telco. CellID Finder has following information for Finland at https://cellidfinder.com/mcc-mnc#F:

What a LAC (Location Area Code) and CID indicate cannot be decoded without a database like OpenCelliD. Wikipedia article GSM Cell ID gives some hints about LAC and CID. The page also lists other databases you may want to take a look.

COVID-19 tracking

Apple and Google being the manufactures of major operating systems for mobile devices combined forces and created Exposure Notifications. This technology does NOT utilize cell towers nor GPS it it. It works only on Bluetooth LE.

As mentioned in appropriate Wikipedia article, the protocol is called Decentralized Privacy-Preserving Proximity Tracing (or DP-3T for short).

Finally

The key takeaway from all this is:
Location of your mobile device is always known.

Your location, movements between locations and timestamp you did the moving (or not moving) are actively being used to track everybody of us. That's because the technology in mobile networks requires the information.

If this information is shared to somebody else, that's a completely different story.

Newspaper media and magazines have been suffering from digitalization for two decades. Quite few of the traditional publishers have been struggling to keep their revenue stream flowing.

Back in the 90s Internet-boom they simply went to net "because they had to". No clue what to do there, though. Paper sales were going strong, no actions required. Then the obvious happened, people stopped subscribing their paper services. Meanwhile, same people who cancelled their subscriptions, were reluctant to pay for the service on the net. Reasons were multitude: bad implementation of the site, bad implementation of subscription and payment, etc.

Past couple years the trend has been to simply block readers out of the site by erecting a paywall. That will keep the free leechers out (like me), but I'm not certain it would improve the sales. Maybe it does, because lot of the media is doing that. However, yet again the implementation is really bad. There must be enough complexity in the paywall that people like me cannot simply run something like this in Javascript console:

javascript:(function(d){d.cookie='Bhb2CdOB3V=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/; domain=.tivi.fi;'})(document)

If you have no idea what a Javascript console is (most non-developer don't), don't worry. Here is the same thing as a bookmarklet. Concept of bookmarking sites into your browser is past gone, everybody just googles everything. Since nobody maintains bookmarks, it is not-so-user-friendly to manage bookmarks in a modern browser. However, the idea of you is to create a Javascript bookmark, aka. bookmarklet. In chrome, something like this:

Then it is easy to just click the bookmark when you run out of reads. Reload the page and keep reading!

Finally:
Apologies for the newspaper publisher for pissing in their coffee pot. Your product is good and I have enjoyed reading the articles, it's just the price point, you're too expensive! My motivation here is to offer you a pro-bono implementation evaluation. Hint: you failed badly.

I totally expect them to improve their implementation. Also I promise not to maintain any possible hacks their future versions may include. Also I'd like to offer a piece of advice.
There are two real options you can go with:
1) implement mandatory login
or
2) keep some articles free, some behind paywall. That seems to be the only working option of keeping people like me out of your system.

Last week I was sitting in an aeroplane and while being bored, I flicked the phone on to test the Wi-Fi. Actually, I had never done that before and just ran a Speedtest:

Yup. That's the reason I had never done that before.
Half a meg down, 150 up. That's like using a 56 kbit/s modem or 2G-data for Internet. Both were initially cool, but the trick ran old very fast given the "speed" or ... to be precise - lack of it.

More investigation:

As expected, round-trip time was horrible. Definitely a satellite link. Or ... is it? But the answer to the topic's question is: no. There is no real Internet access mid-flight.

The exit IP-address was in /24 block of 82.214.239.0/24 belonging to Hughes Network Systems GmbH. I took a peek into Hughes Communications Wikipedia page at https://en.wikipedia.org/wiki/Hughes_Communications and yes. They have a German subsidiary with the same name.

After I landed and was in safe hands of a 150 Mbit/s LTE-connection, I did some more googling. Side note: When your internet access gets a 100x boost, it sure feels good!

There is a Quora article of How does Wi-Fi internet access in an airplane work? It has following diagram:

That suggests a satellite connection. Also I found The Science of In-Flight Wi-Fi: How Do We Get Internet At 40,000 Feet? from travelpulse.com, but it had some non-relevant information about a 3G-connection being used. That surely was not the case and I seriously doubt, that in Europe such a thing would be used anywhere.

Ultimately the issue was closed when I found the article Row 44 to begin installing connectivity on Norwegian's 737-800s from flightglobal.com. So, it looks like company called Row 44 does in-flight systems for commercial flights. They lease the existing infrastructure from HughesNet, who can offer Internet connectivity to pretty much everywhere in the world.

Wikipedia article Satellite Internet access mentions, that number of corporations are planning to launch a huge number of satellites for Internet access. Hm. that sounds like Teledesic to me. The obvious difference being, that today building a network of satellites is something you can actually do. Back in IT-bubble of 2001, it was merely a dream.

Little bit of background about having certificates

A quote from https://www.brightedge.com/blog/http-https-and-seo/:

Google called for “HTTPS Everywhere” (secure search) at its I/O conference in June 2014 with its Webmaster Trends Analyst Pierre Far stating: “We want to convince you that all communications should be secure by default”

So, anybody with any sense in their head have moved to having their website prefer HTTPS as the communication protocol. For that to happen, a SSL certificate is required. In practice any X.509 would do the trick of encryption, but anybody visiting your website would get all kinds of warnings about that. An excellent website having failing certificates is https://badssl.com/. The precise error for you would see having a randomly selected certificate can be demonstrated at https://untrusted-root.badssl.com/.

Google, as the industry leader, has taken a huge role in driving certificate business to a direction it seems fit. They're hosting the most used website (google.com, according to https://en.wikipedia.org/wiki/List_of_most_popular_websites) and  the most used web browser (Chrome, according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers). So, when they say something, it has a major impact to the Internet.

What they have said, is to start using secured HTTP for communications. There is an entire web page by Google about Marking HTTP As Non-Secure, having the timeline of how every single website needs to use HTTPS or risk being undervalued by GoogleBot and being flagged as insecure to web browsing audience.

Little bit of background about what certificates do

Since people publishing their stuff to the Net, like me, don't want to be downvalued or flagged as insecure, having a certificate is kinda mandatory. And that's what I did. Couple years ago, in fact.

I have no interest in paying the huge bucks for the properly validated certificates, I simply went for the cheapest possible Domain Validated (DV) cert. All validation types are described in https://casecurity.org/2013/08/07/what-are-the-different-types-of-ssl-certificates/. The reasoning, why in my opinion, those different verification types are completely bogus can be found from my blog post from 2013, HTTP Secure: Is Internet really broken?. The quote from sslshopper.com is:
"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."

Nowhere in the technical specifcation of certificates, you can find anything related to actually identifying the other party you're encrypting your traffic with. A X.509 certificate has attributes in it, which may suggest that the other party is who the certificate says to be, but's an assumption at best. There is simply no way of you KNOWING it. What the SSL certificate industry wants you to believe, is that they doing all kinds of expensive verification makes your communications more secure. In reality it's just smoke and mirrors, a hoax. Your communications are as well encrypted using the cheapest or most expensive certificate.

Example:
You can steal a SSL certificate from Google.com and set up your own website having that as your certificate. It doesn't make your website Google, even the certificate so suggests.

Little bit of background about Symantec failing to do certificates

Nobody from Symantec or its affiliates informed me about this. Given, that I follow security scene and bumped into news about a dispute between Google and Symantec. This article is from 2015 in The Register: Fuming Google tears Symantec a new one over rogue SSL certs. A quote from the article says:

On October 12, Symantec said they had found that another 164 rogue certificates had been issued
in 76 domains without permission, and 2,458 certificates were issued for domains that were never registered.

"It's obviously concerning that a certificate authority would have such a long-running issue
and that they would be unable to assess its scope after being alerted to it and conducting an audit,"

So, this isn't anything new here. This is what all those years of fighting resulted as: Replace Your Symantec SSL/TLS Certificates:

Near the end of July 2017, Google Chrome created a plan to first reduce and then remove trust (by showing security warnings in the Chrome browser) of all Symantec, Thawte, GeoTrust, and RapidSSL-issued SSL/TLS certificates.

And: 23,000 HTTPS certs will be axed in next 24 hours after private keys leak.

In short:
They really dropped the ball. First they issued 164 certificates, which nobody actually ordered from them. Those rogue certificates included one for google.com. Then they somehow "lost" 23k private keys for already issued certificates.

That's really unacceptable for a company by their own words is "Global Leader In Next-Generation Cyber Security". That's what Symantec website https://www.symantec.com/ says, still today.

What next?

Symantec has a website called Check your website for Chrome distrust at https://www.websecurity.symantec.com/support/ssl-checker.

I did check the cert of this blog, and yup. It flagged the certificate as one needing immediate replacement. The certificate details have:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            24:6f:ae:e0:bf:16:8d:e5:7a:13:fb:bd:1e:1f:8d:a1
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA
        Validity
            Not Before: Nov 25 00:00:00 2017 GMT
            Not After : Feb 23 23:59:59 2021 GMT
        Subject: CN=blog.hqcodeshop.fi

That's a GeoTrust Inc. issued certificate. GeoTrust is a subsidiary of Symantec. I did study the history of Symantec' certificate business and back in 2010 they acquired Verisign's certificate business resulting as ownership of Thawte and GeoTrust. RapidSSL is the el-cheapo brand of GeoTrust.

As instructed, I just re-issued the existing certificate. It resulted in:

Now, my certificate traces back to a DigiCert CA root.

That's all good. I and you can continue browsing my blog without unnecessary this-website-is-not-secure -warnings.

If you're lucky enough to get to go to a really cool event, it may be handing out a Xyloband to everybody attending it.

For those who've never heard of a Xyloband, go see their website at http://xylobands.com/. It has some sample videos, which this screenshot was taken from:

See those colourful dots in the above pic? Every dot is a person having a Xyloband in their wrist.

The thing looks like this:

As you can see, mine is from King's Kingfomarket, Barcelona 2017. There is an YouTube video from the event, including some clips from the party at https://youtu.be/lnp6KjMRKW4. In the video, for example at 5:18, there is our CEO having the Xyloband in his right wrist and 5:20 one of my female colleagues with a flashing Xyloband. Because the thing in your wrist can be somehow remote controlled, it will create an extremely cool effect to have it flashing to the beat of music, or creating colourful effects in the crowd. So, ultimately you get to participate in the lighting of the venue.

After the party, nobody wanted those bands back, so of course I wanted to pop the cork of one. I had never even heard of such a thing and definitely wanted to see what makes it tick. Back of a Xyloband has bunch of phillips-head screws:

Given the size of the circular bottom, a guess that there would be a CR2032 battery in it is correct:

After removing the remaining 4 screws, I found two more CR2016 batteries:

The pic has only two batteries visible, but the white tray indeed has two cells in it. Given the spec of a button cell (https://en.wikipedia.org/wiki/Button_cell), for a CR-battery it says: diameter 20 mm, height 3.2 mm. So, if you need 6 VDC voltage instead of the 3 VDC a single cell can produce, just put two CR2016 instead of one CR2032. They will take exactly the same space than a CR2032, but will provide double the voltage. Handy, huh! My thinking is, that 9 VDC is bit high for a such a system. But having a part with 6 volts and another part with 3 volts would make more sense to me.

Plastic cover removed, the board of a Xyloband will look like this:

Nylon wristband removed, there is a flexing 4-wire cable having 8 RBG LEDs in it:

The circuits driving the thing are:

Upper one is an Atmel PLCC-32 chip with text Atmel XB-RBG-02 in it. If I read the last line correctly, it says ADPW8B. Very likely a 8-bit Microcontroller Atmel tailored for Xylobands to drive RBG-leds.

The radiochip at the bottom is a Silicon Labs Si4362. The spec is at https://www.silabs.com/documents/public/data-sheets/Si4362.pdf. A quote from the spec says:

Silicon Labs Si4362 devices are high-performance, low-current receivers  covering the sub-GHz frequency bands from 142 to 1050 MHz. The radios are part of the EZRadioPRO® family, which includes a complete line of transmitters, receivers, and transceivers covering a wide range of applications.

Given this, they're just using Silicon Labs off-the-shelf RF-modules to transmit data to individual devices. This data can be fed into the Microcontroller making the RBG LEDs work how DJ of the party wants them to be lit.

While investigating this, I found a YouTube video by Mr. Breukink. It is at https://youtu.be/DdGHo7BWIvo?t=1m33s. He manages to "reactivate" a different model of Xylobands in his video. Of course he doesn't hack the RF-protocol (which would be very very cool, btw.), but he makes the LEDs lit with a color of your choosing. Of course on a real life situation when driven by the Atmel chip, the RBG leds can produce any color. Still, nice hack.