Shouldn't Teams, Zoom, Slack all interoperate securely for the Feds? Wyden is asking Collaboration software used by federal government agencies — this includes apps from Microsoft, Zoom, Slack, and Google — will be required to work together and be securely end-to-end encrypted, if legislation proposed by US Senator Ron Wyden (D-OR) passes. That's a big if. Without a lot of bipartisan momentum behind it, his …
Given that email already has long established standards, mostly being followed, there are only a couple of changes, neither very radical that need to be made. One is to ban the use of any that don't follow the standard - I wonder who that would be - and the other is to roll PGP into the standard. In regard to the last PGP itself has been available in email clients for years, nothing new there.
Public key distribution would appear to be the main issue. It's not as if serving small text files is a massive technological leap. The only problem is telling the punter where to find the server. There are a few possible alternatives. One is to add a new type of record alongside the MX record to point to the key server. Another is to extend SMTP to allow the mail server to query the location of the key server. A third would be to have the mail server function as the key server and extend SMTP to request the key.
For large organizations, S/MIME probably makes more sense than PGP. PGP has a lot of issues and it really, really does not address PKI in a way that works for anyone who's not nerd-spec. While PGP remains popular for some applications (e.g. signing OSS tarballs, vulnerability reports from outside researchers), it's not a great choice for rolling out to millions of ordinary email users.
S/MIME is far from perfect too — for one thing, it's built on MIME, which was the worst mistake in the history of email. And it also involves failure modes that will baffle non-expert users, like how MUAs handle expired non-timestamped signatures. Yes, some people save email messages and read them some time later (my own collection of work email goes back to 1997). But on the whole it generally works better than PGP. And support is built into Outlook, which is an advantage if only because so many people already use Outlook.
One is to add a new type of record alongside the MX record...
Um, DMARC (SPF and DKIM), DANE, MTA-STS... if anything, we've already over-engineered the solution(s) to this one. We don't need yet more "email security mechanism in DNS" standards. Implement S/MIME and SPF, then DNSSEC, then DANE (which requires DNSSEC), then DKIM, then DMARC, and finally MTA-STS if you want; that's how you get improved email security. Trying to fix PGP key distribution would only muddy the waters further.
No that's forcing them to the lowest common denominator.
People choose Signal for a reason. If they use it but the person on the other end uses WhatsApp, the security guarantees they get (for the purpose of this argument assume they are 100% true) disappear because the other end is something else.
If Apple wants to add features to iMessage like when they added support for sending Apple Cash payments to people I guess they'd be SOL, because it wouldn't be part of the standard and the other side wouldn't support it. They could propose it, but once everyone else gets their fingers in it and adds the kitchen sink then they have to waste time implementing a lot of irrelevant crap that Facebook wants like maybe micropayments or something that lets companies whose pages you follow send you ads and you get paid for viewing them.
What's wrong with Microsoft having their own collaboration software and Zoom having theirs? What's the point of investing in R&D to develop this stuff, it will make no difference when it is the same as anyone else's so just slap on the open source version and be done with it. Now no one is investing in ideas to make it better, because there's no money in it. They'll pursue AI instead - until someone like you comes along and decrees that OpenAI has to be compatible with Grok, and Apple can't do on-device AI because the standard says the model has to be a certain size that's too big to run on a phone.
Nothing stops IETF from making a conferencing standard, people writing an open source version, etc. Let the best product win in the market, not by government decree.
The situation we have now, where every vendor's offering is made deliberately incompatible with every other vendor's offering, is precisely the result of "letting the market decide".
And what the market has decided is, "interoperability" is a dirty word. Once the mug punters have already chosen your proprietary solution, it's going to cost them more -- even before factoring-in things like downtime and user retraining -- to migrate away to anyone else's proprietary solution than it would to stick with what they already know.
@DS999 "Nothing stops IETF from making a conferencing standard, people writing an open source version, etc. Let the best product win in the market, not by government decree."
Is that not how the proposed bill will work. The IETF come up with a standard for example for video conferencing, four years after that date Federal agencies will only be able to procure collaboration software if the video conferencing component supports the standard and end to end encryption.
The proposed bill does not require/decree the producers of video conferencing software Microsoft, Zoom, etc, support the standard, but if they don't then Federal agencies will not be able to purchase their collaboration software. Is that not how the market works Federal agencies are in the market to buy collaboration software that meets their requirements if their is a large enough profit to be made then someone will produce it.
I can see at least 3 ways this will pan out.
A) None of the tech companies adopt the standards so the agencies have to buy bespoke solutions instead of off the shelf software. More expensive and probably vender lock-in.
B) Only one company the largest suppler (Microsoft) supports the standards, vender lock-in and maybe more expensive if they have Government and commercial versions.
C) The major players support the standards in their off the shelf collaboration software, which seems to be the goal of the bill.
I think you're correct in general but incorrect about this. In this case, the bill simply requires that the government use an open standard instead of a proprietary thing. That makes it necessary for a standard to be created and encourages its use, but people are free to create an incompatible version and make it available. It just won't be purchased for U.S. government use. This bill will promote the existence of a standard, hopefully a good one, without enforcing it on everyone. I would support it.
Where I agree with you is when laws are passed mandating that nothing may exist that isn't interoperable with a standard. That prevents someone from choosing to give up interoperability in order to get some feature not supported by the standard. This is important to me because, for many of the things that have done this, the thing they wanted to include that wasn't in the standard was encryption, which is a feature I value quite a bit. It's also the most likely place where encryption will be limited by legislation. I think we should have the choice to build incompatible things, but I have no problem with the government refusing to buy them.
Everyone?
I don't use any of those. I have Signal installed, but no one's ever actually sent me a Signal message. I have no interest in using WhatsApp, iMessage (not an option anyway as I won't use Apple OSes), Telegram, etc.
If people want to send me a message, I have email, and I have SMS. Or, if security is a concern, Signal. If they want to use anything else, they can talk to someone else.
This is Wyden. He is the one legislator who consistently pushes against such things and tries to get privacy respected. He's not the hypocrite here. This is probably not a good thing for the likelihood of this bill being passed, though, as his fellows have been ignoring his suggestions for decades.
It's almost as if he's proposing some sort of internet engineering task force, where interested parties can, in the interests of mutual co-operation and compatibility, spend time properly devising sensible and open standards, and make requests for comments so as to get wide input into what will make a good workable standard, rather than just hastily throwing together some proprietary crud and then fighting in the mud to see who can grab usage share…
The problem is they want to force companies to only create products that work according to these standards, rather than letting them create whatever they want and if consumers refuse to use it because it doesn't interoperate, it will fail. Nobody is forcing the government to use these products, or for one department to use one and another department to use another, nobody is forcing individual users or businesses to use them, and if they want to be able to communicate with others they can all use the same product, or one or the other can switch, OR they can convince the two product creators to make them communicate with each other, and stop paying for it if it doesn't happen. Forcing interoperation though means users get the worst of both worlds. When talking to someone on a different product, they get only the shared features, rather than all the features that they wanted by choosing the product they chose.
> Forcing interoperation though means users get the worst of both worlds.
Potentially, much depends on whether parties with vested interests sabotage the Standard etc.
But forcing interop was a good thing for networking and the wider computer industry, okay the world didn’t go ISO OSI, so perhaps the Internet is the the worst of both worlds…
they want to force companies to only create products that work according to these standards
My impression is that Wyden's bill — I haven't read it — specifies purchasing standards for the US Federal Government. It doesn't dictate what companies do. It dictates what they need to do if they want to sell the product to the Feds.
The Feds already have many standards of that sort. Companies can choose to play, or not.
I'm about as hardcore on the right as it gets, and I'm a fan of Wyden in this arena. In fact, I'm planning on complaining to his office, bypassing my own congresscritters about the latest IRS initiative.
Seriously, give the devil his due--even if he's wearing a "D" (today).
"The legislation would also require that, "to the extent practicable," end-to-end encryption and other technologies to protect government communications from foreign surveillance would have to be built in. These collaboration technologies must also comply with federal record-keeping requirements."
So, designed so nobody else can read it, but recorded so it can be read? Aren't those opposites?
Why are those contradictory? The solution seems simple: encrypted backups. If you have the keys and access to the disks, you can play them. If you intercepted the communication, you can't. Ideally, the backups would be stored by the user so the encrypted versions can't be obtained by the provider. It would also work if the provider stored the backups but not the keys, because they would have access to the files but not the ability to read them.
That's used by all sorts of protocols. My messages are end-to-end encrypted in transit, but nothing stops me from keeping them on my device once I have them and copying them onto another system for backup.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
