For example in the US, a court could compel any external vendor we outsource our data to for operational, processing or storage purposes to access that data for any use it deems necessary. This was the expectation of any commercial business relationship across the country.

Gmail broke this with ad data, but the data was meta-data - information about information, like ad groups and categories relevant to your org.

Now publicly published content is being ingested and used to train models, at this stage I would assume if you share Docs publicly that would be in scope.

Proton has a good article explaining what is and isn’t ingested, and what they have the right to use: https://proton.me/blog/google-docs-ai-scraping

Realistically, secrets alone shouldn’t allow an attacker access - they should need access to infrastructure or a certificates in machines as well. But unfortunately that’s not the case for many SaaS vendors.

It's totally insane to send them to a remote service controlled by another organization.

1) employees are trusted with secrets, so we have to audit that employees are treating those secrets securely (via tracking, monitoring, etc)

2) we don’t allow employees to have access to secrets whatsoever, therefore we don’t need any auditing or monitoring

IMHO needing to be monitored constantly is not being "trusted" by any sense of the word.

Similarly employees can be trusted enough with access to prod, while the company wants to protect itself from someone getting phished or from running the wrong "curl | bash" command, so the company doesn't get pwned.

Factually, it is necessary for auditing and absolutely correlates with the extreme of needing to monitor the “usage” of “secrets”.

In a highly auditable/“secure” environment, you can’t give secrets to employees with no tracking of when the secrets are used.

Sending env vars of all your employees to one place doesn't improve anything. In fact, one can argue the company is now more vulnerable.

It feels like a decision made by a clueless school principle, instead of a security expert.

If you lean in the direction of keylogging all your employees, that's not only lazy but ineffective on account of the unnecessary noise collected, and it's counterproductive in that it creates a juicy central target that you can hardly trust anyone with. Good auditing is minimally useful to an adversary, IMO.

This does not seem to require regularly exporting secrets form the employee's machines though. Which is the main complaint I am reading. You would log when the secret is used to access something, presumably remote to the users machine.

Repeat after me: Security is not a bolt on tool.

Good start, might need a little more work around the edges.

Yeah. So you track them when they are used (which also gives you a nice timestamp). Not when they’re just sitting in the env.

It works the same way for biometrics like face unlock on mobile phones

Right, but doesn't that mean there is no risk from sending employee laptop ENV variables, since they shouldn't have any secrets on their laptops?

If you’re a PCI company then ending up with a credit card number in your SIEM can be a massive disaster. Because you’re never allowed to store that in plaintext, and your SIEM data is supposed to be immutable. In theory that puts you out of compliance for a minimum of one year with no way to fix it, in reality your QSAs will spend some time debating what to do about it and then require you to figure out some way to delete it, which might be incredibly onerous. But I have no idea what they’d do if your SIEM somehow became full of credit card numbers, that probably is unfixable…

You'd get rid of it.

They certainly wouldn’t let you keep it there, but if your SIEM was absolutely full of cardholder data, I imagine they’d require you to extract ALL of it, redact the cardholder data, and the import it to a new instance, nuking the old one. But for a QSA to sign off on that they’d be expecting to see a lot of evidence that removing the cardholder data was the only thing you changed.

This isn't realistic, it's idealistic. In the real world secrets are enough to grant access, and even if they weren't, exposing one half of the equation in clear text by design is still really bad for security.

Two factor auth with one factor known to be compromised is actually only one factor. The same applies here.

I think some configurability would be great. I would like to provide an allow list or the ability to redact. Or exclude specific host groups.

We all have different levels of acceptable risk

My mental model was that Apple provides backdoor decryption keys to China in advance for devices sold in China/Chinese iCloud accounts, but that they cannot/will not bypass device encryption for China for devices sold outside of the country/foreign iCloud accounts.

There's a triggering action that caused the env vars to be used by another ... ehem... Process ... that any EDR software in this beautiful planet would have tracked.

Why?

There is no need to send your environment variables.

Why are they only doing it for macs then?

Arbitrarily high levels of market penetration by sloppy vendors in high-stakes activities, far from being an argument for functioning markets, demand regulation.

Arbitrarily high profile failures of the previous two, far from indicating a tolerable norm, demand criminal prosecution.

It is recently that this seemingly ubiquitous vendor, with zero-day access to a critical kernel space that any red team adversary would kill for, said “lgtm shipit” instead of running a test suite with consequences and costs (depending on who you listen to) ranging from billions in lost treasure to loss of innocent life.

We know who fucked up, have an idea of how much corrupt-ass market failure crony capitalism could admit such a thing.

The only thing we don’t know is how much worse it would have to be before anyone involved suffers any consequences.

$16B is far too cheap for a company like them though. They almost pull that in revenue in a single year without locking out third party marketplaces. Their margins are notoriously high.

I’d triple it.

Fake interviewees are pretty rampant. We’re getting to the point where presenting yourself in-person to a government representative, agency or a private attestation company will be part of the onboarding process. At this point it looks like it’ll be iris scans.

In the US it’s even an issue in-person with H1B’s where they get interviewed and hired online, then someone else shows up.

Also the fact that insider threats are almost never budgeted for, and so many companies blanket-approve access to systems like logging systems, customer support systems, source code, etc - means attackers don’t even need to get hired into a very important role to get the data they want.

Oh god no, a piece of not-that-secret information which can't be revoked when eventually leaked.

"This is a courtesy alert that your iris scan has been found on the darkweb..."

Either way, I think this is one of those "if it was used properly, people won't like the limitations, so they'll use it improperly" situations. Kind of like with social security numbers.

"Welcome to Acme Bank. To prove you are the owner of this bank-account, please supply your full name and street address. *ding* Authentication successful! Please choose an amount to transfer."

At best, biometrics can only replace usernames. In other words, information that is quasi-public and not expected to be easily changeable... With the additional problem that sometimes it changes all on its own.

someone else shows up ? what is the denominator

This may be a reasonable gamble, as many companies do probably not expect such a rochade, and do not have detective measures in place. And if that doesn't work, you still have 3 months time to find another job in an environment that favored job seekers at this time.

[1] https://expatrist.com/losing-a-job-in-germany-with-eu-blue-c...

However, locked down Chromebooks and Android profiles are generally the best way to go. Not sure about the Apple ecosystem (even though that's what I'd choose - just haven't found readily available advice).

Also contract length. Pretty common to get deep discounts with multi year agreements.

And definitely! We do have contract length, though that's locked away as a Pro feature

It’s sad that the argument of “but what if”, and slippery-slope fallacies immediately shut down even the most strict, bureaucracy-filled approach which requires the person to have no significant assets for a period of time (to be certain they aren’t being forced by family), or mandatory psychologist assessments.

Please note, I said dignified. But because they weren’t able to notify or tell anyone their plans (I assume so as to not burden or implicate them), because they were unable to take the euthanasia path - we found them 3 days later. The weather was not cold.

This is the reality that families face when no choice is made possible by the state.

My exposure to these issues is rather more mixed. One of my grandmothers suffered from dementia. During the early stages, she was aware and suffered quite badly. But oddly enough, once the dementia was full blown, she lived several more years happier than she'd ever been, because the worries and restraints which had bothered her all her life were gone.

Another relative died in the earlier stages of dementia, and his last two years were fairly miserable. And now there is a relative who is also in the earlier stages, and who is determined to avail themselves of assisted suicide rather than live with dementia.

Speaking with their doctor, we learned how exactly the procedure works — in our country, it just requires a doctor's note, but the doctor will NOT issue that note if the patient already HAS full blown dementia (for obvious reasons). So you would have to request euthanasia relatively early in the process.

My relative is convinced that they are just fine, and that it's really hackers and conspiracies out to get them. Should I press the issue and insist that they are in the earlier stages of dementia and should get euthanized before it's too late for that option? I've chosen not to that — if they make that decision, I will support it, but I will not attempt to influence them one way or the other beforehand.

Are you saying because a new version breaks the current build of a downstream proprietary application, that should constitute a high priority support request from the maintainers of the project?

That doesn't compute with me. If they were paying for forwards-compatibility and had that expectation in a contract, sure. But they should be able to make changes they see fit without having to make trade-offs to ensure future compatibility with an Enterprise organisation's product.

At that point they're basically making design decisions to suit the Enterprise, at which case - you're not just free resources for software engineering for the organisation, you're actively pushing your project to be vendor-compatible. I could see this reasoning if your project is largely funded by them (Chromium), but in this case, they're not.