Well, given that Github today doesn't seem to support meaningful 2FA (only TOTP and SMS), wouldn't it be good to fix that issue before starting to talk about requirements like these?
Maybe it's just my account, but I can't currently enroll my hardware token with Github in any way whatsoever.
Sure, they offer some 1.5FA, but why would I bother with that?
They let you enroll a hardware token after you enable either a TOTP or SMS 2FA method. No idea why, seems to defeat the point of the additional security that a hardware token offers.
Authenticator apps, and SMS help them derive you have identity -- which is more secure for them and you. Hardware token via WebAuthn (etc) is only more secure for you.
When they say "for the sake of security" they mean for them too.
There's a reason they want you to verify using one of the first two methods first.
> Authenticator apps, and SMS help them derive you have identity
How do they do that?
TOTP (i.e. authenticator apps) is a simple algorithm where the value is derived from a secret key and current time. It certainly doesn't verify anything about you.
Yet, if you go into the "enable 2FA" settings on Github, you only get the option to enable insecure TOTP or SMS.
Apparently, once you do that, you might be able to add proper authentication. But no word on whether that then replaces the obsolete methods you were forced to configure earlier.
But, yes, right on track to enforce 2FA in 2023, I see...
Just technically it makes no sense. WebAuthn is a great technology that addresses many privacy concerns, but once they had an excuse collecting phone numbers they don't want to stop. Even though it's not the most secure method. Google, and many others are the same way.
2FA is often used as an excuse to obtain more PII from people, and to verify your identity, as a whole. Most businesses want to match logins to individuals, not roles. And that's what 2FA provides them.
Since about the moment that teams all over the world discovered they could just paste the enrollment QR code (a.k.a. private key) into their wikis, and thereby continue unlimited sharing of their role accounts?
Oh, that's lovely UX... "After you configure 2FA, using a time-based one-time password (TOTP) mobile app, or via text message, you can add a security key"
So, after you enable a broken-by-design 1.5FA method, which you don't want, and which will further expose you to account takeovers, you can, possibly configure actual security.
No wonder these guys are raking in the big bucks...
The TOTP "private key" can be easily cloned. Targeted malware, a database compromise at your app provider that you "securely" sync your settings to, or just a few minutes access to your "authentication" device, will do the trick.
> or just a few minutes access to your “authentication” device
Oh, come on. Your “hardware” “authentication” “key” can be stolen in mere seconds by someone with physical access. Clearly, we should dispense with that fake bullshit 2FA and require face-to-face verification. Drive to the GitHub office and let them run a DNA test to confirm your identity, or GTFO, amirite?
There is no sync to provider servers on any TOTP implementation I use. Nor does a TOTP implementation need to be an application on a phone. Are you perhaps referring to the Google Authenticator or the Microsoft Authenticator apps when you refer to TOTP?
Manufacturers that sell the "meaningful" 2FA hardware tokens can manufacture and sell duplicate keys, they even provide this as a service when you want backup keys. What makes you think they don't "securely" make a few duplicates themselves?
> Are you perhaps referring to the Google Authenticator or the Microsoft Authenticator apps when you refer to TOTP
No, I'm referring to the actual RFC 6283 TOTP protocol. Which uses a trivially-cloned single private key. Which is, see the example above, in fact trivially cloned 'for convenience' by at least one widely-used 'enterprise' security solution.
> What makes you think they don't "securely" make a few duplicates themselves?
Since that literally makes no sense if you know how hardware tokens work.
@john_cogs: Are there any plans to connect a self-assessment of mental state to the assignment of issues/pings about mentions/incident-response pages in the GitLab app?
So, on "I'm on top of the world" days, I get assigned All The Issues, get a full-screen popup about each mention, and will be asked to be incident lead on just about anything.
Then, if my state is "slightly hungover", I mostly get a list of the most pressing issues still pending, without being overloaded with new stuff.
And finally, the "hugging my teddy bear" state: no additional automated workloads, respectful notifications to anyone pinging me, and a note to my manager if it lasts more than a few days?
Yes, we have a Yerbo+Gitlab/Github integration coming. At the beginning it will be to identify and prevent mental wellbeing anti-patterns and then we'll move forward into this direction you mentioned.
Feel free to reach me out to marcos at yerbo dot co if you want to expand your use case!
Short-and-easy read that contains much truth. Especially item #10, "Lead by example" which encourages managerial review of recurring meetings (which often boil down to "well, here is my Excel sheet, you tell me how you're doing on each line item: I'll let you talk a lot, but I'll only jot down the completion percentage in the end") is worth emphasizing.
Well, the race to attract the outflow of the current Russian 'brain drain' is definitely on.
If the US is able to attract the majority of that (as it most likely will), while keeping out the Putin-aligned plants and/or otherwise mentally deficient factions (which remains to be seen), that will definitely be huge gain for them.
If the US is able to attract the majority of that (as it most likely will)
That remains to be seen. There is a huge undercurrent of Russophobia, and potential takers will have observed the FBI-led harassment of Chinese scientists (not too long ago a Tennessee jury refused to convict a Chinese national on account of the threadbare evidence), already these factors would make anyone coming from an enemy country hesitant. Combine that with funding and employment issues in the physical and life sciences - anyone young and ambitious would be well advised to settle in China instead.
In the workplaces that Russian scientists and engineers will go in western countries, like software/pharma/bio/academia/etc, it's highly unlikely there will be virtually any ethnic hate. I've never once seen it in the places I've worked; we are all quite accustomed to diverse colleagues and most of us celebrate that.
I personally wouldn't count on China, an ethno-nationalist country that does not offer a pathway for naturalization for people who are not Chinese-passing, to provide a safe place for me or my family to reside. Not to mention the enormous scale of abuse of power the current Chinese government is engaging in.
Where? The highly skilled Russians part of the brain drain will most likely go to big cities, full of high earning and/or well educated people, not in hick towns full of xenofobic loonies.
Russians brain drain to the US is not something new, but has been going on for several decades and it seems to have worked fine for them.
You don't seem to be up to date on current events. The Russiaphobes are the well educated (but not necessarily high earning) people in big cities. It's the hip new thing to proudly broadcast your support for heroic Ukrainians and your disdain for evil nazi Russians.
This is totally opposite to my experience. I’m Russian living in bay area and people often ask how my family back at home. I never had even a slight negativity towards me based on nationality.
Meanwhile, no source required for "hick towns full of xenofobic [sic] loonies".
Anyway, take a look at reddit, which is full of highly-educated baristas from large American cities. A common sentiment is that the "average Russian citizen" should be out protesting, and that if they aren't, then they support the evil nazi leadership.
> observed the FBI-led harassment of Chinese scientists
give me a break - chinese students with USA sponsorship write reports back to their sponsors, and some of them do grab data and code, by the thousands.. I have seen it on networks and I believe in person at University.. one line about alleged harassment is equivalent to nothing without that context
Reports from Chinese graduate students to their sponsors - of course they would report to their funding agency, any funding agency will insist on progress reports. There's no need to elevate that to some sort of conspiracy straight of Our Man in Havana, complete with atomic vacuum cleaners.
Or at least some cosmopolitain eastern locality such as Dubai; the one which would naturally meet the 'unprecedented invasion of an independent nation' accusations with a lot of laughs.
Having said that, I can imagine that there would be (already is a) proxy brain drain from Russia to Dubai but catering to the Western customers.
Dubai is a stationary Potemkin village. There is nothing there for technical people to do outside of ill-conceived construction projects for princelings.
My employer is based in Warsaw, Poland with offices in Ukraine, Russia, and many other countries. A day or two after the invasion they sent a company wide email saying they will pay for and coordinate moving, transit, housing, food, etc for anyone and their family in Russia, Ukraine, or the surrounding countries. About a week later they shut down operations in Russia. Though not confirmed we were told a not insignificant portion of Russian employees fled to Poland and still work my employer.
I doubt this occurred at very many places, but anecdotally Poland gained a meaningful number of highly skilled tech workers. I haven't worked with any of the Russians, but many of my Polish counterparts hold the belief that the US is largely responsible for the invasion of Ukraine. I will be very interested to see immigration numbers of where Russians end up.
It also has to do with keeping that brainpower from going to other potential problem nations. There is a reason the US basically paid former Soviet rocket and nuclear engineers after the fall of the USSR.
America doesn't need political purity tests, let them all come. If the concern is espionage, that's the FBI's concern to worry about. If the concern is them sending money back to Russia, simply forbid that. If the concern is their influence on American politics.. well that's a non-issue because native born Americans sympathetic to Putin far outnumber all the PhDs in Russia. And besides, American society can and should be able to tolerate dissent. A small number of wackos are outnumbered by reasonable people and aren't a realistic threat to the system.
People will not emigrate if it means leaving relatives and family behind. That's why you saw so little emigration from the USSR - once they're out they were completely shut off.
"gain for them".. which side does your "them" refer to?
because I could see gains for both US and Putin. US obviously gains with more smart people here working for the US and paying taxes. Putin gains because he remove smart people from Russia, making it easier to keep hold on power.
It doesn't seem they even tried this in this case? So this should be a dismissal right away, albeit at great emotional/monetary expense to the original owner. Unfair, but yeah, cryptobros will be cryptobros, and any harm to members of society is just for the good of society, I'm sure...
(Later edit: so, apparently I'm wrong, and there is no binding arbitration clause. Still, lame action, and this seems the exact situation arbitration is designed for, especially since 'local courts' is not exactly well-defined for .com...)
Sure you can. It's stated explicitly in the UDRP on the very page you just linked: one way to handle a dispute is to take it to a court and get a ruling.
> Under the policy, most types of trademark-based domain-name disputes must be resolved by agreement, court action, or arbitration before a registrar will cancel, suspend, or transfer a domain name.
> ... file a complaint in a court of proper jurisdiction against the domain-name holder ...
Emphasis mine. You don't have to choose arbitration.
Why do you think the UDRP has any bearing on what Jump can do in court? ICANN can't make up rules that apply to third parties; there's such a thing as privity of contract! The UDRP may be incorporated into the contract that Merryman agreed to with his registrar, but Jump isn't a signatory to that agreement.
Ah, yes, the same kind of guide that brought us "how to professionally respond to outages"... With classics like "We recognize the incident", "a small subset of customers", "degraded performance" and "the next update (which will be the exact same meaningless drivel as the current 'update') will be in 60 minutes". Don't we just love those? So let's add more of that to the shared vocabulary of IT professionals!
Or... let's just not? In writing, always avoid clichés. Whether it's "do the needful", "by utilizing" or "we did not live up to our customer's expectations", there is one simple rule: if you've seen the exact same sentence or expression before in the exact same context in the last week or so, you should probably avoid it.
And if that makes you unsure what exactly to say, just type what you mean, then get an editor before posting it to your blog or incident report. And if it's time-sensitive, then just ask for forgiveness later, not permission upfront (which is also a cliché but reworded, see what I did there?)
I’m so glad I work in a place that emphasizes benevolent directness.
In fact, I’m so far removed from this kind of lingo that I have to ask: is this website an accurate depiction of how people communicate in other organizations? Or is this a caricature?
This is held up as a great example of transparent communication. For me, this is true, but only for the meaning of 'transparent' which equates to 'you can see right through it, to the extent there is effectively nothing there'.
But as per the article this comment thread is about, this kind of response apparently the 'professional' state-of-the-art.
I think I was unclear. I always assumed (perhaps foolishly) that this kind of communication was the result of some sort of PR committee, and was mostly found in outward-facing communications. Are you saying that colleagues interact this was amongst themselves too? Because _that_ would indeed be despairing.
Still, what does it signal that vector extensions are required to get better string performance on x86? Wouldn't it be better if Intel invested their AVX transistor budget into simply making existing REPB prefixes a lot faster?
AVX-512 is an elegant, powerful, flexible set of masked vector instructions that is useful for many purposes. For example, low-cost neural net inference (https://NN-512.com). To suggest that Intel and AMD should instead make "existing REPB prefixes a lot faster" is missing the big picture. The masked compression instructions (one of which is used in Lemire's article) are endlessly useful, not just for stripping spaces out of a string!
Why is a large speedup from vectors surprising? Considering that the energy required for scheduling/dispatching an instruction on OoO cores dwarfs that of the actual operation (add/mul etc), amortizing over multiple elements (=SIMD) is an obvious win.
My question is whether Intel investing in AVX-512 is wise, given that:
-Most existing code is not aware of AVX anyway;
-Developers are especially wary of AVX-512, since they expect it to be discontinued soon.
Consequently, wouldn't Intel be better off by using the silicon dedicated to AVX-512 to speed up instruction patterns that are actually used?
AVX-512 is not going to be discontinued. Intel's reticence/struggling with having it on desktop is irritating but it's here to stay on servers for a long time.
Writing code for a specific SIMD instruction set is non-trivial, but most code will get some benefit by being compiled for the right ISA. You don't get the really fancy instructions because the pattern matching in the compiler isn't very intelligent but quite a lot of stuff is going to benefit by magic.
Even without cutting people without some AVX off, you can have a fast/slow path fairly easily.
My point is that vector instructions are fundamentally necessary and thus "what does it signal" evaluates to "nothing surprising".
Sure, REP STOSB/MOVSB make for a very compact memset/memcpy, but their performance varies depending on CPU feature flags, so you're going to want multiple codepaths anyway.
And vector instructions are vastly more flexible than just those two.
Also, I have not met developers who expect AVX-512 to be discontinued (the regrettable ADL situation notwithstanding; that's not a server CPU). AMD is actually adding AVX-512.
Anyone using software that benefits from vector instructions. That includes a variety of compression, search, and image processing algorithms. Your JPEG decompression library might be using SSE2 or Neon. All high-end processors have included some form of vector instruction for like 20+ years now. Even the processor in my old eBook reader has the ARM Neon instructions.
Why would it be irrelevant? Even the paucity of availability isn't really a problem - the big winners here are server users in data centers, not desktops or laptops. How much string parsing and munging is happening ingesting big datasets right now? If running a specially optimized function set on part of your fleet reduces utilization, that's direct cost savings you realize. If the AMD is then widening that support base, you're deeply favoring expanding usage while you scale up.
Given Intel's AVX extension could cause silent failures on servers (very high work load for prolonged time, compare to end user computers), I'm not sure it would be a big win for servers either: https://arxiv.org/pdf/2102.11245.pdf.
I'm downvoting you because the assertion you're implying--that use of AVX increases soft failure rates more than using non-AVX instructions would--is not sustained by the source you use as reference.
Indeed, I'd summarise that source as "At Facebook sometimes weird stuff happens. We postulate it's not because of all the buggy code written by Software Engineers like us, it must be hardware. As well as lots of speculation about hypothetical widespread problems that would show we're actually not writing buggy software, here's a single concrete example where it was hardware".
If anything I'd say that Core 59 is one of those exceptions that prove the rule. This is such a rare phenomenon that when it does happen you can do the work to pin it down and say yup, this CPU is busted - if it was really commonplace you'd constantly trip over these bugs and get nowhere. There probably isn't really, as that paper claims, a "systemic issue across generations" except that those generations are all running Facebook's buggy code.
One interesting anecdote is that HPC planning for exascale included significant concern about machine failures and (silent) data corruption. When running at large enough scale, even seemingly small failure rates translate into "oh, there goes another one".
Is it generally possible to convert rep str sequences to AVX? Could the hardware or compiler already be doing this?
AVX is just the SIMD unit. I would argue the transistors were spent on SIMD, and the hitch is simply the best way to send str commands to the SIMD hardware.
If you are arguing most string ops have just a few chars and therefore don’t use vectors… why do we need to spend silicon enhancing rep prefix in the first place?
Maybe it's just my account, but I can't currently enroll my hardware token with Github in any way whatsoever.
Sure, they offer some 1.5FA, but why would I bother with that?