Posts by Michael Wojcik 12268 publicly visible posts • joined 21 Dec 2007
the problem of yet to be discovered/created vulnerabilities and bugs has to be accepted in any complex software
True. That said, what we know about a number of high-profile Android vulnerabilities (e.g. Stagefright) suggests that Android development practices are not particularly good. Are they requiring static code analysis for all Android code, for example? Doesn't look like it - at least not historically.
As someone that has to spell out both my first and last name I can relate
Who doesn't? "Michael" was one of the most common given names for boys in the year I was born, and has remained popular, yet half the mail I get is addressed to "Micheal".
And while it's a bit more of a stretch, "Wojcik" is so common in the area around the Stately Manor that I can reasonably expect to see it in our local paper at least once a month. And an Internet search for "Michael Wojcik" returns a great many hits. (I am a former Chicago alderman known for my appearance on "Dancing with the Stars", don'cha know.) Yet most people I have to spell it for act baffled, like it's an inconceivable string of letters the contemplation of which invites a Lovecraftian descent into madness.
Mavis "Titty" (Altounyan) Guzelian said in at least one interview1 that she wasn't too happy about Ransome immortalizing that nickname, which she acquired as a child for her love of "Titty Mouse and Tatty Mouse".
Alas, she died some 18 years before the BBC decided to change the character's name, so we don't know what she might have thought of that controversy.
But then the relationship between "Uncle Arthur" and the Altounyans was complicated in a number of ways.
1Alas, I don't have my references at this house to find and cite it precisely.
Yes, "Brigham" is hardly of recent coinage. The same can be said of Charleston and Cedar, though those two are less commonly seen as given names.
Brigham Young was born in 1801, and presumably named not long after. A quick Google ngrams search didn't turn up an earlier use of "Brigham" as a given name, though of course it's been a surname and place name in English for quite some time.
One site claims "Charleston" has been in use as a given name since the start of the twentieth century, based on US SSA data. It looks like the SSA website doesn't support searching for less-common names via the interactive interface (presumably the other site is using a web API, which I can't be bothered to ferret out), so I haven't confirmed that. In any case, it seems to have picked up in the 1970s, so for the US, at least, it's not novel either.
I couldn't bear the thought of any further investigation into the question.
Modern drives shouldn't suffer head crashes from sudden power losses, unless they're already having other problems (e.g. failing drive electronics). It only takes a tiny bit of power to park the heads, and it's easy to supply that with a capacitor on the drive controller, along with the logic to self-park.
I have a Dell Latitude laptop which hasn't been able to charge its battery for years, due to Dell's rubbish engineering. It's suffered numerous sudden power failures, since it's dependent on wall-socket power. It's never had a head crash. Anecdotal, I know; but it shows that power-failure head crashes aren't nearly as common as they were in the 1980s.
AFAIK this is equivalent to disabling UAC
The article says to set Run all administrators in Admin Approval Mode to Enabled, which enables UAC. If it's not already set to Enabled, then the system has UAC disabled.
FWIW, my Win7 machine has maximum UAC (all UAC GP settings set to the most-secure option, prompting for credentials on the secure desktop1), and I haven't seen this issue.
1Which, yes, is still far from bulletproof; but it does increase the attack work factor.
the Surface initiative seems to have been successful in improving the design of PC hardware
Has it? How? I admit I don't pay much attention to the design of PCs, but I don't recall seeing a single story about how it has "improved" recently. Or even changed significantly, except for USB whatever-it-is-now and this dual-screen thing the Surface is apparently sporting. Maybe I've missed some major innovation.
Atheism, assuming we're talking about true atheism and not just some form of agnosticism, has an article of faith as its central tenet, since it assumes an untestable hypothesis. Any hypothesis about the supernatural, including the null hypothesis, cannot be tested scientifically. That's what "supernatural" means: outside of nature, and therefore not required to be consistent with any other observed principle of the material world.
So yes, atheism is a faith, if not a religion per se.
Someone who's serious about not committing to untestable beliefs would be an agnostic, ideally a Perfect Bayesian Reasoner agnostic aware of the formal limitation on belief in consistency (from doxastic logic). That's about as uncommitted-to-unprovable-propositions as you can get.
In reality, of course, the ability of the human mind to avoid unproven and unprovable assumptions is extremely limited. Even in conscious thought, it requires continual vigilance, which carries a high cognitive load and can't be sustained for long stretches. In the preconscious and unconscious, forget it.
I was told I would never be an active member of a jury simply because I have a degree level education
This is simply false. I've served on a jury in a criminal case, and I hold three degrees. I have friends with doctorates who have served on criminal and civil juries. I've seen other jurors selected (when I was in the pool) who admitted to bachelor or advanced degrees.
My neighbor is a lawyer and law professor who specializes in aspects of trial process, and she tries to keep as many well-educated candidates in the jury as possible.
US voir dire is a complex process. Counsel typically get a handful of peremptory challenges (the right to remove a candidate from the jury for no expressed reason), but beyond that they have to present cause. And they don't know what the rest of the pool contains. Basically, it's a generalized secretary problem.
One time I drove a couple of screws using a manual screwdriver, and it only took a couple of minutes.
Another time I used my impact driver, but I had to charge the battery for 20 minutes first, so it took an order of magnitude longer than the manual screwdriver.
This proves that manual screwdrivers are superior to impact drivers, regardless of the use case or how the tool is employed.
In-band signalling is a problem with C, not just with null-terminated1 strings but with formatted I/O, another common source of vulnerabilities.
Of course as with most problems in computing, this was a trade-off. It arguably makes sense for the language's original use case, system programming on a machine with rather limited resources.
In C++ there's rarely any good reason to use C strings, except string literals to initialize C++ strings and other objects, and transient use of the value returned by the c_str method and similar when calling C functions. Of course much C++ code is just a mishmash of poor C++ and poor C compiled as C++, because many of the people who write C++ can't be bothered to learn the language. (In part that's the fault of the language; it's too damn big.)
In C, non-trivial programs should refactor string handling into higher-level abstractions that employ appropriate safeguards and memoize intermediate results. Inline sequences of strcat() and the like aren't just dangerous; they're a sign that the programmer couldn't be bothered to abstract and refactor properly. The same can be said of the use of "safer" string functions like strncpy (which has broken semantics) and the Annex K string functions (strcpy_s, etc, or nonstandard predecessors like strlcpy). As Richard Heathfield used to point out, a well-behaved program should know whether the result will fit in the target before attempting the operation, so that it can handle the error case correctly.
But from what I've seen (and I've seen a lot of C), very few C programmers have the discipline to do that.
1An unfortunate aspect of the C standard (ISO-IEC 9899) is the overloaded use of the term "null", which can refer to a null pointer (a special value, not necessarily all-bits-zero, for a pointer type which indicates it does not refer to any object); a null pointer constant (an integer type with value 0, or the same cast to void*, when used in a pointer context); and the char object with all-bits-zero. For the last the committee would have done better to use "nul", the ASCII name for that code point.
Because perl was hated, no one learned it - the hate was based on hearsay - crowd effect*, but real enough.
Shrug. I didn't hate Perl until I started learning it (from the O'Reilly book and articles in DDJ by Tim Kientzle and others). The more I learned, the more I hated it. This would have been in the mid-1990s, so Perl 5.
I have a strong UNIX background and had been writing sh and awk scripts for years before I first looked at Perl. And I knew Wall's work from patch and rn, both of which I'd used pretty extensively.
I wrote a few non-trivial utilities in Perl, but never warmed to it. The syntax made too much use of arbitrary punctuation. There were too many ways to accomplish basic tasks, with subtle differences. CPAN modules were far too inconsistent (a problem that plagues open-source component systems to this day, of course) and too many Perl developers relied on them for trivial things. Perl encouraged poor coding habits, particularly the production of unreadable and stovepiped code.
Some of these things are true of other languages I continue to use - the aforementioned sh (though these days I can assume bash on all the machines I use, which helps somewhat) and awk, C, etc. But Perl's no better, so there's no incentive to switch.
I think it's possible to produce good Perl code, but most of what I've seen is lousy, and enforcing that discipline on other maintainers is impossible. I already have that problem with C; I don't need it in Yet Another language.
True, it takes a lot of energy. Some very casual browsing suggests that steam rockets to LEO are physically feasible with reasonable payloads,1 so it might be possible to create an economically viable steam-rocket system using massive solar arrays or the like to heat the water.
That would lower the marginal cost quite a bit, since the energy inputs for launching would be free; but of course the capital costs of building the whole system would be huge, and maintenance and operating costs wouldn't be cheap. And it'd be a disposable rocket, presumably, not one of these newfangled come-back-home types.
1Though the author's example is pretty big: "A three stage rocket bigger than the Saturn V could put 10 tons into LEO!"
The only question is whether anyone will still remember analog TV snow when we do.
What I've always found interesting about that line is that the digital television sets I've seen all display a blue screen when there's no input signal. So a reader who's familiar with analog sets and assumes one will picture a cloudy sky, while one who only knows digital sets will presumably picture a clear one.
Gibson's weather imagery is a function of the age of the reader, to a first approximation.
Nah, there are plenty of use cases for graphical DBs, just as there are for RDBMSes, and key-value stores, and object databases, and even good old hierarchical databases and hash databases and indexed files. Horses for courses.
Some of the obvious use cases are mentioned in the article. If a graph does a good job of capturing the data you need to model, and you want to make complex queries on it, then a graph DB is often a suitable approach. (Not always, of course, and sometimes there will be other components in play. You might be working in the sort of problem space where graph sparsification is useful, for example, and you might not want to use a graph DB until after that step.)
That said, generalizations like "queries that explore relationships, and which would be more challenging or complex to construct in relational databases" aren't of much help. Relationships are straightforward to construct in relational databases when they can be modeled as, you know, relations.
Well, I suppose blaming everyone is one option.
While we're at it, why not complain that computing technology has improved so quickly? If we were all still using TENEX on PDP-10s, all we'd have to worry about is the login timing side channel, and Alan Bell fixed that a while ago.
a password has to be difficult to guess but easy to remember
This rules out (traditional) passwords, full stop. The asymmetry of effort between "guessing" and "remembering" is far too steep.
there's no password imaginable that can't be broken offline given time
That's trivially true for any finite sequence, so it's not a useful observation in itself. It's possible to make more productive observations about password or passphrase entropy versus contemporary cracking approaches under realistic economic assumptions and a plausible threat model; but generalizations like this are pointless.
There's also not much point in talking about passwords unless you're also going to consider passphrases.
For example, we might say something like: most people will find it non-trivial to come up with a passphrase that 1) has sufficient entropy to resist extant cracking engines, 2) also resists cracking by a hypothetical engine with access to large natural-language corpora and is able to do sufficiently-fast partial and close-match searches on it (to account for minor variation such as character substitution); and 3) can be reliably remembered by the user.
If we want to raise the stakes, we might also ask that it have enough entropy to resist BQP attacks (Shor's or variations thereof) for what we guess is an economically-feasible number of functional qubits given the value of the protected resource. (If an attacker is willing to dedicate 100 f-qubits to attacking the passphrase, you probably need at least 60 characters, if the passphrase is in English - but that's just a rough estimate.)
But even statements like those are just handwaving.
Angela Sasse at University College London did masses of very useful research into password effectiveness and usability
Indeed, including the classic 1999 CACM article "Users Are Not the Enemy" (with Anne Adams), which is a useful corrective for the Reg article we're responding to here. And Sasse has published on many other aspects of IT security. And so have many, many other researchers. And most software developers have studied little or none of this research. What else is new?
Developers and other IT practictioners, with their ignorance of relevant research, aren't the enemy either (tempting though it often is to blame them). There are reasons - economic and psychological1 - why the vast majority of IT practitioners don't follow relevant research. And why most researchers aren't practitioners. And why both are often disconnected from users.
There are ways to change those economics, such as regulation.They come at a cost, too. Maybe at some point we'll decide, as a society, that the cost of poor IT security justifies the cost of changing the economics of better software security.
1Which are really two aspects of the same thing, of course; that's why we have behavioral economics as a research field.
There was a time when even some security experts were suggesting that reusing a password for very-low-value sites - the ones that didn't hold personal or financial information, and didn't pose other privacy concerns, but wanted a login anyway - was not necessarily a bad idea, to reduce the burden on the user.
These days, those re-used passwords are increasingly a problem, since they help deanonymize your other online activity, if nothing worse.
On the plus side, they're likely to show up in porn-extortion spam ("I hacked your webcam and recorded you..."), which is a handy reminder to track down those old sites and change those passwords to something unique.
Because of the generally terrible state of web authentication, password managers have become more or less indispensable, unfortunately. And people who use multiple devices with the same sites, which is most people these days, will probably need a manager that has both desktop and mobile clients and provides some kind of synchronization mechanism.
We're starting to see wider adoption of web MFA and FIDO2, but it will be a long time before those are practical for most users.
"rock solid"? Password cracking engines have been using adaptive dictionaries that accommodate l33tspeak and other simple substitutions for years. John the Ripper had support for l33tspeak in 2008, for example.
Sufficiently-long (10+ characters, depending on the value of the target) decently-pseudorandom sequences are adequate these days. Random-word passphrases (extended versions of the xkcd method) also can be, though length requirements are difficult to estimate because cracking engines use various language models and are always improving.
For most low-value websites I use a password manager. (I like StickyPass, because it supports Pale Moon and is highly configurable.) For some higher-value accounts which unfortunately lack pervasive MFA, I use randomly-generated passphrases of several words and punctuation, in the 40-50 character length range. Still far from ideal, but it puts my credentials outside the current capabilities of typical cracking facilities.
"g_czechout" is an odd one, because the pun makes it seem plausible (though that's a really high rank unless it's some pop-culture reference I don't recognize), but the "g_" is ... weird. Is this maybe a hard-coded password for some widely-deployed script or something?
I was glad to see perennial favorites like "iloveyou" (#14, also mentioned in TFA) and "monkey" (#30) are still on the list. "monkey" is the example I usually use when I talk to non-IT folks about well-known passwords, because it's not obvious but has been prominent in these lists for decades.
Let me get this straight. You have to register with a party to get a vote, fair enough. Then you have to turn up in a wee room to cast a vote. Then if your chosen candidate doesn't make the top two in that wee room then you have to vote for someone else. Then the room vote is eventually phoned in to the state tally, and the number of delegates depends on those totals That is so 17th century.
Here's an idea, a single transferable vote nationwide on a paper ballot on a single night
I fear you have not, in fact, gotten it straight.
This is the Iowa Democratic Party Caucus. It has nothing to do with the actual election, except indirectly in helping the Democratic Party pick its candidate for the election. Nor does it apply to any other party. So "a single transferable vote nationwide" isn't applicable.
The Democratic Party bylaws - which are set by the party, and not by the government - say that each state gets to decide how to appoint its delegates to the national party convention, where the candidate for the election will be chosen. Iowa decided on this rather archaic caucus system. Most states use primaries, which are ordinary ballots, instead.
Again, this is all party business. The states get their fingers in it, for various reasons, but it's not governed by national law. (For the most part; the assembly clause of the Constitution1 was used to strike down California's "open primary" law, for example. Incidentally, an "open primary" is one where you wouldn't have to join a party to vote in that party's primary.) And so we have a fragmented, inconsistent, often-criticized system for picking each major party's candidates, because 50 states aren't going to agree on much of anything.
Also, Iowa is unlikely to switch to a primary because it likes to go first, and New Hampshire passed a law saying they get to have the first primary. If another state schedules a primary earlier, New Hampshire has to move theirs up in front of it. By (their own) law. No matter how stupid the result.
Around this time of year, every election year, you'll find plenty of editorials and position pieces suggesting the party bylaws be amended to use some more sensible system. No signs of that actually happening, though.
1The one that you can translate directly to machine code.
The point of impeaching Trump is political theater.
No one in the House dreamed for a second that the Senate would convict. (That would have been disastrous for the Democrats.) They impeached suspecting that McConnell wouldn't be able to resist putting on a blatant show trial, because McConnell can't resist throwing his weight around here at the very peak of his power. And they counted on that to "energize the base", to use a favorite cliche of the party machinery.
McConnell is probably hoping for the same effect, because he knows he's putting some vulnerable Republican senators at risk. But ultimately I suspect he doesn't care. He's king of the hill at the moment and his only real pleasure is pushing other people down. He has no policy agenda of his own (he's a champion flip-flopper, having once fillibustered his own bill); all indications are that he's only interested in power for the sake of power, and his route to it has been obstruction, so obstruct he will.
Basically, the point of impeaching Trump was to highlight McConnell again for the professional bully that he is, in the hope of increasing Democrat turnout in November, and maybe irritating some of the former anyone-but-Trump Republican voters into staying home.
Will it work? Hell, we'll probably never really know. But Democrats control the House and they had to be seen as doing something other than papering McConnell's desk with bills that will never get a hearing.
It's true that a lot of the land area of Iowa is rural, though that's true of most states. (Looking at the Census Bureau map, I think Connecticut, Hawaii, and Rhode Island are the only states with no rural counties, by the CB's definition.)
Nearly 2/3 of the population of Iowa lives in an urban area. While Iowa precinct maps turn out to be a pain the ass to read (the Secretary of State website has them as per-county PDFs, and the county websites all use excessive scripting), I assume the precincts cluster by population.
But there will still be some rural precincts, and a couple coverage maps I looked at suggested there might be some dead zones. So, yeah, it might well go beyond "slow download" to "no signal at all".
Why even bother with email? Just have the party set up a temporary call center. It's for one night (OK, you'll probably want the call center staffed for 48 hours or so, in case of problems), and there are fewer than 1800 precincts calling in.
There are any number of ways to authenticate callers for a specialized application like this.
There's really no reason to involve user-facing computer applications at all.
I'm hoping Shadow dies a quick and well-deserved death. US elections need less Internet, not more.
While the years since the HPES merger have been disappointing in terms of financial metrics, in some ways they've been pretty good to live through. Yes, we in Development have many complaints about infrastructure, processes, and so on, and the use of, and eventually migration away from, the HPE network has been a big, persistent pain in the ass. But the merger brought together a ton of really interesting people and a bunch of fun new toys.
It's very different than the grim MERANT years under Gary Greenfield, a CEO who seemed determined to piss customers off. Things were really quite bad in the 1998-2001 period. Morale was terrible, people were leaving, customers and analysts couldn't figure out what the company was doing. MERANT was a company that charged into the room, drew both pistols, emptied them into its feet, and proudly announced it had saved the day.
This was a poor year, but it was still a profitable one, even without taking the SUSE sale into account. (See the press release or presentation slides released today for details; they're available on the website.) EBITDA is down but EBITDA margin is up, which is encouraging. Even in a bad year Micro Focus makes money and pays dividends. And development remains strong, with new major releases coming out all the time. Obviously I'm biased, and perhaps I'm being foolishly optimistic, but I believe we'll return to the kinds of profit margins we enjoyed before the merger.
And in the meantime, my ESPP contributions will buy a lot of shares. Historically that's worked well for me.
In no particular order: Fortify SCA, FoD, and WebInspect; LoadRunner; Vertica; Sentinel;
DigitalSafe and other archiving & compliance products; Content Manager; SecureData.
And a bunch of other stuff. (Did the data center automation / management products come from HPES or Attachmate? I don't remember.)
There's actually quite a lot of good tech there. Fortify SCA may be the overall best static-code analysis system out there, and Fortify On Demand (Fortify as a service) is doing well. WebInspect is a pretty good web dynamic-scanning tool, though that's an area with a lot of competition from open source. Not everyone needs a columnar RDBMS, but for use cases where it's appropriate, Vertica is a strong contender. SecureData is a format-preserving encryption product line and interest in that area is growing.
A lot of the products are "make life easier for the guys in Operations", which isn't sexy and doesn't get a lot of press. And to be honest I have no idea how well most of them work. (I've played a bit with the SIEM products, ArcSight and Sentinel.) But it seems like an area where there's real need, and we ought to be able to sell more once we work through the sorts of things described in the announcement (and, more or less, the article).
(JFTR, the part of MF where I do most of my work is doing just fine. But I'd like to see the company as a whole do well.)
Assuming those in the US are very similar- and from what I've heard, they are
I suspect the vast majority are.
When I'm at the Stately Manor, if I listen to radio it's the local college station, which is staffed by students and thus cheerfully unpredictable. During the day the format is "college alternative", which, if I'm going to listen to music, is something I can tolerate; there are a variety of evening, nighttime, and weekend shows. It's certainly not all to my taste but it doesn't sound like everything was programmed by some central office, and it changes frequently.
(When I bought my car, it came with a six-month subscription to Sirius satellite radio. I tried it on one long trip, and memorized the playlists for the couple of stations I could stand before the day's drive was half over. I did not renew.)
At the Mountain Fastness, we are blessed with three (!) independent radio stations in town, plus the local public radio (NPR) affiliate. They play an eclectic variety of music, present local news, have call-in segments for things like lost pets. I know at least one has actual live DJs for all the programming, because they're well-known local personalities. Even the advertisements are for local businesses, and generally less annoying than typical corporate output.
But the sort of stations offered by iHeartMediocrity (formerly Clear Channel) aren't worth my time, as far as I'm concerned. Once in a while when I'm driving across the country I'll scan the bands just to see what's out there. I rarely find anything I want to listen to for more than a few minutes.
Yes, Kermit was a godsend in the days of dial-up.
For a while in the early '90s I had a remote office with a POTS connection to the main office. Most of my connectivity requirements were file transfer and email, for which I used UUCP - the modems at each end were Telebit Trailblazers with UUCP spoofing, so that made sense. But I built Kermit on machines at both ends and used it for a variety of ad hoc purposes because it was just so versatile.
Eventually we got a 56K dedicated line and I could just SLIP up an IP connection between the sites, but UUCP and Kermit helped me get a lot of work done before that.
Here the Teams rollout hasn't proved popular, at least with the people I work with. Email volumes haven't changed noticeably, and the Teams traffic is far less than even on the relatively unpopular RocketChat installation it replaced. There are days when there's no traffic at all on the 20+ channels I'm subscribed to, and days when it's nothing but robot traffic - announcements of people joining or leaving channels, auto-posts from CI systems, and that sort of thing.
It's been nearly six months, and many people seem to be using it grudgingly and as little as possible, while many others seem to be successfully ignoring it entirely.
Indeed.
When you get the certificate, you know when it expires. Perhaps Microsoft should sell some sort of software that provides a calendar with a reminder feature?
You can check the certificate's expiration date at any time, since it's part of the certificate.
You can trivially automate the process of checking a certificate's expiration date. There are any number of tools which do this.
You can easily automate the process of renewing certificates before they expire.
This is not the first time that Microsoft has been caught out by an expired certificate for a public service. Over the years they haven't been able to establish corporate policy and tooling to prevent this?
I admit I haven't tried it yet, because it's not a platform we support for the products I work on, and I've had far too many home-update projects to spend time messing with a new OS for my personal machine. But the latter is getting long in the tooth and would be more useful with a decent Linux than it is running the factory Windows installation. There are only a couple of Windows-only packages on it that I'll want to keep available, probably in a VM.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
