

exactly
default: on
user: explicitly turns off
random “update”: defaults back on
Now wait 1 year
exactly
default: on
user: explicitly turns off
random “update”: defaults back on
Now wait 1 year
ok fair enough, sorry i may have misinterpreted what you meant.
it sounds like your argument is that if the attacker doesn’t know the service is running then the assertion that this reduces the risk profile is classified as an obscurity control - this argument is correct under these conditions.
however, certain knocking configurations are not obscurity, because their purpose & value does not depend on the hope that the attacker is unaware of the service’s existence but rather to reduce the attacker’s window of access to the service with a type of out of band whitelisting. by limiting the attacker’s access to the service you are reducing the attack surface.
you can imagine it like a stack call trace, the deeper into the trace you go, every single instruction represents the attack surface getting larger and larger. the earlier in the trace you limit access to the attacker, you are by definition reducing the attack surface.
in case i’ve misinterpreted what you meant. susceptibility to a replay attack does not mean something isn’t a security measure. it means it’s a security measure with a vulnerability. ofc replay attacks in knocking is a well known problem addressed long ago.
perhaps the other source of miscommunication is for us to remember that security is about layers, because no single layer is ever going to be perfect.
if you can’t work out what knocking might have to do with whitelisting then i’m not sure what you hoped to contribute towards reducing misconceptions in the conversation
would you classify out of band whitelisting by IP (or other session characteristic[s]) as having no security merit whatsoever?
would you classify it as purely a decision regarding network congestion & optimisation?
you’re ofc free to define these things however you wish, but in a form which is helpful to OP’s question i’m not sure i follow you.
I fucking hate this timeline.
my first thought as well…how did we get to the point that this is a valid topic?
(not a comment about you OP, just the state of the world)
to reduce attack-surface, if there’s no reason for the port to be open, don’t open it.
while the most bare bones knocking implementation may be classed as obscurity, there’s certainly plenty of implementations which i wouldn’t class as obscurity.
People iterate through all the IPv4 addresses since there are only 4,294,967,296 possible addresses. There are 340,282,366,920,938,463,463,374,607,431,768,211,456 possible IPv6 addresses
i love your thinking!!
do you have a backup in case you accidentally find yourself locked out from an ipv4-only network?
can you pls explain what you mean in more depth?
your original post is sufficiently vague that tbh i don’t blame people for assuming you were just bootlicking? [which probably says more about the state of the world than you as an individual, but honestly it’s not clear what you’re trying to say?]
we all know a random citizen/local business presenting an identical calibre of evidence of repeated crimes would be extremely unlikely to routinely receive this degree of resource allocation.
so if it’s an idealised aspirational universal “order” you’re talking about then obviously noone’s buying it - and i don’t think you are either. so what do you mean?
tar pits target the scrapers.
were you talking also about poisoning the training data?
two distinct (but imo highly worthwhile) things
tar pits are a bit like turning the tap off (or to a useless trickle). fortunately it’s well understood how to do it efficiently and it’s difficult to counter.
poisoning is a whole other thing. i’d imagine if nothing comes out of the tap the poison is unlikely to prove effective. there could perhaps be some clever ways to combine poisoning with tarpits in series, but in general they’d be deployed separately or at least in parallel.
bear in mind to meaningfully deploy a tar pit against scrapers you usually need some permissions on the server, it may not help too much for this exact problem in the article (except for some short term fuckery perhaps). poisoning this problem otoh is probably important
deleted by creator
Imo signal protocol is mostly fairly robust, signal service itself is about the best middle ground available to get the general public off bigtech slop.
It compares favorably against whatsapp while providing comparable UX/onboarding/rendevous, which is pretty essential to get your non-tech friends/family out of meta’s evil clutches.
Just the sheer number of people signal’s helped to protect from eg. meta, you gotta give praise for that.
It is lacking in core features which would bring it to the next level of privacy, anonymity and safety. But it’s not exactly trivial to provide ALL of the above in one package while retaining accessibility to the general public.
Personally, I’d be happier if signal began to offer these additional features as options, maybe behind a consent checkbox like “yes i know what i’m doing (if someone asked you to enable this mode & you’re only doing it because they told you to, STOP NOW -> ok -> NO REALLY, STOP NOW IF YOU ARE BEING ASKED TO ENABLE THIS BY ANYONE -> ok -> alright, here ya go…)”.
imo i wouldn’t overlook CERN too much due to apparent obscurity. that’s CERN as in WWW & LHC.
plus it’s specifically designed for hw, unlike most of the others which are more likely to lean sw centric?
if your hw is very sw-heavy you could even consider splitting the license types between firmware and hardware if it helps.
not saying what the right choice is for you, just the apparent obscurity i think isn’t such a big issue. but welcome correction.
i think they mean future devices, not previously sold.
either way the thread is 99% invalid criticism of what is afaict one of the best projects of our generation
Google could snap its fingers tomorrow and lock down the ability to unlock bootloaders.
only valid point in the post afaict
is the machine the problem? that seems more like a philosophical or semantic debate.
the machine is not fit for the advertised purpose.
to some people that means the machine has a fault.
to others that means the human salesperson is irresponsibly talking bs about their unfinished product
imo an earnest reading of the logs has to acknowledge at least potential evidence of openai’s monetisation loop at play in a very murky situation.
It’s not any more conductive
quick note: you’re likely correct the conductivity may not be higher, but the conductance likely is.
in other words, i second your suggestion of heavier duty foil (for EM reasons, skin effect etc) alongside the mechanical factors you mentioned.
tldr: VM->RDP seamless render
WinApps works by: Running Windows in a Docker, Podman or libvirt virtual machine. Querying Windows for all installed applications. Creating shortcuts to selected Windows applications on the host GNU/Linux OS. Using FreeRDP as a backend to seamlessly render Windows applications alongside GNU/Linux applications.
i’m a piece of shit
and obviously lying about how well it worked out for me, or i wouldn’t be here forcing a smile for the camera and spruiking my latest bs
without further explanations of OP’s intent i’m inclined to think this is perhaps the best approach