Companies

Couple months ago Ubisoft decided to make paying customers hate them. Early July they made an announcement for Decommissioning of online services for older Ubisoft games. The link here is to Waybackmachine as original announcement has been updated multiple times.

Quote from Ubisoft:

technology that drove those services becomes obsolete

Ok. I and many others paid for your 15 products. Why should I first send you my money and then wait for you not to maintain servers. Technology becomes obsolete every day. What proper software engineers do, is update and maintain our running software. A decision to decommission Anno 2070 servers was reversed, apparently because the developers felt bad.

Ubisoft: Ask your competition! See how many games others are decommissioning.

Btw. if you didn't know, the technology in question is Java. See Oracle announcement from 2021: Java SE 7 End of Extended Support in July 2022 Obviously it took Ubi, in their infinite wisdom, almost an year to react to the last warning. End-of-life was known years ago. Also, I know moving from Java 1.7 forwards isn't trivial, but it isn't impossible either!

PS.
As Ubisoft is offering their UBI+ trial free-of-charge (subscription will turn into paid one after first month). Currently I have an active UBI+ -subscription, which I'm using to play their games. Obviously I'll cancel before paying. I urged you already in 2020 to take my suggestion: Don't send any of your money to them. I know I won't.

For ages spammers' tactic has been to use either free trial of a service or payment via "liberated" credit card. As public cloud service providers want to lure in new customers, there is a habit of offering non-paid services for a period of time. All major providers like AWS, Azure and Google Cloud Platform have such free-of-charge use available.

Also smaller companies have such offering. Smaller companies (are still quite big, but not as big as biggest ones) would include Hetzner and OVHcloud. Both have number of data centers around the Europe and for any postmaster, are a royal pain in the ass. You can get a really cheap VM on either and start spewing spam email into unsuspecting SMTP-servers, like the one I maintain.

This type of free-spam-for-all isn't sustainable, or hasn't been for years, but these companies still allow it to happen. In 2021 Hetzner made a change for better. Lot wasn't communicated, however, this information was published to its customers:

Microsoft Blacklist

Microsoft maintains their own internal blacklists, which are used to reject emails coming from specific IP addresses.

Note: Entire info is available @ Hetzner website.

As a customer of Hetzner having an operational VM, I bumped into a new undocumented restriction applied to new accounts. On my own box, everything still works as usual. Has been for years. To my surprise, outgoing TCP/25 on a new account having a new VM is blocked. What!? Investigating this, led me to Hetzner customer support site, as it has following options for support request:

There is a drop-list with different types of problems having a specific category of Sending mails not possible. Apparently somebody designed the support pipeline for that particular need.

Lack of official documentation made me look in The Net. There I found a confirmation of this policy change. In June 2021 Bjørn Erling Fløtten of Norway wrote in his blog post Ditching Windows and AWS, diving into Linux and Hetzner following story:

Step 8: Setting up an email server

...

(This reminds me of the good old days when a mail server by default usually would be an open relay. Now you definitely get a more secure basic install)

Now I could actually also telnet to port 25 from my Amazon instance, and the connection appeared in the Postfix log. I have no clue why it did not work on the first attempt.

Time to ask Hetzner to open port 25 outbound (SMTP port).

(There is no mentioning of port 25 blocking anywhere on Hetzner's pages. But it is of course natural to assume that port 25 is blocked, even though the firewall administration page of Hetzner's Cloud Console says "All outbound traffic is allowed. Add a rule to restrict outbound traffic.").

So I decided to open a Support ticket, which suggest:
"Server issue"
and
"Server issue: Sending mails not possible"
Choosing the latter gives this:
"Outgoing traffic to ports 25 and 465 are blocked by default on all Cloud Servers.
A request for unblocking these ports and enabling the send mail option is only possible after the first paid invoice."

Fair enough, some thrust needs to be established.

Invoice information says:
"Invoice information
You currently receive 1 invoice a month.
The invoice will be created on the following day:
...th of the month"

...

Bjørn: Hint! Get a free-of-charge TLS-certificate somewhere. Most browsers refuse to enter your site. Thanks, though, for sharing your experience. Now I know to first wait for the invoice and then request for the ports to be opened.

Hetzner: Hint! Would it be smart to document all of this somewhere? Thanks for this change in your policy, though. Anybody needing SMTP will eventually get access. Deactivating option to spam at will makes life of criminals looking for the-easy-way look for other alternatives. This new policy leaves plenty of details about perpetrator's identity for police to investigate.

Update 19th Sep 2022:
Hetzners rules are both of these need to be true:

• First invoice must be paid
• Account must be at least month old

By paying, your SMTP-ports won't open. They open only after bit of a wait.

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.