Archive for the ‘information technology’ Category
I am in the process of relocating video embedded in entries to this 'blog. (Only a few and rather old entries have such content.)
My experiences with YouTube have been unhappy. It routinely messed-up the synchronization of sound with image for my content. Without a ready appeal process, YouTube disabled videos that made fair use of copyrighted content. Although my content has not been affected by the political bias of Alphabet Inc. (the parent company of YouTube), it was grossly unethical for YouTube to get people to cluster at their site by representing itself as an honest broker, and then to bring a bias to bear. And, when YouTube disabled a video for one reason or for another, the embedding code responded inappropriately.
For now, I am moving most or all of my video content to BitChute; I don't know that my content will remain there. But any host that does not apply an ideologic filter will attract a disproportionate share of content from those penalized by the biases of YouTube; the main-stream of the media (who share the ideologic bias of YouTube) will seize upon this disproportion to claim or to insinuate that the host and those who use it are sympathetic with the more repellent of those filtered-out by YouTube. The sophistry will be evident to all but the rather stupid, but a much larger share of people will rôle-play as if the argument were sound.
DreamHost, the hosting service that I use, recently broke this 'blog in at least two ways.
First, they deleted one or more files from my installation of Wordfence, which deletion crippled security. Second, they corrupted the database that underlies the 'blog, causing an old entry on usernames to be very imperfectly duplicated, with a date-stamp of 30 June 2019.
I noticed the problems in the wake of an up-dating of the operating system used by DreamHost; I infer that something went wrong in that process.
I contacted DreamHost and then stewed for some days, leaving things as they were to allow the support staff to set things right. They repaired the installation of Wordfence, offering an implausible conjecture about what had gone wrong. They did not repair the database appropriately.
This 'blog has been bit hard by a bug in a plugin.
WP-Sweep includes an ostensible ability to purge categories and tags that are not used for any entries. Unfortunately, the programmer made an error such that the categories and tags purged are any not used in generally accessible entries; tags and categories used exclusively in restricted entries are therefore purged.
Still more unfortunately, I did not discover the bug until after I had made various content changes; simply restoring a previous version of the database would undo those changes. I don't remember what they were, and my only records are the database and saved versions thereöf.
I will, over time, try to repair the damage.
Readers may have noticed some technical problems with this 'blog over the previous few days. I believe that the problems are resolved.
Recently, browsers have become concerned to warn users when they are dealing with sites that do not support encryption. Simply so as not to worry my visitors, I have tried to support the
But I found that WordPress was still delivering some things with the less secure
HTTP protocol, which in turn was provoking the Opera browser to issue warnings. At the WordPress site, I learned that I needed to modify two fields.
Unfortunately, changing these two fields broke my theme — my presentation software — so that fall-back text, rather than the title graphic, was sometimes displayed; but I didn't discover the breakage for a while, because the symptom wasn't always present. Ultimately, I realized that something were amiss. I tracked the problem to inconsistencies in how WordPress determines the protocol of the URI of the 'blog versus that of the directory holding the themes.
I recoded my theme to handle this inconsistency. (In the process of this recoding, my 'blog was made still more dysfunctional over several brief intervals.) My code is now sufficiently robust that it should not break if WordPress is made consistent in these determinations.
This evening, I was looking at a record of recent failed attempts to log into this 'blog. I found that relatively few attempts tried to do so with the popular username of
, whereäs by far the majority were with the username
(that it to say with the second-level domain name). There is not and never has been an account here with username
; the would-be intruder was guessing mistakenly — but not unreasonably. If my logs are representative, then having an account name match a second-level domain name is less secure than having it be
. With people avoiding
, it is natural for crackers to try other likely candidates, including candidates whose probabilities are conditional upon the domain names.
Mind you that the reasoning of my earlier explanation of why the avoidance of
doesn't add a discernible amount of security if passcodes are properly selected can be applied to avoiding a username that matches a domain name. An account with a known username and a well-chosen password of m+n characters is more secure than an account with a secret m-character username and an n-character password.
Choose a username that pleases you. Choose a password that is long and that looks like chaos, and make occasional changes to it.
Dictionaries and thesauri often treat
precision as synonymous, or as nearly so. But the words
precision and their coördinates are each most strongly associated with a distinct and important notion. The word
exactitude (often treated as synonymous with the previous two) and coördinates are most strongly associated with something rather like the combined sense of those other two, but with a notable difference.
When we say that a specification is
precise, we do not necessarily mean that it were correct when judged against the underlying objectives. We may merely mean that it were given with considerable explicit or implicit detail. If I tell you that a musical show will begin at
8:15:03 PM, then I am being precise (indeed, surprisingly so). But the show may begin at some other time; in fact, it may never have been planned to begin at that stated time; I can be both precise and wrong.
If your friend tells you that the show will begin
shortly after 9 PM, then she may be accurate, though she was far less precise than I. The word
accuracy and coördinates are associated with closeness to the truth; and, in everyday discourse, she might be said to be
more accurate were she to be more precise while remaining within the range implied by
shortly after 9 PM. But the word is also associated with encompassing the truth; if the precision seemed to narrow the range of possibilities in a way that excluded what proved to be the truth, then she might be regarded a having become
less accurate. (If one is told that the show is to begin at
9:15 PM, but it begins at 9:05 PM, then one might feel more misled than had one been less precisely told
shortly after 9 PM.)
(Note that it would be seen as self-contradiction to say that someone were
accurately wrong, though we sometimes encounter the phrase
precisely wrong. The latter carries with it the sense — usually hyperbolic — that the someone had managed to be so wrong that even the slightest deviation from what he or she had said or done would be an improvement.)
Although some people might jocularly, eristically, or sophistically pretend that one truth were somehow truer than another, any meaningful proposition is either simply true or simply false (though which may be unknown and there are degrees of plausibility). If Tom and Dick each go to the store, then it is true that one of them has gone to the store. It is not closer to the truth that two of them have gone to the store. It might be said that it were more
accurate that two of them have gone to the store, but this seems to imply that it is truer that two went than that one went, and this implication is false. Fortunately, we have a word and coördinates that can carry with them a particular sense of accuracy and precision, with exclusion. These words are
exactitude. It is true that one person has gone to the store, but it is not true that exactly one person has gone to the store.
exactly wrong is usually in hyperbolic contrast with
exactly right, but is sometimes applied elliptically, when there is believed to be exactly one way in which to have been wrong.)
Even if one is not greatly concerned with rigor, these distinctions can be important. Asking members of an audience to be more
accurate when one wants them to be more precise may inadvertently suggest to the audience that one thinks them to have been untruthful! Typically, risking that inference brings no benefit. It would then be better to ask them to be more
precise or more
exact. The latter may work best with the passive-aggressive or with the autistic, who might otherwise be more precise while less accurate.
 The coördinates of a word are simply the other parts of speech built of the same root and carrying the same general sense adapted to a different grammatical rôle. For example, the adjective
accurate and the adverb
are coördinate with the abstract noun
 In discussions of computer science, the everyday distinction between
precision is made more emphatic, because the mathematics of computing is discrete, and limitations in detail have important implications. For example, ordinary
floating-point encoding imperfectly represents numbers such as 1/10. That's why calculators and computers so often seem to add or to subtract tiny fractions to or from the ends of numbers. Number-crunching scientist who do not themselves recognize this issue have generated spurious results by proceeding as if computers have unlimited precision, and thus by mistaking artefacts of limited precision for something meaningful within the data. I strongly suspect that a major reason that so many reported econometric results were not subsequently found by other researchers poring over the very same data was that the original researchers (or, sometimes, the later researchers!) were not taking into account the implications of limited precision.
 The words
only can carry the same meaning, but often bring normative implications.
 In mathematics,
∃x translates to
for some x, while
∃!x translates to
for exactly one x.
 Asking a person to be more
just or more
only would almost surely provoke bafflement.
Just as in a natural language there are issues of style on top of those of grammar, of orthography, and of syntax, there are issues of style in computer languages.
For example, in some languages,
var = 3
var to 3, while
var == 3
var is (already) equal to 3. Omit an
in a test, and the test accidentally becomes an assignment; many programs silently fail as a result of such an omission. But adopt the style of always putting any constant on the left side of the test (eg,
) and the error (eg,
3 == var
, which attempts to set 3 to something) is noticed as soon as the compiler or interpetter reaches it. (There are compilers, interpretters, and separate utilities that will spot possible instances of errors of this sort. It's good to use tools with these features, but best not to be dependent upon them; and one doesn't want the notice of a genuine error to be lost in a sea of largely spurious warnings.)
3 = var
The specifications of some computer languages, especially of those that are older, significantly limit the lengths of names and of labels; but it's otherwise stylistically best to chose names and labels that clearly identify the nature of whatever is named or labelled. Transparent names and labels then function as integrated documentation. One identifies a lazy or thoughtless programmer by the needless use of opaque names and labels. In Java, the stylistic convention is to name things in ways that clearly identify them; and the convention is to camel-case the names of variables, methods, and classes (eg,
); other languages also allow names to be clearly identifying, but the convention is to separate naming words with underscores (eg,
). One uses the naming convention that prevails amongst programmers of that language, so as not to throw-off other programmers who have to deal with the code; it is literally uncivil to use the convention prevailing amongst programmers of one language when writing code in a language where a different convention prevails. (Had it been up to me, then we'd use a different naming style in Java; but it wasn't up to me and I abide by the prevailing convention.)
Many languages end statements with
. When I helped other students debug SAS programs, I found that the error that they most often made was to omit that semicolon. Sometimes the program wouldn't compile, but sometimes it would compile and silently do something unintended. So I told them to put a space just before the semicolon. The program would still compile just fine if otherwise properly done; but, with all the semicolons visually floating instead of being up against something else, an omission would more easily be spotted. I don't myself use this style for every language in which it would work, but I adopt it for languages in which I notice myself or others omitting the semicolon.
(I was reminded of the general issue of coding style when working on some code written in Python, and wondering whether to put a space before each semicolon.)
 Civility is not conterminous with pleasantry; but, rather, a matter of behaving to avoid and to resolve conflict in interaction with other persons.
To-day, I found myself unable to log-in to this 'blog. I got a diagnostic that I were entering the wrong password. I don't want to burden my readers with a detailed retelling, but what had actually happened was that an up-date of WordPress rejected my password — it wasn't that I were entering the wrong password; it was that the password that I was entering was now prohibitted.
On top of the login code misreporting the problem, the code for resetting the password wouldn't tell me why my password was being rejected. But it was rejected for containing a particular sub-string; and when I removed that sub-string, the password was then accepted.
If you understand passcodes (perhaps in part from reading my previous entry in which they were discussed), then you should see that there is something literally stupid in the WordPress software. Let's say that the forbidden sub-string were
and that my password were
. If I drop the
, the password becomes
. That is now accepted, though it is less secure!
If a would-be intruder knew where in the original password
appeared, and knew the length of the password, then the password would effectively be p1p2…p14
8675309p22p23 where each
pi were an unknown character, and the new password would be p1p2…p14p22p23 so that the two passwords would be equally secure!. (Either way, an intruder must find a sequence of sixteen unknown characters.) But, as it is, would-be intruders wouldn't be sure that the sub-string appeared, let alone where in the code it would appear, nor how long the password were. One could, in fact, conceptualize the sub-string
as if it were a single character of extraordinary length (a macro-character) and of great popularity which character might appear within a string of equal or greater length, in which case prohibiting the sub-string would be rather like prohibiting the use of
That's not to say that common sub-strings should simply be accepted as passwords or within passwords. A great many systems have been hacked because someone foolishly used passwords such as
. But, instead of rejecting a password because it contained a popular sub-string, the software could, for example, test to see whether the password would be secure if the sub-string were excised, in which case it should be at least slightly more secure if the sub-string were retained.
(Note that this approach works with popular sub-strings of any length, including those of just one character! In fact, when there is no upper-limit on the length of passcodes, they may be securely constructed of nothing but popular sub-strings each of which has multiple characters; a secure password could be made by concatenating ten or more of the one hundred most popular passcodes. Mathematically, the problem of using just one popular passcode is fundamentally the same as that of using a short passcode!)
Sometimes, it's smart programming to write stupid programs, because the costs of designing, implementing, and maintaining more sophisticated software out-weigh the benefits. But, here, the WordPress programmers have opted for cheapness in a way that needlessly thwarts and insults some users, and can actually make systems less secure in those cases. (And the poor diagnostics are simply inexcusable.)
Those managing 'blogs are frequently told that the administrative account should not have a username of
admin nor of
administrator. Indeed, 'bots attacking this 'blog try the username
admin multiple times every day. None-the-less, I think that concern about easily guessed usernames is quite misplaced.
Ordinary access to an account requires two pieces of identification, the username and a passcode. We can conceptualize these jointly as a single string, the first part of which is practically fixed, the second part of which is changeable. For example, if one had the username
admin and the passcode
h3Ll0p0p3y3, then the string would be
adminh3Ll0p0p3y3 Some might imagine that two strings represent two hoops and therefore more security; but, actually, each character is a hoop. If usernames and passcodes were equally secure, then the username-passcode pairs
kelsey5 dO0DL3bug and
kelsey 5dO0DL3bug would be perfectly equivalent as far as security were concerned. So we can imagine the two strings concatenated, so long as we remember that one set of its characters are unchangeable, while the others may be changed. In general, the form of the string can be conceptualized as u1u2…ump1p2…pn where each
ui represents an unchangeable username character and each
pj represents a changeable passcode character. Now, if we simply know that the administrative account username is
adminp1p2…pn unauthorized access is a matter of guessing the characters of the passcode, without knowing how many they might be. (How passcodes are stored may limit or effectively limit the length of passcodes, but this will typically not have much effect unless those limits are very tight.) On the other hand, if the administrative username is completely unknown, then the string is the apparently more mysterious u1u2…ump1p2…pn That might seem significantly more secure. However, the number of characters in the passcode is unknown to the opponent, and u1u2…um-kp1p2…pn+k is more secure for all 0 < k ≤ m, because usernames are unchangeable. (Were usernames as changeable as are passcode, then the two would be equally secure.) And
adminp1p2…pn+m is more secure than u1u2…ump1p2…pn
So real security here is to be found in long and strong passcodes, for which secret usernames are poor substitutes, and one can easily compensate for a readily guessed username by having a stronger passcode.
[0 (2016:03/30, 04/09)] I've fleshed-out this entry a bit, in an attempt to make in more easily understood.
 See, for example, the entry for 23 March at the Wordfence 'blog.
 The case k = m represents a zero-length username, which really is to say no username at all. It would be quite possible to create a system with just passcodes and no distinct usernames — or, equivalently, a system with very changeable usernames and no passcodes — though this would present some practical difficulties.