This is a low-priority issue and not really a problem per se. I am just curious about how it works and why one thing does not seem to work. I am trying to figure out what is different with this one thing and why they appears differently than the other things.
Had to test on my own and noticed that when I tap on the url bar to modify the url, all of those emojis appear URL encoded. It seems that the browser fails to show those codes as an emoji when it comes to certain ones.
Thanks for helping me to check. It may depend on which web browser you’re using and what platform you’re on. On my Windows 10 laptop using Vivaldi browser (Chrome based) some of the emoji appear in the URL. The only 2 that show as encoded values are the “Locked” and “Unlock” emoji. I have to do some more testing on different browsers / platforms.
Thanks for checking. I just find it strange that some of them appear in the URL on my browser but not others. It must makes me curious what the difference is. Usually things either work one way or they don’t. But, having it work sometimes makes troubleshooting harder. This is the way the URL’s appear on Windows 10 using Vivaldi browser (Chrome based):
This is how the “Locked” / “Unlocked” emoji appear in the same browser:
Now I also found out with Firefox that the key emoji will show encoded as well (only on it though, not on Chromium-based browsers)!
Emojis are basically Unicode characters, and some Unicode characters might get URL-encoded by the browser when it reads the URL. That’s why @HELPINDIA was getting the URL encoded result in his URL bar.
I appreciate everyone taking a look. It definitely seems to be a browser issue. The server probably handles them all as unicode but, different browsers display the output differently. This was just a test I was doing to see how the server would handle emoji folders. I don’t really plan to do anything serious with this. I was just scratching my head trying to figure out what was different.
This seems to be a browser related “issue” to me. Although I wouldn’t be surprised if this was by design, seeing how you’re specifically having this issue with padlock emoji.
Many people have been taught to “look for the lock in the address bar to know the website is secure”.
So then some scammer publishes their page on http://🔒accounts.google.example.com or something like that, and someone less well versed sees “ah, there is a lock, so it must be safe!”, even though the connection is insecure.
There have been phishing attacks with special non-latin characters that makes things appear differently. Like someone setting up apple.com, but then the a was not the letter A, but some Greek (I think) character that looks like an a but is actually a different unicode character. So I fully understand that browser makers are cautious with unicode handling.
Is https really necessary to determine how safe a website is nowadays? The point of SSL is to encrypt the handled data between a client and the server in order to prevent problems such as data being read by MITM.
A scammer/phisher could set it up easily and make the website use https considering how easy it is to get an SSL certificate nowadays.
Speaking of unicode issues, here is an interesting example:
Nowadays, you’re right. But 10+ years ago, it was generally considered that HTTPS was only accessible to “trustworthy” sites.
Maybe it was a bad example on my end. But having the padlock in the URL itself could still be used to make people believe the connection is secure when it actually isn’t.
With modern browsers typically showing non-HTTPS sites with a red, broken padlock it should still be pretty obvious. But why run the risk of confusing people.
That makes a lot of sense and explains the behavior. I just randomly picked emoji and never thought about that aspect. I was thinking about developing a game. Thanks for the input.
one simple explaination is that these emojis can be used to impersonate ssl [which is basically lock symbols] and maybe hence they aren’t implemented intentionally as emojis in browsers url bar
