Having trouble with the IRS site? Try all caps
latimes.com
latimes.com
You gotta love those who lobby against simplifying tax processes and harvest data on behalf of the IRS. And, I'm absolutely convinced Intuit will treat that sensitive data with the utmost respect and would never, ever resell a list of people who haven't filed taxes in a couple of years in order to discriminate against them in loan applications, leases, and purchases.
0. https://www.freefilefillableforms.com/static/privacy_stateme...
- Blocking copy-paste of my bank account information
- Input value for income can't contain commas or a dollar sign
- Obscuring input field of SSN as if it were a password (I suppose this might not seem wrong to some folks, but technically SSN isn't a password and most other sites I've used don't treat it like a password)
Sadly he passes many years ago. His wife called me in desperation. She needed to get rid of and donate a bunch of tools and hardware filling their garage. However, everything had his SSN on it, I mean, he had an amazing collection of Snap-on tools with his SSN engraved on everything, down to the screwdrivers.
She trust me implicitly. We took everything out of their garage and donated it to our local high school's robotics club. The caveat was: The kids had to help me grind off the SSN from every single tool they got. That was an interesting week.
SSN for deceased people is published broadly in various forms.
Plus I use Bitwarden, which auto-fills the boxes so I don't need to paste passwords at least.
If you’re writing a little JS snippet to “fix” this, https://gist.github.com/nuxero/6dda1287ccfb91999e9f8c42d7246... or https://gist.github.com/SukkaW/26dc57f3bf3d7f17a89763dcd9f7d... might also help.
It should be possible to add this to iOS using the Shortcuts app. https://support.apple.com/en-us/guide/shortcuts/apd218e2187d... Though... I’m not entirely sure you can block pasting in Safari on iOS. I can’t say I’ve noticed it there, perhaps the native keyboard password manager integration avoids it.
What harmful thing can an attacker do with it that doesn't require further identity verification?
Is this an urban legend?
So, for example, "I" had "my identity" "stolen" according to Verizon.
In reality, some criminals learned facts about me and then Verizon happily let them run up thousands of dollars in phone charges in a two month period. (I assume this is part of a larger scam where a 900 number pockets the charges?) This had nothing to do with me, but Verizon then polluted my credit history by falsely reporting the unpaid charges as being mine. So even though there were clearly two parties at fault—the criminals for the fraud and Verizon for not verifying the ID of the person getting the phone line and then falsely harming my credit reputation—I, an uninvolved third party, was made to do the legwork of cleaning up the mess. It's really scandalous that we allow this, but the PR of "identity theft" has been quite good at brainwashing the public.
The summary is that the USA does not have an official national person identity number. The SSN is the closest approximation, so it is being (ab)used as one. This is despite that it is explicitly not designed for it and has some qualities which make it less suitable (the numbers are small and very predictable).
In general, nearly every national-identity-system suffers from a contradiction between assigning identities and identifying. Where the number you get assigned is simultaneously your identity and a secret you use to establish your identity. There are initiatives to solve this using cryptography, but this is complicated by political attitudes towards privacy and government tracking. I dare say in the USA this is more pronounced due to both the problem and the political attitude against solutions being more pronounced.
As personnel management became more sophisticated and formalized, a unique identifier was needed that was guaranteed to refer to one and only one person. And since SSNs already existed and were guaranteed unique, most of them just used those rather than inventing a unique identifier of their own.
Yeah.... about that: https://www.cio.com/article/3004596/a-tale-of-two-women-same...
Don't assume a specific keyboard layout when you're trying to filter out non-numeric values in a text field
I use a French keyboard, and numbers on the top keyboard row are accessed with Shift. A unmodified keypress in this row is for various accented characters, quotes, parentheses and a few others. In other words, it's the opposite of a US/UK keyboard.
Almost every week I come across a website (including a large US stock broker) whose numeric fields seem to block out modifier keys. I have to switch my Macbook to US layout just to type those in (because conveniently, they also disable pasting in those fields of course)
This is very widespread (is that part of a popular front-end framework maybe ?) and difficult to report, because most devs in English-speaking countries never experience the issue first-hand.
So I bet there is some internal API that searches or something for an address with all caps.
In the address form, there is a field for PO Box. It is labeled "PO Box". One would assume you should type your PO Box number in this field, e.g. "1234". That is incorrect. You must enter the entire string "PO Box 1234". In a field that is already labeled "PO Box"
It's been a long time since I've had to look at it, but there is a Postal Addressing Standards document that covers all of the various use cases. It actually gets pretty interesting when you need to get a letter delivered to a customer mailbox at a UPS store in an area with rural mail delivery.
Rather than something searching with all caps, isn't it more likely that the query/search is case-sensitive, and the data just happens to be stored/retrieved with all caps?
Lowercase is acceptable, but it must meet their guidelines for OCR readability. https://pe.usps.com/text/pub28/28c2_002.htm
Tried all uppercase for my street address and it worked.
curl https://www.latimes.com/business/story/2020-04-27/irs-website-hack-coronavirus-stimulus-checks-all-caps?_amp=true|sed -n 's/.*<title>/<title>/;/footersubscribe/d;/<h1/,/<\/h1>/p;/<title>/p;/<blockquote/p;/<p>/p' > 1.htm
firefox ./1.htmFor probably good reasons they won't tell you if your input information is valid, if you intentionally put in a bad address it will tell you "payment status unavailable."
It's annoying because I don't know if my issues are because of my tax status or my input information. A form would help with that. Particularly because my street has ambiguous naming and I don't know if it's what the street sign says, what the USPS prefers, or what is written on my tax return.
But my most heretical belief is that the only thing that should be case-sensitive is passwords. Any system that is case-sensitive by default will eventually break your heart about it in the stupidest possible way.
Case-insensitivity by default everywhere will be a pain.
Deep down somewhere there is a LIKE 'EML STREET%'. Making it case insensitive will kill the performance because the index cant be used.
It could almost be a 2-liner Javascript (gasp!), 1 to import jQuery (more gasps!) and 1 to run all inputs through toUpperCase()...
The bill will be 95K, thanks!
Same as the restaurant bill is not equal+margin to what they spend on food, it's also everything else like rent, salaries + margin.
That is usually what makes cost in government projects explode as they are an utterly wild mix-and-match of code and hardware that is from the earliest era of mainframes 60 years ago to stuff that has been made in the last half year. Alone testing for encoding issues can take weeks... because most testing has to be done and verified manually.
Also noticed the page is running Google Analytics. Might that be a privacy issue?
It really wouldn't surprise me.