-
-
It’s worse than you think. Read this article from ProPublica…
Inside TurboTax’s 20-Year Fight to Stop Americans From Filing Their Taxes for Free
Using lobbying, the revolving door and “dark pattern” customer tricks, Intuit fended off the government’s attempts to make tax filing free and easy, and created its multi-billion-dollar franchise
by Justin Elliott and Paul Kiel Oct. 17, 2019
1 user thanked author for this post.
-
-
There’s lots that needs to be said on this issue. But my music program is going to end soon, and I’m not sure I want to stay awake long enough to finish writing this diatribe. But let’s begin and see how far we get.
BACKUPS
Yeah, great. With you and bbearren all the way on this one. Problem is… What you WANT to have is a backup that was made (and verified) within MINUTES of the time the update occurs, so you can be SURE you have captured EVERYTHING of value.
Under the current Win10 update regime you cannot do that because you typically do NOT have control over EXACTLY WHEN the update will occur. So the best you can do is an approximation… what the machine state looked like when the backup program was last run, NOT what the state of the machine was just prior to the update.
If you have to restore under a condition of approximation, then you have a rock and hard place choice to make: Abandon everything that didn’t make it onto the backup, or try to capture it from the failed system and merge it into the restored system. I’ve done both; NEITHER is acceptable to me. I want FULL CONTROL over updates. MY timeline, NOT someone else’s.
TELEMETRY
If I could be SURE that MS’s telemetry could actually do all the wonderful things you claim it can do for us, then yes, I would be in favor of it, too. But I do NOT believe it can. Or ever will.
In a former lifetime I did program development in a world-class scientific research lab. I once tried to write code that watched one of my programs run and gave me feedback on what went wrong. That’s a VERY HARD task. MUCH harder than writing the code itself. Perhaps impossible. As in NP Complete impossible. And I suspect Gödel himself might have a few words to say about the theoretical impossibility of doing it, too.
Why? Because the ONLY things your telemetry code can test for are things you already know to look for, and how to test for. But in order to do what you want MS’s telemetry to do that code has to watch for all the UNEXPECTED things that by definition cannot be predicted IN ADVANCE before you actually SEE them happen at least once.
Here’s another way to look at this. What MS is trying to do is analogous to trying to write a diagnostic program that runs within the OS. But writing diagnostic programs that REALLY and FULLY test hardware and/or software is well known to be a thankless and difficult task.
In that same former lifetime, my fellow engineers and I used to quip that our application programs were better at diagnosing failures of the DEC hardware we were running on than the diagnostic programs that DEC wrote and supplied to us.
We’d have a failure and call in a DEC FE. First thing he did was run the standard diag. Most of the time it would come up clean. But our app would crash consistently. And if we could get the FE to try a few board swaps, oftentimes the problem would vanish with one of them. And magically reappear if the original board was swapped back in. QED
But sometimes it wouldn’t, because the failure was intermittent. Then we would have to pare down our code until we found something that would repeatably provoke a failure. Once we knew EXACTLY what to look for, and how to tickle it, then AND ONLY THEN could we write a diagnostic that reliably demonstrated the fail.
How is that different than Win10 updates? If MS knew what was going to fail in a new patch, then they certainly could write telemetry code to test for that particular failure. But why would they do that, when they could more easily use that same insight to correct the problem in the patch BEFORE it shipped.
How does the telemetry code know to look for a particular profile failure mode when there are hundreds or thousands of ways that something can go wrong? Or identify a race condition that cannot even be defined let alone tested for? And again, if MS knew what to look for, a more straight-forward approach would be simply to FIX THE CODE, either in the OS or the patch, and be done with it. Writing yet more telemetry code gets you nowhere useful. It’s a REACTIVE strategy whereas what you really want is a PROACTIVE approach.
And don’t tell me “AI can do it”. Nope. Still have to train it. And if there’s a category missing from the training set, AI won’t help you find it. AI is good for finding exotic variants of things you already know something about, NOT for exploring the unknown. Which is what bad code is, because if you KNEW in advance it was bad, then you wouldn’t ship it until it was fixed. Or at least most competent programmers wouldn’t.
One final point. There are also fundamental limits on HOW MUCH telemetry you can gather before your telemetry becomes a drag on productivity. So even if you know what to look for, you may not be able to gather sufficient data to perform the needed analysis, because the computation required is so cpu- or disk-intensive that the user would immediately notice the slowdown.
Bottom line: NO, I do NOT believe telemetry BY ITSELF can now or ever will compensate for MS’s poor coding. Or make updating easier or safer for the average user or sysadmin.
And with that, I’m donning my flame-proof nightgown and heading off to bed…
— EstherD
19 users thanked author for this post.
rc primak,
Bengalensis,
Kranium,
LH,
OscarCP,
Lars220,
Charlie,
DriftyDonN,
woody,
SueW,
jburk07,
wavy,
Cybertooth,
phaolo,
zat_so,
Kathy Stevens,
Fred,
David F,
migongo
-
It also causes “sfc” on Win7 to emit a cryptic error message, something about files it tried to restore but couldn’t, presumably because “sfc” also can no longer read the jscript.dll files after the workaround is implemented. Since the logfile generated by “sfc” is effectively unparsable by mere mortals, it is difficult to determine exactly what “sfc” is complaining about. Therefore, you may not want to implement this workaround if you rely on “sfc” to validate the health of your Win7 system.
-
Agree with your appraisal of EMET. Ran it on the family’s three personal laptops for about 5 years in the late-2000’s and early-2010’s. EMET never stopped anything nasty (though our AV’s caught a number of them during those years). Meanwhile, EMET was constantly throwing up false positives, usually just after every new release of Chrome or Firefox. Got to be too much of a maintenance headache, so I ripped it out.
Currently using Malwarebytes Pro as our AV and anti-malware tool of choice, with Win7 Defender turned off. Highly recommended.
1 user thanked author for this post.
-
-
Are you sure you mean JAVA rather than Javascript?
The two technologies are NOT the same, but they are often confused with one another.
Javascript is built into all browsers. Most websites require Javascript to render correctly.
JAVA is a browser PLUGIN from Oracle that you have to install (and update) manually. Very few sites need JAVA. Notable exceptions are a few science-based sites, which use JAVA to compute things like star maps and satellite tracking. Personally, have never seen JAVA required by any banking and/or e-commerce sites.
If you have JAVA installed, it will have its own control panel and appear in the list of installed programs. Javascript does not do either of these things.
-
Last time I checked, which was admittedly about 5 years ago, you could stop the scanning, but you could NOT uninstall / disable the low-level code that implemented it. So it’s there, ripe for the pickin’, whenever someone has the incentive to figure out how to exploit it.
1 user thanked author for this post.
-
If MS were supplying a “clean” patch just for the BlueWho family of vulnerabilities, then I would agree with you: Waiting to patch would be foolhardy. However, that is NOT the case; the BlueWho patch is bundled with all manner of unrelated stuff. Consequently, the risk calculation is NOT as simple as you make it out to be. A prudent sysadmin needs to balance the risk of leaving BlueWho unpatched with the risk of patching quickly and then taking one on the chin because of some other so-called “fix” that is buried in the same patch file. And I do mean BURIED, since MS seems loath to tell us EXACTLY what change(s) are present in any given patch. That makes testing VERY difficult, and impossible to do with any degree of confidence, since it becomes a complete guessing game as to what must be tested to feel some assurance that the patch won’t adversely affect production systems. And don’t tell me that unexpected interactions are highly unlikely. What about the recent “Visual Basic” fiasco? Or the early Spectre/Meltdown patches, which actually made the systems on which they were installed LESS secure than if those systems hadn’t been patched at all? If “side-effects” like that were predictable, then why didn’t MS catch (and FIX) them during design, implementation or testing? If not, then my point is proven: Fools rush in whereas prudent sysadmins tread slowly and lightly. QED
1 user thanked author for this post.
-
The term should be “pwned”, not “owned”. (Google it.)
Quick explanation:
If you NEVER reuse the SAME password on multiple websites, then there is nothing to see here.
However, if you DO reuse passwords, then you should STOP that practice. You should probably also consult Troy Hunt’s “Have I Been Pwned” website (see link in earlier post) for details about why that’s a BAD IDEA, and whether or not you are currently at risk, because some miscreant has stolen a hash of your favorite password from some site and cracked it so it can be used on another site, e.g. your bank or credit card account.
— EstherD
1 user thanked author for this post.
-
-
Years ago, boot problems like those described here could often be fixed by replacing the CMOS battery. Sometimes the cure was as simple as removing the battery, cleaning the contacts and putting it back (no actual replacement needed). HTH… EstherD
1 user thanked author for this post.
-
Author
