Microsoft Purview: Additional classifiers for Communication Compliance (preview)
191–200 of 317 posts
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#192Earlier quoted context omitted.
Not P, but I agree. One does not have to like a billionaire or even dream about being one to disagree with disproportionate taxation out of other principles or concerns.
It goes the other way around too. There are billionaires in favor of increased taxes on billionaires.
So that group of billionaires who think the government can use their money more efficiently than they can in order to advance American society are absolutely free to do so! Go them! They don't need the government to compel them. They can form their own Philgubernatorial group -set their own donation rules and taxation (donation) bands and percentages and come tax season give it to the feds.
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#193This seems to be office 365 implementing monitoring of official communications of employees & contractors for the office account? I don’t think it extends to a personal office 365 account, at least it didn’t seem to. Why is this exactly newsworthy? Any communication through official channels is the property of the employer anyway. To collude, leave & other stuff use personal channels maybe.
Why is there always this attitude of "it's a private business, they can do what they want". Why does the fact that they can do something distract from criticism of them doing it? The fact that this tech exists is horrifyingly dystopian on its own merits. But it also has widespread consequences in a country with so many employment monopolies and opportunities for outright wage slavery. Heavy-handed workplace surveillance and heuristics-based crap are becoming increasingly difficult to simply opt-out of.
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#194Earlier quoted context omitted.
1) You need to audit that code, which.. everyone will have to do on both sides of the communication channel. 2) https://signal.org/blog/reproducible-android/ > the Signal Android codebase includes some native shared libraries that we employ for voice calls (WebRTC, etc). At the time this native code was added, there was no Gradle NDK support yet, so the shared libraries aren’t compiled with the project build. A good…
1) Nonsense. If you don't trust other people's code, you're screwed. You put yourself into the position where you have to audit your OS code, your CPU code, code of every driver that runs in your system. None of which you did. 2) Isn't WebRTC open source too? 3) Their code, their decisions.
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#195I'm already not wanting to have personal conversations on teams. My tech savvy colleagues and the ones who can be convinced are on signal, where we talk about job offers and relationships. A few others do Instagram, and get to see my art photography. And occasionally I'll bump into someone when we're both in the office and be able to say whatever not looked over by AI. There's a real chilling effect on getting to kno…
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#196Earlier quoted context omitted.
It goes the other way around too. There are billionaires in favor of increased taxes on billionaires.
And the IRS allows you to contribute as much as you prefer to the treasury. It's voluntary and no one is compelling you. So that group of billionaires who think the government can use their money more efficiently than they can in order to advance American society are absolutely free to do so! Go them! They don't need the government to compel them. They can form their own Philgubernatorial group -set their own donatio…
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#197Has this been reported to EFF?
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#198Earlier quoted context omitted.
1) You need to audit that code, which.. everyone will have to do on both sides of the communication channel. 2) https://signal.org/blog/reproducible-android/ > the Signal Android codebase includes some native shared libraries that we employ for voice calls (WebRTC, etc). At the time this native code was added, there was no Gradle NDK support yet, so the shared libraries aren’t compiled with the project build. A good…
1) Nonsense. If you don't trust other people's code, you're screwed. You put yourself into the position where you have to audit your OS code, your CPU code, code of every driver that runs in your system. None of which you did. 2) Isn't WebRTC open source too? 3) Their code, their decisions.
> What's not trust worthy exactly?
to:
> Their code, their decisions.
It's okay to be a fanboy! Evangelism is needed for any great product/company/ideology. But on HN you'll get typically called out for disingenuous or bad-faith lines of rhetoric.
The person above gave you a perfectly reasonable answer to your original question of "What about Signal is not trustworthy?". It'd be kind to acknowledge that they at least have a single iota of merit.
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#199Reinforces that during interviews candidates should be determining what the company uses for internal communications and choose accordingly. Anyone using Teams is already a red flag.
Re: Microsoft Purview: Additional classifiers for Communication Compliance (preview)
#200Earlier quoted context omitted.
1) You need to audit that code, which.. everyone will have to do on both sides of the communication channel. 2) https://signal.org/blog/reproducible-android/ > the Signal Android codebase includes some native shared libraries that we employ for voice calls (WebRTC, etc). At the time this native code was added, there was no Gradle NDK support yet, so the shared libraries aren’t compiled with the project build. A good…
1) Nonsense. If you don't trust other people's code, you're screwed. You put yourself into the position where you have to audit your OS code, your CPU code, code of every driver that runs in your system. None of which you did. 2) Isn't WebRTC open source too? 3) Their code, their decisions.
I expect more of people on this forum honestly.
Taking the core of your argument: "Trust".
The point of E2EE is that we don't trust the network. We put all the trust in the client, something we control. Or at the very least we seperate our concerns. (please refer to this lovely interactive "Tor" diagram by the EFF for what I mean by splitting out concerns: https://www.eff.org/pages/tor-and-https )
Not being able to run your own client is a pretty big problem. At the very least in that case you should expect to be able to run on another network.. Otherwise that's a lot of trust for one entity and it's not different than just using TLS with HPKP/CA pinning
To give a direct refutation to one of your points: "Isn't WebRTC open source too?"
It is, but they're using native libraries which are compiled. Like I said, it's a good argument, but the result is that they don't have reproducible builds.
> Their code, their decisions.
Extremely dismissive, almost to the point of insulting.
It is absolutely not true that they are above criticism because they built something. They've positioned their product as a security product. Thus it will be judged on those merits. There are many pro-signal zealots who will bend over backwards to defend it in all circumstances. It's intellectually dishonest to do so in the face of valid criticisms.
I will shut up when federation is supported, or you can run your own network, or you can bring third party clients.
You need this to be able to trust your client, because the point is to decouple some trust from a single entity.
that's what e2ee is!