Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hold on, E2E encryption is now required for telehealth in Australia, yet the Australian government passed laws that required LEO's to have access to E2E encrypted data [1]? How are tech companies supposed to comply with that?

[1]: https://www.wired.com/story/australia-encryption-law-global-...



This is a fairly small/simple example but a significant (yet hidden) portion of compliance is figuring out how best to "comply" with conflicting regulations. Everyone always complains about the operational cost of compliance but the expense that goes into making these decisions (risk assessment, lawyers, senior executive time, board meetings, etc.) is where compliance quickly gets very costly IMO.


It's not incompatible technically. The law requires access on request, not all the time. If LEO doesn't ask, it may be still E2E.


A requirement for e2e is that the company doesn't hold the keys, otherwise it's just regular transport encryption + a promise that they'll never peak at the your data, even though they can. So yes, it's very much incompatible technically.


You just have two modes, one with e2e enabled and one not. e2e is enabled normally but when LE requests access, the user client receives a message telling it not to use e2e. That may not satisfy you as someone who wants secure encryption (and it probably shouldn't), but it is e2e when it's actually enabled.


Does it inform the user or otherwise stop functioning for telehealth once the signal is received? If not, then does that mean that someone is considered e2e encrypted if it in theory can support e2e encryption even if it isn't using it right now?

It looks like the situation has not been fully thought through and the government is creating a Kafka trap when its laws.


> does that mean that someone is considered e2e encrypted if it in theory can support e2e encryption even if it isn't using it right now?

No. My assumption is that certain communications are required to be end-to-end encrypted, unless the individual is under surveillance. All end-to-end encrypted communications providers are required to have a mechanism in place for disabling and MITMing e2e communications. It stops being e2e encrypted for the duration of that surveillance.

I suppose it's possible that a foolhardy government (I'm not Australian, so I can't say for sure what they've done) would word the laws in such a way that they can't technically be achieved, but there's no reason why they have to be. The laws aren't bad laws because they are logically impossible to fulfill (if they are), they're bad laws because they violate the individual's right to privacy.

Note that the law might also prohibit the government from surveilling communications between patients and licensed health professionals. In that case it would be quite possible to mandate no-exceptions e2e for those communications, and a mechanism for disabling e2e. e2e that is never disabled is always e2e.


The company doesn't have to keep the keys for everyone. They can switch you on request from E2E to central encryption for you account only. Without an opensource client and the possibility to verify the used keys, you wouldn't know that happened. And realistically, even with those options, almost nobody verifies the changed fingerprint.


That adds an even bigger layer of complexity for people to understand. The whole point of E2E was so that only the two ends could decrypt the data being transferred. If we now add "except if government agency requests it" then we're hijacking the term and making it no more meaningful that saying "yeah our app has encryption".


I'm not trying to hijack the term. Once LEO puts in the request the system stops being E2E - that's true. It would be good if this wasn't possible, but for that we need the whole stack of: open protocol, opensource implementation, signed verified release, and people keen to verify fingerprints. And if we're pedantic, also a verifiable execution environment.


The law actually requires the companies MITM the video to give them access. It doesn't place any requirement on the end user.

So use a solution that doesn't put a company in the middle. Use open source, E2E encrypt with keys secured by the user and not central server and you are good. One solution available now - Signal.

Despite the heat being laid on Zoom, they have no choice. Any platform that does mixing to produce a composite image with Picture in Picture like Zoom does has no choice. That includes Hangouts, Skype and so on. They do it to save bandwidth - something I've been grateful for.


PIP or other effects can be done well on client side eg with WebGL or nultiple canvases.

Possibly you can save on BW by server processing - far from "no choice" however.


Probably the simplest way would be for the clients to chose a key for E2E encryption, and then to encrypt a copy of that key with some government public key, and save that encrypted copy of the E2E key somewhere that the government can get to when the law requires that they be able to access the plaintext of the encrypted communications.

This lets the tech company comply with the law, without the tech company itself gaining access to the plaintext.


The server is one of the "ends" in "end to end".

The law didn't contemplate that you would use a service but not want that service to access your data.


> The server is one of the "ends" in "end to end".

Not in the phrase "end to end encryption", which is specifically used to refer to schemes and services where the service provider does not have the ability to access the communications (a-la Signal).

If that wasn't the case then any site with TLS would be called "end to end encryption".

> The law didn't contemplate that you would use a service but not want that service to access your data.

This law in particular does. The only restriction (relevant here) is that TCNs must not result in the creation of a "systemic vulnerability". The meaning of this term is not outlined in the legislation -- my understanding is that it is meant to mean something like "backdooring OpenSSL and thus making most of the internet insecure" rather than "backdooring all communications using a particular service provider". If that understanding is accurate, then it's a meaningless restriction.


Same in the EU: service providers that provide services that allow people to share content must install content filters that screen for illegal (read: copyrighted by large corps) content.

You can't operate an E2E encrypted communication service in Europe without breaking the law.

caveat: I'm not sure whether this has actually been adopted/ratified by either the EU or member states yet.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: