Only 8? Those are rookie numbers
Only 8? Those are rookie numbers
That’s… why we want the labels?
Looks like lots of people’s year end bonuses were contingent on them releasing something related to AI by the end of the year.
JavaScript is a language that runs on a user’s computer, when they visit a web page. It is often used for dynamic functionality, ie when you click “like” on a comment… JavaScript running in your web browser will make a request to the server letting it know that you liked the post, then the server will respond with a total number of people who liked it or something.
But, the server needs to know how to authenticate which user liked the comment (so you can’t like it twice etc). There are various authentication mechanisms to do this, with their own trade-offs. Over all, there’s secret information that the browser and the server have to share with each other, and we don’t want that information being accessed by the wrong people.
There’s also a common problem with web apps called “cross site scripting”. Basically somebody might craft a cleverly formatted comment that exploits a bug in the web page and causes the attacker’s code to run. One trivial example might be if every time a person read a comment thread, the attackers code caused that person to “like” a request. A more serious exploit would be one that finds out that secret authentication information I mentioned and shares it with the attacker. They can then pose as the victim user and do anything they want as that person. This would be bad.
So, on to the different approaches and their tradeoffs.
Anyhow, one common solution here is to set very short expiration dates on those bearer tokens. That way if somebody steals it, they can’t use it for long.
Another strategy is to limit what each token can do. OP needs to make it so you can like a comment using one of those bearer tokens, but more dangerous actions like purchasing things, deleting content, etc, should be guarded by a more secure mechanism. Then the damage is mitigated if the bearer token leaks.
I use a “real name” domain. My last name ends in the letters “in”, so I bought a .in
domain, such that the domain name is my last name with a dot in it.
Can’t honestly recommend that approach. It’s a cute gimmick, but when non-technical people ask for your email address and it doesn’t end in a TLD they recognize, their heads explode. I usually give out my gmail address.
Is it the employer’s responsibility to determine that somebody is or is not a spy? Like the scam here was to do the actual job and send money back, not to steal company information etc. companies have legal obligations to make sure people are authorized to work in the US etc, but the government sets those standards. If you’ve got convincing enough paperwork, it’s the governments job to enforce this stuff, not the employer.
That said, I’ve interviewed several remote people who were clearly using fake identities and also clearly didn’t have the skills for the job. Seems obvious their scam was to just collect a paycheck doing nothing, so if that’s the same group, then the employers bear some fault for hiring unqualified people… but on the other hand if the North Koreans were actually doing the jobs they were paid for, no reason the company should care.
If that’s a 16oz glass of ranch dressing, and you’re planning on drinking what’s left, I’m all for this
Congratulations on your transition. Hope you get some new photos taken soon.
console.log
counts as “a debugger”, right?
It doesn’t matter what browser you’re using. Everything Google was tracking here is the stuff all browsers send in incognito mode. This lawsuit was totally frivolous