I mean basically that. If you hit a corporate IP, unless they have flow level logging or you have very extensive timestamps, then the game ends, company says they've enacted new training or controls, but they can't identify a specific person and it's not their fault.
Essentially - this is not a suggestion.
Residential ip's map to a specific person, and it's a lot harder for them to deflect and say I'm not responsible for my own Internet connection
Since when does every household member have their own residential IP?
Even in single households that's not true (friends visiting, on-and-off partner, one night stands, helping the neighbor out cause their wifi is broken, ...)
And I don't know the logging + data retention requirements for CGNAT.
Most devices should be using temporary dynamic IPv6 addresses, for this exact reason. I believe this is the default on most Linux distributions, not sure about others.
I felt quite let down when I realised Fedora which bills itself as "free & private" didn't use temporary addresses by default and I had to go hunting for configuration files to enable it as it's not exposed in the UI either.
From the ISPs perspective, companies are still just as responsible for whatever takes place over their connection. From the law's perspective, the person responsible is whoever a jury can be convinced did it.
In cases where the company wifi is open or places like hotels the person who did it could be long gone. Unsecured residential wifi connections aren't much of a thing anymore, but I've seen a lot of people lending out their residential connection when they airbnb their vacation homes to strangers.
>Unsecured residential wifi connections aren't much of a thing anymore<
most residential wifi are not very secure, put the black hat on for a second, then send a message telling a user there is something they cant have; cant do; or will lose, unless they log in, or sign in. then you see the joe password, and many times its the same password for everything.
Because it's not worth it financially. After icann is the tld registrar, and after that above. So, if anyone is destroying it, it's not the registrar, it's the tld.
>> In light of the fact that Verisign and ICANN are in the process
of discussing the upcoming renewal of the .NAME Registry Agreement, ICANN is issuing Verisign this letter in lieu of a contract amendment to the expiring
It's clear to me ICANN can say no agreement change or total destruction. You are correct that they could do something else and show every indication that they would never do the right thing and that is why they should be destroyed.
Dev/shm is used to materialize them, and then you have the ability to isolate the downstream code you might use from accessing it by dropping permissions or sandboxing it away from a file. You cannot really hide your environment from anything in process, since it's such a low level construct.
Not at all clear why this is a better setup than a launcher shim that pulls secrets from a secret store and injects them into the environment as the program launches --- which is a pretty normal shape for these things to take.
I guess you could be thinking "subprocess inheritance" as a downside? But subprocesses often need secrets, and if you arrange for that with the filesystem you have the same problem. And, of course, files leak all the time.
More to the point, though: none of this has anything to do with whether you should add secrets to your .bashrc or whatever, which is the argument I'm seeing on the thread.
Youre required to have a policy. That policy may be throwing bananas at the wall, but if it's documented and you follow it, you're compliant with policy.
The better way is that for each policy you look at what do you actually want to do and how you want to do it, and then write that down as the policy. Now the policy makes sense because it's how you wanted to do it anyway.
I've set up policies and processes from the ground up for SOC2 audits in startups, that's how I do it.
Largely the line was if you could write code. In the old days it was assumed, but for much of the late 90s/early aughts, it wasn't an obligation to admin, but was for devops
It requires humans to verify what agents have done.
Weird