P
TurboTax can peek at your page
- Thread starter pmikep
- Start date
- Watchers 4
-
SpinRite v6.1 Release #3 Guest:
The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
/Steve. -
Be sure to checkout “Tips & Tricks” Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!
/Steve. -
BootAble – FreeDOS boot testing freeware
To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.
GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.
The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.
You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.
(You may permanently close this reminder with the 'X' in the upper right.)
They probably would use an enterprise solution where they send her a small executable that she runs, it grants permission for them to access her machine and then calls home so they can connect to her.
P
pmikep
Guest
If they don't supply Linux-based software, I don't see why they would. If you don't trust Intuit, why would you let her install TurboTax?
Yes.calling home meaning calling THEIR home, of course
P
pmikep
Guest
If you're not careful, and you get a mal 800 number, they will pretend to be the company's tech support, while they work an angle on you to get into your system to hold you for ransom. So saying they were on the phone talking doesn't mean anything in that sense.
The OP mentioned that his friend(?) initiated the call to TurboTax. Assuming she used the number provided by the software, she should be fine.
Sure, if they got it from the software. But the bad guys will buy nearby mis-dials also. And if you Google for the number, you're more likely t o get a bad one than a good one unless you're very careful... so I wanted to make sure people are extra cautious.
Really, it would be best for software support if they designed the support process such that the company would call you. You would ask for help in the software, and give your phone number, and it would show a confirmation code on screen which the agent would confirm (whether you call them or they call you.)
Like many corporations, I got the impression that they contracted third party service(s) for customer support. This person's home was kind of out in the boonies. No cellular data service, no broadband service... and quite naturally dialup wasn't really a viable option; even if available. The TurboTax customer called the Geeks/Nerds onsite to help him. Several years ago, I was that Geek/Nerd tech. Product documentation and customer service were both claiming that the product would support doing Federal taxes with no internet connection except, for reasons I don't quite recall at the moment, it wouldn't. With only a few minutes of exposure to the issue, it seemed that I knew more about the product than their customer support team.
In other examples where I had to install their product on an O/S that I setup... which is always the PROPER way... that is, the user is NOT operating from an Administratively privileged account, their software just couldn't handle it. Diving in further, it became apparent that they were still using antiquated coding practices from more than a decade ago. (like Windows Millenium/98/95... not even NT) Even if I changed the install locations using custom setup options, Symbolic Links and/or used ProcMon in conjuction with SubInACL to grant the user/program access to all file and registry resources, the program would still demand privileges it wasn't using and didn't need. Setting compatibility modes didn't help. Like 99% of the software out there, it didn't install drivers or service(s).
I *HATE* programs like theirs with a passion... rendering even basic security practice useless; asking for full control of the system just to launch even if it wasn't doing a self-update. Last thing you want, is to train a user to routinely enter elevated credentials where doing that should be a rarity. In an Enterprise environment we ran into similar issues with their products and I HATED them there too. Just to keep from being bothered my coworkers would always elevate users to local admin.
In that situation and fortuantely, I only had to elevate program privilege upon a self-update. But again, it demanded privileges it didn't need because I had already granted the user access to the specific file and registry resources that the program wanted to modify.
It wouldn't surprise me at all if their software is wildly exploitable.
BTW, the handle is of no relation. Intuition was a strong ally growing up... no glasses and not being able to see the chalk board (even sitting in the front row), or read facial expressions... had to learn to put two and two together with large information gaps.
In other examples where I had to install their product on an O/S that I setup... which is always the PROPER way... that is, the user is NOT operating from an Administratively privileged account, their software just couldn't handle it. Diving in further, it became apparent that they were still using antiquated coding practices from more than a decade ago. (like Windows Millenium/98/95... not even NT) Even if I changed the install locations using custom setup options, Symbolic Links and/or used ProcMon in conjuction with SubInACL to grant the user/program access to all file and registry resources, the program would still demand privileges it wasn't using and didn't need. Setting compatibility modes didn't help. Like 99% of the software out there, it didn't install drivers or service(s).
I *HATE* programs like theirs with a passion... rendering even basic security practice useless; asking for full control of the system just to launch even if it wasn't doing a self-update. Last thing you want, is to train a user to routinely enter elevated credentials where doing that should be a rarity. In an Enterprise environment we ran into similar issues with their products and I HATED them there too. Just to keep from being bothered my coworkers would always elevate users to local admin.
In that situation and fortuantely, I only had to elevate program privilege upon a self-update. But again, it demanded privileges it didn't need because I had already granted the user access to the specific file and registry resources that the program wanted to modify.It wouldn't surprise me at all if their software is wildly exploitable.
BTW, the handle is of no relation. Intuition was a strong ally growing up... no glasses and not being able to see the chalk board (even sitting in the front row), or read facial expressions... had to learn to put two and two together with large information gaps.
Similar threads
