SIDEBAR
»
S
I
D
E
B
A
R
«
Big Tech Lay-offs, Winter 2023
Jan 20th, 2023 by miki

So, recession is here making local and global companies alike feel the heat. Changes in consumer behaviour affects especially the global tech companies very quickly because of the way they have almost completely gobbled up all marketing spending of every seller and reseller with any digital outlet presence.

As the digital advertising chain is decoupled from anything physical this ripples from consumer spending to impacting big tech revenue with immense speed. This, of course will affect how these companies use their resources, and the workforce needed to run their businesses.

To try to quantify what is happening to global tech companies’ workforce, I’ve collected some numbers and below is a chart illustrating the announced lay-offs in nine prominent big tech companies as of 2023-01-20. On this day, Google announced their reduction of 12’000 “roles” which triggered me to look into this.

Note some trends;

  • the lower headcounts, the higher relative lay-offs
    suggesting that bigger companies have equity and willingness to opt keeping more of the workforce/knowledge
  • Tesla and Cisco seems to have chosen a different strategy as their ratio a considerably lower than similar sized companies
    Tesla’s reluctance to lay-off hourly paid production workers (suggestion that production is regarded as a more severe bottleneck than development) is probably a factor in this

Download spread sheet in ODS format

Numbers and Sources

Lay-off Summaries

Comments Off on Big Tech Lay-offs, Winter 2023
[Danish] S&S: Android-x86 og Chromebook
Jun 8th, 2019 by miki

Lidt flere dråber i Spørgsmål&Svar-kategorien fra Facebook.

Når jeg endelig forvilder mig derind, og går på opdagelse i de tekniske grupper, ender det ofte med at får jeg skrevet en fristil i forsøget på at hjælpe.

Denne gang en snak om Android på “PC”, og basale digitale processeringsbehov for den almindelige dansker.

Spørgsmål

Stillet i gruppen “Danske Android Brugere “:

Er der nogen som ved, om man kan få en pc med Android system?

Svar

Mit svar:

Som andre omtaler, kan der fås en uofficiel variant af det frie styresystem Android til x86-arkitekturen (den gængse Intel/AMD-baserede computer kendt som “personlig computer”).

Det projekt lever på https://www.android-x86.org/. Installationsvejledning på engelsk er på https://www.android-x86.org/installhowto.html. Man kan både installere som multiboot på samme disk som et eksisterende operativsystem, starte fra en ekstern disk (USB-medie, cd/dvdrom e.l.) eller evt. køre i en virtuel maskine på et eksisterende operativsystem (VirtualBox,QEMU/KVM, VMware Player/Workstation).

Jeg har kun erfaring med livedisk boot fra USB og VM, og der synes jeg ikke altid tingene spiller perfekt, så forvent ikke en helt problemfri oplevelse.

“Android på PC” er på kanten af noget understøttet, hvor man ofte er på egen hånd. Nogle af folkene bag Andoid-x86 forsøgte at lave en kommerciel forretning på det, hvor det var tanken at sælge det som færdige hardwareenheder, RemixOS – https://en.wikipedia.org/wiki/Remix_OS, men det gik ikke så godt og er lukket ned igen.

Hvis behovet bare er “en bærbar computer uden for meget vrøvl”, så er en færdig Chromebook med Chrome OS (der ligesom Android også er bygget på GNU/Linux) eller noget af det der dyre Frugt-udstyr nok det mest tilgængelige (men jeg fornemmer at pris også kunne være en faktor?). Til forskel fra traditionelle operativsystemer til computere, er Chrome OS dog møntet specifikt på at få dig til at bruge Googles webbaserede tjenester (mere om softwaren bag på https://www.chromium.org/chromium-os), så hverken software eller hardware er beregnet til at lagre data på selve enheden, og der er sjældent meget diskplads tilgængelig til f.eks. billeder.

Et hurtigt kig på markedet identificerer Acer Chromebook 15 (https://www.edbpriser.dk/produkt/acer-chromebook-15-cb515-1h-c7kg/) og Lenovo S330 (https://www.edbpriser.dk/produkt/lenovo-chromebook-s330-81jw-3292492/) som populære Chromebook i 2k kr.-klassen, men kender ikke maskinerne specifikt.

God jagt :).

Comments Off on [Danish] S&S: Android-x86 og Chromebook
Silent browser redirect on invalid certificate
Nov 15th, 2018 by miki

Hit an odd browser behaviour today.

Trawling through some of those nice and dandy terms for a service (no I won’t tell) I followed a link and suddenly hit an “insecure connection” message from Firefox.

Examining the certificate using the usual “openssl s_client” and “openssl x509” tools surely enough revealed that the served certificate didn’t include the second-level but only on the third-level www sub-domain. Strangely enough I discovered that when entering the same URL directly into the address bar of Firefox the connection was somehow redirected to the www sub-domain and loaded fine without any complaints from Firefox.

Looking into what was happening on the wire using wget directed to not check the certificate (–no-check-certificate) and displaying server responses (–server-response/-S) revealed that the server behind the misconfigured certificate was aiming to issue a HTTP 301 redirect to the valid www sub-domain of the site (actual site replaced by foo.bar and localhost ip);

$ wget –server-response –no-check-certificate –output-document=/dev/null https://foo.bar
–2018-11-15 18:59:14– https://foo.bar/
Resolving foo.bar (foo.bar)… 127.0.0.1
Connecting to foo.bar (foo.bar)|127.0.0.1|:443… connected.
WARNING: no certificate subject alternative name matches
requested host name ‘foo.bar’.
HTTP request sent, awaiting response…
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: https://www.foo.bar/
Date: Thu, 15 Nov 2018 17:59:13 GMT
Content-Length: 152
Location: https://www.foo.bar/ [following]
…

Apparently Firefox’s behaviour in this scenario differs depending on the method in which the user is supplying the URL, in some cases silently ignoring the TLS/SSL warning. A little more experimentation revealed that it was actually not the source of the URL, link followed versus one entered in address bar, that made any difference. Instead it is the presence of a trailing slash on the URL that triggers the silent suppression of the serious red flag that the second-level domain asked to be fetched is not present in the served certificate. I was fooled by the fact that when entering URLs in the address bar Firefox suggests ending the URL on a slash (‘/’) if it is not already present. Manually removing this when editing in the address bar also makes Firefox display the security warning. Alas, the link I originally followed was also missing the trailing slash and behaved as expected by throwing me into a security warning.

The whole “feature” of silently ignoring a security issue seemed very odd to me, but a bit of searching revealed that this was apparently championed by Google Chrome a couple of years ago. It is described in this servertastic post which also directs to a discussion on Twitter, with some key points replicated below, about its presence in Chrome and confirmation from a Chrome team member that the behaviour is intended.

The thread ends with a guy who had dug up the source code of the feature in Chromium (on which Chrome is based) known as “SSLCommonNameMismatchHandling” in file browser/ssl/common_name_mismatch_handler.cc (see all mentions across code base).

This has obviously also trickled down into Firefox, however, not much mention of that is to be found. Not even traces of it by some quick searches of the mozilla-central codebase. Some day I promise (really!) to dig through all source of Mozilla and hunt down the implementation, but for now I’ll revert to a bit of practical experimentation showing the behaviour in the different browsers and operating systems I happen to have access to at the moment;

  • Ubuntu 16.04
    • Firefox 62.0.3: warning, with trailing ‘/’: No warning
    • Chromium 69.0.3497.81: no warning, with trailing ‘/’: no warning
  • Windows Server 2016
    • Firefox 62.0.2: warning, with trailing ‘/’: no warning
    • Google Chrome 70.3538.102: no warning, with trailing ‘/’: no warning
    • Internet Explorer 11.2580.14393.0: warning, with trailing ‘/’: warning
  • Windows Server 2008
    • Firefox 59.0.3: warning, with trailing ‘/’: warning
    • Google Chrome 70.3538.102: no warning, with trailing ‘/’: no warning
    • Internet Explorer 11.0.9600.19080: warning, with trailing ‘/’: warning

So somewhere between 59.0.3 and 62.0.2 Firefox also implemented a policy of silently accepting invalid certificates when certain non-obvious criteria is met (is the redirect actually followed and certs checked, or is “www.” just prefixed?), but this happens only when the URL ends on a slash. Go figure…

Comments Off on Silent browser redirect on invalid certificate
Setting free a Google Authenticator TOTP secret
Nov 7th, 2017 by miki

Below you’ll find an illustrated guide for freeing the authentication mechanism used by the Google Authenticator app for Android or iPhone for use on your favorite device (anywhere an implementation is available). In fact the Authenticator is using a standards based 2FA (two factor authentication) scheme defined by OATH (Initiative for Open Authentication) and published in RFC6238 dubbed TOTP – Time-Based One-Time Password Algorithm (more Authenticator background and it’s basis HOTP).

This is a rather fine contraption but Google doesn’t advertise it very loudly being a standard instead locking the generated TOTP secret into a QR code that they will only imply are for use by their own Google Authenticator. That is not true as a host of alternative Android OTP apps are compatible and can read the QR codes as they are based upon the Authenticator’s legacy as an open source application which Google took private.

Retrieve Google Account QR Code

Login to your Google Account (maybe using the authenticator?) and go to Account -> Security -> Signin -> 2-step verification.

Locate the “Authenticator app” section and Click “CHANGE PHONE” (really “CHANGE TOTP SECRET”).

Screenshot from 2017-11-06 22-32-05

In my country’s locale, Danish, this is BTW mistranslated as “SKIFT TELEFONNUMMER” = change phone number);

Screenshot from 2017-11-07 00-50-06

You’ll now get a choice between either iPhone or Android, this will only affect the link to the app store shown on next screen which also contains the QR code, the one we are really after:

Screenshot from 2017-11-06 23-03-44

Right click the QR code image, select to save it and put it somewhere you can find it (~/Google_TOTP_QR.png might be sensible).

Get your tools right

Install the QR-code decoder zbar for extracting the TOTP secet from the image and the OATH toolkit oathtool for generating future TOTP passwords using it. On Debian/Ubuntu this can be done by installing the packages zbar-tools and oathtool.

 

$ sudo apt install zbar-tools oathtool

 

Now extract the otpauth URI (seems to be a Google thing) by passing the image file to zbarimg;

 

$ zbarimg ~/Google_TOTP_QR.png
 QR-Code:otpauth://totp/Google%3Auser%40domain.com?secret=pca7uyfht7f6mfs7oiec4aeavxaevish&issuer=Google
 scanned 1 barcode symbols from 1 images in 0.02 seconds

 

The URI contains all parameters to input into the TOTP algorithm for generating a password usable for 2FA authentication, notably the secret key in base32 format. Defaults are not mentioned in the URI and are not necessary to specify explicitly for oathtool. So for the above URI specifying only a secret, a password can be generated as such;

$ oathtool --totp --base32 pca7uyfht7f6mfs7oiec4aeavxaevish
 491293

“491293” being the password, having a default validity of 30 seconds (called step size because of the counter based nature of the HOTP behind it).

If your are interested in the defaults assumed by oathtool they can be viewed by supplying -v to it (not showing TOTP mode=SHA512, I later added this feature in my oath-toolkit fork, and opened a MR) ;

$ oathtool --totp --base32 pca7uyfht7f6mfs7oiec4aeavxaevish -v
Hex secret: 7881fa60a79fcbe6165f72082e0080adc04aa247
Base32 secret: PCA7UYFHT7F6MFS7OIEC4AEAVXAEVISH
Digits: 6
Window size: 0
Step size (seconds): 30
Start time: 1970-01-01 00:00:00 UTC (0)
Current time: 2017-11-06 23:23:31 UTC (1510010611)
Counter: 0x30007F7 (50333687)

133339

 

Use & Behold

Enjoy having cut your reliance on the Google Autenticator, and opened up for your own choice of client:

Also see the dongleauth.info website for a list of other sites supporting TOTP and U2F.

Clean Up & Secure

Be sure to delete the QR code image when finished, and seek out a suitably secure place to store your TOTP secret. One solution could be using PGP encryption, maybe even through some clever management system such as pass.

Also educate yourself of the shortcomings of TOTP/HOTP and consider studying and using the FIDO U2F standard and related devices.

Comments Off on Setting free a Google Authenticator TOTP secret
Street View Googling Denmark again
Aug 19th, 2010 by miki

Just saw the Google Street View car driving by at my daily whereabouts in Esbjerg, Denmark. Did get a little exhilerated and spilled some coffee in excitement and attempt to wave at the cameras (Hi mom!!) . Here’s a shot of the car taken by itself when passing my home at it’s last visit in 2009.

Apparently Google Streetview has started collecting data again here i Denmark, as they did in Norway, Sweden, Ireland and South Africa in July. Now with the Wi-Fi privacy issue resolved.

The following netfrenzy brought me to the official schedule at http://www.google.dk/help/maps/streetview/where-is-street-view.html which shows some mid to large sized cities in Denmark beeing up for an update, including Esbjerg. Strangely I haven’t noticed any lack of imagery in my local area. I know that most of Denmark was beeing photographed during July and August 2009, so something must be missing, or of inferior quality since they are coming back.

I also found a fun Street View Partner site; Legoland in California has allowed Street View to take a tour through the park. Fun for me, because the Lego Group HQ and original Legoland Billund is close to Esbjerg, and I have been going there regularly wiht the kids. Going to be fun to take them for a virtual walk in the park in California ;). The Billund park doesn’t seem to have been mapped internally, though.

Also a hilarious joke on Google Streetview from an interesting group of people; The Free Art and Technology (F.A.T.) Lab. Will be digging these nutty people out for sure.

Comments Off on Street View Googling Denmark again
»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2023 Mikkel Kirkgaard Nielsen, contents CC BY-SA 4.0