01 April, 2024

More to be Peeved at Alphabet (but What Else is New?)

Alphabet, a.k.a. Google, a.k.a. YouTube, to me have a thin veneer of caring about security.  I think I understand their motivations for no longer allowing one to log in only for a browser session, they want to have you authenticated (identified) for all the processing they do on their backend, ostensibly wherever you visit the WWW.  But it's a dimunition of security.  If I close (exit) any of my browsers, I expect to be logged out. One used to be able to check/uncheck a box on the login page to have to log back in again. Except that for a couple of years now, all the cookies behind the scenes that make that tolerable (i.e., not having to authenticate for each and every page visited) are now persistent instead of temporary.  Although I have devised methods of detecting which ones these are, such as "diffing" dumps of browsers' SQLite databases, I have not yet bothered to write anything (Tampermonkey code, browser extensions) to make them nonpersistent again.  Nor have I found any cookie extensions that will do what I want, at least not automatically (basically, change the expiration date/time on them).

Today, I went to log in, and I thought I would make sure my "backup" Yubikey (YK) works.  Hmmm....Chrome says that key does not look familiar.  Wow.  Uhhh....OK.  After logging in with my "primary" key, I looked at the list of 4 keys associated with the account.  Huh, that's odd, the one I labelled "work-1" says it's never been used.  That's kind of weird for two reasons: I suspect I've used it at least once, and how is it that it's not recognized at login time?  I very well could have reset the YK after some experimentation gone wrong, which would have invalidated anyplace it had been registered.  No matter, I deleted it (as I do not know which YK that is, the one I have in my hand is the only one I would think to label it that way).  Great...let's (re?)enroll this key.

...Except apparently with Alphabet, you can't simply enroll a Yubikey anymore.  You have to enroll a "passkey."  I don't want to enroll a passkey.  I just want to insert my key in a USB port and touch it.  If I enroll it as a passkey, I have to enter a PIN.  I don't want to enter a PIN.  I just want to touch the darned key!  Alphabet, considering you have such weak stuff as SMS as second factor, why are you insisting I set up a passkey rather than just accepting a touch on a YK?

I will say, Alphabet are not totally uncaring about users' opinions about their products.  I'm not sure; on this blog I may have previously mentioned my utter disdain and loathing of animations.  Thankfully, the Android developer options have three settings which allow one to disable animations.  But unfortunately, this is not implemented in a way that enforces this for all applications; they must choose to observe these settings.  A case in point is the Google Play app.  A couple of years ago, its whimsical developers thought it was a good idea to have dots whiz around an app's icon while it is queued for update.  It struck me as the sort of thing that might trigger epileptic seizures in individuals who are sensitive to flashing lights.  Actually, I complained about it.  In prose, I told them exactly how to reproduce the "issue"--what things to tap in what order.  They asked for (a) screenshot(s).  I was dumbfounded.  As this was an animation, WTF would a screenshot tell you?  If anything, it would have to be video.  (And BTW, if they wanted video, they should have asked for video.)  For the time, I dropped it, figuring there was little I could do to communicate this properly.  But....lo and behold, many moons later, I was updating apps, and there were no disgusting "I am queued for update" animations.  I guess I'll take small victories where I can get them.


English is a difficult enough language to interpret correctly when its rules are followed, let alone when the speaker or writer chooses not to follow those rules.

"Jeopardy!" replies and randomcaps really suck!