I'm familiar with how it feels to be at the wrong end of a dispute like this, but I think it's important to tell you that it would strengthen your case if you had shared more information about your attempts to contact them. Did you call? Or initiate a chat? How did it end up resolving? The thread you have only confirms the beginning of the problem, not the middle or the end.
EDIT: my motivation here is to tell you honestly what would strengthen your case. There is no upside for me in this conversation. I'm not affiliated with namecheap or any other registrar, and am merely offering my perspective: as a happy customer, I can be moved by other people's bad experiences, but they must be well documented. If you don't like hearing that, then ignore it.
A simple mechanical touch device, with some kind of electromagnetic actuator.
I read about people who put a mobile phone in a fixed cradle, so that when the phone receives a call and vibrates, a band of steel attached to the cradle and with a bulb of conductive rubber on the other end locks into resonance and eventually hits a USB security token.
> The real story here is Twitter's lack of spear-phishing training for their support staff, not support employees have access to support tools.
Spear-phishing by its very definition is a highly targeted attack. I wouldn't count on any level of training to prevent someone from getting phished. Given some of the spear phishing campaigns I've seen, I wouldn't trust even myself not to fall for them.
It's a problem that needs to be solved with technical solutions like hardware U2F, locked-down customer support devices (e.g. Chrome enterprise policy managed ChromeOS devices), and special account VIP/anomaly locking and auto-escalation.
FWIW, this is actually quantifiable. We contract with a firm that tests employees' response to spear phishing about once a quarter with varying degrees of "difficulty". Part of an overall scheme that also identifies people who blindly click on things for, uh, further email education.
I'd love to know if you have any data to show if that "further email education" makes any difference in future behaviour...
The cynic in me reckons "Hell no! Those sorts of people are way too often _proud_ of their zero-thought blind clicking and lack of understanding of how things work"...
It's very easy to avoid being spear phished: do not trust any unsolicited message over any medium. Email/text/phone message/popup window purporting to be from your registrar with an urgent call to action? Ignore said call and contact them directly via known good number, email address, URL, etc.
EDIT: Voice mimicry scam? Verify via known channel before taking action.
The question isn't how you and I can individually avoid being spear phished, but what policies can be implemented across an organization to prevent it. Even the most trusted security teams aren't going to be allowed to summarily fire everyone who fails the test.
I also think this is a much stricter standard than you're recognizing. In my company's last spearphishing test, they sent out a link purporting to be a company survey immediately after an all-hands meeting announcing there'd be a survey (the real survey link came a few hours later). Expecting that nobody will be distracted enough to fall for such a thing seems unrealistic no matter how well you train them.
Just wondering if employees failed the test just by clicking on the link or if they had to actually enter some passwords or confidential information on the fake survey site. I wouldn't think clicking a link then looking at the address bar and seeing the domain name is wrong, then closing the page would be a problem, would it?
We got judged on both. Most security teams in my experience feel that even clicking on the link is a big risk, although I've never read a more detailed explanation of why than "oh there might be a 0-day".
The corporate security team sent out the email. It had a link with no actual content, giving an error, but that got you on the list of people with bad security behavior.
The trouble at my office was that most employees were highly capable security researchers. These are people who reverse engineer malware for pay and for fun. Of course they eagerly attempted to download from the link! They wanted fresh new malware. People would typically download via wget in a virtual machine on a PC without important data.
How would this work? I get emails like "you have been added to <link> gerrit review" and "<link> Redmine issue was updated" several time a day and I need to open these links.
Maybe on individual level but on organisation level it's one of the biggest current attack vectors.
And there is no magic bullet. Trying to educate people gives some results, but mostly just prevents low effort phishing attack.
I have never seen pentest that include social engineering fail. (This might be just our customers. I would expect govt or infrastructure organization to be better)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome]
"ExtensionSettings"="{\"*\":{\"runtime_blocked_hosts\":[\"*://ycombinator.com\",\"*://boh.com\"]}}"
Tested in a new Windows 10 x64 (2004) VM with a new install of Google Chrome 81.
Thank you - it must be me. Had the same issue in a macOS 10.12 VM with Chrome 81. Here's a screen recording of the issue in the Windows 10 x64 (2004) VM: https://tinyapps.neocities.org/cg.mp4 . Tried reloading policies in chrome://policy and waiting 15 seconds as well, but there was no change.
I've played with it fairly extensively in a brand new Windows 10 VM, trying various permutations, but still cannot get it to work as intended. superasn's suggestion[0] to set site access permissions via Preferences > Extensions > Details (for the extension in question) > "Site access" worked a treat for me.
Correct me if I'm wrong but wouldn't I still have to take the time to wrap everything in the codebase? I feel like that's the majority of the painful work.
Developers with large code bases have complained that it takes weeks to manually wrap all their strings. We have an experimental tool for ReactJS which can wrap all the front facing strings with our function instantly. It's currently in beta but we recently used it to onboard a codebase with over 1000 strings in half an hour. We're also looking to build this auto-wrapping service for other frameworks.
Ping me at abhi@langapi.co if you want a demo of this beta tool or if you want it for another framework.
Yep, I can no longer see my Cloud SQL database - it's as if I've never created one at all. Really hoping this is just an issue displaying it and that Google hasn't punted my infrastructure and backups.
Reports claim that it's a network congestion issue primarily in the northeast United States. It seems doubtful that any data has been lost, but you probably can't see resources due to requests not getting through. I hope that hearing this helps you to feel better.
This is a networking issue, and your data is safe. Cloud SQL stores instance metadata regionally, so it shares a failure domain with the data it describes. When the region is down or inaccessible, instances are missing from the list results, but that doesn't say anything about the instance availability from within region.
Wow, these comments make me sad - this is pretty clearly satire (although the vulnerability is real and pretty scary). Did the "DynoRoot!!!1111" really not give this away? :)
Is IPv6 big enough to not recycle IPs in the modern high-churn deployment world? (It's probably big enough to give every human (or payment card holding customer) a few million blocks of IPs that they can personally control, and recycle IPs within each accountable block that)
For IPv6, clearly yes, at least so far. It's pretty typical to get at least a /64 aka LAN with a VPS. That's 18 x 10^18 addresses. ISP customers typically get a /56 (256 LANs) or a /48 (65536 LANs).
This is my bad, I could've made it work for Firefox but was just testing if it was vulnerable at all. I don't really wanna pay the ether to fix it since I don't actually want to exploit anyone :)
