Gogo, the WiFi provider for airlines like Air Canada, is not available to Linux users even though it advertises "access using any Wi-Fi enabled laptop, tablet or smartphone". It is however possible to work-around this restriction by faking your browser user agent.
I tried the User-Agent Switcher for Chrome extension on Chrome and Brave but it didn't work for some reason.
What did work was using Firefox and adding the following prefs in
about:config
to spoof its user agent to Chrome for Windows:
general.useragent.override=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36
general.useragent.updates.enabled=false
privacy.resistFingerprinting=false
The last two prefs are necessary in order for the hidden
general.useragent.override
pref to not be
ignored.
Opt out of mandatory arbitration
As an aside, the Gogo terms of service automatically enroll you into mandatory arbitration unless you opt out by sending an email to [email protected] within 30 days of using their service.
You may want to create an email template for this so that you can fire off a quick email to them as soon as you connect. I will probably write a script for it next time I use this service.
I noticed that I was receiving some bounced email notifications from a
domain I own (cloud.geek.nz
) to host my blog. These notifications were all
for spam messages spoofing the From
address since I do not use that domain
for email.
I decided to try setting a strict DMARC policy to see if DMARC-using mail servers (e.g. GMail) would then drop these spoofed emails without notifying me about it.
I started by setting this initial DMARC policy in DNS in order to monitor the change:
@ TXT v=spf1 -all
_dmarc TXT v=DMARC1; p=none; ruf=mailto:[email protected]; sp=none; aspf=s; fo=0:1:d:s;
Then I waited three weeks without receiving anything before updating the relevant DNS records to this final DMARC policy:
@ TXT v=spf1 -all
_dmarc TXT v=DMARC1; p=reject; sp=reject; aspf=s;
This policy states that nobody is allowed to send emails for this domain and that any incoming email claiming to be from this domain should be silently rejected.
I haven't noticed any bounce notifications for messages spoofing this domain in a while, so maybe it's working?
DKIM
Cloudflare suggests also including an invalid DKIM record:
*._domainkey TXT v=DKIM1; p=
and referring to it in the DMARC record via adkim=s
:
_dmarc TXT v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;
I'm not sure why a mail server would correctly handle DKIM but not SPF since the former is more complicated. Maybe this is not really necessary and is merely a belt-and-suspender kind of approach.