Be glad it wasn't fetching dates from upstream somewhere. But at least you now know these devices are designed to become obsolete sometime between now and 2016.
Someone obviously reverse engineered it. They saw 0x02 in 2002 and 0x03 in 2003 and assumed it was an 8-bit binary number of years since 2000. They should have read the specs instead to learn it was BCD (a leftover relic from the mainframe era that needed to die over a decade ago). OTOH, the spec designers should have use plain unsigned binary (which would have lasted until 2255 instead of 2099). Or better yet, don't even break up dates into bytes and nybbles; leave them encoded as number of nanoseconds since the epoch, times some scaling factor to fit less resolution in fewer bits as needed.
0x10 is 8 bits with the pattern value of 00010000. That's 16 when interpreted as binary. The BCD (binary coded decimal) puts DECIMAL values in each 4 bit nybble. So 10 is 00010000 and 99 is 10011001. The problem seems to be that the year is encoded as the last 2 digits in BCD, so it is encoding 2009 as 00001001 and 2010 as 00010000 and 2011 as 00010001. Interpreting this (incorrectly) as binary gives 9, 16, and 17 (adding 2000... or formatting as 2 digits and prepending "20"... gives 2009, 2016, 2017).
Dumb programmers. Don't they have any real world experience?
Dumb formatting. Obviously a legacy thing from the mainframe era.
Two digits is fine, now... until we approach 2100. I plan to be retired by then, so I don't care. Fear those who are using ONE digit (that has happened). But in this case I can believe that someone used the wrong conversion like maybe: strtol(year_str,NULL,0x10).
I do have an ASUS EeePC netbook with a solid state flash drive. It has 16GB and runs at a nice 88 MB/s. The trouble is now, you can't find ANYTHING with an SSD, regardless of the size (of the SSD as long as it is at least 16GB, or the screen/etc). I guess everyone still wants spinning metal platters that can be damaged by some strong impacts. If I ever needed to replace this one, I couldn't as a new unit (have to go to EBay and hope someone will part with their precious baby).
The problem is these greedy capitalist solutions are not proportional to sales. While Mom and Pop can probably pay less than Jeff Bezos would have to pay, it certainly won't be at the same rate per dollar of sales. There will be some big fixed price component to this service, like a $10,000 up front access fee. To make this work, government needs to ensure that all retailers of all sizes have a properly proportional and affordable way to comply.
It shouldn't be web based. But HTTPS based might work. One complication might be privacy. But I could go for that. We just create an XML schema for the data exchange. Connect online, provide customer address info, get tax list back for all product classes (need a standard set of product classes), and dates of validity (if changes are within 91 days, the data must include the changes, too). This should be operated by at most the individual states. The location to connect to should be findable by a DNS name, such as "X.statetax.gov", where X is the state code or maybe even the zip code. Then just connect to an IP address given with HTTPS, send the request with the XML data giving the address info, and get XML back with the tax data. Vendors would be allowed to cache the data for 91 days.
Yes, I know about these. And when I find a city that does this, I plan to call them up and ask them what their tax rate is, telling them I'm putting their zip codes in "the tax collection database", and that if they refuse to tell me the numbers, I won't collect tax for them and will keep a recording of this phone call as proof that they didn't care to have me collect tax for them... just to harass them for making the world a mess.
I say that when any government jurisdiction wants to impose tax collection on ANY business OUTSIDE their jurisdiction, they MUST do so on a strictly simple basis... one percentage, with a list of product type code numbers for exemptions. If they don't want to work it that way, they should not be permitted to impose outside their boundaries. That's why I support a federal law (if someone will submit one) that sets up an interstate sales/use tax system and mandates that it be executed on a mandatory simplified basis. Jurisdictions not willing to join with that (and KISS) are then limited to collecting their use taxes directly from their own residents. To join, they must provide a rate percentage table per product class per zip code, with changes provided at least 3 months in advance of being in effect, with activation dates always on the 1st of a month, and direct deposit info for the clearing house to send the collected money each month.
What I think is essential to this is finding the happy median between NOT imposing high fixed burdens on smaller retailers, and keeping the TOTAL cost as low as possible. I could argue that the cost of collecting these taxes for the various governments should be deducted from the collected taxes themselves... on the basis that this is technically a "use tax" charged to the consumers themselves, and that the stores are merely providing a convenience to the governments to ensure that the tax is actually collected. E.g. this shouldn't be an unfunded mandate. But I know that won't fly. And if there was a central agency through which all web orders were processed to figure the tax, privacy concerns would emerge. So I'm looking for low cost, nearly proportional to sales, solutions, that add no new privacy issues.
The states with 0% tax rates don't need to support it. They don't need to participate.
As for having your address somewhere else to evade taxes... that doesn't change. You can still break the law. But my proposal doesn't put the burden of catching you at this on the mom and pop web store.
And how much will it cost a "mom and pop" web store to get these new tables every month? And for new address, how will the system deal with them between the time they come to exist, and when the monthly service adds them? How would you make sure that new addresses always work even if the table doesn't have them? And what about people that have stuff shipped to their PO box, PM box, or office address (a very legitimate thing to do)?
How is this database accessed? What software does it? How much does the Linux version cost? Where is the open source version? Shouldn't public data be free? I'm not worried about Amazon solving this. Instead, I'm worried about the cost for mom and pop. Will it be under $150 a year?
Yes, there is a real burden here. A "brick" store only has to deal with exactly ONE tax rate, which is the rate for their physical location. A chain of stores would only need to deal with this on a per-store basis. However, the web retailer is expected to charge tax based not on their own physical location, but rather, the location of the customer ordering the merchandise. This means keeping a database, and keeping it updated, for each and every single tax jurisdiction in the country. In many states this varies by individual city and town. There are thousands of these. In some cases they are even split across zip codes. And it's not just rates to worry about. Different jurisdictions have different exemptions of what products don't require a tax (food in one place, only perishable food in another, bath products might be included in another, school supplies exempted in a few, etc).
Then there is the issue of ensuring the taxes get paid to the proper government entity. That and making sure people are not subverting the system by sending packages to other locations.
Some solutions to this are possible.
I suggest that instead of the stores charging the tax, the credit/debit card processor charge the tax. The advantage of this is that they readily know the billing address of the account holder. Their payments to the government entities would be more in bulk, instead of these governments getting thousands of small payments from all the "mom and pop" web sites that would be compliant with tax law changes. The one change that would need to be made is each credit/debit charge would need to have split up according to product type classifications (a federal standard needed for that).
Another alternative is for a federal law that simply requires each of the states to submit ONE tax rate for the whole state, and accept a set of exemptions designated by that federal law, to be part of the inter-state tax program. One other requirement is, to be a part of it, they treat in-state web retailers exactly the same as out-of-state (e.g. all or nothing).
The burden on web retailers is NOT a myth. It is very real. Amazon can probably handle it. But you know the smaller retailers will be next, and eventually they will try to impose this on others. Taxes are essential, but it needs to be kept simple. Also, smaller retailers need to have a SINGLE (not 50) payment destinations (a central clearinghouse for this).
Tell them that your system has separate root passwords for each user, and you need access to the machine to get it to give it do them.
Seriously, you SHOULD be providing them with the information so they can help you. OTOH, if they lock you out to get the password, then you need to change provider IMMEDIATELY (and tell us who the scumbags are... written in a factual ways so you can defend if they sue for slander... which they might since thousands of Slashdotters already know you host with scumbags.
I set up separate root accounts, including one for my hosting provider to use. Yes, they can get in as root. The hardware is in their data center. In fact it is THEIR hardware, since it's a dedicated service rather than colocation. I take daily backups, so if there is ever an issue, I can switch providers without them holding my data hostage.
That's part of what makes this case potentially meaningless, in a moral sense, not a case law sense... the fact that there are deep pockets involved and it may well be decided not on merits, but on who can throw enough money at protecting their interest.
The TLD "com" is not a US domain. It is a world-wide top level domain. Aussies are just as eligible for it. And the actual site hosting is still in Australia:
traceroute to stephen-conroy.com (202.174.225.243), 30 hops max, 38 byte packets ... 16 ae-21-69.car1.SanJose2.Level3.net (4.68.18.11) 113.907 ms 122.092 ms 208.463 ms 17 PRIMUS-TELE.car1.SanJose2.Level3.net (4.59.0.58) 89.807 ms 91.116 ms 89.976 ms 18 p3-0.cr2-sjc2.primustel.com (209.227.128.202) 88.329 ms 87.974 ms 89.192 ms 19 p3-0.cr1-sjc2.primustel.com (209.227.128.137) 88.078 ms 88.084 ms 89.717 ms 20 209.227.129.242 (209.227.129.242) 537.434 ms 544.115 ms 545.142 ms 21 193.233-50-210.static.corp.mel.iprimus.net.au (210.50.233.193) 509.382 ms 489.600 ms 453.880 ms 22 ge1-1.sw02.mel.idc.iprimus.net.au (210.50.0.10) 426.940 ms 407.743 ms 385.031 ms 23 hyperlink.idc.iprimus.net.au (210.50.3.156) 362.932 ms 326.418 ms 296.706 ms ...
And the IP address is under this network:
inetnum: 202.174.224.0 - 202.174.255.255 netname: SWISH descr: Swish Group Ltd. descr: Corporate Data Centre descr: Melbourne country: AU admin-c: RH115-AP tech-c: MS93-AP mnt-by: APNIC-HM mnt-lower: MAINT-AU-SWISH changed: hostmaster@apnic.net 20000515 status: ALLOCATED PORTABLE changed: hm-changed@apnic.net 20030121 source: APNIC
You just ruined it for me by spilling the big secret. Now the prices for all those busted-screen laptops are going up. And I was working on building a super computer cluster of the bottoms.
With the right hardware present, the rest of this is all software. A fast-boot thin Linux on an SD card can run in 1GB... 4GB might be nice to help X do more caching. That should be doable right inside the monitor case these days (use COTS keyboard/mouse).
A better way would be for the FCC to require that cable companies provide a finite bit rate to each program source provider (charge more for more bits, or pay less if they demand more bits), and let that provider encode as desired. Over the air broadcasters would have to be carried at their full ATSC 19.39mbps bit rate (hence all subchannels and PSIP would be carried) even though cable can use QAM256 instead of 8VSB can get 2 such broadcasters in 6 MHz. Then national TV networks would be contracted at specific bit rates which they supply on their feeds. Then if History HD looks like crap, blame the History Channel people. Cable companies should not be doing the video compression at all, except for the local ad inserts where the contracts provide for that). Even then, a future STB can pre-download the ads and store inside on a flash/hard drive and overlay them into the framebuffer at ad-insert times, eliminating all need to do recompression. Where I live, Comcast is actually wasting their spectrum, not just with 50 or so analog channels still on the system, but every HD program is duplicated with an SD version in digital, even if it's also in analog. They need to let the STB do ALL the scaling down to the customer desired outputs (note that is plural... customers should be able to set more than one video format and when the program is in one the customer display can handle, no change is made at all).
Of course this all depends on the cable company understanding their own technology and doing things smart. That's pushing the envelope for most of them, like Comcast.
Slashdot Mirror
Be glad it wasn't fetching dates from upstream somewhere. But at least you now know these devices are designed to become obsolete sometime between now and 2016.
Someone obviously reverse engineered it. They saw 0x02 in 2002 and 0x03 in 2003 and assumed it was an 8-bit binary number of years since 2000. They should have read the specs instead to learn it was BCD (a leftover relic from the mainframe era that needed to die over a decade ago). OTOH, the spec designers should have use plain unsigned binary (which would have lasted until 2255 instead of 2099). Or better yet, don't even break up dates into bytes and nybbles; leave them encoded as number of nanoseconds since the epoch, times some scaling factor to fit less resolution in fewer bits as needed.
0x10 is 8 bits with the pattern value of 00010000. That's 16 when interpreted as binary. The BCD (binary coded decimal) puts DECIMAL values in each 4 bit nybble. So 10 is 00010000 and 99 is 10011001. The problem seems to be that the year is encoded as the last 2 digits in BCD, so it is encoding 2009 as 00001001 and 2010 as 00010000 and 2011 as 00010001. Interpreting this (incorrectly) as binary gives 9, 16, and 17 (adding 2000 ... or formatting as 2 digits and prepending "20" ... gives 2009, 2016, 2017).
Dumb programmers. Don't they have any real world experience?
Dumb formatting. Obviously a legacy thing from the mainframe era.
A 60 year old programmer would have known better.
Two digits is fine, now ... until we approach 2100. I plan to be retired by then, so I don't care. Fear those who are using ONE digit (that has happened). But in this case I can believe that someone used the wrong conversion like maybe: strtol(year_str,NULL,0x10).
I do have an ASUS EeePC netbook with a solid state flash drive. It has 16GB and runs at a nice 88 MB/s. The trouble is now, you can't find ANYTHING with an SSD, regardless of the size (of the SSD as long as it is at least 16GB, or the screen/etc). I guess everyone still wants spinning metal platters that can be damaged by some strong impacts. If I ever needed to replace this one, I couldn't as a new unit (have to go to EBay and hope someone will part with their precious baby).
The problem is these greedy capitalist solutions are not proportional to sales. While Mom and Pop can probably pay less than Jeff Bezos would have to pay, it certainly won't be at the same rate per dollar of sales. There will be some big fixed price component to this service, like a $10,000 up front access fee. To make this work, government needs to ensure that all retailers of all sizes have a properly proportional and affordable way to comply.
It shouldn't be web based. But HTTPS based might work. One complication might be privacy. But I could go for that. We just create an XML schema for the data exchange. Connect online, provide customer address info, get tax list back for all product classes (need a standard set of product classes), and dates of validity (if changes are within 91 days, the data must include the changes, too). This should be operated by at most the individual states. The location to connect to should be findable by a DNS name, such as "X.statetax.gov", where X is the state code or maybe even the zip code. Then just connect to an IP address given with HTTPS, send the request with the XML data giving the address info, and get XML back with the tax data. Vendors would be allowed to cache the data for 91 days.
Yes, I know about these. And when I find a city that does this, I plan to call them up and ask them what their tax rate is, telling them I'm putting their zip codes in "the tax collection database", and that if they refuse to tell me the numbers, I won't collect tax for them and will keep a recording of this phone call as proof that they didn't care to have me collect tax for them ... just to harass them for making the world a mess.
I say that when any government jurisdiction wants to impose tax collection on ANY business OUTSIDE their jurisdiction, they MUST do so on a strictly simple basis ... one percentage, with a list of product type code numbers for exemptions. If they don't want to work it that way, they should not be permitted to impose outside their boundaries. That's why I support a federal law (if someone will submit one) that sets up an interstate sales/use tax system and mandates that it be executed on a mandatory simplified basis. Jurisdictions not willing to join with that (and KISS) are then limited to collecting their use taxes directly from their own residents. To join, they must provide a rate percentage table per product class per zip code, with changes provided at least 3 months in advance of being in effect, with activation dates always on the 1st of a month, and direct deposit info for the clearing house to send the collected money each month.
What I think is essential to this is finding the happy median between NOT imposing high fixed burdens on smaller retailers, and keeping the TOTAL cost as low as possible. I could argue that the cost of collecting these taxes for the various governments should be deducted from the collected taxes themselves ... on the basis that this is technically a "use tax" charged to the consumers themselves, and that the stores are merely providing a convenience to the governments to ensure that the tax is actually collected. E.g. this shouldn't be an unfunded mandate. But I know that won't fly. And if there was a central agency through which all web orders were processed to figure the tax, privacy concerns would emerge. So I'm looking for low cost, nearly proportional to sales, solutions, that add no new privacy issues.
The states with 0% tax rates don't need to support it. They don't need to participate.
As for having your address somewhere else to evade taxes ... that doesn't change. You can still break the law. But my proposal doesn't put the burden of catching you at this on the mom and pop web store.
And how much will it cost a "mom and pop" web store to get these new tables every month? And for new address, how will the system deal with them between the time they come to exist, and when the monthly service adds them? How would you make sure that new addresses always work even if the table doesn't have them? And what about people that have stuff shipped to their PO box, PM box, or office address (a very legitimate thing to do)?
How is this database accessed? What software does it? How much does the Linux version cost? Where is the open source version? Shouldn't public data be free? I'm not worried about Amazon solving this. Instead, I'm worried about the cost for mom and pop. Will it be under $150 a year?
Yes, there is a real burden here. A "brick" store only has to deal with exactly ONE tax rate, which is the rate for their physical location. A chain of stores would only need to deal with this on a per-store basis. However, the web retailer is expected to charge tax based not on their own physical location, but rather, the location of the customer ordering the merchandise. This means keeping a database, and keeping it updated, for each and every single tax jurisdiction in the country. In many states this varies by individual city and town. There are thousands of these. In some cases they are even split across zip codes. And it's not just rates to worry about. Different jurisdictions have different exemptions of what products don't require a tax (food in one place, only perishable food in another, bath products might be included in another, school supplies exempted in a few, etc).
Then there is the issue of ensuring the taxes get paid to the proper government entity. That and making sure people are not subverting the system by sending packages to other locations.
Some solutions to this are possible.
I suggest that instead of the stores charging the tax, the credit/debit card processor charge the tax. The advantage of this is that they readily know the billing address of the account holder. Their payments to the government entities would be more in bulk, instead of these governments getting thousands of small payments from all the "mom and pop" web sites that would be compliant with tax law changes. The one change that would need to be made is each credit/debit charge would need to have split up according to product type classifications (a federal standard needed for that).
Another alternative is for a federal law that simply requires each of the states to submit ONE tax rate for the whole state, and accept a set of exemptions designated by that federal law, to be part of the inter-state tax program. One other requirement is, to be a part of it, they treat in-state web retailers exactly the same as out-of-state (e.g. all or nothing).
The burden on web retailers is NOT a myth. It is very real. Amazon can probably handle it. But you know the smaller retailers will be next, and eventually they will try to impose this on others. Taxes are essential, but it needs to be kept simple. Also, smaller retailers need to have a SINGLE (not 50) payment destinations (a central clearinghouse for this).
Tell them that your system has separate root passwords for each user, and you need access to the machine to get it to give it do them.
Seriously, you SHOULD be providing them with the information so they can help you. OTOH, if they lock you out to get the password, then you need to change provider IMMEDIATELY (and tell us who the scumbags are ... written in a factual ways so you can defend if they sue for slander ... which they might since thousands of Slashdotters already know you host with scumbags.
I set up separate root accounts, including one for my hosting provider to use. Yes, they can get in as root. The hardware is in their data center. In fact it is THEIR hardware, since it's a dedicated service rather than colocation. I take daily backups, so if there is ever an issue, I can switch providers without them holding my data hostage.
Would Verizon survive a mass stop pay? Or would they ask the government for a bailout?
... if we had let corporations create it. And it's what it will be like if we don't keep them in check with net neutrality.
... just to give the complete picture of this.
That's part of what makes this case potentially meaningless, in a moral sense, not a case law sense ... the fact that there are deep pockets involved and it may well be decided not on merits, but on who can throw enough money at protecting their interest.
The TLD "com" is not a US domain. It is a world-wide top level domain. Aussies are just as eligible for it. And the actual site hosting is still in Australia:
And the IP address is under this network:
... the domain name being registered was stephen-conroy-facist.com.au or stephen-conroy-destroys-freedom.com.au or something like that.
You just ruined it for me by spilling the big secret. Now the prices for all those busted-screen laptops are going up. And I was working on building a super computer cluster of the bottoms.
With the right hardware present, the rest of this is all software. A fast-boot thin Linux on an SD card can run in 1GB ... 4GB might be nice to help X do more caching. That should be doable right inside the monitor case these days (use COTS keyboard/mouse).
Isn't the point to keep the cost of a thin client really thin?
So someone forgot to turn on the percentage number compression.
A better way would be for the FCC to require that cable companies provide a finite bit rate to each program source provider (charge more for more bits, or pay less if they demand more bits), and let that provider encode as desired. Over the air broadcasters would have to be carried at their full ATSC 19.39mbps bit rate (hence all subchannels and PSIP would be carried) even though cable can use QAM256 instead of 8VSB can get 2 such broadcasters in 6 MHz. Then national TV networks would be contracted at specific bit rates which they supply on their feeds. Then if History HD looks like crap, blame the History Channel people. Cable companies should not be doing the video compression at all, except for the local ad inserts where the contracts provide for that). Even then, a future STB can pre-download the ads and store inside on a flash/hard drive and overlay them into the framebuffer at ad-insert times, eliminating all need to do recompression. Where I live, Comcast is actually wasting their spectrum, not just with 50 or so analog channels still on the system, but every HD program is duplicated with an SD version in digital, even if it's also in analog. They need to let the STB do ALL the scaling down to the customer desired outputs (note that is plural ... customers should be able to set more than one video format and when the program is in one the customer display can handle, no change is made at all).
Of course this all depends on the cable company understanding their own technology and doing things smart. That's pushing the envelope for most of them, like Comcast.
So you don't believe in using government force to deal with theft?