Not that it matters because the admins at this site don't seem to care!

I’m glad you found my posts hilarious. Laughter is the best medicine, so they say.

There are much simpler explanations, that resorting to an argument that it is due to hacking is ludicrous. 

They could make a stupid comedy out of you😂👍

You’re a great example of this 🤪

Sorry, autocorrect, “Botvinnickfan720” was intended to be “idiot” 

Your claims are ludicrous.

No, it does no such thing. But believe what you want to

I feel like this should have been locked already.

As a professional web developer, I can confirm, that if you want to really cheat with time or pieces manipulation, you would need to access their backend somehow, what is very unlikely... (I do believe, that chess.com architecture is good enough, and no such manipulations can be done through API). If one wants to cheat, much easier way is to use computer analysis during the game. And also it's just absurd to cheat other way (with time and pieces manipulations), because it is too easy to spot this and ban the cheater... So such effort will be all for nothing. It's very likely, that you just have poor Internet connection. Because in my experience, in this case you will have the delay and your local clock will not be synced with clock on chess.com end correctly.

It's kind of funny you're insulting other people's intelligence and you used the wrong word. The irony.

+1,

Many people don't know that  there are three clocks independently running with their own count down timers.

It is crazy, isn't it!!

1. Your clock 

2. Opponent Clock

3. Server Clock

Server clock is the boss who correct your GUI timer and your opponent GUI timer.

Let us say, your clock display 1 min remaining when you make a move but the message was delayed to the server for 5 secs. ( e.g hang due to flash , java script).

You will see 1:00 in your time and 0:55 seconds in opponent time.

But the server get 0:55 in your time and 1:00 in opponent time.

Once the server synchronized, you get 0:55 seconds and your opponent get 1:00.

You lost 10 seconds.

This is a problem that we all face nowadays even outside of chess.

It has been more than adequately established that your understanding of the subject matter is quite insufficient.

What is the foundation that your doubts and fiercly defended arguments are based on?

Why do you believe that assembling your own anecdotal evidence and personal experiences is enough to form an opinion?

How do you hope to acquire knowledge and progress when your utterly obstinate behavior denies you that opportunity at every turn?

People with this type of hyper ignorant and aggressive attitude are very quick to dismiss the information relayed by those who are more qualified and will continue to remain stagnant in their foolish ways until the point of no return. 

You are displaying a very typical pattern that has been observed time and time again.

You are right about the server side hacking, but the two bolded statements above are just pure BS when put together.  The fact that clock manipulation would be very difficult in no way means that cheating via engine use only can occur at longer time controls. 

I do notice you said you majored in comp sci and IP law, not that you have any degrees...how far did you get?

Have you ever installed a chess engine and run it at the command line, sans UI?  If you have, then you fully realize that chess UIs and engines are usually completely decoupled, and with your vast coding knowledge you would then be able to dope out that writing a new UI for an engine that can play moves for you (i.e. a bot) is not hard at all...right?  If you have ever front-ended any command line utility with any simple windowed UI, you're already most of the way there.  Heck, if you have even passed SQL queries to a backend by hand rather than using some bloated API layer, you're most of the way there.  If you can actually parse out a result set, you're overqualified .

There's no hacking of "closed source code" on the chess.com servers required to cheat using an engine at bullet and blitz time controls.  I do suspect you are well aware of this, actually, but that's another thread.

That's incorrect, because every move that is registered and linked by the app's UI is relayed to the server and authenticated via some kind of verification protocol to prevent such silly ideas. And in order to bypass that one must manipulate the closed source code, directly.

You don't get it.  There's no server verification/authentication involved at all.  It can all take place before anything is sent anywhere by the browser.  From the browser's perspective (and ergo the server-side's severely limited perspective), it cannot distinguish where input is coming from.  How exactly are you planning to "authenticate" whether a desktop mouse movement and click is "unassisted" by software or not without full access to the client's OS (and/or drivers, because you can burrow under the OS and manipulate keyboard and mouse input directly)?  You have to detect the behavior after the fact.

You can control your own app, or your own client software, but you can't do anything about desktops running browsers.  

You don't have to take my word for it...you can watch videos of bots playing bullet online.  Again, though, I suspect you are already aware of this phenom.

No, you don't get it.

Once a move is made, that information is captured by the appropriate listener and immediately transmitted to the server. The reason why one couldn't interfere with that information before it is relayed is because those packets are either encrypted or already carry the unique verification sequence which will allow the server to authenticate. One would have to bypass the verification process itself, merely intercepting UI data is insufficient. 

OMG.

Read your own statement:  "once a move is made".  Horse already out of the stable.  You are only authenticating the end result. not how the result is produced.  The listener doesn't know and cannot prove how the move was made.

You are speaking as if a listener didn't have half a dozen layers underneath it and was some absolute arbiter of end-to-end mouse activity from the physical mouse, cord, and motherboard and all the way logically through the driver, the OS, and then passed to the browser...the listener has no visibility on *any* of that.  The listener knows there was a mouseclick reported by the browser, and where the click was.

Yes, but the input data it generates is useless because it does not carry the verification sequence or isn't appropriately encrypted with the correct key.

You are always so quick to jump to conclusions, while lacking the most basic knowledge to even interpret the information given to you.😒