> Among the requirements of the DMA is that Apple ensures that headphones made by other brands will work with iPhones. It said this has been a block on it releasing its live translation service in the EU as it allows rival companies to access data from conversations, creating a privacy problem.

This sounds bogus right? If all the headphones can do is transmit audio via first party operating system features how is this creating a data privacy issue? How are headphones going to exfiltrate data unless they have their own Wi-Fi connection or application that can serve as a bridge? Just disallow both.

▲ STKFLT 6 hours ago | parent | next [-]

It is somewhat complicated by the specific requirements of the DMA specifications for Apple:

> The interoperability solutions for third parties will have to be equally effective to those available to Apple and must not require more cumbersome system settings or additional user friction. All features on Apple will have to make available to third parties any new functionalities of the listed features once they become available to Apple.

Apple is saying, "We designed our API in a way that requires trusted headphones as part of the privacy model, and DMA would force us to give everyone access to that API."

What goes unstated is that trusted headphones aren't necessary for the feature and a company trying to meaningfully comply with the spirit of the DMA probably would have chosen to implement the API differently.

https://digital-markets-act.ec.europa.eu/questions-and-answe...

▲

isodev 5 hours ago | parent | next [-]

And “trusted headphones” - all headphones, including AirPods, are untrusted until paired. This entire narrative that Apple is pushing is political, not technical.

▲

sceptic123 5 hours ago | parent | prev [-]

Can you explain how you know that trusted headphones aren't necessary and where Apple is saying what you are quoting here?

▲

STKFLT 3 hours ago | parent [-]

Those are fair questions. This is what Apple says in the press release:

> Live Translation with AirPods uses Apple Intelligence to let Apple users communicate across languages. Bringing a sophisticated feature like this to other devices creates challenges that take time to solve. For example, we designed Live Translation so that our users’ conversations stay private — they’re processed on device and are never accessible to Apple — and our teams are doing additional engineering work to make sure they won’t be exposed to other companies or developers either.

We know it isn't necessary because Apple believes it is possible and are working on it. That's a pretty good indication that Airpods and their associated stack are currently being treated differently for a feature which fundamentally boils down to streaming audio to and from the headphones. It's not even clear how 'securing' live translated audio is any different from 'securing' a FaceTime call in your native language. I think a reasonable reading sans more technical information from Apple is that they give Airpods more data and control over the device than is necessary, and they want us to be mad at the DMA for forcing them to fix it.

	▲	atq2119 3 hours ago \| parent [-]
		Agreed. There is no sane reason why live translation and/or its privacy properties should depend on the specific headphones used. Even if the live translation were to happen in the headphones themselves, that should only tie the availability of the feature to the headphones. The privacy implications ought to be orthogonal. I see three possibilities. Either the whole thing is made up entirely by Apple for bad faith reasons. Or some non-technical person with bad faith motivations at Apple suffered from some internal misunderstanding. Or somebody at Apple made some incredibly bad technical decisions. Basically, there's no way that this isn't a screw up by somebody at Apple in some form. We just can't say which it is without additional information.

▲ sippeangelo 6 hours ago | parent | prev | next [-]

It sounds like a straight up lie. Third party apps have always been able to record from microphones, and the live translation doesn't work without a connection to its app. They're just annoyed that they have to share their private APIs that let them do it without the normal restrictions for apps.

▲ giancarlostoro 6 hours ago | parent | next [-]

> Third party apps have always been able to record from microphones

Maybe not the way Apple is doing it is my guess. Apple can bypass security concerns for Apple itself since they know they aren't doing anything malicious.

I love Apple and would love better integration with other headsets, but I have a feeling none of us have the full picture.

▲ pk455 6 hours ago | parent | prev [-]

why should they have to share those private APIs?

▲ STKFLT 6 hours ago | parent | next [-]

Because the DMA legally obligates them to share those APIs when they are necessary to implement a feature for a connected device. The goal of the regulation is to promote healthy competition for connected devices by outlawing self-preferencing by massive players. Reasonable people can disagree about the goals or the downstream effects of the DMA, but creating Private APIs for connected device features absolutely falls under the umbrella of self-preferencing.

▲

mbirth 5 hours ago | parent [-]

> creating Private APIs for connected device

In the same way, the EU could ask manufacturers of wireless headphones to open up and homologise their proprietary “APIs” with which they communicate with the other earpiece so you can mix&match single earpieces from different manufacturers.

	▲	tpush 5 hours ago \| parent \| next [-]
		Yeah, they could.
	▲	tpm 5 hours ago \| parent \| prev [-]
		The point of this regulation (DMA) is to enable more competition in important market segments. If this exact thing becames somehow very important, sure, it's possible, otherwise it's a bit contrived. What's the point?

▲ AlotOfReading 6 hours ago | parent | prev | next [-]

Let's flip this. It's the user's device, providing the user's data to the user's headphones, via an app the user has chosen, that was written by a developer vetted by Apple, who's already reviewed and approved the code that will be running. And it's the law that they have to.

Why shouldn't they share those APIs?

▲ danaris 5 hours ago | parent [-]

Because the user's device, providing the user's data to the user's Meta headphones, via a Meta app, can then record all the time and exfiltrate all that recorded data to Meta.

Or whatever other shady company wants to make headphones that sell for dirt-cheap in order to get their private spy devices into people's homes and offices.

I'm personally a bit on the fence about whether I think this is a sufficient concern to justify what Apple's doing, but AIUI this is the gist of their objection.

▲ AlotOfReading 4 hours ago | parent [-]

If it violates Apple's views on acceptable privacy practices, why are they approving the app? They already have guidelines against identifying information or collecting more data than absolutely required. The developer data use page is quite frank about the expectations:

    Apps on the app store are held to a high standard for privacy, security, and content because nothing is more important than maintaining users' trust.

This is a rhetorical question, obviously. Apple is happy to stand on principle when it benefits them, and more than willing to soften or bend those principles when it'd be too difficult.

	▲	danaris 3 hours ago \| parent [-]
		If a particular app only demonstrates this undesirable behavior when the phone is paired with a particular subset of headphones (or other hardware), then Apple may never notice it in App Review.

▲ fundatus 6 hours ago | parent | prev | next [-]

Because (since they control the platform/market) they're giving themselves an unfair advantage over competitors.

Example: iCloud photos backup can upload a photo to iCloud in the background immediately after it was taken. Competing cloud storage providers cannot do this[1], because Apple withholds the API for that. Of course they're saying this is for "privacy" or for "energy saving" or whatever, but the actual reason is of course to make the user experience with competing services deliberately worse, so that people choose iCloud over something else.

[1] There is some weird tricks with notifications and location triggers that apps like Nextcloud or Immich go through to make this work at least somewhat but those are hacks and it's also not reliable.

	▲	troupo 5 hours ago \| parent [-]
		> Competing cloud storage providers cannot do this[1], because Apple withholds the API for that. Of course they're saying this is for "privacy" or for "energy saving" or whatever, but the actual reason is of course to make the user experience with competing services deliberately worse, so that people choose iCloud over something else. Which makes Google Photos so much more impressive because it's heads above iCloud in this regard. No idea how they do that, pure magic.

▲ troupo 5 hours ago | parent | prev [-]

They can chose not to share them. But then they should stop preventing other from shipping the same functionality.

So, I'm a user who's looking to buy some headphones. Why can't I buy any headphones that offer live translation functionality except Apple's?

▲ solatic 4 hours ago | parent | prev | next [-]

I read this thinking about how movie studios tried to have a fully encrypted chain between the TV, the cable, the graphics card, all the way down so that HDCP would prevent anybody from putting something in the middle to record movies onto.

I don't think it's beyond the pale to argue that some shady headphone company could throw a cell modem into a set of over-the-ear headphones to exfiltrate audio. I just can't see the business case for it, even considering shadier business cases.

▲ inetknght 6 hours ago | parent | prev [-]

> This sounds bogus right? If all the headphones can do is transmit audio via first party operating system features how is this creating a data privacy issue?

Wait until third parties "require" an app to be installed, and the headphones send audio as data to the app instead of calling itself a microphone, and the app then sends that data to wherever you don't want it to.

Bose, for example, "requires" an app to be installed. For "updates", they tell you. Updates... to headphones...?!

▲

dragonwriter 6 hours ago | parent | next [-]

> Bose, for example, "requires" an app to be installed. For "updates", they tell you. Updates... to headphones...?!

The headphones work without the app, but the app is required for updates (the headphones have onboard software) and also if you want to manage the multipoint connection capability from your phone (which can be more convenient than doing it from the headphones and each device you want to connect to, but is not necessary to use the feature.)

▲

general1465 3 hours ago | parent | prev | next [-]

Yes this is a thing. I.e. I have Samgung Buds and first thing my Samsung phone did was to load new firmware into them, probably for active noise protection

▲

mcsniff 6 hours ago | parent | prev [-]

Stop the FUD with those quotes. Bose does not require or "require" an app to be installed to use their headphones and I'm not sure any vendor of BT headphones does; feel free to share if that's not the case...

I do not install vendor apps for BT peripherals, and have been through the QC and 700 series of headphones without using their app. Same for Google and Samsung BT earbuds.

Can you install an app and get updates for bugs or changes to equalizer, noise cancellation, or other features (wanted or unwantes)? Yes, but it is not required nor "required", whatever that means.

▲

inetknght 2 hours ago | parent [-]

> Stop the FUD with those quotes. Bose does not require or "require" an app to be installed to use their headphones and I'm not sure any vendor of BT headphones does

Is it FUD? It's fear, for sure. Uncertainly maybe. Doubt, not really.

An app that doesn't do that today is an app that could do that after an update tomorrow.

As for firmware... well the fact that something that just processes audio needs a firmware update demonstrates that the company isn't doing proper engineering. Proper engineering processes would be able to resolve just about anything with firmware before it gets released. Yes there "might" be bugs. No, those bugs shouldn't be severe. And regardless of proper engineering, a firmware that doesn't send telemetry back today is a firmware that could send telemetry after an update tomorrow.

So it is FUD? No. It's awareness of what's possible.

	▲	StopDisinfo910 7 minutes ago \| parent [-]
		Yes, it’s FUD. You are implying things which are untrue to serve your purpose through fear. That’s highly dishonest. You are welcome.