Hacker News new | ask | show | jobs
by mabcat 2268 days ago
End-to-end encryption has been named as a required feature for telehealth in Australia. Interest in telehealth has gone from zero to infinity over the past two weeks for obvious reasons. So I've been trying really hard to work out if Zoom is E2E, and reached the same conclusions as the article. First, it isn't, and second, Zoom are really going out of their way to obscure that fact.

It's great that The Intercept is taking a look at this, because it's absolutely beyond the capabilities of healthcare practitioners and the professional bodies to get to the bottom of. There's a ridiculous amount of confusion here, compounded by "you need to get the HIPAA version because HIPAA means privacy".

13 comments

Just an FYI, two weeks ago, CMS announced it would be suspending enforcement of telehealth tools used in good faith during the COVID pandemic. [0]

Basically, if you are a family doc that's been thrown into the telehealth ringer, you can get started with everyday tools for video chat, like Facetime, Google Hangouts, Skype, etc - regardless of that tool's Hipaa compliance.

Overtime I do expect they'll want to see providers transition to compliant solutions, but they understand thousands of doctors, some of whom have never delivered telemedicine, can't simply audit and on-boarding a new provider overnight.

[0] https://www.cms.gov/newsroom/fact-sheets/medicare-telemedici...

As a note, HIPAA does not require end-to-end encryption as long as you have a BAA with the provider. Zoom has an option for a BAA starting at $200/month.

edit: Server-client communication does need to be encrypted which zoom does.

The Security Rule and Transmission Control Standard mention encryption, but as Addressable, not Required, if memory serves. That means you have to do it if it's "reasonable and appropriate", and in this context they just mean transport encryption like TLS, not Signal-style actual E2E.

Not that you shouldn't, of course. And you better have an excuse for not doing it (e.g. we don't re-encrypt after the load balancer terminates TLS is a common one). But doctor's offices fax stuff to each other all the time, and that certainly is not encrypted. Perhaps you're thinking of a HITRUST control?

(Minor nit: HIPAA, not HIPPA.)

It's a bit more nuanced. Hipaa (two a's) does not require the type end-to-end encryption that most devs come to think of.

Generally, Hipaa does require transport encryption from the client to the server processing the request. The importance here is SSL/TLS should be terminated at the app server.

HIPAA (all caps)
What is a BAA?
A BAA is a Business Associate Agreement. It's a standard HIPAA document where an entity with PHI (typically a Covered Entity, which is an entity specifically mentioned by HIPAA, such as e.g. a healthcare facility) effectively puts a vendor on notice: we may stuff PHI in your service, you agree to abide by this set of rules and regulations. A big one is that the vendor agrees to disclose when they've been breached, and the timeline on which that happens.

Even though a lot of online sources suggest BAAs are only for Covered Entities, that's not strictly speaking true. The standard form document doesn't require the buyer to certify they're a CE. It makes tons of sense for vendors of CEs, themselves bound by BAAs, to bind _their_ vendors to BAAs! If there's a decent chance your customers put PHI in your service, there's a decent chance they put PHI in your support system, and they don't really care if your support system is something in-house or Zendesk when that happens. There's also a good chance that PHI might end up in your logging system, and from there in your Slack instance, and... before you know it everyone's signed a BAA with everyone.

The life-hack consequence for that is that you can just collect BAAs from anyone who will sign them and now you have disclosure timeline guarantees.

PHI: Protected Health Information.

I figured someone asking what BAA stands for doesn't necessarily know all the other acronyms.

Edit: Fixed definition!

Protected, not Personal.
> disclosure timeline guarantees.

depends on your definition of "guarantee".

what you really have is externalisation of risk.

Business Associate Agreement.

A contract which defined how protected health information will be dealt with by the provider and how HIPAA provisions will be followed (ie: provider will do X but you need to do Y to be compliant).

https://www.hhs.gov/hipaa/for-professionals/covered-entities...

I wrote this a while back for our customers: https://www.aptible.com/hipaa/what-is-a-baa/
Business Associate Agreement, which defines the legal requirements between two parties sharing HIPAA data.
Note this only applies to the USA, other countries might not have loosened their regulations quite yet.
Extremely loose in Canada as well. Facetime, skype, phone calls are all fair game currently
FaceTime is E2E, fwiw, although it might not comply with other requirements.
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.

How do you E2E encrypt a video stream and still allow adaptive bit rates?

If the server can't read (decrypt) the video, it cannot re-encode the video at different bitrates for different clients.

Or the Zoom client has to encode multiple steams and upload them locally...or it just downgrades to the bitrate of the slowest client...

You get shitty video and E2E encryption or good video and transport encryption.

First of all, there are 2 different kinds of video calls: 1:1 and group calls. For 1:1 calls, e2e encryption doesn't cause any problem at all.

For group calls, it depends on how it's implemented, but many group calls are implemented using what's called a Selective Forwarding Unit (SFU) and the sending clients send multiple resolutions (either independent, called "Simulcast" or dependent, called "SVC"). In that case, the adaptation is done by the server in selecting which resolution to forward at any given time. This is fairly common practice in the industry. For example: https://github.com/jitsi/jitsi-videobridge and https://tools.ietf.org/html/draft-aboba-avtcore-sfu-rtp-00 and https://www.w3.org/TR/webrtc-svc/.

For those types of group calls, the server only needs to know the sizes of the various streams and which packet is for what stream. It does not need to see the decrypted media, so one can implement e2e encryption for such types of group calls. This is less common in the industry, but is possible. For example: https://support.google.com/duo/answer/9280240?hl=en

(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).

That would seem to require significantly more upload bandwidth & compression capacity from clients, which is often not broadly available to consumers. I guess you could drop down to the lowest resolution only when sending to the service if you have a bandwidth challenge, but that seems less than ideal.
Lots of video conferencing systems already work this way (the SFU way). Compared to just sending the full resolution all the time, adding the smaller resolutions doesn't add that much bandwidth and compression because they are so much smaller.
Actually I'm calling BS on this. Zoom is literally adjusting frame rates at the single frame per second level. There is definitely upload pressure. SFU isn't going to be enough.
But a lot of video conferencing systems are designed for office environments, where you tend to have symmetric bandwidth.
I used to work in video and if I remember correctly there were I, P and B frames. You need I and P but the B frames are optional. So if some meta data is unencrypted the server can tell which packets are B frames and decide not to send them to slow clients. The actual data is still encrypted.
Sure. Then maybe don't claim that the service is e2e-encrypted?
I'd probably have each client encode one high quality stream that's targeted to be accessible to 90+% of clients, and a very low quality stream that's 5% of the bitrate of the high quality one. Low encoding complexity and adds a negligible amount to your upload bandwidth requirements. (Obviously if a client can't meet the upload quota for the highest quality, you max out at whatever they can do.)
Note: what follows is probably not how anyone actually does it. It is just an illustration that adaptive video is not incompatible with E2E encryption.

Suppose you have a block of 4 pixels, represented by 4 24-bit values. Instead of sending the 4 pixel values, send one 24-bit value that is the average of all 4 pixel values, and then the actual 24-bit values for 3 of the 4 pixels. The receiver can figure out the 4th pixel from those 3 and the average.

Send the average values and the groups of 3 discrete pixel values in logically separate streams, separately encrypted.

If something transporting this needs to lower the bandwidth, it can just drop the E2E discrete pixel stream, leaving just the E2E average stream. The receiver can then use that average value for all 4 pixels, in effect getting a video that is 1/2 the resolution both horizontally and vertically.

This scheme only gives you two rates: Full resolution and 1/2 x 1/2. No doubt you could do systems based on block sizes other than 2x2, and with multiple levels of averaging, that would give a wider range of fall backs.

Actual state of the art video encoding is, I believe, based on things like the discrete cosine transform, which represents an image as a sum of cosines of various various frequencies.

In this kind of representation the higher frequencies correspond to higher resolution detail in the image. I'd expect that you could do an E2E transmission scheme were you have different encrypted streams for different frequency ranges. Like with my far less sophisticated or clever 2x2 averaging scheme above, you could simply drop the streams for higher frequencies and the receiver would be able to reconstruct a lower resolution image, but unlike my 2x2 averaging scheme this would have much finer drops in resolution.

> Suppose you have a block of 4 pixels, represented by 4 24-bit values. Instead of sending the 4 pixel values, send one 24-bit value that is the average of all 4 pixel values, and then the actual 24-bit values for 3 of the 4 pixels.

So you still send 4*24 bits? what's the point?

> If something transporting this needs to lower the bandwidth, it can just drop the E2E discrete pixel stream, leaving just the E2E average stream. The receiver can then use that average value for all 4 pixels, in effect getting a video that is 1/2 the resolution both horizontally and vertically.

But you need knowledge of this protocol, so the sender is the only one able to do this. In that case just encode the downsampled resolution and send that, no tricks needed.

The way these video meeting services work is the participants all connect to the service's servers. Each participant sends their video feed to the server, which sends it on to the other participants in the meeting.

It's that server that wants to be able to dynamically downgrade outgoing feeds based on the bandwidth between it and the meeting participants, which can vary from participant to participant.

Alice, for example, might be on a symmetric gig fiber connection with consistent and low latency. Her client can send a high resolution feed to the server. Bob might have no trouble with receiving that, but Carol might be on slower, less stable connection, and need a lower resolution version.

If you aren't trying to do E2E encryption, you can handle this by having the server deal with taking the high resolution feed from Alice and generating a low resolution feed and then sending the other participants whichever is the best version they can handle. That works because without E2E encryption the server actually has access to the video, so it can do things like resample and re-encode.

If you are using E2E though then the only parties that should have access to the video itself are the meeting participants. The server should not have access to the video except in encrypted form.

The problem then is how to encode and encrypt a video stream in such a way that a server that is copying that stream between a sender and one or more recipients can alter a copy of the stream in such a way as to reduce the resolution even though it does not have access to unencrypted video?

I'm concerned that the exigencies of pandemic will cause people to get used to a system that tosses privacy out the door. Not sure how to stop this.

A couple of nits to pick:

> in Australia. Interest in telehealth has gone from zero to infinity over the past two weeks

Slight exaggeration; wouldn't you call the royal flying doctors service telehealth? And HIPPA is a US law.

The key point is that a video consult with a doctor is now (as of last week) available to most of the population, including those in the city, and can be claimed on Medicare. That’s a huge change from previously where it only applied in specific scenarios. I’m sure the RFDS did some video/phone consults but their patients are literally remote - some hundreds of kilometres from the next property.
I'm not sure that you can really say "a system that tosses privacy out the door". There's lots of privacy protections in place. Sure, it requires trustworthy providers, but that's largely true of a non-open source E2E solution as well.

Nit: HIPPA is not a US law, but HIPAA is. ;-)

> Nit: HIPPA is not a US law, but HIPAA is. ;-)

Touché! I'm even HIPAA trained and have to deal with it all the time yet I chronically make that error. I can't even see it when proof reading. Ouch.

End-to-end encryption is hard to implement, might cost more processing or bandwidth or storage (depending on the product) and does not yield benefits for companies interested in processing user data.

If it's not clearly advertised on the front page, _emphasized_ and not a foot note, then it's NOT e2e encrypted.

Example: https://signal.org

There are 2 different kinds of video calls: 1:1 and group calls. For 1:1 calls, e2e encryption incurs negligible processing and bandwidth. Do you worry about the processing and bandwidth increase when using HTTPS/SSL? Probably not. Same goes for 1:1 calls.

For group calls, it depends on how it's implemented, but many group calls are implemented using what's called a Selective Forwarding Unit (SFU). One benefit of SFUs is that they take much less processing for the server than the other kinds (where the video is re-encoded by the server). For those types of group calls, e2e encryption can be implemented with negligible increases to processing and bandwidth.

However, you are correct that it is harder to implement correctly. And it does prevent certain features to be added to the product, such as recording and server-based processing of information (for example, meeting transcriptions).

(I used to work at Google on WebRTC, Duo, and Hangouts, but now work on video calling at Signal).

Recording will work fine locally, no (albeit perhaps more fiddly)? It does push some things off the server obviously, but arguably none of those things should be happening on the server in a situation when E2E is mandated, anyway.
Yeah, I was just trying to point out that there is a feature vs. privacy/security tradeoff. Although I think e2e encryption is usually much more valuable.
fair enough
Given that Signal doesn't have reproducible builds and may therefore have absolutely anything inside of it's distributed binaries, I'm not sure if this is meant to be a good or a bad example.
Signal for Android has had reproducible builds since 2016: https://signal.org/blog/reproducible-android/
It says it does not right on that page.
It's not clear from the context if you mean to say that's simple or hard with that link.

A OTP might be mathematically simple, but logistically it's very hard - you have to safely distribute the key and that key must be at least as long as the message you're passing.

For any health professionals out there looking for a good video solution tailored for doctors and psychologists; check out Confrere. It's a Norwegian company that has built it's service on top of the webRTC-protocol. I have helped several Norwegian doctors offices to get up and running the last few weeks, and they love it!
I don't know that Zoom is really going out of its way to obscure that it is not E2E. I never for a second thought they were doing E2E when I enabled the encryption. It was very clear from how the features was described that you got TLS to Zoom's servers, not E2E.
They literally call it "an end to end encrypted connection" and "secure with end to end encryption".

How is this "clear" that it is not E2E?

Because I live in a world where that term is pretty ambiguous because they aren't security experts.
Right - if you have used signal - I have - zoom is obviously not that. The pain to do call mixing, call recording, join a call late and do playback, join a call at all - does E2E even work in telehealth? I do virtual visits in the US and it doesn't look at all E2E to me.
As far as I know, there's nothing special about telehealth that prevents it from using e2e encryption.
The telehealth platforms I see are terminating through the health provider itself. It does the call setup, conference setup if needed, waiting room for prior call to end, if you send a photo it can be saved to your record etc.

If this is e2e to the physicians home, how does the telehealth system do all these add in functions?

At least in the US, the requirement have been understand to use secure transport everywhere. Folks keep on saying HIPPA requires e2e but I've literally not seen anything that looks like that out there in the actual market for this - the enterprise paying the big bucks usually wants features that are incompatible with e2e as far as I can tell.

You mean, other than requirements that service provides track & preserve an audit trail for all data. ;-)

I believe this is a similar problem with financial trading systems with ETS.

I didn't investigate this requirement, but it's probably insufficiently thought out. Presumably you need E2E encryption so that the SP can't intercept (either willfully, compelled, or as a result of compromise) en masse. If that's the case, then you also need to have a way to verify keys of both parties, and you need a way to do that for group communications.

This is hard.

So even if Zoom is E2E, this is checkbox compliance. (if my assumptions are correct for the reasons behind it)

I have a telehealth appointment (in Australia) this week, and they are using https://doxy.me/

Anybody know much about that one?

My wife uses this when talking to clients (shes a psychologist), but she has the upgraded version that is HD.

If your doctor is on the free plan, it is highly pixelated, and because they offer a hippa-compliant free plan, most providers are on the free plan.

They had a 3-4 hour outage recently. Assuming because of the number of new free users.

> LD video

TIL: there is a quality below SD.

How is a doctor supposed to do a video consultation if the blotches on your bum, purely for example, are all blurry because the definition is less than HD?
Perhaps the system could allow users to send high resolution still photographs alongside the low-quality video stream.
You get most of the consultation with history, described symptoms, etc. handled over telehealth and a quick follow-up in person if you require a physical examination. The process has to cover people who call from a landline as well.
Actually zoom despite its privacy concerns is on the whitelist for telemedical application by the insurers in Germany, so I think they understand how to play the game...
It's not (see the list in the sibling comment). To get certified you need to transport the video/audio stream peer-to-peer between the clients only and end-to-end encrypted, see § 5 of the agreement https://www.kbv.de/media/sp/Anlage_31b_Videosprechstunde.pdf The regulatory bodies took some time to understand the issues and this is why it took so long until it arrived at all.

Private consultations not billed through public insurance is not quite as regulated though.

Thanks for pointing out. I thought the false claim of E2EE was exactly the reason. I got the false (?) info from my neighbor working for a large AT provider. They are making money exactly with such regulational requirements, so I am really puzzled on the actual state of affairs.
really? Psychotherapists are required to use one of the certified providers to be able to bill for tele sessions.

https://www.kbv.de/media/sp/Liste_zertifizierte_Videodiensta...

Hipaa has additional restriction/controls for psychotherapy notes as they are considered highly sensitive. I'd expect this is the same line of thinking in Germany.

Discussing your heart disease or skin condition is sensitive, but it's not as sensitive as discussing deeply personal thoughts or inner monologues.

Now I know why it was the only video conferencing service that worked in Dubai. Others, like meet, WhatsApp - video are not working for censorship reasons.
I'm pretty sure that Google Meet isn't end-to-end encrypted either. Nothing that Google does is.

WhatsApp does claim that videos are end-to-end encrypted as well, although given Facebook announced they'll implement client-side agents for processing user data and given its proprietary nature, I avoid WhatsApp for anything very sensitive as well.

Google Duo is end-to-end encrypted [0]. I don't know about Meet.

Disclaimer: Working at Google, in the same org as Duo.

[0] http://support.google.com/duo/answer/9280240?hl=en

Ah, it's nice to hear that Duo does e2e, thanks.
Very well explained, too. Great work.
> I'm pretty sure that Google Meet isn't end-to-end encrypted either. Nothing that Google does is.

To the best of my understanding, they say that it is https://support.google.com/a/answer/7582940?hl=en

EDIT: On rereading they actually just say that it is encrypted, not neccesarily end-to-end encrypted.

Google provides close captioning for meet calls. That means it's not E2E. Also pretty much no service can provide multi-party video call with adaptive quality without completely destroying your bandwidth.
I'm interested in knowing more about why closed captions would imply not end-to-end encrypted. Wouldn't it be possible to build a model and distribute the model with the client-side application, and run it at the edge?
If they did that, everyone would have the model (meaning you would see closed captions in a lot more places, because it would absolutely be stolen).
Isn't 128-bit AES and SHA-1 fairly weak encryption nowadays?
128-bit AES is not "weak" by any definition of the term.

SHA-1 is deprecated but it's good enough for this application for the near future.

>128-bit AES

Perfectly fine...

>SHA-1

You missed the important bit:

>SHA-1 HMAC

Also perfectly fine...

Do you have any opinions on Pexip Infinity? Would Zoom be a better replacement if it did have E2E?
Hopefully we've reconsidered the laws of mathematics in the last few years ...

https://www.newscientist.com/article/2140747-laws-of-mathema...

"“The laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia,” said Turnbull.

Turnbull’s comments came as he proposed a new law to force tech companies to give security services access to encrypted messages."

"The UK home secretary Amber Rudd has previously called encryption “completely unacceptable” and the UK prime minister Theresa May has said that the big internet companies give terrorists “safe spaces” to communicate."

Going to have to get over this first :/

> The UK home secretary Amber Rudd has previously called encryption "completely unacceptable" ... Theresa May has said that the big internet companies give terrorists "safe spaces" to communicate.

Ironically, the UK government in fact uses Zoom for all its meetings depsite privacy and security implications. Saudi Arabia, take note.

Ref: https://www.businessinsider.com/coronavirus-boris-johnson-zo...

So with the right URL, you can tell them yourself!
Actually: Just a screenshot tweeted by Boris Johnson himself should be enough (if he was faster to tweet it): https://twitter.com/BorisJohnson/status/1244985949534199808
That's terrible for national security. Zoom engineers are based in China: https://www.cnbc.com/2019/03/26/zoom-key-profit-driver-ahead...
It doesn't matter where they're based. What matters is that Zoom isn't safe by any measure and tells you about that if you spend a little time reading critically.
It’s certainly no less safe than the backdoored-for-decades phone/fax networks used by medical professionals to discuss medical secrets with patients and send prescriptions to pharmacies. It’d be nice if it was more safe, but it’s hard to sink lower than a telco line.
You can send faxes to someone without the telco running a local webserver on your fax machine, and you don't run thousands of other applications on your fax machine, and your fax machine doesn't usually come with a nifty record feature, nor a camera and a microphone.
If they're based in Australia they can be legally coerced into installing any code the Australian government feels like telling them to insert. So I'm not sure that China is much worse.
Charles tells me that when I installed Zoom, my iPhone made four HTTPS connections to zoom.com.cn/69.174.108.252
Zoom raises the possibility of this perception in their S-1 filing [0]:

"we have a high concentration of research and development personnel in China, which could expose us to market scrutiny regarding the integrity of our solution or data security features"

[0]: https://www.sec.gov/Archives/edgar/data/1585521/000119312519...

Components of the GB 5g network are also being outsourced to China. Some of the ruling party's MP's are not happy about it.
The noisy back-benchers are a little silly as all of Huawei's work is scrutenised: https://www.wired.co.uk/article/huawei-gchq-security-evaluat...

Of course, in the UK, calling Tory back-benchers "a little silly" is an understatement.

Are the NATO countries refusing to use Huawei's work for their 5g networks also all "a little silly"?

What if Huawei was Russian, would it still be "a little silly"?

It goes far further than stupid comments by our (former) prime minister. The current legislation (passed in 2018) allows the government to force the installation of backdoors through a process that doesn't have any judicial overview or substantial public scrutiny whatsoever.
Number one reason we dropped JIRA.
Out of curiosity, what did you switch to?
Why? How is it related to Jira?
Atlassian is an Australian company, headquartered in Sydney, though the current plc is legally in the UK. (I have no idea if that means they're bound by said backdoor law.)
They are because they provide services to Australians and have an Australian subsidiary -- just as anyone in Australia must comply with a warrant or any other lawful request by law enforcement.
Atlassian is based in Australia.
I realize HN will think much the same of it either way, but AFAICT that second quote of yours is a lie; she called WhatsApp's encryption unacceptable, not encryption in general.
"Encryption we can't backdoor isn't acceptable"
> The laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia,” said Turnbull.

Heh, that reminds me of the Indiana Pi Bill[0], where the state tried to legislate the value of pi to be 3.2.

[0]https://en.wikipedia.org/wiki/Indiana_Pi_Bill

> ... the [former] UK prime minister Theresa May has said that the big internet companies give terrorists “safe spaces” to communicate.

Yes, IIRC she also said wanted to enter a dialogue about this "with the people that know the right hashtags"!

That was Amber Rudd.