Fun fact: The IRS Economic Impact Payment (EIP) site for non-filers is run by Intuit. [0]
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.
So this worked for me, but I hadn't tried since a couple weeks ago (maybe the all-caps thing was fixed by yesterday?). What's funny is that the subsequent step (verifying tax info) had a couple of other old-school slightly bad practices:
- 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)
An old college friend of mine from 30+ years ago used to write his SSN on every college book he bought. He also used an engraver to etch his SSN into every tool he owned. The SSN was't all that important back then. I can't say when it became something of potential value.
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.
Maybe this is a silly question, but exactly what was the risk? If knowing a random SSN is problematic then it's not exactly hard to just generate a couple yourself.
I used to work for a credit bureau, and a lender once asked us to build an application that could pull credit files based on SSN only. (Pulling a credit file normally requires multiple identifiers.) Fortunately, someone foresaw the very problem that you mentioned, and we declined to build it.
> cant say when it became something of value
As soon as banks started allowing SSNs themselves instead of requiring an SSN card for establishing lines of credit.
One day I will find the security consultant who keeps going around companies and telling them that letting me paste content is insecure. On many platforms I use a password like "Fart123!!" because I can't paste "$3f4[FEsz$%643we]]SFv" from my password manager.
Firefox's "Don't Fuck with Paste" extension is a lifesaver. It disables all the event handlers on the page and the input that prevent pasting. Kind of a sledgehammer but when you're pasting someone's 26-digit account number, I mean.. you don't want to copy that by hand.
Plus I use Bitwarden, which auto-fills the boxes so I don't need to paste passwords at least.
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.
I recently had a broken phone screen and had to find a password entry workaround. On iOS pasting in fields that show the iOS keyboard seems to always be enabled, but rotation of the keyboard in landscape mode is disabled on some password entry fields for some reason. A quick workaround is the notes app for a quick copy paste and the calculator app for numbers if needed, although I wish there was a way to toggle comma separation in the iOS calculator.
Ya, anytime a site uses a contenteditable element, they usually need to listen for paste content and do things like stripping html tags and whatnot. Basically any wysywig style editor like a Facebook post.
Please don't ever post your passwords, even in jest. The web is filled with crawlers that scrape passwords and add them to vast password dictionaries to be used in cracking.
You can fire up developer tools and paste into the value attribute. This will work on an old-school form, but i have no idea what it will do to client-side JavaScript!
You can paste in the value and then change the value to something wrong and to the right thing back again. This will make sure that the required events will fire.
Here's another input filtering bad practice that most US front-end devs don't seem to know about (but really should when they build global websites)
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.
I didn't know that about the French keyboard. The Japanese keyboard is mostly a mess because they have to shove a bunch of extra characters into the same physical space, but the one thing I miss is that they have @ as an unshifted character. It's very convenient for that. I'd gladly trade away unshifted ` for unshifted @.
Every time I encounter a site that disables pasting something, I just disable JavaScript, paste it, and then re-enable. Obviously not a solution for non-technical users, though.
In fall of 2000 when I started college, we used to have SSN numbers publicly listed as student ids :). I never thought much of it back then. Good old days when you didn't have to worry about being identity hacked.
In America, it is very easy for corporations to put the blame for their bad security practices onto consumers and for consumers to just shrug and accept the blame.
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.
It's an artifact of the unregulated credit system. Credit reporting agencies starting using SSN as an identifier for consumers, thus it gets pasted everywhere. Back before the financial crisis, there was little to no oversight. If someone got your SSN and some basic info, they could open up credit accounts in your name very easily. Most upstanding places like Banks would require some form of ID. But what about the cashier at K-Mart when you were filling out an in-store credit application? They were much less caring. Same with used car dealers, and tons of other places.
Basically, many institutions have horrifically poor standards for verification and will accept nothing (or not much) more than an SSN. SSNs were never meant to be a secret.
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.
What was the purpose of using your SSNs as ID rather than names? Very interesting I didn’t realize scientists wore uniforms with names/ids across the back like baseball or hockey players.
Names aren't necessarily unique. It's not hard to imagine a large enough organization having multiple John Smiths on staff, for instance.
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.
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"
I think that field can be used for other box purposes. "PO Boxes" are exclusively offered by the USPS, but there are private providers that provide a "PMB" mailbox, which depending on the situation may just a number. I think military post office may use that field as well.
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.
For USPS, they need to use OCR to read the address off the mail. In general, uppercase is more legible and avoids some issues (lowercase L vs uppercase I)
> So I bet there is some internal API that searches or something for an address with all caps.
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?
Been checking everyday without success. I haven't gotten a refund in several years, so I knew from the FAQ they would not have direct deposit info, even though they pulled the money I owed out using the same bank info.
Tried all uppercase for my street address and it worked.
For what it is worth, errors are being hammered out. The first few times I received "unspecified error" then tried it again one day and it worked like a charm.
"Firefox detected a potential security threat and did not continue to archive.md. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details."
What bothers me is that they provide a single line to enter your information instead of the same form they have on your tax return.
For 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.
I tried a 100 times but then used the shortened version of north and drive (ie N and Dr). And it worked. Shame on me for using the address spelled out on a letter from the IRS.
I accept that I have a number of beliefs that are considered heretical to other programmers. = Should be for testing equality, not assignment. Null should equal null in SQL. Whitespace is a bad delimiter.
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.
I agree (with pedantic caveats not worth mentioning) with everything you've listed, unless you're using the regex view of what whitespace is and think the \t character is a bad delimiter, well then, that's where I draw the line.
To be fair, the 95K (imaginary, I know, but let's just roll with that) is not for paying you to write those four lines, but rather to pay you for your investment in knowing that you only have to write those four lines.
Same as the restaurant bill is not equal+margin to what they spend on food, it's also everything else like rent, salaries + margin.
Or rather, the 95K also includes the formal verification testing for the boatload of downstream systems that get the data.
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.
I was trying almost every day including yesterday, did this and it worked. If it is required to be all caps it'd be nice if the site said so... I guess maybe they just finally loaded my data.
could this be because it bypasses a cached response? does it work if one just changes capitalization of any character? (i have no deal with the IRS so cant test myself)
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...