To prevent it from happening again, we created a company-wide policy that all computers would return to IT to have their contents backed up, and the computers would be formatted and reloaded for the next user. Consistently the owners of the company break this and other policies we set up to prevent data loss, theft, etc.
They're breaking your rules. Or (informally) making a decision that your rules do not apply to them, which they don't.
all computers would return to IT to have their contents backed up, and the computers would be formatted and reloaded for the next user.
I suspect that last bit is the problem.
The CEO being without his laptop for an hour while you "back it up" is a minor inconvenience for the CEO.
The CEO being without his laptop for several hours while you preemptively format it is absurd.
The policy does not respect the employee or their convenience.
It aims for only expediency that serves the IT department.
In that view the policy is unacceptable and should be changed.
The difference between IP and Phones, is in IP the IP address is both the destination host's identity and its location.
In the telco networks, there is an identity, locator split between the phone number itself and the SS7 ID of its destination. That is, there's a database that maps the phone numbers to a location; the database rarely changes, and when a change needs to happen it gets propagated at a glacial pace (sometimes requiring manual actions by other operators).
In the "IP" world, this would be like every packet having a "locator ID" for its destination, in the form of an AS number or other identity of the ISP the packet is destined for, separate from the IP and indicating the routing.
And other providers used the 'locator' to route the packet, instead of the destination IP.
But in the IP world today, there's no such thing as source routing; that notion was deprecated a long time ago, due to obvious security/DoS risks. The source of the packets has no ability to choose what route they will take through someone else's network, or where the packets will ultimately go.
Each router operates independently (except within the administrative controls of the autonomous system that operates the router) and determines where each packet gets routed.
Each IP address doesn't get its own route in routing tables.
Instead major ISPs get assigned fair-sized blocks such as/20,/19,/16, etc, and announce those blocks to their peers, in order to route traffic to them.
They can announce more-specifics, but there's a limit, created by filtering other people's routers do.
There are practical problems which lead to this not being allowed as a means of 'switching ISPs'.
Unless you justify provider-independent IP space in the first place.
You don't get to take your IPs (and fragment your provider's block) when you leave.
IP routing table slots are expensive, since every router has to be able to make a routing decision very quickly, and every block of usable IPs needs a slot, the bottleneck is memory.
The real crux of the issue is not necessarily what the tab key does, but how embedded tabs are treated and displayed when opening a file, be it a.C file, a header file, resource file or text file in the VS editor.
It's an example of Microsoft imposing a policy decision on users of the software.
Some of them don't want this, but they're going to be forced to do it this way because Microsoft is defining a tab policy
The problem with this is.... old code, created with different settings in VS 2008 or earlier.
And the need to be able to open it in VS 2010 and actually make sense out of it.
E.g. backwards compatibility.
Also, configurability of tab width and indent width is probably a good thing.
If the other editors can't config tab width, they suck.
Obviously companies and developers using the software should have coding standards that specify what tab width and indent width to use (normally 4 spaces)
But still, regardless of software used, the number of spaces to use for a tab is a policy thing, that should be dictated by the developer(s) or their company.
2-way communications over the public internet, as used by some smartgrid devices, requires that each node have a global IP.
I'm not really fond of it. I think it's a security risk.
The fact you or I don't think they ought to be using public addresses, doesn't actually force them to use technologies and design their networks to have them using private addressing, and no direct internet connectivity, though.
Oh, but the standards can't make guarantees that your ISP doesn't route it inside their own internal network.
If you use private IPs, a pre-requisite is that your router should be configured to block traffic to/from those private IP ranges on its WAN interface.
Basic bogon filtering/spoof protection suggests you should block all private ranges on your WAN interfaces (not just private IP ranges you use).
If you reclaim a single/8, you increase the availability of the resource by 5%
If you reclaim 12/8s, you increase the availability of the resource by 25%.
How much reclaiming a/8 delays exhaustion depends on the rate of consumption.
In the past few years, the rate of consumption has been increasing at a steady rate.
So long as justified need and demand for IP addresses continues to grow, we can expect consumption to grow.
We haven't considered new applications yet like smartgrids, which want to use a lot of global IP addresses, as in probably many/8s worth, so everyone's electric meter at their house, toaster oven, etc, can have a public IP address on the smart grid.
If we are fortunate, they will consider not going ahead with V4 IPs and use IPv6 IPs instead..
I have no idea how the phone system manages to handle number portability. I suspect that either they just rely on the fact that relatively few numbers are ported
To an extent this goes towards underlying operations of the SS7 protocols and the underlying routing methods used by the PSTN, which there are standards for, but some region specificity...
While the number is ported, the donor provider is generally paid a monthly compensation, for the service they continue to provide (in terms of porting the number).
Their own customers when using L3-assigned ip addresses?
Or transit customers' networks too?
If the latter.. 4.2.2.2 would still be widely available then, given L3's status as Tier1 provider, lots of ISPs buy their transit from Level 3, so e.g. lots of networks are customers of L3....
It's normally in the man page for traceroute.. on most OSes "-I" means to send ICMP ECHO (ping) packets instead of UDP packets to perform the traceroute.
Traceroutes may vary over multiple attempts, even with the same options.
Anyways, they work by sending a packet to the destination host with a very low initial TTL, and waiting for an ICMP "TTL Exceeded" error to be returned.
"TTL" or "Hop Limit" is a loop avoidance measure in the internet protocol. A TTL value is assigned to each packet, that is decremented after the packet passes through each router.
If the TTL is ever zero, the router will drop the packet (to prevent a loop), and attempt to send an error message back by sending an ICMP "Time to live exceeded" error.
The actual destination host will return an ICMP "Destination port unreachable" error instead, because no program is listening on the port.
The router that returns the "TTL Exceeded" error identifies a hop on the path to the destination.
After every hop or "wait period", the TTL is increased by one, and a new packet is sent to discover the next hop.
So in your first example, no router ICMP response came in for TTL=3, TTL=4, and TTL=5.
In your second example no ICMP error response came in for TTL=7, TTL=8, or TTL=9
There are a number of different things that can cause this.
Either the traceroute varies, or ICMP packets you sent are handled differently.
Some routers on the path may be overburdened, may decrement the TTL of a packet passing through by more than 1. Might not respond with "TTL Exceeded" out an interface that can reach you at all.
Or a firewall rule at some hop in the path could be blocking the ICMP error response required for your traceroute to work.
ARIN and the RIRs did not exist until 1997.
Prior to that date it was Network Solutions in the 90s, and prior to that it was IANA itself.
Before CIDR, the size of address blocks that organizations needed was different than today.
The policy was also different.
When ARIN was formed, one of the conditions they had to agree to in order to take on the role was to continue to service the existing allocations under the same terms.
The legacy registrants have held, since their allocations were not conditional, ARIN can't impose new conditions on them, such as requiring them to pay fees, or require them to renumber/return unused addresses.
In other words... "taking away the/8" is out of ARIN's hands, unless the entity or network no longer actually exists, and you can prove that....
The problem with "Class E" is these addresses have a "not a valid IP address" status; the classification of the addresses are "Experimental", not UNICAST. As a result, many OSes or devices from many vendors will not allow you to assign a Class E address, or communicate with a Class E address.
Windows XP falls into that category, Vista falls into that category, I cannot confirm whether Windows 7 falls into the category or not; unless there has been a recent patch, Class E IPs are unusable. Even Linux wouldn't allow you to communicate with a Class E address or assign it to an interface, until a kernel patch that was first introduced in January 2008
Many routers and firewalls are in a similar situation.
There is a lot of old software running at internet sites that is unlikely to be updated.
If "Class E" address space is ever opened, it's likely that IETF would not direct IANA to assign Class E to the RIRs for public allocation, instead it might be made available for private purposes, much like the RFC1918 address space.
The possibility of allocating 240/4 for use has been discussed on various network engineering mailing lists.
Their findings were that many software programs and hardware devices recognize "Class E" addresses and indicates an error.
So the thought that "Class E" is just more IP addresses to pick up for free, is a nice idea, but unfortunately no panacea.
It would be very hard to resurrect that range to 'usefulness' at this point in the Internet's evolution (with such a large installed base).
Just to be clear: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 are officially assigned for use by private networks. They cannot be allocated for use on the internet.
And "192.0.0.0/24" has been allocated for use in documentation, so those 256 addresses won't be allocated for use on the internet, either.
A good example of an undesirable IP address is one that's on a bunch of spam blacklists.
Some IP addresses are more likely to have connectivity issues than others.
One major issue improper or poorly maintained filters, that effects most address blocks that were previously not being assigned from equally, hence the DEBOGON projects and testing.
There are more insidious issues that only effect some blocks, however.
For example the guerilla usage of "1.0.0.0/8" by AnoNet, and "5.0.0.0/8" by Hamachi, plus private use of those, and other ranges instead of proper RFC1918 addresses by some enterprises.
Makes hosts that use those IP addresses more likely to have
communication problems with other hosts on the internet, just because their IP address is in that block.
I see a big problem here. If the govt just took people's W-2s, had charities report electronically, require brokerages to track cost basis, 99% of people could just click "accept" and be done with filing taxes.
Brokers can't track cost basis definitively, when investors receive the assets in their own name, and then later transfer to or sell through a different broker.
When investors have accounts at multiple brokerages, or multiple different types of accounts, a broker can't detect a Wash Sale.
And also cannot detect constructive sales or shorting against the box..
For example: person A might by 100 shares of stock XYZ from Broker A, and then buy an offsetting PUT option for XYZ or shorting a futures contract against the stock from Broker B.
In either case, the result is an offsetting position, which for tax purposes has the same tax consequence as a sale of the stock at Broker A (in terms of unrealized gains)
But Broker B has no means of detecting the position at Broker A.
Moreover, the investor who performs a wash sale at a loss (i.e. they buy back the position through a different broker) has to delay the loss.
But in so delaying the loss, the cost basis is increased.
So if the broker reported "their view" of the cost basis to the IRS, the number would be incorrect, due to the application of the wash sale rule.
Unless all transactions get reported to the IRS, with details sufficient to identify wash/constructive sales, the IRS cannot be sure of matters for much of the population.
And we haven't even gotten into things like barter arrangements.
E.g. I trade you my iPod Touch, Mighty mouse, Mac Mini, and 17" CRT monitor, to you in exchange for receiving your 27 inch iMac, Apple Tablet, and iPhone.
Yeah... just be careful, you know..
little known fact: kidnapping is treated as a more serious crime than having an uncorrected error on your tax form.:)
Or at least it used to be. I don't know if that's the case anymore.
The proposed change prevents a taxpayer from being dishonest (by informing him of what the IRS already knows of his finances), and only gives him a chance to correct the records.
The proposed system doesn't prevent a taxpayer from being dishonest: it makes it easier, because it informs the taxpayer of exactly which details the IRS is aware, and which they are unaware.
It facilitates the taxpayer knowing what the IRS is unaware of, and thus assists the taxpayer in hiding money in future years..
If the taxpayer is not presented with the info, then they have to be sure to report everything to really be certain they won't be caught red-handed.
Probably the real 'big bad guys' such as insiders at the IRS, criminal orgs, etc, already know major blindspots, where they can elude dtection.
If the IRS always reported everything it knew to the taxpayer... they'd lose a big part of their edge, they'd be opening up insight into the extent of info they get to the general public, resulting in opening up illegal tax fraud to the commoners, instead of just large entities with lots of money....
I think most of these places have guarantees that if they did your taxes wrong, they (not you) pay the price.
This generally only applies to calculation errors on their part.
And they don't pay until you can prove they made the error, anyways.
The customer of the prepare gets to be liable in the mean-time, and the prepare liable to pay the customer, only if the preparer is asked to review the matter and determines that they have made an error.
This doesn't aply to errors in you communicating return information to your prepare.
This doesn't apply to: "The IRS disallowed my mortgage interest deduction, because condition Y made it not permissible", "The IRS disallowed my medical expense deductions, because I was unable to produce a receipt", OR
"The IRS disallowed the exemption for my finacee, because we're not married and the relationship is not legal according to my local laws"
And it definitely doesn't apply to intentional abuses.
All preparers that make guarantees like that apply some explicit and implicit conditions to the guarantee.
In reality, the guarantee is worth a lot less than they would like you to think.
It's an advertising gag, that they are not likely to make good on, unless you make great lengths to prove it was their calculation or submission error.
And even then you might need to sue the preparer (in some cases).
Intuit would probably argue that it's a conflict of interest to be a tax preparer and not Intuit
Intuit probably also thinks it a conflict of interest for the IRS to decide the layout and contents of the forms.
Instead the layout, presentation, and contents of the forms should be determined by a company like Intuit.
(And by the time they're done, only someone who has a law degree, a computer science, a finance degree, AND a mathematics degree, or equivalent experience, and knowledge of a series of OS-specific proprietary encoding standards will be able to understand anything the form says, prior to being processed by Intuits annual $100,000 per-seat "Tax form decoding suite"), and initially encoded using their tax sw.
Slashdot Mirror
They're breaking your rules. Or (informally) making a decision that your rules do not apply to them, which they don't.
I suspect that last bit is the problem.
The CEO being without his laptop for an hour while you "back it up" is a minor inconvenience for the CEO.
The CEO being without his laptop for several hours while you preemptively format it is absurd.
The policy does not respect the employee or their convenience. It aims for only expediency that serves the IT department. In that view the policy is unacceptable and should be changed.
The difference between IP and Phones, is in IP the IP address is both the destination host's identity and its location.
In the telco networks, there is an identity, locator split between the phone number itself and the SS7 ID of its destination. That is, there's a database that maps the phone numbers to a location; the database rarely changes, and when a change needs to happen it gets propagated at a glacial pace (sometimes requiring manual actions by other operators).
In the "IP" world, this would be like every packet having a "locator ID" for its destination, in the form of an AS number or other identity of the ISP the packet is destined for, separate from the IP and indicating the routing.
And other providers used the 'locator' to route the packet, instead of the destination IP.
But in the IP world today, there's no such thing as source routing; that notion was deprecated a long time ago, due to obvious security/DoS risks. The source of the packets has no ability to choose what route they will take through someone else's network, or where the packets will ultimately go.
Each router operates independently (except within the administrative controls of the autonomous system that operates the router) and determines where each packet gets routed.
Each IP address doesn't get its own route in routing tables.
Instead major ISPs get assigned fair-sized blocks such as /20, /19, /16, etc, and announce those blocks to their peers, in order to route traffic to them.
They can announce more-specifics, but there's a limit, created by filtering other people's routers do. There are practical problems which lead to this not being allowed as a means of 'switching ISPs'.
Unless you justify provider-independent IP space in the first place. You don't get to take your IPs (and fragment your provider's block) when you leave.
IP routing table slots are expensive, since every router has to be able to make a routing decision very quickly, and every block of usable IPs needs a slot, the bottleneck is memory.
The real crux of the issue is not necessarily what the tab key does, but how embedded tabs are treated and displayed when opening a file, be it a .C file, a header file, resource file or text file in the VS editor.
It's an example of Microsoft imposing a policy decision on users of the software. Some of them don't want this, but they're going to be forced to do it this way because Microsoft is defining a tab policy
The problem with this is.... old code, created with different settings in VS 2008 or earlier.
And the need to be able to open it in VS 2010 and actually make sense out of it.
E.g. backwards compatibility.
Also, configurability of tab width and indent width is probably a good thing.
If the other editors can't config tab width, they suck.
Obviously companies and developers using the software should have coding standards that specify what tab width and indent width to use (normally 4 spaces)
But still, regardless of software used, the number of spaces to use for a tab is a policy thing, that should be dictated by the developer(s) or their company.
2-way communications over the public internet, as used by some smartgrid devices, requires that each node have a global IP.
I'm not really fond of it. I think it's a security risk.
The fact you or I don't think they ought to be using public addresses, doesn't actually force them to use technologies and design their networks to have them using private addressing, and no direct internet connectivity, though.
ISI.EDU is no longer DoD contracter for the IANA function.
ICANN is the current holder of the USG contract for the IANA function.
Many of IANA's roles were stripped from it and assigned to other entities which makes sense.
Still, it is perhaps among the saddest moments in internet history, that this change happened...
Good and bad things have come of it. But don't think of IANA as a separate entity anymore, it's really just ICANN.
10.x.x.x is unroutable private IP address space.
Oh, but the standards can't make guarantees that your ISP doesn't route it inside their own internal network.
If you use private IPs, a pre-requisite is that your router should be configured to block traffic to/from those private IP ranges on its WAN interface.
Basic bogon filtering/spoof protection suggests you should block all private ranges on your WAN interfaces (not just private IP ranges you use).
In this case, there are 24 /8s remaining.
If you reclaim a single /8, you increase the availability of the resource by 5%
If you reclaim 12 /8s, you increase the availability of the resource by 25%.
How much reclaiming a /8 delays exhaustion depends on the rate of consumption.
In the past few years, the rate of consumption has been increasing at a steady rate. So long as justified need and demand for IP addresses continues to grow, we can expect consumption to grow.
We haven't considered new applications yet like smartgrids, which want to use a lot of global IP addresses, as in probably many /8s worth, so everyone's electric meter at their house, toaster oven, etc, can have a public IP address on the smart grid.
If we are fortunate, they will consider not going ahead with V4 IPs and use IPv6 IPs instead..
I have no idea how the phone system manages to handle number portability. I suspect that either they just rely on the fact that relatively few numbers are ported
To an extent this goes towards underlying operations of the SS7 protocols and the underlying routing methods used by the PSTN, which there are standards for, but some region specificity...
While the number is ported, the donor provider is generally paid a monthly compensation, for the service they continue to provide (in terms of porting the number).
Depending on which portability scheme is in use...
Or (more likely) how recently the number has been ported, the central database queried for every call made may indicate.
Or the donor network redirects or provides the new routing information to the call, when it hits their switch.
So the calling network routes to the new network instead.
Their own customers when using L3-assigned ip addresses?
Or transit customers' networks too?
If the latter.. 4.2.2.2 would still be widely available then, given L3's status as Tier1 provider, lots of ISPs buy their transit from Level 3, so e.g. lots of networks are customers of L3....
It's normally in the man page for traceroute.. on most OSes "-I" means to send ICMP ECHO (ping) packets instead of UDP packets to perform the traceroute.
Traceroutes may vary over multiple attempts, even with the same options.
Anyways, they work by sending a packet to the destination host with a very low initial TTL, and waiting for an ICMP "TTL Exceeded" error to be returned.
"TTL" or "Hop Limit" is a loop avoidance measure in the internet protocol. A TTL value is assigned to each packet, that is decremented after the packet passes through each router. If the TTL is ever zero, the router will drop the packet (to prevent a loop), and attempt to send an error message back by sending an ICMP "Time to live exceeded" error.
The actual destination host will return an ICMP "Destination port unreachable" error instead, because no program is listening on the port.
The router that returns the "TTL Exceeded" error identifies a hop on the path to the destination. After every hop or "wait period", the TTL is increased by one, and a new packet is sent to discover the next hop.
So in your first example, no router ICMP response came in for TTL=3, TTL=4, and TTL=5.
In your second example no ICMP error response came in for TTL=7, TTL=8, or TTL=9
There are a number of different things that can cause this. Either the traceroute varies, or ICMP packets you sent are handled differently.
Some routers on the path may be overburdened, may decrement the TTL of a packet passing through by more than 1. Might not respond with "TTL Exceeded" out an interface that can reach you at all.
Or a firewall rule at some hop in the path could be blocking the ICMP error response required for your traceroute to work.
I don't know of ARIN ever handing out a /8.
ARIN and the RIRs did not exist until 1997. Prior to that date it was Network Solutions in the 90s, and prior to that it was IANA itself.
Before CIDR, the size of address blocks that organizations needed was different than today.
The policy was also different.
When ARIN was formed, one of the conditions they had to agree to in order to take on the role was to continue to service the existing allocations under the same terms.
The legacy registrants have held, since their allocations were not conditional, ARIN can't impose new conditions on them, such as requiring them to pay fees, or require them to renumber/return unused addresses.
In other words... "taking away the /8" is out of ARIN's hands, unless the entity or network no longer actually exists, and you can prove that....
The problem with "Class E" is these addresses have a "not a valid IP address" status; the classification of the addresses are "Experimental", not UNICAST. As a result, many OSes or devices from many vendors will not allow you to assign a Class E address, or communicate with a Class E address.
Windows XP falls into that category, Vista falls into that category, I cannot confirm whether Windows 7 falls into the category or not; unless there has been a recent patch, Class E IPs are unusable. Even Linux wouldn't allow you to communicate with a Class E address or assign it to an interface, until a kernel patch that was first introduced in January 2008
Many routers and firewalls are in a similar situation. There is a lot of old software running at internet sites that is unlikely to be updated.
If "Class E" address space is ever opened, it's likely that IETF would not direct IANA to assign Class E to the RIRs for public allocation, instead it might be made available for private purposes, much like the RFC1918 address space.
The possibility of allocating 240/4 for use has been discussed on various network engineering mailing lists.
Their findings were that many software programs and hardware devices recognize "Class E" addresses and indicates an error.
So the thought that "Class E" is just more IP addresses to pick up for free, is a nice idea, but unfortunately no panacea. It would be very hard to resurrect that range to 'usefulness' at this point in the Internet's evolution (with such a large installed base).
Just to be clear: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 are officially assigned for use by private networks. They cannot be allocated for use on the internet.
And "192.0.0.0/24" has been allocated for use in documentation, so those 256 addresses won't be allocated for use on the internet, either.
A good example of an undesirable IP address is one that's on a bunch of spam blacklists.
Some IP addresses are more likely to have connectivity issues than others.
One major issue improper or poorly maintained filters, that effects most address blocks that were previously not being assigned from equally, hence the DEBOGON projects and testing.
There are more insidious issues that only effect some blocks, however.
For example the guerilla usage of "1.0.0.0/8" by AnoNet, and "5.0.0.0/8" by Hamachi, plus private use of those, and other ranges instead of proper RFC1918 addresses by some enterprises.
Makes hosts that use those IP addresses more likely to have communication problems with other hosts on the internet, just because their IP address is in that block.
Ah... 127.0.0.1.... sometimes mistyped as 27.0.0.1 though, especially by folks trying to "ping 127.0.0.1" for some reason :)
I see a big problem here. If the govt just took people's W-2s, had charities report electronically, require brokerages to track cost basis, 99% of people could just click "accept" and be done with filing taxes.
Brokers can't track cost basis definitively, when investors receive the assets in their own name, and then later transfer to or sell through a different broker.
When investors have accounts at multiple brokerages, or multiple different types of accounts, a broker can't detect a Wash Sale.
And also cannot detect constructive sales or shorting against the box.. For example: person A might by 100 shares of stock XYZ from Broker A, and then buy an offsetting PUT option for XYZ or shorting a futures contract against the stock from Broker B.
In either case, the result is an offsetting position, which for tax purposes has the same tax consequence as a sale of the stock at Broker A (in terms of unrealized gains)
But Broker B has no means of detecting the position at Broker A.
Moreover, the investor who performs a wash sale at a loss (i.e. they buy back the position through a different broker) has to delay the loss.
But in so delaying the loss, the cost basis is increased. So if the broker reported "their view" of the cost basis to the IRS, the number would be incorrect, due to the application of the wash sale rule.
Unless all transactions get reported to the IRS, with details sufficient to identify wash/constructive sales, the IRS cannot be sure of matters for much of the population.
And we haven't even gotten into things like barter arrangements.
E.g. I trade you my iPod Touch, Mighty mouse, Mac Mini, and 17" CRT monitor, to you in exchange for receiving your 27 inch iMac, Apple Tablet, and iPhone.
How is the IRS going to sort that one? :)
Yeah... just be careful, you know.. little known fact: kidnapping is treated as a more serious crime than having an uncorrected error on your tax form. :)
Or at least it used to be. I don't know if that's the case anymore.
People did learn...
And then they got laid off, and replaced with outsourced development companies from India, who haven't learned yet, or just don't care as much.
The proposed change prevents a taxpayer from being dishonest (by informing him of what the IRS already knows of his finances), and only gives him a chance to correct the records.
The proposed system doesn't prevent a taxpayer from being dishonest: it makes it easier, because it informs the taxpayer of exactly which details the IRS is aware, and which they are unaware.
It facilitates the taxpayer knowing what the IRS is unaware of, and thus assists the taxpayer in hiding money in future years..
If the taxpayer is not presented with the info, then they have to be sure to report everything to really be certain they won't be caught red-handed.
Probably the real 'big bad guys' such as insiders at the IRS, criminal orgs, etc, already know major blindspots, where they can elude dtection.
If the IRS always reported everything it knew to the taxpayer... they'd lose a big part of their edge, they'd be opening up insight into the extent of info they get to the general public, resulting in opening up illegal tax fraud to the commoners, instead of just large entities with lots of money....
I think most of these places have guarantees that if they did your taxes wrong, they (not you) pay the price.
This generally only applies to calculation errors on their part.
And they don't pay until you can prove they made the error, anyways. The customer of the prepare gets to be liable in the mean-time, and the prepare liable to pay the customer, only if the preparer is asked to review the matter and determines that they have made an error.
This doesn't aply to errors in you communicating return information to your prepare.
This doesn't apply to: "The IRS disallowed my mortgage interest deduction, because condition Y made it not permissible", "The IRS disallowed my medical expense deductions, because I was unable to produce a receipt", OR "The IRS disallowed the exemption for my finacee, because we're not married and the relationship is not legal according to my local laws"
And it definitely doesn't apply to intentional abuses. All preparers that make guarantees like that apply some explicit and implicit conditions to the guarantee.
In reality, the guarantee is worth a lot less than they would like you to think.
It's an advertising gag, that they are not likely to make good on, unless you make great lengths to prove it was their calculation or submission error. And even then you might need to sue the preparer (in some cases).
Intuit would probably argue that it's a conflict of interest to be a tax preparer and not Intuit
Intuit probably also thinks it a conflict of interest for the IRS to decide the layout and contents of the forms.
Instead the layout, presentation, and contents of the forms should be determined by a company like Intuit.
(And by the time they're done, only someone who has a law degree, a computer science, a finance degree, AND a mathematics degree, or equivalent experience, and knowledge of a series of OS-specific proprietary encoding standards will be able to understand anything the form says, prior to being processed by Intuits annual $100,000 per-seat "Tax form decoding suite"), and initially encoded using their tax sw.
Fine, as long as they randomly select some substantial items on each return to "pretend" they don't know about.
And if not reported, it triggers an audit.
P.S.S. Or start a daycare centre at your house targetting kids with an IQ of 200 or higher, and pay them off to pretend they are your kids.
When the agents arrive for the inspection, you'll claim you home school your children.