20 December, 2018

Chrome: More From the "My Way or the Highway" Department

Google, in their infinite "wisdom," decided a few months ago that when you sign into Google, you also sign into Chrome.  I in particular do not really want my Google credentials being cached in a whole lot of software, and in particular, not within Chrome (or Chromium for that matter).  When Chrom(e|ium) exits, I don't want either to stay logged in.

A number of security- and privacy-focused folks pointed this out, the fact that they didn't take too kindly to logging into the Google services meant logging into their browser.  So Google said, OK, folks, don't worry, if you really, really want to separate these two functions out, all you have to is go into your flags and disable identity consistency.  That way, if you want to sign out of Gmail (or other services), you can, and still have your Chrome signed in and syncing settings, extensions, or whatever else you've configured to sync.  Or conversely, you can be signed out of Chrome, but still be able to log in and pick up your Gmail.

Now you know, this is the company which by default has a "remember me" style checkbox on their credentials dialog, which defaults to "on."  Similarly, if you've enabled RFC6238 TOTP multifactor authentication, there is a by-default-checked option so that you don't have to enter a TOTP for 30 days.  After all, they're trying to make using Google and its services as convenient and frictionless as possible...why authenticate when you can be remembered?  But of course, I can't tell you for sure, but the odds are pretty good the reason Google wants you to stay signed in is so that you can be tracked by them and other sites.  After all, that's extremely valuable data; they've made an entire very successful business of collecting, curating, and somewhat interpreting that data.

But here's the thing...in a subsequent Chrome release, that flag has no effect.  No, instead of being hidden away in some internal browser configuration page, it has "graduated" to the normal settings UI page, as "Allow Chrome sign-in".  Great,then!  Fixed, right?  Well...no, not really.

The "identity consistency flag" allowed nearly complete separation of in browser and Chrome "logged in status".  You didn't have to go into chrome://flags and toggle it on or off in order to log in or log out of Chrome; you could log into Gmail and not log into Chrome, or vice-versa.  If you did adjust that flag, you'd have to restart Chrome for it to take effect.  But no, this new toggle simply allows logging into Chrome, or disables the ability to log into Chrome and all its syncing goodness.  This is at first subtle, but really is profound in the implications of its implementation.  No longer can I just log into Chrome without logging into Gmail, if I log into one, I am logged into the other.  Sure, if I don't want to be logged into Chrome, I can go back into the settings ( == friction) and pull the slide switch the other way.  But then when I do want to log in, to get a sync going, I have to go into settings and slide the switch again.

And again...I understand the dual implication: they want me logged in/identified as much as humanly and inhumanly possible for their business, and basically their cover story is that they want it to be convenient and as frictionless as possible for the end user.  But to the security and privacy minded, conscientious end user, it is less convenient and more friction.

So...it's Sundar's way or the highway.  Sure...I suppose you could download the Chromium source, slice out these nasty bits, and build it yourself, but who wants that badly to take on that maintenance responsibility?

Idunno...I'm actually tempted to do this, because I'm sick and tired of all the goddamn stoopid animations...like you can't even open the main menu without a stoopid bloom of the 3 dots, and you can't visit a subsection without the page being slid all around, either horizontally or vertically.  This is DESPITE many requests to remove UI animations, usually from folks accessing computers with Chrome on them remotely (and the slow update times that entails sometimes).


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!

19 December, 2018

Everything Old is New Again Department, Part 2 for Today

My, it certainly is true that there are no new novels, no new movies, no new TV programs.  It's the same thing retold in different ways, which I guess is what keeps us watching and listening, trying to figure out what that "new" way is.

One of my favorite movies is "Sneakers." I have listened to the soundtrack CD many, many times.  One of my favorites from that is "Cosmo… Old Friend," particularly in the one part with a strings crescendo I think in a major key, followed by a decrescendo in a minor key, followed by a piano (meaning soft) replaying of the major key, and this 3 (or 4) measure figure is repeated.  All that is with a really great bass behind it (not sure what instrument; maybe a bunch of double basses arco).  I was kind of wondering what scene in the movie was this put behind.  And I found a "Movieclips" YouTube video of at least part of the scene.  That part I'm talking about is where Marty/Robert Redford says, "...small countries?" at about 1:40.

Then Cosmo/Ben Kingsley nods smilingly and says, "I might even be able to crash the whole damn system...destroy all records of ownership.  Think of it, Marty: no more rich people, no more poor people, everybody's the same.  Isn't that what we said we always wanted?"

Upon seeing that again, I thought, gee...isn't that one of the story arcs in "Mr. Robot," fsociety taking down E Corp?  The aim of fsociety was to compromise totally all the world's financial systems, so everything is "level" again.


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!

From the Everything Old is New Again Department

A local talk show host, WBEN-AM's Tom Bauerle, had a good point: we are going back to the time of the ancient Egyptians, who used hieroglyphs to communicate.  The modern day equivalent is emoji!  In fact, Matt Gray and Tom Scott launched (and not too long afterward took down) a Web site dedicated to communicating with no text, only emoji.  (OK, that was gratuitous use of linking using Blogspot to link to 3 different YouTube videos.)



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!

09 December, 2018

Don't Trust Your Disk Enclosures to Assess Disk Health

For the second time, I have removed a disk from its purchased enclosure (the first was IEEE1394/FireWire, yesterday's was USB 2).  The result both times is that the disk was exhibiting wonky behavior in the enclosure, either outright throwing errors or hearing the read/write heads being repositioned a lot of times (you experienced computing folks know exactly what I heard), and after being extracted, work just fine on its own.  The lamentable part is both of them were intended as backup disks, and the next-to-last thing you want to go wonky is your backups (with your first thing you don't want to go wonky is the computer itself).  A case-in-point follows.

Almost ever since I got my 2 TB Seagate FreeAgent, it would have that tell-tale "I'm having trouble reading the platters" thonking of the heads.  However, Seagate will not take warranty claims unless their utility (ugh...Windows only, .NET 4 requiring) tests it and the utility pronounces it defective (or put another way, it sounded like if you tried sending it in for a warranty claim without their utility finding it defective, you'd be economically responsible, not Seagate).  At the time, I should have taken that as a hint that lots of folks found these disks dodgy, probably with the same almost unmistakable "help! I'm having read problems!" head thrashing, and had their warranty claims shot down.  After all, why would Seagate even have to caution people about that on their site?  But I digress.  Recently I pressed it into service as the storage for MythTV recordings attached to a Raspberry Pi.  Finally, this past week I had had enough of sitting there during recordings, and at times during viewings, of hearing the thwacka...thwacka...thwacka of repositionings/retries.  I bought a 2 TB Toshiba USB disk (essentially it's a laptop drive with a case and a USB to SATA converter).  While copying the MythTV videos from one disk to the other, there were plenty of times I heard that head banging.  I then put the Toshiba drive in Myth service, with seemingly the only detriment being that if you plug it into the running Pi, it makes the voltage dip below threshold (making the red LED go dark for half a second or so) during the time the disk motor spins up.  (After all, the Pi is only USB 2, the Toshiba is a USB 3.x unit, therefore has those higher allowable current draws.)  I then proceeded to tear apart the Seagate case.

After putting the Seagate drive on a Sabrent USB 3 disk converter (turns out it's a Barracuda LP at heart), I did the same rsync copy where I heard the clackity-clacks before, but this time, there was no such noise.  Soooo.....did it remap sectors and now it was getting a clean read?  Was it overheating in the enclosure?  Was the Seagate USB converter board wonky?  Was the power supply unstable?  Without some professional diagnostic tools, and maybe a clean room, it will be VERY difficult to tell for sure, but I'm guessing it's unstable power to the drive, like the 160 GB LaCie FireWire drive that preceeded it.

That's OK...the FreeAgent power suppy is being used for a different purpose, on some audio gear, where it doesn't seem to make a difference.  Whatever glitches it might have had do not seem to be audible.  My money's on the traces on the USB to SATA converter board just weren't up to scratch, and didn't provide enough stable current for the disk.



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!

14 November, 2018

Recent systemd Update May Make Your Service Units Not Start Properly


I had set up a MythTV on a Raspberry Pi using the mythtv-light repository.  I even used a lot of the suggestions from the MythTV wiki advising how to formulate a systemd service unit file.  It seemed to be working fine, I was watching programs, pulling content from a SiliconDust HDHomeRun Quatro and dutifully recording streams from it to a USB HDD.  Then TV enjoyment disaster struck.

Today I decided to set up another Pi to do the commercial flagging and any transcoding (although currently not doing it, although I may start due to things like Roku not supporting the native format, which may be either its own Nupple format or MPEG-TS, not sure).  The plan is also to include MariaDB replication to the new Pi so that the database is fault tolerant too.  I'd like to a make note here that I do like to do my own OS updates rather than have them done automatically; that way it's far simpler to relate something that starts breaking to a recently performed update rather than having to go back into some log files and figure out what changed.  This would be for Raspbian Stretch (FYI, Raspian releases follow Debian releases, and Stretch is the current stable release as of writing this.)  And once again this policy decision proved quite useful.  I remember that there was a systemd update very recently, probably between the last start of my mythbackend and now.  Having a User= directive in my unit file worked just fine, up until today when I restarted MariaDB, then the Myth backend (don't know if it tolerates the DB being restarted too well).

Suddenly mythfrontend was complaining that it could not connect to the backend.  huh....That's odd.  Does systemctl show that it's running?  Indeed, it's running, and it's not exiting and respawning, because its PID is not changing (the unit file specifies it is to be restarted after 3 seconds if it exits for any reason other than systemd telling it to do so).  But was there a listening socket?  Darn, netstat -tln told me that no, there was not.  There was nothing much to go on in the log file or systemcl status output, just something about not having data in a files cache in order to process expirations.  A weird thing was that the HDD activity LED indicated frequent disk access, yet there was very little/no activity indicated on the network switch LED for the HDHomeRun.  I had no idea what else it would be trying to do with the disk other than recording a program.

I thought, OK, slow way, way down, this is just too freaky.  Even stopping the backend was taking a really long time.  I got impatient and just used killall to try to stop it directly.  That seemed to "help."  So I wanted to see if something would be written to stdout if I ran the backend manually, from an XTerm command line.  And of course, while doing that, I would not use the loglevel clause.  But an odd thing happened: it ran normally.  OK, might this have been a temporary anomaly?  I tried once again to start via systemctl , and no, it was consistent.  Listening sockets were never being opened.  watch netstat -tln confirmed that.  Starting via the command line (which worked) and watching for the sockets to open showed it was only a few seconds.

I must say, I have had a lot of experience in things running differently depending on whether they have been started from an interactive login versus by the system (from init).  It's all in the execution environment.  Unix/POSIX/Linux has so many process properties, but more often than not it's environment variables (LD_LIBRARY_PATH and PATH are two of the most common which are different between system and interactive invocation and therefore cause things to fail).  So the next thing to try was removing User=mythtv (with "#") and adding /bin/su - mythtv -c to the command specifying how to start this unit.  Bingo, there you go; it started, stayed running, and even more importantly opened the socket listeners.  So hmmmm....what else does the system do for interactive logins?  Why, not only does it set HOME (which was already being done in the unit file) but it also sets your current working directory (cwd) to that value!  So hmmm....does a unit file have any directive like that?  Yes, yes it does, WorkingDirectory=.  So I set that to /home/mythtv, and it worked!  For some really oddball reason, mythbackend will not open its sockets/operate normally unless the cwd is set like that.  I have to wonder what systemd will choose for a service's cwd if you don't specify it, maybe the root.  Moreover, I don't know if User= previously changed the cwd to that listed for the user (usually in /etc/passwd) or not.

Hopefully this story will help someone whose service daemons have stopped working.

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!

Google+ Shuts Down, so This Will Have To Do for "Microblogging"

grrr...Oh, well, I'm glad for how long it lasted, but as of next year sometime, G+ will be going away.  So therefore, I see no reason to continue posting there, even though it is very much more convenient than posting here.  That's OK.  I didn't post particularly frequently over there anyway.



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!