ech

had to edit title to have it fit length limit. paper title is "More is Less: How Group Chats Weaken the Security of Instant Messengers Signal, WhatsApp, and Threema"

my edit shouldn't change the meaning.

absolutely. raising the noise floor would make it harder for the adversary to pick up valuable signals. but why bother with complicated jamming setups that require you to cover a very wide spectrum, at high power, while taking care of not interfering with your own equipments, and still have signals going out that with sufficient means and motivation, a sophisticated attacker may still intercept (we're pretty good at extracting valuable signals from noise) when you can just put on your RFP to stick the lot in a faraday cage, use optical connectivity inside it, forbid wireless HIDs, buy shielded monitors and shielded phones, and put a couple of scary bald men in front of the door.

air gapping removes connectivity to the wider world, and a computer system (as in, a system of computers) can totally have value without being connected to anything that is outside of the organization.

no need to resort to hyperbolic alien computers that are anyway easily hacked by plucky heroes with a taste for ascii skulls.

you're correct in that of course we may want to insert and retrieve data from a secure zone. but when those types of systems are necessary, "manual human intervention" is far too blurry. manual data entry/retrieval by vetted people ? a HUMINT problem the organizations that tend to require those systems are familiar with, and have adequate procedures to deal with. same with printouts and assorted "low tech" issues. inserting a USB key and ensuring that the whole chain doesn't compromise your very valuable system is a far more complex problem that you probably do not want to deal with if you can avoid it. there is a reason the "usb gadget give away" and "lost usb key in the parking lot" are a staple of flashy pentests demos. it works remarkably well, and is remarkably hard to defend against without enacting procedures that make the life very much harder on everyone. (try suggesting epoxying the USB ports of every single computer and servers in a medium to large company to its CISO)

like another commenter remarked. it is truly the operational challenges of ensuring your system says properly isolated from the rest of the world that are hard to deal with. cutting a cable is definitely not the end of it. i'm sure people that deal with high assurance environments and are more qualified than i am to answer specifics have their share of stories of creatively compromised isolated environments.

you'd be surprised. when specifications get passed around in the endless maze of defense affiliated sub contractors and sub sub contractors, they may be implemented in all kind of creative ways. and i entirely agree that the operational issues of enforcing the air gap are by far the most challenging cost in this kind of environment. the culture of business environments is by and large ill suited to the kind of strict enforcement these environment require.

if RF leaks are part of your threat model, then i would definitely not class them as "proximity attacks". without adequate shielding, antenna black magic and a rented apartment on the other side of the street work perfectly well to capture signals of interest.

it has been submitted as such on both HN and reddit. i think it is reasonable to clear any misunderstanding.

i am, i get people to use it, and it works well. but superuser2 is right. to be honest, i think we're touching to fundamental limitations in the git model that gitlab cannot solve without becoming rational team concert, and catering to a fundamentally different public.

if locked code review is coming in, i'll be all over it. just let me select multiple approvals, and nested approvals.

it's an immensely useful feature. once again, the more i can define a process in software, the better it is for most non-western, non-modern-management companies.

yeah i read the scope. but since the border between scheduling, configuration management, monitoring etc... is extremely blurry, with a high number of interconnection between systems, and lacking any kind of standard contract between them, i'm more wary about the introduction of these features.

firefox has a plugin that works fine from what i've heard from the others. i still rely by default on totp for generic dual factor auth, since i can provide already working solutions from web to ssh authentication. however, yes for web applications, some clients went the u2f options, and the users overwhelmingly prefer it. since u2f is getting very quickly traction in products (case in point, gitlab) and the user experience is so simpler for a similar level of security, it'll probably become my go to in the near future.

gitlab is gearing up to be the one-stop-shop from development to production. i really like that. unifying the toolset developers and ops have to understand is really a boon for everybody involved.

merge restriction as a feature may sound silly, but in my experience, when driving organizations toward CI/CD, especially with "mature" organizations, having the computer say no instead of a human is a major facilitator in adoption of good practices. now we just need to protect tests in tree. (currently, i tend to favor tests as a git submodule, so we can prevent chronic offenders from altering/commenting tests that should pass)

plus U2F integration, so now i won't hear anymore how "terribly slow" it is to have to whip out a phone to grab a TOTP code...