An argument for using a VPN even when completely innocent in all one’s online activities.
The above is a variation on the homograph attack. Imagine how bad it would get if applications generally evolve in the direction of allowing any Unicode characters in a username.
Spot the difference between
this__that
and
this＿that
On my screen (and font) the former has ‘an underscore’ that is slightly thicker.
But this merely scratches the surface of the mischief that users could get up to - and I see a fair few of them in spammers’ attempts to slip spam past the spam filter.
When the first step goes wrong, bad results follow.
Once they’ve made the initial mistake, no amount of careful work on all the rest of the case is going to recover from the mistake.
I think the initial mistake happened in the US. So it’s already more global than just Canada.
Edit: And, yes, there seems to have been something of a failure that noone really took any notice of the fact that there was no corroborating evidence at all (other than that the person arrested did have an account on that platform). Too much faith was placed in the evidence from the destination device.
With such a low bar for the prosecution to jump over, you wonder what evidence from the suspect’s house could possibly have been exculpatory. (For the general person, I guess if the person didn’t own or have access to a phone or a computer, that might have been enough. But given that the guy did have an account on the platform, he obviously must have access to some device.)
This is kind of an issue. But the reason why i often copy Strings after marking and paste them into a text file and wrote the same by hand in the text file. Open it with some hex Editor and compare the stored data.
This is a well known attack. Like using some other font or char from some different language which look alike.
But to add some other issues. Some Hackers or Bots try to steal the right to send messages and fake something like an old conversation to steal attention and trust in the same way. Because many Mail Clients filter them into the post conversation or looked alike like the rusted before one. To hijack some old trusted relationship in to some new malware delivered link or conversation…
Just my 2 Cents and thanks for sharing irvinewade.
There are countries where that means that users cannot have their actual name as the username. Users can mess around with transliteration but …
Sometimes it is considered just too risky and problematic to extend from ASCII to (e.g. UTF-8 encoded) Unicode. An example of this is with the IDN (Internationalized domain name) functionality where Punycode is used to encode Unicode that is not pure ASCII as ASCII (while ensuring that existing pure ASCII domain names are not encoded, and ensuring that any pure ASCII domain name that was previously valid remains valid as far as is possible).
So can I have a username in /etc/{passwd,shadow} that is not pure ASCII? It’s not something that I have looked into.
Hypothetical scenario: You know that you are going to use a platform for illegal activities. So you survey who are registered users of the platform and how active they are. (If that information is only available to logged in users then you create a temporary, throwaway account to login and do the survey.) Then you create your account by using a subtle variation on the chosen victim account.
So was it coincidence and a shared love of “Skyrim”? or was it malicious and intentional?
If the former, you can imagine trying to sign up and it says “sorry, that username already in use” and then you think “I’ll just add an underscore so that it is not a duplicate”.
You raise a good point/. I assumed it was something like that especially since I almost never get my preferred name for new accounts the past 15 years, but your scenario is certainly possible. I’m curious whether the actual perp sent a picture of himself.
Well, um, I assume that we are only talking about bodyparts that were insufficient to identify the perp - otherwise surely the case would have fallen over almost immediately???
OK, I understand that in the era of generative AI, even if an image included a face, the face might not be real. But in the absence of both generative AI and digital mischief, I assume that the perp’s face was
not in frame
cropped out
black rectangled out or otherwise obscured
The article says only
man had been sharing sexually explicit images online with a 12-year-old female
Does not make clear the direction in which sharing went. Could be both. Could be one-way only.
but it requires non-default options when creating the account (so unclear whether it would work at all when creating the first account automatically during first-boot)
and there are some additional restrictions anyway but they mostly apply to funny ASCII characters not to Unicode characters that are not ASCII characters (for example trying to put a colon character in your username will break very quickly).
However there is more to this overall issue. It is my guess that most “platforms” when they allow user creation are not creating real users on the underlying operating system but rather just users at the application level (just some application database somewhere).
So for illustrative purposes, I went looking to see what restrictions the Discourse forum software applies to usernames. Answer: A certain version of Discourse introduced the functionality where you can have non-ASCII usernames but this is not on by default (and it does apply some restrictions by configuration or by default as to what non-ASCII characters are permitted).
As I noted above, I18N requirements simply don’t allow global platforms to restrict to ASCII only. Not forever anyway. It is only a matter of time.
So my guess would be that if law enforcement can’t even handle a doubled underscore, things are going to get a lot more difficult for them and so they need to lift their game / improve their procedures.
I guess you could always use a non-typical ASCII character in your login name, to be unique and to make it difficult for investigators to enter-in to their system when investigating you. The idea would not be to confuse the investigators, only to make it difficult for anyone, including the investigators, to even enter your user name in to their respective keyboards.
For example, if you enter [CTRL]-[ALT] 248 in to your keyboard, you’ll get a small circle (the degree symbol) in the text output. That is because the ASCII number for the degree symbol is 248. So look up an ASCII table on the internet. Pick one or more a-typical symbols there that you want to use from that table, as a part of your login name. Pick one or more characters there that do not appear on any keyboard. Write down the character’s ASCII number from that table. Then every time you enter that user name in to your login name fields, use the [CTRL]-[ALT] (followed by the ASCII number), to reproduce that unusual character when you login. Not only does that make it more difficult for others to recreate your login name, even the investigators might have to consult with their IT department, just to find out how to enter your login name in to other systems. The average person will see the unusual character and not have a clue how you produce that symbol using a keyboard. But you may have difficulty using that character on your phone.
I guess that’s a different approach. I feel though that if they are motivated enough, they will just keep entering in until they don’t get an error. Whereas the approach implied by me (may not be true!) relating to the article in the OP is that confusion (a valid username of someone else) will actually stop them trying.
Aside …
I doubt it. I think that is
a) Windows only, and
b) from the IBM-PC (DOS) Code Page 437 character set.
Unfortunately Linux is wildly inconsistent in how you actually enter various non-ASCII characters.
For the specific example character that you mention:
ctrl-shift-u b0 space OR
compose oo (where you have to have defined a compose key).
For web-based platforms, a more dastardly approach might be to rely on any irreversible transformations that occur when the web front end converts the true username to its display format, presuming that such transformations occur.
For example, let’s say that the web front end is expecting printable ASCII only for the username but the back end allows any valid UTF-8 for the username. For safety reasons, the web front end strips anything out that is not printable ASCII i.e. throws away anything unexpected. Or maybe the front end strips trailing (or also leading) whitespace from the username. In that case, it will be impossible to enter in what was seen in the web client and then get the correct username. (Of course this could be considered to be a bug in the application as a whole and also may only be a temporary situation during the phase in of Unicode usernames.)