Archive for the ‘information technology’ Category

Preserve the Proxies!

Monday, 22 June 2015

Under the original ethos of the 'Net, those who registered domain names were required to make publicly available their contact information.

A technical loop-hole was found. One party could register a domain name, and that party could provide its own contact information; yet the party could allow (and perhaps even be contractually required to allow) some other party to use the domain name for its own ends. So the technical registrant was a proxy agent for the practical holder. This loop-hole was challenged, but ultimately allowed to remain.

Now pressure is being brought upon ICANN to prohibit proxies for what are deemed commercial sites. The primary motivation appears to be to help firms identify and pursue those who infringe upon trademarks and other intellectual property. (At present, they would have to get a court order requiring the proxy service to release the identity of the practical holder.)

I think that this effort should be strongly resisted. At the time that the use of proxies began, I had mixed feelings about it. But use of the Internet and of the World-Wide Web has evolved, and evolved within the context of this proxied registration being an accepted practice. A rule-change now would impose new costs — sometimes quite significant — on many people, the vast majority of whom are quite innocent of any trespass on intellectual property. Further, I note that most of those who are deliberate in their infringements are unlikely to have qualms about using using proxies that simply claim to be practical holders.

You may want to read ICANN's discussion of the matter

Comments may be sent to comments-ppsai-initial-05may15@icann.org before 7 July.

A Question of Characters

Sunday, 31 May 2015

At various times, I'm confronted with confusion by persons and by systems of characters with glyphs. Most of the time, that confusion is a very minor annoyance; sometimes, as when wrestling with the preparation of a technical document, it can cause many hours of difficulty.

It's probably rather easier for people first to see that a character may have multiple glyphs. For example, here are two distinct yet common glyphs for the lower-case letter a: and here are two for g:

People have a bit more trouble with the idea that a single glyph can correspond to more than one character. Perhaps most educated folk generally understand that a Greek Ρ is not our P, even though one could easily imagine an identical glyph being used in some fonts. But many people think that they're looking at a o with an umlaut in each of these two words: whereäs the two dots over the o in the first word are a diæresis, an ancient diacritical mark used in various languages to clarify whether and how a vowel is pronounced.[1] The two dots over the o in the German shön are indeed an umlaut, which evolved far more recently from a superscript e.[2] (One may alternately write the same word schoen, whereäs schon is a different word.)

Out of context, what one sees is a glyph. Generally, we need context to tell use whether we're looking at Ϲ (upper-case lunate sigma), our familiar C, or С (upper-case Cyrillic ess); likewise for many other characters and their similar or identical glyphs. Until comparatively recently, we usually had sufficient context, mistakes were relatively infrequent and usually unimportant. (Okay, so a bunch of people thought that the Soviet Union called itself the CCCP, rather than the СССР. Meh.) But, with the development of electronic information technology, and with globalization, the distinction becomes more pressing. Most of us have seen the problems of OCR; these are essentially problems of inferring characters from glyphs. It's not so messy when converting instead from plain-text or from something such as ODF, but when character substitutions were made based upon similarity or identity of glyph, the very same problems can then arise. For example, as I said, one sees glyphs, but what is heard when the text is rendered audible will be phonetic values associated with the characters used. And sometimes the system will process a less-than sign as a left angle bracket, because everyone else is using it as such. In an abstract sense, these are of course problems of transliteration, and of its effects upon translation.

Some of you will recognize the contrast between character and glyph as a special case of the contrast between content and presentation — between what one seeks to deliver and the manner of delivery. Some will also note that the boundary between the two shifts. For example, the difference between upper-case and lower-case letters originated as nothing more than a difference in glyphs. Indeed, our R was once no more than a different way of writing the Greek Ρ; our A simply was the Greek Α, and it can remain hard to distinguish them! I don't know that ſ (long ess) should be regarded as a different character from s, rather than just as an archaïc glyph thereof.

Still, the fact that what is sometimes mere presentation may at other times be content doesn't mean that we should forgo the gains to be had in being mindful of the distinction and in creating structures that often help us to avoid being shackled to the accidental.


[1] In English and most other languages, a diæresis over the second of two vowels indicates that the vowel is pronounced separately, rather than forming a diphthong. (So here /koˈapəˌret/ rather than /ˈkupəˌret/ or /ˈkʊpəˌret/.) Over a vowel standing alone, as in Brontë, the diæresis signals that the vowel is not silent. (In English and some other languages, a grave accent may be used to the very same effect.) Portuguese cleverly uses a diæresis over the first of two vowels to signal that diphthong is formed where it might not be expected.

[2] Germans used to use a dreadful script — Kurrentschrift — in which such an evolution is less surprising.

Not Following the Script

Monday, 13 April 2015

I frequently run across the problem of websites whose coders silently presume that all their visitors of interest have Javascript enabled on their browsers. Yester-day, I found this presumption affecting a page of someone whom I know (at least in passing), which prompts me to write this entry. (The person in question did not generate the code, but could suffer economic damage from its flaw.)

The reason that one should not presume that Javascript is enabled on the browsers of all visitors is that Javascript is itself a recurring source of security problems. Careful users therefore enable Javascript only for sites that they trust; very careful users enable Javascript only for sites that they trust and even then only on an as-needed basis; and paranoid users just won't enable Javascript ever. Now, in theory, the only visitors who might interest some site designers would be careless users, but we should look askance at those designers and at their sites.

(And trusting a site shouldn't be merely a matter of trusting the competence and good will of the owner of the domain. Unless that owner is also owner of the server that hosts the domain, one is also trusting the party from whom the site owner leases hosting. In the past, some of my sites have been cracked by way of vulnerabilities of my host.)

A designer cannot infer that, if-and-when his or her site doesn't work because Javascript is not enabled, the visitor will reälize that Javascript needs to be enabled; many problems can produce the same symptoms. Most of the time that sites don't work with Javascript disabled, they still don't work with it enabled. Further, the party disabling Javascript on a browser might be different from the present user; the present user might have only vague ideas about how web pages work. (An IT technician might disable Javascript for most browsers of users at some corporate site. Some of those users, perhaps very proficient in some areas but not with IT, may be tasked with finding products for the corporation.)

The working assumption should typically be that Javascript is not enabled, as this assumption will not be actively hurtful when Javascript is enabled, whereäs the opposite assumption will be actively hurtful when Javascript is not enabled.

The noscript element of HTML contains elements or content to be used exactly and only if scripting has been disabled. That makes it well suited to for announcements that a page will work better if Javascript is enabled

<noscript><p class="alert">This page will provide greater functionality if Javascript is enabled!</p></noscript>
or not at all if it is not enabled.
<noscript><p class="alert">This page requires Javascript!</p></noscript>
(It is possible to put the noscript element to other uses.) So a presumption that Javascript is enabled certainly need not be silent.

However, in many cases, the effect got with Javascript isn't worth badgering the visitor to enable Javascript, and the page could be coded (with or without use of the noscript element) so that it still worked well without Javascript. In other cases, the same effects or very nearly the same effects could be got without any use of Javascript; a great deal that is done with Javascript could instead be done with CSS.

Non-Violent Neutrality

Tuesday, 14 January 2014

I don't know that 'Net-neutrality were, in fact, a good thing; but, even on the assumption that it were, state action is not the proper way to promote it.

'Net-neutrality can be promoted by how people do business with ISPs. At one end, subscribers can consistently migrate towards those ISPs who deviate least from neutrality. At the other end, website owners can impede access by ISPs that do not practice an acceptable degree of neutrality.

In fact, Google and Facebook could effectively impose neutrality by announcing that, in one year, they would begin blocking access by providers who did not make pledges, renewed annually but each extending for ten years, to practice 'Net-neutrality. It might, however, require state inaction for these heavy-hitters to make such a demand. Specifically, Congress might need to clear a path in anti-trust law to allow such a policy.

Google Play Store Warning

Monday, 5 August 2013

Before installing an app from the Google Play Store, if you do not otherwise have familiarity with the app's developer, look at the time-stamp listed for the latest version. If this version is only a day-or-so old, then look at the time-stamps for the app reviews. If all of these are only from the previous day-or-so, then wait a couple of days before installing the app.

I discovered that scam-ware is being posted to the Play Store, sometimes with thousands of shill down-loads and shill reviews, to give to it the appearance of legitimacy. Google acts to remove this scam-ware, but it takes them some time to catch up to it.


The Play Store review system is unfortunately very easily manipulated, and some developers are doing just that even for apps that are not themselves intended as scam-ware. Hundreds or thousands of shill reviews are posted over time. (These reviews are typically short, and sometimes absurd, as when a utility is said to be a great game.) Negative reviews are marked as Unhelpful by shills, and positive previews perhaps as Helpful; which, since the Play Store normally presents reviews ordered by Helpful-ness, means that negative reviews slide out of sight.

Self-Locating QR Code

Friday, 14 June 2013
QR Code pointing to http://www.oeconomist.com/images/Miscellany/self_locating_qr_code.png

Missing Links

Monday, 11 February 2013

Assuming that you do much surfing of the WWWeb, you've surely noticed that there are a great many sites that now require one to use an account with an external social-networking service in order to access functionality that previously would have been available without such an account. For example, to comment to some sites which are not themselves hosted on Yahoo! or on Facebook or on Google+, one must none-the-less log into an account with one of these services.

From the perspective of the site-owners, reliance upon such external services can reduce the costs of managing site-access. The external social networks provide this management partly as valued-added to their account-holders, but providing this service is a means of building a behavioral profile of those account-holders.[1] (To this day, most people do not assimilate the fact that most social-networking services exist largely as profiling services.) As you might expect, I feel that efforts to build such profiles should be resisted.

I understand both the problems of the client-sites instead independently managing access, and the difficulties of knowing just where to draw some objective line that would distinguish acceptable and unacceptable external services. (For example, it seems to be perfectly acceptable to require a verified e.mail account, and even to require a verified e.mail account from a service that is not black-listed. But, once one requires a verified e.mail account from a service that is white-listed, one may be pushing visitors into allowing themselves to be profiled (by an e.mail-service provider), if the white-list is overly constrained.)

What seems inexcusable to me is not simply handing access-control over to an external service, but handing it over exclusively to one external service that is a profiling service. The very worse case of such inexcusability is handing control over to the biggest of these services, Facebook, but it remains inexcusable to give exclusivity to any other external service (unless that service has some real guarantee against building profiles).

Which brings me to a policy change that I will be effecting for my own 'blog, not-withstanding that it has never required an external account to access its functionality.


At this and some other sites, a list of implicitly or explicitly recommended links is provided, outside of the body of principal content. (With the present formatting of this 'blog, they are in a right-hand column.)

In the case of my own list, I will be removing (or refraining from providing) links whenever I discover that the only evident way to access those other sites or to comment to them is by using an account with exactly one external social-networking site.

For example, if a 'blog is not hosted on Facebook, but the only readily seen way to comment to it is by using a Facebook account, then I will not wilfully provide a link to it. I will continue to link to Facebook sites; I will continue to link to sites where the only readily seen ways of commenting use social-networking accounts, so long as accounts from more than one social network may be used.

This policy only applies to the sort of generalized recommendations represented by that list. I may continue to link within principal content to such things as news-stories at sites that are enabling such profiling.


[1] I don't know that those handing access-management off to such services receive side-payments for doing so, but it wouldn't surprise me.

Farewell to my LJ Friends

Saturday, 2 February 2013

Because LiveJournal has again broken its support for OpenID, I am again locked-out of reading Friends-only entries.

This time, instead of struggling to find a work-around (while the LJ support team does nothing but collect information which will be ignored by the LJ programmers, and then eventually expresses regrets at the lack of action), I am simply done with it. I won't be reading LJ entries.

I won't even bother with the more public entries at LiveJournal. If there's something that my LJ Friends want me to read, then it will have to be written elsewhere.

I am presently undecided as to whether I'm willing to enable LiveJournal to the extent of allowing it to continue to access my RSS feed. If you find that entries from this 'blog stop appearing on your Friends pages, then you might check as to whether that's simply because the 'blog has become quiescent, or because I've blocked the LJ server.

[Addendum (2013:02/06): I am informed that LiveJournal's alleged feed of this 'blog hasn't delivered any of the entries from this year anyway, so the question of whether to permit it to do so might perhaps be put aside.]

Openly IDed

Saturday, 16 June 2012

More than a year after finding that I could no longer log into LiveJournal with my OpenID, I am now again able to do so.

The server software that I had been using has long been orphaned. But, with some assistance from Kelvin Mo, I was able to get his SimpleID functioning properly for the most part. I worked around a final glitch yester-day. (I still have a problem with Blogspot/Blogger; but, for practical reasons, that is of less concern than was the problem with LJ.)

I am still trying to figure-out how to get the original OpenID for the Woman of Interest again working. She uses a different sort of directory structure and WordPress configuration than do I, and this is breaking something.

Installing Firefox 12.0 under RHEL, Scientific Linux, and CentOS 6.x

Tuesday, 24 April 2012

If you're actually trying to install another version of Firefox, then click on the Firefox tag, as there may be an entry on that other version.

The installation method that worked for Firefox 11.0 under Scientific Linux 6.1 works, mutatis mutandis, for Firefox 12.0 under Scientific Linux 6.1, and therefore ought to work for Firefox 12.0.x under RHEL 6.x and under CentOS 6.x.

So here are the steps that I recommend:

  1. Download the archive, firefox-12.0[.n].tar.bz2.
  2. The tarball contains a directory, firefox, which should be dropped-in as a sub-directory of something. If you want to ponder where, then study the FHS. As for me, as root, I put it in /opt:
    tar -xjvf firefox-12.0[.n].tar.bz2 -C /opt/

    (Omit that [.n] if it isn’t in the name of the archive that you downloaded. Replace it with the actual number from the name of the archive if such a number was included.)

  3. You’ll need a .desktop file for Firefox (though you may already have one). As root, edit/create /usr/share/applications/firefox.desktop, ensuring that it reads
    [Desktop Entry]
    Categories=Application;Network;X-Red-Hat-Base;
    Type=Application
    Encoding=UTF-8
    Name=Firefox
    Comment='WWW browser'
    Exec='/opt/firefox/firefox'
    Icon='/opt/firefox/icons/mozicon128.png'
    Terminal=false

    (If you didn't install in /opt, or changed the name of the firefox directory, then you'll need to change the above accordingly.)

  4. Restart the GUI, by logging out and back in or by restarting the system.