Effected Keyboard 2 feels convenient when you press the keys with its gentle feedback (if you disabled heavy animations), it feels more mature and natural with its look and feel, has multiple languages, easy gestures that trigger useful features: if you swipe left from spacebar you have two different layouts of symbols, on swipe right from spacebar you change language and on swipe up from spacebar you get a mini popup keyboard where you can find undo/redo, select text and copy/paste with a clipboard. Sounds familiar?
Effected Keyboard 2 is based on Anysoftkeyboard and has been developed on top of it since 2013(!) It has some paid features, even though to be honest I really tried to not be greedy with them. There are 3 packs, $5 each - basic one with themes and simple effects as you type, flying letters one - which pops flying letters from the keyboard to the app itself and the immersive effects which blow the minds of your friends when you show it them.
Effected Keyboard 2 is an app for Android, even though with its tiny touches such as the round corners (which are everywhere) it reminds me an Apple product.
Comparing to Anysoftkeyboard, Effected Keyboard 2 has a new set of Emoji which look more stylish. It has additional themes. And its function keys are more of Gboard styles, with an option to wider spacebar or a bit shorter one in favor of additional punctuation keys in the button row.
Effected Keyboard 2 might not replace your keyboard completely since it doesn’t have the AI typing predictability and AI level of spelling correction. But! And that’s an important “but” — this keyboard is all about a different experience and just like a trip to Eurodisney where you would like to stay for a couple of nights, but not to live there forever, then same here with this keyboard. It deserves any bit of attention it’d get from you.
https://youtube.com/shorts/lj-jIrZ6XZ8
https://play.google.com/store/apps/details?id=com.vitali.pom...
Foreseeing a probability of such circumstances to happen I filed a patent on an idea I had.
The issue that almost any website has is the ability to be proxied by a Man in The Middle. Means by that is that if I (Haim/Vital) now copy exactly a website, put it on my server and forward the same user actions from my site to the original site, then once the user is logged in, since it’s done via the hacker’s machine in the middle, then the attacker can keep using the victim’s session as technically it’s simply possible.
In my patent I do not let a MiTM attack a room to happen. How? Simply. Each request and response are treated like JWT! The only difference is that both parties both sign and validate the JWT. And the additional shared secret which is required by design is shared via a 3rd communication channel, via email. So that even if user’s credentials are stolen, the shared key still won’t let the attacker to fake a request.
It was a great journey. My patent herby goes to trash since there are non Saas solution which are utilized to defend against phishing. And I am about to start a new journey where I begin to build a secure web portal which tells its users how to build a secure web portal with their own users!
The attack I mentioned allows to present a login page using a proxy of any webpage on a non webpage’s domain. Which in turn allows either a session hijacking or credentials sniffing.
My patent suggested transferring a secret token to the user’s email box in order to create a third channel of communication whereas the attacker so or so does not have an access to the user’s email box. Nor to the 3rd Saas security service that secures the communication between the client and the attacked host with that token.
What I’ve seen that is being used instead is splitting the login into username and ON ANOTHER page password, which is defended by CORS - since once username is entered and the Next button is clicked, there is a CORS issue which arises because the fake login page is being served on the fake domain which does not have the permission to go on with the cross origin request to the next page after entering the username where password is required.
Say bank.com has SSL. Cool! Now how does Angular work? You visit angular-site.com/some/path and backend server rewrites the request to angular-site.com/index.html. You still see angular-site.com/some/path. And it works and that's how Angular servers that serve Angular apps work.
Now, what prevents bank-malicious-url.com from acting like a viewer, where it access bank.com when you visit it hence the SSL encryption/decryption is made between it and the legit bank.com, whilst malicious-bank.com url has a simple letsencrypt certificate that is showing you a not so legit green secured URL web address on the top of your web browser?
Please help! I abandoned my patent, I've been building my Angular web app and now I think that the old me was not so dumb after all. Where to proceed from now?
While striving to find and provide a straight route path for assured security on the websites, I have come up with a Context Design Pattern for CSRF Tokens, which is very simple but might be not what you think or not what you are used to.
In the traditional approach, to defend against foreign links that target i.e. deleting your users’ profiles while clicking a link, we know that CSRF Tokens is the answer. But what happens when the links are on your website, e.g. in the HTML formatted posts or comments section?
Well, I suggested the following to Chat GPT and the machine has fallen for it!
Think of csurf lib’s cookie being sent with the string “posts-cookie-token” while in the posts or comments section along with a CSRF Tokens. The cookie is a session identifier and the CSRF must be provided along with the cookie. In order to not allow actions such as user deletion from the comments section, there is a different cookie-csrf-token pair(s) for the user profile section. Means that CSRF Token for user deletion will never resolve for the comments section.
Are there any node developers in here at those hours? Security fans? What do you think gang? I’m up to writing a security manual for the novice web developers and selling it for some cash online. WDYT?
The traditional solution is validating such action by prompting with a required confirmation i.e Are you sure you want to delete the account? Or entering some text such as "delete" or the user's name.
I have a suggestion for a framework that utilizes contexts, which will defend sensitive actions more broadly and I would like to bring it up here.
What I suggest is to have context on every website section, such as comments and user's profile, so that when a logged in user is in the comments section they are only able to utilize front end's comment context. From the comments context the profile context will be invisible and the comments context is the only one that will be able to talk with the comments endpoint on the server.
Problem is solved? WDYT?
In this video I talk about signmeonly.io pre-launch.
https://youtu.be/8EjVz4wEFFo
Well signmeonly intends to solve just that. With a secret that is send via email and stored in the local browser storage which is not sent anywhere, yet accessible by the website you develop, signmeonly uses the secret to encrypt a random string every time your client talks to your website.
Want to hear more? Leave your message in the comments and we - are eager to tell you everything you need.