You have a point, but as a musician and programmer, I'm far more fond of AI generating things of a "no wrong answers" nature than things that are ostensibly correct.
Music does have certain notions of correctness (e.g., [0]) but with a very forgiving "know the rules, then break the rules" aspect. Code has bugs or it doesn't, and it's probably easier to debug human-written code (certainly easier to grok every line of a human-written PR, IMHO).
The real problem is with the domains that aren't at the far ends of this spectrum.
It also puts a throbbing highlight (for a few seconds) on whichever channel is associated with the notification whose gear icon you used as a shortcut into the channel list. At least for Pixel phones.
I find it to be a poor default that sensitive data is shown on the lock screen. I change that setting as a first order of business whenever I'm setting up a new phone.
If someone texts me something that's not interesting to those MITMs but is sensitive to mom catching a glance while my phone is on the table, that's a problem this toggle creates/destroys. Threat models vary.
I recently got an unsolicited OTP email from Microsoft, which led me to fear that someone had entered my password, but no: I eventually was able to confirm that the arrival of an OTP does not, in fact, require that someone enter anything beyond my email address. This is rather insane (I should not be having a blood pressure event due to Microsoft) but on the other hand I do understand the passwordless concept which is just a password-reset flow sans password-change. Perhaps a nice middle ground would be if the OTP email explicitly stated that my password was not entered.
This also happened to me about a week ago and I had the same reaction/discovery process you did. OT but I wonder if there was a recent ramp up in these attacks. It was done against an email I do not regularly use that was attached to my account as an alternate and haveibeenpwned confirmed was in a data breach back in 2020.
I had been thinking someone with a similar address made a typo. But now I'm thinking Microsoft already considers this a known incident depending on whether a bazillion attempts were made in a detectable manner. I hope a successful launch at least demands a botnet and random delays/backoff.
Some providers (looking at you, Intuit) don't seem to understand TWO factor authentication and will allow someone to bypass your password if they can intercept the SMS or email, and treat it as a normal login.
4. Someone says "take the password reset flow, trigger it automatically when a user tries to log in and has only given their email, hide the password field during login, and after the email is validated drop the user back to their previous journey instead of having them set a new password"
5. You see #4 as #3 failing, but when #3 was never applied it's not quite that. Aside: making #3 mandatory would be smart.
It's Intuit's normal login flow. Enter username and it then says enter password or click here and we'll text/e-mail you a code. Ironically, if you use a password it will often text you a 2FA code.
Knowing what numbers are real through an official publication is very good, but it only allows you to place trust in calls you make, not calls you receive, because making calls doesn't involve caller ID, receiving calls does, and caller ID is spoofable.
Ask them their name/ last initial, employee ID or unique identifier for the conversation, direct phone number, job title and what location they're based at. Scammers will pretty much always refuse/argue/hang up on this (once I had one start insulting my mother in Hindi when I asked him this). Then call your bank's proper number and verify all of these details.
(But in any case your bank will never call outwards to you, unless you've specifically requested that, which you almost never do.)
Unfortunately my UK banks (and others) DO regularly make calls to me unannounced and demand my ID to 'prove who I am'. They are not scam calls and the callers cannot understand what they are doing wrong. If I'd had more strength in the last round of this stupidity I'd have done a number on them with the regulator. (I used to work in finance and was the director of a regulated financial entity, so I think I'd have a head start.)
In the US Caller ID has been so hopelessly compromised (for almost two decades now, that's on Congress) that financial institutions almost never make outbound calls, and only ever use standardized published numbers; I wasn't aware other countries differ so much.
Please tell us more context with regard to your UK banks making multiple unannounced calls demanding your ID ... were you an individual customer? finance director? MD? or what? Why on earth do they do that? Have you told them in writing not to? There must be more backstory to that.
Banking example: trying to move some savings from one UK bank to another - back to where the money had originally come from, and that had just purchased the first bank too. It took 8h on the phone over a week or so to get the money back, which was interspersed with a comedic number of calls from withheld numbers and people unknown to me demanding enough info to get access to my money. And other very poor practice. The bank even conceeded at least once in writing that it knew that it was screwing up and sent me £100 by way of apology - but carried right on screwing up.
Non-banking: getting a call out of the blue from my Internet Service Provider again demanding enough credentials to get access to my (business) account, and unable to understand why that was very poor practice. I used to like that ISP a lot, and have been with it for a looooooong time, but the angry exchange with who seems to have been my account manager has soured the relationship a lot.
Happy note: just had a sensible interaction with my bank where it called me back but the caller understood why NOT to ask data that could be used to access my account, and we managed to resolve the issue that I was having (which, I think, was my error)!
My bank (big green French one) pretty much always calls me whenever I do some unusual money transfer, even between my company and my personal accounts (they're both with the same bank), even though the transfers are authenticated either via the app or by an SMS code. However, the people calling me don't ask any details, just "is this vladvasiliu? Is it actually you who initiated this transfer, for x amount on y date?".
What are they, then? Sales/marketing calls? Or some security notifications ("we noticed some suspicious operations in the last 3 days...")? If it's the former, that's still scam in my books. Specifically, it's a first-party scam, as opposed to a third-party scam, where some third party pretends to be your bank.
They both should be treated similarly; unfortunately, you can't report first-party scams to police.
In my experience they're security calls. UK has good opt out marketing rules for legit companies.
But the usual security call is exactly like a spam call, no authentication from their end, immediately requesting id verification "answer these security questions", and refusing to go off script.
People have been asking for years to be able to lodge a security challenge code on their profile that can add confidence in the caller. Given there are already multiple security questions on an account, this could be a process change: the security challenge script becomes "the first and sixteenth characters of your mother's maiden name are 7 and F, what are the third and fifth characters of your first pets name".
In the UK, banks like Starling, Monzo and Revolut (and building societies such as Nationwide) have added a call status feature in their apps [0][1][2] that tells you if they are actually the ones calling.
Yeah, this is a no brainer (and I think most banks let you verify via the app rather than personal info) to avoid the annoying uncertainty (but note my mother would not be able to handle that I expect)
No "challenge code" your profile can be used to authenticate a caller. Profiles get leaked, almost all of them have been at some point, or at least that's the safe assumption to operate under.
Yeah as sibling points out, lots of orgs have scammy official security calls. This leads to a dance I have been through quite often.
<phone rings, I pick up> Hello
Them: Am I speaking to Sean Hunter
Me: Yes
Them: This is <rubbish bank who should know better>. Can you confirm your <date of birth/full address with postcode>
Me: Yes
Them: Err, … sorry I didn’t quite catch that.
Me: Yes.
Them: <thoroughly confused>I asked whether you can confirm your <date of birth/full address with postcode>
Me: Yes. I can.
Them: err… I can’t talk to you without you passing security.
Me: You called me.
Them: I’m sorry…?
Me: You called me. You wanting to talk to me about something is your problem.
Them: I need you to pass security before I can talk to you.
Me: OK, well. Have a nice day. <hang up>
Almost this exact thing has happened multiple times with one of my bank accounts which I can’t completely shut because of boring reasons but I have basically deprecated because they do this sort of nonsense. My main bank now is much better.
One of my banks refused to talk to me over the phone and informed me to go to a branch with 2 pieces of ID. Fair, it was a credit card opened online.
Only to find the 2 pieces of ID were just for them to talk to me and ask for more documents. Rubbish like employment letters (uhhhh, how about YOU call my employer instead of me printing out the “letter” they’ll email me?) or tax return stuff mid-year.
I cut up the credit card and mailed the pieces to their legal department. Someone called me pretty quick and without any authentication hassles.
That’s wild.
If my bank needs something from me they send an email saying that a message is available in the online portal - or in some cases they send me a physical letter.
Anything else would be highly suspicious
I generally say at some point before terminating the call "you should not train your customers to give out account access credentials to strangers" and the caller usually has no clue what I mean. Does no one in the security teams have theory of mind?
This will be the way I bring up the issue with the regulator if I do. I can think of many ways round this issue that would be much safer and not especially arduous.
A few of the bank people that I spoke to during the last caper were pretty senior and those did understand the issue that I raised but found themselves constrained by their rules, though one or two got creative with me in a good way. (Pretty much none of those who called me were 'minimum wage' in my estimation.) But very more senior management should be setting good scripts and expectations for the less-well-paid staff doing the grunt work. That is what their higher pay should be buying, IMHO.
I dream of a time I don’t have a bank, or not in any traditional sense.
I’d been hunting for ways to use a Wisecard standoff a bank but got a bit wary of what would happen if they went bust. Government backed guarantee do not exist for Wise.
I ask them for all of that and their credit card details, mothers maiden name, name of their first pet, first school they went to, and what colour underwear they’re wearing.
I should probably learn how to insult their mother in Hindi too.
Or, which has worked great for me; just never answer the phone. If people need something they will email or chat. If not then it is not going to be important.
This. If people have a "real" reason to correspond with you they will have no problem making a record of it via a voicemail or text or email or whatever.
I've had friends that got into a spot of bother and tried calling from an unknown number. If it's a phone you can't text from, then leaving a voice mail with voice transcription is about the only way I'll know it's a friendly call
Nowadays, when banks call you here, they allow you to verify the bank is actually calling you with the mobile app - you can see their name and number they're calling you from in the app. Also, you can often verify you're you with the app too, same as any other app authorization, so you don't have to share any details over the phone. I feel like this is a pretty good improvement.
That does seem better than blind trust but that app infrastructure could get compromised. I would still be wary in any situation where I did not originate the call with the bank.
Ye, I only get called by banks when my transaction gets classified as potentially fraudulent (which pretty much just means that it is for a bigger amount of money) or some other even more rare situations like finishing a loan application. Still, I'd rather be double sure that it is the bank that's calling me because I don't want to assume solely based on the convenient timing.
If the app infrastructure is compromised, the bank is liable so it feels like less of a problem. If the app does offer authorizing through the app, I shouldn't be asked any personal details that my bank already knows so I (hopefully) would still be wary, if put in such a situation though. Obviously hard to know what I'd actually do unless it actually happens to me.
We have an app called bankid. If my bank calls me they'll ask me to open the app to auth, the app shows that the specific bank initiated auth and also says that they called me.
Same app is used to auth to government pages and all kinds of stuff online, even purchases.
That would take nothing to implement. Services like Truecaller already do live caller ID against databases on iOS / Android. All it would take is a sensible register of verified numbers
Won't stop people from trying to make Truecaller, et al. prove that, though.
The problem here is that the correct security posture of the bank against third-party scams also protects the customers from first-party scams. Telling people the bank will never call them for anything, and even if, they're to always hang up and call the number on the back of their card, works equally well against criminals and telemarketers.
I feel like this is kind-of a solved problem in the jurisdictions where banks are liable for customer losses not arising from gross negligence.
If a bank calls their customers directly and trains them to get phished, the bank does not get to claim gross negligence when this happens and has to refund the customer.
If a bank tells their customers that they'll never call them (and actually doesn't), they have much better chances of claiming gross negligence on the part of the customer.
The tricky bit is that while it's impossible to deprive someone of their idea (i.e., commit theft of an idea), it's possible to steal someone's idea (i.e., copy it and use it illicitly), because only the word theft, but not the word steal, has that "deprive others" stipulation.
So with that in mind, circling back to whether possession occurs in such a way to make possessive language appropriate (being able to say "my data" after stealing data but not depriving the author of the data), my opinion is that the copy of the data that the author still controls is the author's data, and the copy of the data that the stealer controls is the stealer's data. It's the author's idea, but both parties separately possess the data (the data is a record of the idea).
Taking someone else's car illicitly is theft, because theft means taking with intent to deprive the rightful owner of it. Copying can never be theft, only moving can be theft, because only moving it could deprive the rightful owner of it. An illicit copy is merely copyright infringement or a breach of contract or various other concepts that are not theft despite people sometimes using that word as shorthand. It's YOUR illicit copy, not the rightful owner's illicit copy.
I didn't "steal" your passwords, I just "copied" them. I don't know what you're getting so upset about, you still have your list of passwords, and the fact that my changing all your accounts' passwords rendered that list worthless did nothing to move it.
If someone steals my passwords and then does nothing with them, or just uses them for their private purposes, then there's no problem. The problems only occur if my passwords are used to take control of my accounts or identity, which would deprive me of my accounts or money etc. So your example actually reinforces that the relevant ethical distinction (the harm) is indeed in intending to deprive someone of something they possess/control
I don't think this is the case legally, it might depend on the facts, but usually passwords are stored on your systems, and an attacker would have to not only access your system, but to exfiltrate that data.
It would constitute computer fraud and abuse by most definitions. This is relevant because it is sufficient to prove someone has your passwords in order to convict them, you don't need to prove they used them maliciously. (Provided of course they are a third party with no legitimate reason to have your passwords)
Stealing has a much looser definition than theft; notably, it can include ideas unlike theft. You deprived me of my accounts, but not of my now-obsolete passwords, therefore it's a theft of my accounts, but not theft of my now-obsolete passwords; I suppose you stole both. I'd be upset despite lack of password theft because I'd be the victim of your CFAA violation for example.
> theft means taking with intent to deprive the rightful owner of it.
That doesn't sound right my man. If I take your car and return it so you never knew it was taken, wouldn't it still be theft?
What if my intent isn't to sabotage you but to enjoy the car for myself and your deprivation is merely collateral damage, not my intent, is that not theft?
The problem is that it requires not only that the ticketed people (scalpers, show-goers) do something new to prevent scalping, but also that the ticketing people (ticketmaster, etc.) do something new to prevent scalping.
We need a solution that demands only the former, not the latter, because the ticketing people have no incentive to eliminate scalping. It's good for them.
It gets a little confusing because situations like TFA make it seem like the ticketers want to help, and while they might be interested in the goodwill of ensuring that some of the tickets sold go to known actual fans first, they definitely aren't interested in losing the "collect a fee multiple times" aspect of maximizing resale which includes zero-trust transactions.
TUI stands for "Text User Interface" not "Terminal User Interface" considering that the point of TUI vs GUI is to distinguish text mode from graphical mode. The word "terminal" isn't really meant to imply text even if quite a few terminal emulators are, indeed, text mode; rather it typically means that the UI is drawn by some other machine than the one you're touching. For example, a very popular Windows Server feature formerly named "Terminal Services" is for GUI terminals, not TUI terminals. A likely source of confusion is the MacOS app named Terminal, which only becomes a terminal in the real sense of the word once you decide to let some other machine draw your UI (ssh, telnet, rlogin, etc.).
> it typically means that the UI is drawn by some other machine than the one you're touching
I guess you're conflating thin-client terminal in the networking sense vs vt100 hardware terminal lineage (where "terminal" comes from here), but it means a text mode interface that runs in the terminal emulator and uses, say, ansi escape sequences.
Rather, when you see TUI, it just means the app runs in one of your kitty panes.
Btw, your "Terminal Services" example doesn't show that "terminal" implies remote drawing. It shows Microsoft extended the word to cover remote GUI sessions, which is a later, broader usage.
> Btw, your "Terminal Services" example doesn't show that "terminal" implies remote drawing. It shows Microsoft extended the word to cover remote GUI sessions, which is a later, broader usage.
They didn't. It implies remote drawing and that has at least occasionally included arbitrary graphics. See plan 9 for example.
> I guess you're conflating thin-client terminal in the networking sense vs vt100 hardware terminal lineage
Yes, I didn't really think to separate the two. While my examples of ssh/telnet/rlogin are all of the networking variety, I didn't mean to exclude RS-232 (which the VT100 used). Regardless of whether the wire is for serial or packet data, if you're at a terminal (including any of the thin/dumb/smart varieties), you're not at the box doing the heavy lifting because that's on the other end of a wire representing an important demarcation, a demarcation that doesn't really apply to a local app running a text-mode user interface (or if the mental gymnastics are performed that does introduce such demarcation even within a local app -- think backend vs frontend -- then all local apps are terminals).
Historically, “TUI” referred to “Text User Interface”, but language evolves and “Terminal User Interface” has been common usage in terminal-app/tooling communities for at least the last decade (probably more).
The distinction we (Ratatui) draw is that the rendering surface is a terminal: historically sometimes a physical hardware terminal (someone got Ratatui running on a Minitel a while back), more commonly today a terminal emulator/PTY environment.
That framing also better captures the kinds of constraints and capabilities Ratatui apps actually deal with: terminal escape sequences, cell-based rendering, alternate screen buffers, mouse handling, resize behavior, scrollback interaction, etc.
In addition, these apps don't only do text only these days as modern terminals support various graphics protocols (Sixel, Kitty, iTerm graphics) and other extensions that can allow for weird and wonderful things that are not just text.
Thanks! As I think about terminals in quite different contexts (credit card terminal, battery terminal, train terminal, etc.) I'm realizing that it's really just any kind of endpoint at all, so pretty much any human interface device (HID) should probably be called a terminal. But when taken to that level, using the acronym TUI (in the "terminal" sense) to mean "not a GUI/CLI" (as if big old consoles or emulators/PTYs thereof are the only type of terminals) seems questionable.
Sixels are far from modern :) They were introduced in the VT240 (special purpose version of the 220) and became mainstream on DEC terminals with the 320.
On the other hand, there are many elements in the user interface that are not text. In fact, I think it would be quite understandable if one even separated REPLs like bash or octave to be "text user interfaces" while applications that make use of character placement and border special characters "terminal user interfaces", because they use means beyond text stream to communicate with the user. One might even render straight up graphics to a terminal [emulator application].
Even X had a separate application called xterm 42 years ago: the complete X system was not to my knowledge called a terminal system, except perhaps when discussing the dedicated client devices, such as VT1300. Also the term "virtual terminal" as far as I know has always referred to a the kind of interface this application is making use of.
So I think we can just accept that the term is overloaded such that "terminal" refers to both of these situations, as there is no historical precedent to have it exclude the other situation, and the term "terminal-based application" is completely clear to a rational listener.
Try running plain sh / ash interactively without readline, and notice how much pain it is.
But I agree that having multiple windows, etc is a whole new step; it's just a limited GUI accessible easily via SSH. Could involve sixel graphics as well.
Virtual terminal is surprisingly capable, it even has word delete feature! And shells have some nice history features which I'm sure would become even more familiar if one had to use them (as I suppose was the case a long time ago), such as !$ that expands to the last argument of previous entry.
I would argue that a local only session with terminal.app is still a real terminal session because the app is just a terminal for the connection to the MacOS version of getty. In principle, this is not different from having a serial cable between the host and an old-style terminal or encapsulating that connection over a different network like with SSH and telnet etc.
macOS also call their log viewer "Console" for what I'm sure are obvious reasons to some, but seemingly confuses every beginner developer at least initially, while "console" is what many have come to understand "Text-like entry system to run computer commands".
Unix has a dedicated console concept which is the system output. This is more likely to be the hardware console (and maybe synonyms). I think there’s a lot of steps to get to a log viewer named console, though.
Very much agree - "Text User Interface" is also a much clearer descriptor for non-technical users to understand. Normal people have an immediate idea of 'text' but not of that 'strange nerdy terminal thing' - and that's important because often times a good 'Text User Interface' is all that even regular people need !
(plus custom theme customize-able & much less work for the devs to build & maintain, and way less dependencies)
reply