Up the kriek: Apple gets punchy in Brussels DMA compliance workshop Thursday 3 July 2025
在克里克（Kriek）：苹果在2025年7月3日（星期四
After all the fun of attending the second Microsoft DMA Compliance Workshop in person, I attended the similar Apple event remotely, as I was Best Man at my oldest schoolfriend’s wedding in the afternoon. The quotations below are from a transcript I made from the official EC Stream recording.
在亲自参加第二次Microsoft DMA合规研讨会的乐趣之后，我远程参加了类似的Apple活动，因为我是下午在我最大的Schoolfriend婚礼上的伴郎。下面的报价来自我从官方EC流录制中制作的成绩单。
Session 1: Interoperabiity
会议1：互操作性
The first session was looking back at the first year of DMA, and Apple’s interoperability. Kyle Andeer, vice president of products and regulatory law at Apple, came out fighting immediately. He said Apple does not believe “that the lawmakers intended for the EC’s DMA teams to be the final arbiters of user safety and security”, and that the Commission clearly doesn’t know how to do its job:
第一届会议是回顾DMA的第一年和苹果的互操作性。苹果产品和监管法副总裁凯尔·安德尔（Kyle Andeer）立即出来。他说，苹果不认为“立法者打算让EC的DMA团队成为用户安全和保障的最终仲裁员”，并且委员会显然不知道该如何做工作：
The Commission still has an opportunity to create a workable requirement here, to create a proportional interpretation of the DMA, to focus on interoperability areas where clear contestability risks appear, and to pay closer attention to the technical implications of their requirements.
委员会仍然有机会在这里创建可行的要求，对DMA进行比例的解释，专注于出现明显的可竞争性风险的互操作性领域，并密切关注其要求的技术含义。
He gave several indications that Apple intends to litigate until the 29th century:
他给出了一些迹象，苹果打算在29世纪进行诉讼：
As we’ve made clear here, we have disagreements with the EC’s interpretation of Article 6-7 and have exercised our fundamental right to seek judicial review … We think the ambiguity in the law is so significant, and we recognize that the commission has taken its positions, in some cases we think extreme positions, that we hope can be tested as quickly as possible by the European court … It’s unfortunate, very unfortunate, that we’re going to have to wait years in some cases for the courts to weigh in… And we’re going to be looking forward to getting some of that guidance from the courts.
正如我们在这里清楚的那样，我们与EC对第6-7条的解释有分歧，并行使了寻求司法审查的基本权利……我们认为，法律的歧义是如此重要，我们认识到委员会在某些情况下，我们认为在欧洲的某些情况下，我们可以尽可能迅速地审议其立场，以至于我们可以在某些情况下进行迅速的考验……不幸的是，我们的不幸能够在不幸的情况下，以至于我们能够在不幸的情况下，以至于我们能够在某些情况下能够胜任，以至于我们能够在某些情况下能够胜任，以至于我们能够在不幸的情况下，以至于我们能够在某些情况下能够付出不可思议的能力。权衡……我们将期待从法院获得一些指导。
Obviously, this isn’t at all “unfortunate” for Apple; while it wastes time and EU money on litigation, it will continue to rake in billions of dollars of rent from its AppStore tax – which is particularly important now Judge Gonzales Rogers has forbidden Apple’s off-app sales tax in the USA.
显然，对于苹果来说，这一点都不是“不幸的”。尽管它浪费了时间和欧盟在诉讼上的钱，但它将继续从其Appstore税中赚取数十亿美元的租金 - 现在尤其重要，现在冈萨雷斯·罗杰斯（Gonzales Rogers）法官禁止Apple在美国的非应用程序销售税。
Indeed, the tactic of endlessly litigating is classic Apple; as its former General Counsel, Bruce Sewell explained to law students, they
确实，无休止诉讼的策略是经典的苹果。作为前总法律顾问，布鲁斯·塞维尔（Bruce Sewell）向法学院的学生解释了
work out how to get closer to a particular risk but be prepared to manage it it it does go nuclear, … steer the ship as close as you can to that line because that’s where the competitive advantage occurs… Apple had to pay a large fine, Tim [Cook]’s reaction was that’s the right choice, don’t let that scare you, I don’t want you to stop pushing the envelope.
弄清楚如何面对特定风险，但要准备管理它的确会核能核能，……将船尽可能地转移到那条线上，因为那是竞争优势发生的地方……苹果必须支付很大的罚款，蒂姆[库克]的反应是正确的选择，不让您吓到您，我不希望您停止推动信封。
After these warning shots, Andeer went on to tug on our heart strings:
这些警告镜头后，安德尔继续拖着我们的心弦：
But in order to comply with the EC’s interpretation of the DMA, all the changes we’ve put in place lead to very un-Apple bureaucratic processes we aren’t used to.
但是，为了遵守EC对DMA的解释，我们进行的所有更改都会导致我们不习惯的非常不及格的官僚流程。
It’s true: Apple will have to design for interoperability, and -most egregiously- will have to pause to consider the legality and potential monopolistic potential of its products before launching them. Very un-Apple, indeed.
的确：苹果将不得不设计互操作性，并且 - 最令人震惊的 - 必须暂停以考虑其产品在推出产品之前的合法性和潜在的垄断潜力。的确，非常无关。
Personally, I started welling up when I realised that Apple’s reluctance to comply with the interpretation of the law by those entrusted to administer it is not because that could hurt a struggling Cupertino technology company, but could harm everybody else, too:
就我个人而言，当我意识到苹果不愿遵守委托给管理的人对法律的解释时，我开始放松身心，不是因为这可能会伤害一家挣扎的库比蒂诺技术公司，而是可能伤害其他所有人：
No, our focus is not on just the billion-dollar companies, but also the millions of developers today and to come in the future.
不，我们的重点不仅仅是数十亿美元的公司，而是当今数百万的开发商以及将来的发展。
This contrasts with the US Department of Justice, whose lawsuit against Apple [PDF] notes
这与美国司法部形成对比，美国司法部针对苹果[PDF]的诉讼
Competition is what will ensure that Apple’s conduct and business decisions do not thwart the next Apple
竞争将确保苹果的行为和业务决策不会阻止下一个苹果
What Apple calls the Commission’s “extreme interpretation of interoperability” is going to hurt EVERYONE, including developers, the economy, puppy dogs, fluffy kittens, and even EU consumers.
苹果所说的委员会“对互操作性的极端解释”将伤害所有人，包括开发商，经济，幼犬，蓬松的小猫甚至欧盟消费者。
Throughout Apple’s history, it has entirely been in Apple’s interest to invest in giving developers the technologies they need, to create great apps for our users to enjoy, and we’re continuing to do so. Unfortunately, because the EC’s version of interoperability flips that successful model on its head, we’ve already had to make the decision to delay the release of products and features we announced this month for our EU customers. These features include enhancements to iPhone mirroring and new Maps features like visited places and preferred routes.
在苹果的整个历史上，投资为开发人员提供所需的技术，为我们的用户创建出色的应用程序，并且我们正在继续这样做，这完全符合苹果的兴趣。不幸的是，由于EC的互操作性版本将成功的模型倒在其头上，因此我们已经决定延迟我们本月为欧盟客户宣布的产品和功能的发布。这些功能包括对iPhone镜像的增强功能和新的地图功能，例如访问的地方和首选路线。
John Ozbay, of Open Web Advocacy, asked about the process by which developers and other supplicants can request interoperability with iOS:
Open Web倡导的John Ozbay询问了开发人员和其他求职者可以与iOS互操作的过程：
the commission made it clear, if Apple wants to run a request-based system, it must meet basic standards. That includes short response timelines, a clear process with deadlines for Apple, proper explanations when a request is rejected, and a public searchable tracker showing the status of all requests accessible to any developer. Now, none of this is difficult, and Apple already runs public GitHub trackers for other projects. They could have done the same here or built something custom with the brilliant engineers they have. But instead, and this is the genuinely bizarre part, they chose to publish a PDF. Static document, updated once a week, hidden behind a hard-to-find link. No search, no comments, no filtering, or no interactivity. So our question is this. Does Apple believe that a static PDF meets the very clear requirements laid out by the Commission? Thank you.
委员会明确表示，如果苹果想运行基于请求的系统，则必须符合基本标准。其中包括简短的响应时间表，一个清晰的过程，截止时间为Apple的截止日期，拒绝请求时进行了适当的解释以及一个可公开搜索的跟踪器，显示所有开发人员均可访问的所有请求的状态。现在，这都不困难，苹果已经为其他项目运行了公共GitHub跟踪器。他们本可以在这里做同样的事情，或者与他们拥有的出色工程师建立了一些定制的东西。但是，相反，这是真正奇怪的部分，他们选择出版PDF。静态文档每周更新一次，隐藏在难以连接的链接后面。没有搜索，没有评论，没有过滤或没有交互性。所以我们的问题是这个。苹果是否认为静态PDF符合委员会提出的非常明确的要求？谢谢。
Apple replied
苹果回答
Now, we are amazing at what we do. We can do amazing things. Achieving a fantastic solution against those deadlines while trying to comply with the obligations placed upon us causes some practical realities. We set out to comply. We did something that was the absolute best we could achieve in that short timeline. And, of course, we will be looking as we go along to enhance it as we do with everything we work on. It is also available to all developers. Just log in to App Store Connect to access it.
现在，我们的工作很棒。我们可以做惊人的事情。在试图遵守对我们的义务的同时，实现了对这些截止日期的绝妙解决方案，这会导致一些实际的现实。我们着手遵守。我们做了一些绝对最好的事情，在短时间内我们可以实现。而且，当然，我们将随着我们所做的所有工作而进行增强时，我们将期待。它也可供所有开发人员使用。只需登录到App Store Connect即可访问它。
I managed to ask one question about the interoperability process:
我设法问了一个有关互操作性过程的问题：
On behalf of Vivaldi, I submitted an interop request for 3rd party browser engines to read iOS Parental Control settings on Nov 15, 2024 [INTEROP-246]. On Mar 7, 2025 I received Apple’s response: “We will introduce new API to the BrowserEngineKit framework to interoperate with Web Content restrictions … This is a mild engineering effort. We plan to complete development of this solution by March 2026, and ship it shortly thereafter”. Does Apple genuinely believe that 16 months for a mild engineering effort is fast enough? Vivaldi is 57 people, but we’re happy to loan you a C++ engineer if this will expedite implementation
我代表Vivaldi提交了第三方浏览器引擎的Interop请求，以在2024年11月15日[Interop-246]阅读iOS父母控制设置。在2025年3月7日，我收到了苹果的回应：“我们将向BrowserEngineKit框架介绍新的API，以与Web内容限制互操作……这是一种温和的工程工作。我们计划在2026年3月之前完成该解决方案的开发，并在此后不久将其发货。”苹果是否真的认为，轻度工程努力的16个月足够快？Vivaldi是57人
(Well, that’s what I typed into Slido but, although that is still shorter than most of the in-person questions, Slido rejected it as too long. So I had to frantically edit all the context out, until it became “In November 24, I sent an interrupt request for all the browser engines to read iOS parental control settings. In March, Apple said, “this is a mild engineering effort. We plan to complete by March 2026.” The question is, is 16 months for a mild effort fast enough?”)
（好吧，这就是我输入的Slido的内容，但是尽管这仍然比大多数面对面的问题要短，但Slido拒绝了它的时间太长。因此，我不得不疯狂地编辑所有上下文，直到“直到11月24日它变成11月24日，我在3月份的3月份都在浏览ios parten swart in this Isseries oferning。16个月，以迅速迅速努力吗？”）
Andeer answered
安德尔回答
we are working through a number of different requests. Some of those are very simple and we get solutions out very quickly. Others are more complex. When you’re talking about parental controls, you’re talking about tools that are used to protect children. Those are not tools that we are going to simply rush through and see what happens. There are going to be different standards here in terms of what we’re being asked to provide. If we think children are going to be at risk, whether it’s through manipulative or deceptive advertising techniques or other things on our platform that puts them at risk, we’re going to be very careful about developing those solutions.
我们正在处理许多不同的请求。其中一些非常简单，我们很快就可以解决解决方案。其他人更加复杂。当您谈论父母控制措施时，您正在谈论用于保护儿童的工具。这些不是我们只是匆匆忙忙地看看会发生什么的工具。就我们被要求提供的内容而言，这里的标准将有所不同。如果我们认为孩子将处于危险之中，无论是通过操纵或欺骗性的广告技术还是我们平台上的其他事物使他们处于危险之中，我们将非常谨慎地开发这些解决方案。
Andeer’s more jovial sidekick, Gary Davis, senior director on Apple’s legal team in Europe, added
苹果法律团队的高级总监加里·戴维斯（Gary Davis）在欧洲法律团队高级总监加里·戴维斯（Gary Davis）补充说
Maybe just one small point on the mild engineering efforts. That’s not a term that we would use, of course, in the normal course. That’s a term that was introduced by the specification decision. So we are required to indicate efforts as mild, medium, and significant. And so the actual engineering effort was mild. It still takes considerable time. As Kyle indicated, we have to do it in a way that takes full respect of the risks that arise in that space.
也许只有一个小点就轻度的工程工作。当然，这不是我们在正常课程中使用的术语。这是规格决定引入的术语。因此，我们必须表明努力是轻度，中等和重要的。因此，实际的工程工作是温和的。它仍然需要大量时间。正如凯尔（Kyle）指出的那样，我们必须以一种充分尊重该空间中出现的风险的方式来做。
So, that was my answer: a mild engineering effort still takes a year, and if you think that’s too slow, WILL NO-ONE THINK OF THE CHILDREN???
因此，这是我的回答：温和的工程努力仍然需要一年，如果您认为这太慢了，那就不会有人想到孩子吗？？？
In the next session, James Heppell from Open Web Advocacy returned to my point:
在下一个会议上，来自Open Web倡导的James Heppell回到了我的观点：
it sounds that you had six, seven months to implement or at least to know that you had to implement the interoperability system. And sure, maybe it’s hard to create a new system in that time, but we’re not saying you have to make something from scratch. There’s lots of existing systems like GitHub, like Bugzilla for WebKit, like all of these things you use internally that you could have used, which would have been much, much more helpful to developers than the PDF. And in reference to the App Store thing, you say you’re very contactable, that we can come to you with these problems, but there’s not actually a button (unless the app has already been installed) in the App Store to report scams when people try and get in touch with you. It’s a bit of a joke in the website stuff, in the browser community, that sometimes there’s the black hole of the Apple interoperability thing, because we just don’t get back answers sometimes. It’s months. Bruce had the question about 16 months replies. It’s not really workable.
听起来您有六，七个月的实施或至少要知道您必须实现互操作性系统。当然，也许在那时很难创建一个新系统，但我们并不是说您必须从头开始做一些事情。有很多现有的系统，例如GitHub，例如WebKit的Bugzilla，就像您内部使用的所有这些内容一样，您本可以使用的所有这些东西，对开发人员比PDF更有帮助。而且，关于App Store的内容，您说您非常可以联系，我们可以解决这些问题，但是当人们尝试与您联系时，实际上没有一个按钮（除非已经安装了应用程序）在App Store中报告骗局。在浏览器社区中，在网站上有点开玩笑，有时是Apple互操作性的黑洞，因为有时我们只是没有回答答案。是几个月。布鲁斯有一个大约16个月的答复问题。这不是真的可行。
According to Apple, they didn’t have time to set up a Github/ Bugzilla system, and anyway, the system is working brilliantly:
根据苹果公司的说法，他们没有时间设置GitHub/ bugzilla系统，无论如何，该系统正常工作：
I think one needs to take account of the time period, the discussion, the correct outcome, what the Commission had in mind, what we could agree to before one could work towards an acceptable outcome. But I believe the process is working really well now. I believe requests are coming in. We are responding within the allotted time. We have some very specific times that we need to respond by. All of those times have been met, Not one single one of those has been missed in the time period in which we’ve been asked to respond in.
我认为，人们需要考虑到时间段，讨论，正确的结果，委员会的想法，我们可以同意的事情，然后才能努力朝着可接受的结果努力。但是我相信这个过程现在运行良好。我相信请求即将到来。我们在分配的时间内做出回应。我们有一些非常具体的时间需要做出回应。所有这些时期都已经满足了，在我们被要求回应的时间段内，没有一个人被错过。
At that point, it was lunchtime, and I had to go to a wedding. Luckily, OWA had sent three of their finest operatives (codenamed The Chauffeur, The Piano Man, and The Hepcat) and I caught up with the recording next day.
那时，那是午餐时间，我不得不参加婚礼。幸运的是，奥瓦（Owa）派出了三名最好的特工（代号为司机，钢琴男子和赫普卡特（Hepcat）），第二天我赶上了录音。
Session 2: App Store
会议2：App Store
The headline of this session was that Apple is dropping its Core Technology Fee. Or, more accurately, renaming it. There are a huge number of tweaks to the Apple Taxes, and to the customer experience (you can read them in the full transcript). The most important part for me is a new “unified model” of payments to Apple
本次会议的标题是苹果正在放弃其核心技术费用。或者，更准确地将其重命名。苹果税和客户体验有很多调整（您可以在完整的成绩单中阅读）。对我而言，最重要的部分是向苹果支付的新“统一模型”
that all developers will be subject to starting next year. First, there will be a Core Technology Commission, or CTC, of 5% on sales of digital goods and services. The CTC reflects value Apple provides to developers regardless of whether they choose the App Store or alternatives for distribution. The CTC is not tied to whether a developer is distributing through the App Store or steering a customer to making a purchase outside of the store. The CTC reflects Apple’s ongoing investments in platform tools, technologies, and services that enable developers to build and share innovative apps with users. To be clear, as of January, there will be no core technology fee. There will only be the CTC. Second, developers distributing apps on the App Store will pay an App Store Commission on sales of digital goods and services. So this captures things like subscriptions, digital content, and paid apps. Developers who choose alternative distribution do not pay this commission… Under the new terms, there is also a store services fee, or SSF. That reflects the ongoing services and capabilities that Apple provides to developers, including app distribution and management, rediscovery and engagement, app insights, and more.
所有开发人员将从明年开始。首先，数字商品和服务的销售额将有一个核心技术委员会（CTC）为5％。CTC反映了Apple为开发人员提供的价值，无论他们是选择App Store还是替代产品进行分发。CTC与开发人员是通过App Store分发还是指导客户在商店外进行购买。CTC反映了苹果公司对平台工具，技术和服务的持续投资，使开发人员能够与用户构建和共享创新的应用程序。需要明确的是，从一月份开始，将没有核心技术费用。只有CTC。其次，开发人员在App Store上分发应用程序将向App Store委员会支付数字商品和服务的销售。因此，这捕获了订阅，数字内容和付费应用程序之类的内容。选择替代分销的开发人员不付款此委员会……根据新条款，也有商店服务费或SSF。这反映了苹果为开发人员提供的持续服务和功能，包括应用程序分销和管理，重新发现和参与，应用程序洞察力等。
The Core Technology Commission really offends me, as it’s a tax on using the iOS operating system. Developers must already purchase an Apple Developer License every year, buy a Mac to run Xcode, and various iThings to test on, yet must also pay this tax.
核心技术委员会确实冒犯了我，因为这是使用iOS操作系统的税收。开发人员必须每年购买Apple开发人员许可证，购买Mac以运行Xcode，并进行测试，但还必须缴纳此税。
Other device manufacturers know the value of a vibrant app ecosystem gives them. For example, a few days ago, a Danish judge found Google had abused Android to safeguard its dominant position in online advertising. One of the ways it did this was tying access to the Play Store to the pre-installation of the Google Search app and Google Chrome. It could do this because it knew most device manufacturers would be unwilling to ship phones that had no access to an full application store.
其他设备制造商知道充满活力的应用程序生态系统的价值。例如，几天前，丹麦法官发现Google滥用了Android来维护其在在线广告中的主导地位。这样做的方法之一是将访问Play Store的访问权限与Google Search App和Google Chrome的预装。之所以这样做，是因为它知道大多数设备制造商都不愿运送无法访问完整应用商店的电话。
Developers are essential to a vibrant app store, and so vital to Apple’s success. I can see no moral justification for a Core Technology Commission/ Fee/ Tax. It’s just rent extraction.
开发人员对于充满活力的应用商店至关重要，对苹果的成功至关重要。我看不到核心技术委员会/费用/税收的道德理由。只是租金提取。
Of course, Apple claims that its marvellous curation of the AppStore is what makes it so valuable to developers:
当然，苹果声称其对Appstore的奇妙策划使其对开发人员如此有价值：
A big reason why small developers around the world have been able to reach massive audiences on the App Store is because users trust the App Store. In fact, it’s hard to remember what downloading software was like before the App Store. Back then it was the Wild West of the open web. You never really knew what you were downloading. At Apple, we set out to change all that and build a marketplace that users could trust.
世界各地的小型开发人员能够吸引App Store上的大量受众的重要原因是用户信任App Store。实际上，很难记住App Store之前的下载软件。那时就是开放网的野外西部。您从来不知道要下载什么。在苹果公司，我们着手改变所有这些，并建立一个用户可以信任的市场。
That pesky “open web”, eh? No school shooter apps, sanctioned Russian bank apps or ripped-off games get past the in-depth App Store review process. Thanks for saving us, Auntie Apple!
那个讨厌的“开放网”，是吗？没有学校射击游戏应用程序，批准的俄罗斯银行应用程序或剥夺的游戏超越了深入的应用商店评论流程。感谢您拯救我们，苹果阿姨！
John Ozbay from Open Web Advocacy made this point in his usual terse manner:
来自Open Web倡导的John Ozbay以他通常的简短方式提出了这一点：
Kyle, you spoke at length about the App Store as if every app is carefully reviewed, safe, and secure. But that doesn’t simply match the reality. We use the App Store daily. And every single week we’re served ads, often directly from Apple, for apps that are live in the store right now and clearly designed to scam users out of money. These are called fleeceware apps. And they rely on deceptive subscription models and dark patterns to exploit users. And Apple’s review process is ineffective at solving this. So some facts are pretty striking. Apple has just 500 reviewers looking at over 130,000 apps every week. And most of them only spend a few minutes per app, if you divide and do the math. So few have technical backgrounds, and mainly just click around the interface from what we’re understanding. And they work 10-hour shifts. And even Apple’s own executives, once worried it might resemble sweatshop conditions, according to what’s come out. But the real eye-opener for me comes from internal emails revealed during the Epic versus Apple case. Senior Apple staff were openly frustrated, and some quotes, and some of my favorites are, Is no one reviewing these apps? This is insane. A bunch of explanation points. AppReview is bringing a plastic butter knife to a gun flight. They’re more like greeters at a Hawaiian airport than drug-sniffing dogs. Just like in October, AppReview fails to review properly.
凯尔（Kyle），您详细地谈论了App Store，就好像每个应用程序都经过精心审查，安全和安全。但这不仅仅与现实相匹配。我们每天使用App Store。而且，每个星期，我们通常会直接从Apple提供广告，用于现在居住在商店中并且显然旨在骗用户赚钱的应用程序。这些被称为Fleceware应用。他们依靠欺骗性的订阅模型和黑暗模式来利用用户。苹果的审查过程无效地解决了这一问题。因此，有些事实令人惊讶。苹果每周只有500名评论者查看130,000多个应用程序。如果您分开并进行数学，他们中的大多数人只会花几分钟。因此，很少有技术背景，主要是从我们的理解中单击界面。他们工作了10小时。据出现，即使是苹果自己的高管，也一旦担心它可能类似于汗工厂的条件。但是对我来说，真正的大开眼界来自史诗与苹果案中揭示的内部电子邮件。苹果高级员工公开感到沮丧，一些报价，我的一些最爱是没有人审查这些应用程序的人吗？这太疯狂了。一堆解释点。Appreview将一把塑料刀带到枪支飞行中。它们更像是在夏威夷机场的迎接人，而不是吸毒的狗。就像10月一样，Appreview无法正确审查。
Session 3: browser choice architecture
会议3：浏览器选择体系结构
Apple’s choice screen started out as a terrible mess, but with feedback from other browser vendors and the EC, Apple re-designed it a much better way. I have my disagreements with how the Gatekeeper chooses which competiitors it shows on the choice screen, which I’ve raised with the DMA team, but Mozilla, DuckDuckGo (and we at Vivaldi) have seen user numbers increase. I also question why a browser is limited to how often it can check if it’s default (4 times a year).
苹果的选择屏幕最初是一个可怕的混乱，但是借助其他浏览器供应商和EC的反馈，Apple重新设计了一个更好的方法。我对看门人在选择屏幕上显示的竞争者如何选择了我与DMA团队一起提出的竞争者的分歧，但是Mozilla，Duckduckgo（Vivaldi的我们）看到了用户数量的增加。我还质疑为什么浏览器仅限于可以检查一次默认值的频率（每年4次）。
But Apple deserves congratulation on its choice to follow the spirit of the DMA by putting the newly-chosen default browser in Safari’s place on the “hotseat” (the bottom row of apps that always shown, regardless of which home screen is in view). As Roderick Gadellaa from Open Web Advocacy said,
但是，苹果应该恭喜您选择遵循DMA的精神，将新选择的默认浏览器放在Safari的位置上的“ hotseat”（无论哪个主屏幕在哪个主屏幕上，始终显示的应用程序的底部行）。正如Open Web倡导的Roderick Gadellaa所说，
we agree with Apple that the hot seat should be default on Android as well. So we will be raising this tomorrow.
我们同意Apple的观点，即热座也应该在Android上默认。因此，我们明天将举起这个。
Then, Roderick turned to the ridiculous terms Apple imposes on vendors who want to ship non-WebKit browsers:
然后，罗德里克（Roderick）转向苹果（Apple）对想要运送非webkit浏览器的供应商的荒谬术语：
The DMA has been enforced now for 15 months. Despite this, not a single browser vendor has been able to port their browser using its own engine to iOS. It’s not because they’re incapable or they don’t want to; it’s because Apple’s strange policies are making this nearly impossible. One of the key issues slowing progress is that Apple is not allowing browser vendors to update their existing browser app to use their own engine in the EU, and Apple’s WebKit engine elsewhere. This means that browser vendors have to ship a whole new app just for the EU and tell their existing EU customers to download their new app and start building the user base from scratch. Now, we would love for Apple to allow competing browsers to ship their own engines globally. But if they insist on allowing this only in the EU, Apple can easily resolve this problem. Here’s how. They can allow browsers to ship two separate versions of their existing browser to the App Store, one version for the EU and one for the rest of the world. Something which is currently possible in other App Stores. This would allow existing European users to get the the European version of the app without having to download a separate app simply by receiving a software update. But it seems Apple doesn’t want that, and they make this very clear in their browser engine entitlement contract. Given that, Apple can easily resolve this problem simply by allowing browsers to ship a separate version of the app to the EU under the same bundle ID. Why is Apple still insisting that browser vendors lose all their existing EU customers in order to take advantage of the rights granted on the DMA?
DMA现在已执行15个月。尽管如此，没有一个浏览器供应商能够使用自己的引擎将其浏览器移植到iOS上。这不是因为他们无能为力，也不是他们不想。这是因为苹果的奇怪政策使这几乎变得不可能。放缓进度的关键问题之一是，Apple不允许浏览器供应商更新其现有的浏览器应用程序在欧盟中使用自己的引擎以及其他地方的Apple WebKit引擎。这意味着浏览器供应商必须仅为欧盟运送一个全新的应用程序，并告诉他们现有的欧盟客户下载其新应用并开始从头开始构建用户群。现在，我们希望Apple能够允许竞争的浏览器在全球运输自己的发动机。但是，如果他们坚持只允许在欧盟中允许这样做，苹果可以轻松解决此问题。这是方法。他们可以允许浏览器将其现有浏览器的两个单独版本运送到App Store，一个用于欧盟的版本，另一个用于世界其他地区。目前在其他应用商店中可能发生的东西。这将使现有的欧洲用户能够获取该应用程序的欧洲版本，而不必仅通过接收软件更新即可下载单独的应用程序。但似乎苹果不想要那样，他们在浏览器发动机应享的合同中非常清楚。鉴于此，Apple只需允许浏览器将应用程序的单独版本运送到同一捆绑包ID下的欧盟即可轻松解决此问题。为什么苹果仍然坚持要浏览器供应商失去所有现有的欧盟客户以利用DMA授予的权利？
This wasn’t answered. Gary handwaved:
这没有回答。加里（Gary）手动：
both Google and Mozilla have everything they need to build their engines and ship them on iOS today. We heard some other issues mentioned. We are happy to engage in those issues. We are engaging on those issues, but everything is in place to ship here in the EU today. I think that’s an extremely important point to take away from this.
Google和Mozilla都拥有构建引擎并将其运送到iOS上所需的一切。我们听到了提到的其他一些问题。我们很高兴参与这些问题。我们正在谈论这些问题，但是今天一切都可以在欧盟发货。我认为这是一个非常重要的一点。
Kyle added
凯尔添加了
I think one other point I wanna make sure I address as I reflected upon the end, there was a question about why we don’t do this on a global basis. And I think we’ve always approached the DMA as to the European law that relates to Europe. And we are not going to export European law to the United States, and we’re not going to export European law to other jurisdictions. Each jurisdiction should have the freedom and decision making to make its own decisions. And so we’re going to abide by that.
我认为另一点我想确保我在回顾结束时解决问题，这是一个问题，为什么我们不在全球范围内不这样做。而且我认为，关于与欧洲有关的欧洲法律，我们一直在与DMA联系。而且我们不会向美国出口欧洲法律，也不会向其他司法管辖区出口欧洲法律。每个司法管辖区都应该有自由和决策来做出自己的决定。因此，我们将遵守这一点。
Frederick from riedel.wtf asked about APIs currently avalable to WebKit-based browsers (similar to mine about Parental Controls earlier):
来自Riedel.wtf的Frederick询问了目前可用于基于Webkit的浏览器的API（与我的父母控制有关的浏览器类似）：
I would love to learn how Apple will make sure that existing APIs that are currently available in WebKit will be available when people decide to use custom browser engines as well. As an example, we use the ScreenTime API, more specifically the managed settings part of it that really specifically allows us to block certain websites. Users can, for example, also decide to block porn sites. also a parental control setting, but also users decide to put it on their own phones.And yeah, I would love to know if and how Apple will allow developers like me to apply such restrictions in third-party browser engines as well.
我很想了解Apple如何确保当人们决定使用自定义浏览器引擎时，将在Webkit中使用的现有API可用。例如，我们使用屏幕截图API，更具体地说是它的托管设置部分，这些部分确实允许我们阻止某些网站。例如，用户还可以决定阻止色情网站。也是父母的控制设置，但用户决定将其放在自己的手机上。是的，我很想知道Apple是否以及如何允许像我这样的开发人员也可以在第三方浏览器引擎中应用此类限制。
Kyle answered vaguely
凯尔模糊地回答
we’re in a period of transition where we built an operating system, a set of operating systems that was designed to be the most secure in the world, and that is what we have built. A critical aspect of that was our integration of WebKit into our operating systems. We’ve also introduced flexibility and APIs for third-party browser engines to take advantage of these new opportunities under the DMA. We’re also engaged in ongoing conversations with Mozilla and with the other company in terms of bringing them to iOS.
我们正处于一个过渡时期，我们建立了一个操作系统，这是一套设计为世界上最安全的操作系统，这就是我们所建造的。一个关键的方面是我们将WebKit集成到操作系统中。我们还为第三方浏览器引擎引入了灵活性和API，以利用DMA下的这些新机会。我们还与Mozilla和另一家公司进行了持续的对话，以将其带到iOS。
John Ozbay (who seems to be OWA’s “adult content” ambassador) asked about a dark pattern OWA discovered last November: iOS age restriction blocks all browsers except Safari, breaks choice screen:
约翰·奥兹贝（John Ozbay）（似乎是OWA的“成人内容”大使）询问了去年11月发现的黑模式OWA：iOS Age限制阻止了除Safari以外的所有浏览器，但Breaks Choice屏幕：
Apple has given all web browsers on iOS a 17 plus age rating, despite the fact that the websites they can load are not controlled using the age restriction setting, but using the web content restriction setting … So how can it be that the browser’s user interface itself is considered inappropriate for children, not the web content display? Given that all browsers on iOS, including Safari, use the exact same web content restriction setting, what is it about other browsers that means that they’re not allowed to be installed or used when Safari is? So thanks to this dark pattern, we discovered that most users under age of 18, an estimated up to 15% of all European users, cannot use any browser other than Safari, undermining their meaningful browser choice. So these users will grow up having only ever used Safari on iOS and perhaps not even knowing about the existence of other browsers… So given that under the article 13.4 of the DMA, Apple must not use interface design or behavioral techniques to undermine its compliance. What specific steps will Apple take to ensure that third-party browsers and social media apps are treated equally in age-restricted environments?
苹果公司在iOS上的所有Web浏览器均给出了17加年龄的评分，尽管事实上他们可以使用年龄限制设置来控制他们可以加载的网站，而是使用Web内容限制设置来控制……因此，浏览器的用户界面本身如何被认为是不适合儿童的，而不是Web内容显示，而不是Web内容显示？鉴于iOS上的所有浏览器（包括Safari）都使用完全相同的Web内容限制设置，其他浏览器是什么，这意味着在Safari是不允许安装或使用的浏览器？因此，由于这种黑暗的模式，我们发现，大多数18岁以下的用户（估计有15％的欧洲用户）无法使用Safari以外的任何浏览器，从而破坏了他们有意义的浏览器选择。因此，这些用户将长大后才在iOS上使用Safari，甚至不知道其他浏览器的存在……因此，鉴于DMA第13.4条，Apple不得使用接口设计或行为技术来破坏其合规性。苹果将采取哪些具体步骤来确保第三方浏览器和社交媒体应用在受年龄限制的环境中得到同样的处理？
Gary’s answer, again, was encouraging but so unspecific it could have been a watercolour by Turner when he was feeling especially timid:
再次，加里的回答令人鼓舞，但如此特定的特定问题可能是特纳特别胆小时的水彩：
obviously, APIs are available to WebKit or available to WebKit. I think it might be trying to make them available to others on the platform. And obviously, as we go forward– and this is in the 6(7) session– as browser engines become available, which are alternative browser engines, which I presume they will in a timeline to come, there will be 6(7) issues there as well in terms of what iOS features are available to Apple services. And so that’s something we will have a look at in that context as they come in. And certainly, those are the kinds of conversations having, even I think the question we had from Rita, that has been a topic. So you asked about the screen time APIs and how we look at those. They’re all actively under discussion. Some of those things we’ve received interoperability requests for. And I think that is a good process in which to understand what it is that developers need and respond to them in a timely manner. And I think we have been doing that. We are very anxious for child protection and age assurance reasons to make sure that that is working in a good manner on the platform.
显然，API可用于WebKit或WebKit可用。我认为这可能是试图使平台上的其他人使用它们。显然，随着我们的前进 - 这是在6（7）次会话中 - 随着浏览器发动机的可用，这是替代性浏览器引擎，我认为它们将在未来的时间表中进行，因此，就iOS功能提供了6（7）个问题。因此，这就是我们在这种情况下进来的情况。当然，这些是对话的种类，即使我认为我们从丽塔（Rita）提出的问题也是一个话题。因此，您询问了屏幕时间API以及我们如何看待这些。他们都在积极讨论中。我们收到的一些互操作性请求中的一些事情。我认为这是一个很好的过程，可以在其中了解开发人员需要并及时对他们做出反应。我认为我们一直在这样做。我们非常急于保护儿童和年龄保证理由，以确保在平台上以良好的方式工作。
So, rather than just making things interoperable, it looks like Apple want people to request piecemeal access to each system API (explaining why, so perhaps giving product plans to a gatekeeper competitor). Thereafter, it will be logged in a static PDF in a secret filing cabinet and, if it is a “mild engineering effort”, you might be able to use it in 16 months’ time. Agile!
因此，看来Apple不仅要使事情互操作，还希望人们要求对每个系统API零星访问（解释原因，因此也许将产品计划授予看门人的竞争对手）。此后，它将在秘密档案柜中登录静态PDF，如果这是“轻度的工程工作”，则您可以在16个月的时间内使用它。敏捷！
Talking of developer woe, James Heppell of OWA asked
谈到开发商的祸患时，OWA的詹姆斯·赫伯尔（James Heppell）问
Web developers globally must be able to test their sites in the new competing browsers on iOS regardless of where they’re located. We understand that Apple may not wish to allow these browsers to ship to consumers, that’s their choice, I suppose, but that is a completely separate issue to allowing developers to test it. So my question is, what solution does Apple propose to ensure that web developers outside of the EU can install and test these browsers and maintain compatibility and interoperability for users in the EU?
全球网络开发人员必须能够在iOS上的新竞争浏览器中测试其网站，无论其位置如何。我们知道，苹果可能不希望这些浏览器将其运送到消费者，这是他们的选择，但这是允许开发人员对其进行测试的完全不同的问题。因此，我的问题是，Apple提出了哪种解决方案，以确保欧盟以外的Web开发人员可以安装和测试这些浏览器并保持欧盟用户的兼容性和互操作性？
Gary’s answer was Turner-esque again:
加里的回答再次是特纳风格的：
I think as we’ve been going along, we have learned a lot as to how to facilitate that kind of testing outside of the EU, even in relation to browser engines. I think that’s a subjective, active discussion. I think we’ve been discussing it with Mozilla and Google also. And the commission, I would expect to see some updates there. So you can just generally see we are trying to be more conscious of that.
我认为，随着我们的发展，即使与浏览器发动机有关，我们也了解了很多关于如何促进欧盟之外的测试。我认为这是一个主观的，积极的讨论。我认为我们也一直在与Mozilla和Google讨论它。委员会，我希望那里看到一些更新。因此，您通常可以看到我们正在尝试更加意识到这一点。
John “porn advocate” Ozbay of OWA asked a question that we’d jammed together before the meeting:
OWA的John“ Porn Advocate” Ozbay问了一个问题，我们会在会议前一起堵塞：
Last year, after we made a lot of noise to get Apple to reinstate homescreen web apps in the EU,
去年，在我们发出很多声音以使苹果恢复欧盟的HomeScreen Web应用程序之后，
Apple announced that homescreen web apps “continue to be built directly on WebKit and its security architecture”. However, under Article 5.7 of the DMA, Apple is not allowed to impose a browser engine on either users or third-party browsers. Can Apple update us on the progress made for allowing third-party browser engines to install and manage homescreen web apps on iOS once third-party browser engines arrive on iOS?
苹果宣布，HomeScreen Web应用程序“继续直接建立在WebKit及其安全体系结构上”。但是，根据DMA第5.7条，Apple不允许对用户或第三方浏览器强加浏览器引擎。Apple能否在第三方浏览器发动机到达iOS上，允许第三方浏览器发动机在iOS上安装和管理HomeScreen Web应用程序所取得的进展？
Kyle was neither vague, nor encouraging; a sort of Francis Bacon to Gary’s Turner:
凯尔既不模糊，也不令人鼓舞。加里·特纳（Gary's Turner）的弗朗西斯·培根（Francis Bacon）：
So I think on homescreen web apps, obviously these are available today here and around the world. We have nothing to announce in terms of what we will do if and when a third-party browser engine comes to iOS. Certainly I can say from a high level perspective, our focus will continue to be, as I’ve said several times on ensuring that anything that’s operating on our platform is as secure and as private as possible, and it does not damage the operating system. Browsers and home screen web apps are different than other things. They have other access to the operating system that we will have to manage and control. And so we have not settled out on any of those issues. As I’ve said again, we’ve engaged with Mozilla, we’ve engaged with Google. We’re figuring out the solution that works best for all parties.
因此，我认为在HomeScreen Web应用程序上，显然这些在今天和世界各地都可以使用。如果以及何时出现第三方浏览器引擎，我们将无需宣布我们将要做什么。当然，我可以从高水平的角度说，我们的重点将继续存在，正如我已经说过多次确保我们平台上运行的任何东西都尽可能安全和私密的，并且不会损害操作系统。浏览器和主屏幕Web应用程序与其他方面不同。他们还可以访问我们必须管理和控制的操作系统。因此，我们尚未解决这些问题。正如我再次说的那样，我们已经与Mozilla订婚了，我们已经与Google订婚了。我们正在找出最适合各方的解决方案。
John “Fruity Fetish” Ozbay continued,
约翰·“果味恋物癖”奥兹贝继续说，
Apple has previously told the Australian and the UK regulators that web apps are a viable competitor to native apps, and their own app store developer guidelines say that if a developer does not want to use the app store, there’s always the open internet. As such, we believe that web apps should get equal treatment to native apps when it comes to installation. Users can install native apps with one click via the app store, which a website can link to, or even open without user interaction.
苹果此前曾告诉澳大利亚和英国监管机构，Web应用程序是本地应用程序的可行竞争对手，他们自己的App Store开发人员指南表示，如果开发人员不想使用App Store，那么总会有Open Internet。因此，我们认为，在安装方面，Web应用程序应获得与本机应用程序的平等处理。用户可以通过App Store单击一键安装本机应用，网站可以链接到，甚至无需用户互动即可打开。
Users can also directly install native apps with one click within browsers using smart install banners on the top.
用户还可以使用智能安装标语在顶部直接在浏览器中直接安装本机应用程序。
Web apps inside of Safari and even third party browsers are unable to do either of these at the moment. So to install a web app on iOS, user must go through a four-step process, navigating the Safari menu, finding the share icon, which I don’t know why it’s labeled share, scrolling down and clicking to the confusingly named at the home screen button instead of install.On other operating systems, most browsers clearly place this button labeled install app in the first page of the menu or in the address bar and crucially allow websites to prompt users to install web apps just like native apps. So our question is, what will Apple do to ensure quality and installability between native apps and web apps? And related to this question, has to do with iOS26… Last year, in a beta release, right before DMA deadline, Apple quietly tried to kill web apps on iOS until we, Open Web Advocacy, led an letter with over 5,000 signatures from organizations, companies, individuals, including European MEPs, to ring the alarm bells and tried to stop Apple. So this year, right before this DMA workshop, with the iOS 26 beta, Apple has made it even more difficult to install web apps and added them to add them to home screen and hidden, the functionality, two more button presses and menus deep compared to the previous version. So why is Apple trying to make it even harder than already is to install web apps and trying to add them to the home screen?
目前，Safari甚至第三方浏览器的Web应用程序都无法执行任何操作。So to install a web app on iOS, user must go through a four-step process, navigating the Safari menu, finding the share icon, which I don’t know why it’s labeled share, scrolling down and clicking to the confusingly named at the home screen button instead of install.On other operating systems, most browsers clearly place this button labeled install app in the first page of the menu or in the address bar and crucially allow websites to prompt users to install web apps just like native应用。因此，我们的问题是，Apple将如何确保本机应用程序和Web应用程序之间的质量和安装？与这个问题相关，与iOS26相关……去年，在Beta版本中，就在DMA截止日期之前，苹果悄悄地试图在iOS上杀死Web应用程序，直到我们开放网络宣传，启用了一封信，与组织，公司，公司，包括欧洲MEP在内的5,000多个签名，包括欧洲MEP，敲响了警钟并阻止了苹果。因此，今年，在此DMA研讨会之前，Apple在iOS 26 Beta的情况下，安装Web应用程序变得更加困难，并将它们添加到主屏幕和隐藏中，功能，两个按钮按钮和菜单与以前的版本相比。那么，为什么Apple试图使其更难安装Web应用程序并尝试将其添加到主屏幕上？
Gary again:
加里再次：
So I think we’ll have to get back to the iOS 26 issue. That’s not something I’m aware of. And I think on the first issue, I do think there is a fundamental difference in terms of installability and what a user should know between an app that has gone through the thorough app review process, which has checked it across all the app store guidelines, run the code, examined how it worked, and then see what the experience is, check what privileges it wants to access, examined how it’s going to access them. To me, those things are different. And I think they’re different from a threat vector for users. And so I do think they’re going to have to operate slightly differently to make sure that users are not unintentionally installing something from the web that they simply don’t understand.
因此，我认为我们必须回到iOS 26问题。这不是我知道的。而且我认为在第一个问题上，我确实认为，在整个应用程序审核过程中，在所有应用程序审核过程中，用户应该了解的用户应了解什么，该应用程序已在所有App Store指南中进行了检查，运行代码，检查了代码，检查了它的工作原理，然后查看经验是什么，检查了哪些特权访问，检查了如何访问它可以访问它们的访问权限。对我来说，这些情况与众不同。而且我认为它们与用户的威胁向量不同。因此，我确实认为他们将不得不略有不同的操作，以确保用户不会无意中安装他们根本不了解的东西。
And that concludes my highlights from the day. Session 4 was on data portability, which is vital, but outside my primary interests.
这是我当天的亮点。第4节的数据可移植性是至关重要的，但不在我的主要利益之外。
My initial thoughts
我的最初想法
Apple made a few vague promises, but I expect those to be punted decades hence, as Apple gets its litigation leviathan prowling the depths of the Commission. Which is a shame, but leopards don’t change their spots.
苹果做出了一些模糊的承诺，但我希望这些承诺被刺穿了几十年，因此，随着苹果的诉讼勒维亚坦（Leviathan）在委员会的深处促进了诉讼。很可惜，但是豹子不会改变他们的景点。
There were a few occasions in the day when I suspected that the Apple representatives might be playing a game of saying spectacularly preposterous things, just to see if anyone noticed in the heat.
在一天，我怀疑苹果代表可能正在玩一个荒谬的事情的游戏，只是看看是否有人注意到了炎热。
For example, Andeer claims that it is
例如，安德尔声称这是
difficult to strike the right balance between privacy and security concerns and interoperability, as the Commission is acting without detailed input from the experts in the field who can weigh in with their deep knowledge… all the complex decisions on the trade-offs that must be weighed around interoperability are being made by those without the requisite ongoing technical knowledge in privacy and security.
很难在隐私问题和安全问题和互操作性之间取得适当的平衡，因为委员会在没有详细的意见的详细意见中行事，他们可以深入了解自己的知识……所有关于权衡的复杂决策必须由互操作性进行权衡，而互操作性的人则是由没有必要的私人与隐私和安全性的持续技术知识所必需的。
Alas, Apple did not disclose which independent experts it consults with, when it weighs up the trade-off between interoperability and security. Perhaps the EU and Apple could share the expertise of that particular totally independent third party?
las，苹果在权衡互操作性和安全性之间的权衡时，没有透露它与哪些独立专家进行咨询。也许欧盟和苹果可以分享那个完全独立的第三方的专业知识？
I was tempted to ask (but didn’t) whether Apple had considered asking some of the developers of MacOS to come and work for them. After all, I can install apps on my Mac without going through its AppStore – even those that contain non-WebKit engines! – yet simultaneously Apple claims MacOS is secure and private:
我很想问（但没有）苹果是否考虑要求Macos的一些开发人员来为他们工作。毕竟，我可以在Mac上安装应用程序，而无需浏览其AppStore，即使是包含非webkit引擎的应用程序！- 但同时苹果声称Macos是安全和私人的：
Designed to protect your privacy. Mac gives you the freedom to choose what you share and how you share it, so you can use apps more securely, protect your data, and keep yourself safer on the web… Advanced security comes standard on Mac. By integrating Mac with Apple silicon and macOS, Apple builds security protections into Mac from the ground up. Every Mac comes with industry-leading encryption and robust virus protections.
旨在保护您的隐私。Mac使您可以自由选择您共享的内容和共享方式，因此您可以更安全地使用应用程序，保护数据并在网络上保持更安全……高级安全性是Mac上的标准配置。通过将Mac与Apple Silicon和MacOS集成，Apple从头开始将安全保护构建到Mac中。每个Mac都有行业领先的加密和强大的病毒保护。
Linux, Windows, and Android are similar. Such magical Operating Systems! If only Apple knew how to contact MacOS developers.
Linux，Windows和Android相似。如此神奇的操作系统！如果只有苹果知道如何与MacOS开发人员联系。
Another fun part was when James Heppell (OWA) pointed out that he was not paid by anyone and, like the other two folks there from Open Web Advocacy, had travelled to Brussels and booked a hotel on his own dime:
另一个有趣的部分是，当詹姆斯·赫佩尔（James Heppell）（OWA）指出，他没有得到任何人的薪水，就像开放网络宣传中的其他两个人一样，他去了布鲁塞尔，并用自己的一角钱预订了一家酒店：
I’m just a student. I volunteer because I truly believe in the open web. I don’t get paid. I don’t receive any compensation. I paid for myself to be here because I want to be.
我只是一个学生。我志愿服务是因为我真正相信开放的网络。我没有得到报酬。我没有收到任何赔偿。我为自己付钱，因为我想成为。
Andeers replied, with fabulous condescension,
安德斯以神话般的屈服回答，
I am not in any way disparaging where you’re coming from. I understand you’re a well-meaning person who believes that he understands how to best design our operating system. I get that.
我不会以任何方式贬低您的来源。我了解您是一个善良的人，他认为他了解如何最好地设计我们的操作系统。我明白了。
My favourite Pinocchio-nasal-expansion moment was Apple’s Kylie Andeer claiming “You won’t see Apple telling any developers what to do in their app”. They probably wouldn’t be getting half of the regulatory attention they’re enjoying now if the App Store rules hadn’t imposed rule 2.5.6: “Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript”, or imperiously decreed that they must use Apple’s payment service.
我最喜欢的Pinocchio-Nasal-expansion时刻是苹果的凯莉·安德尔（Kylie Andeer）声称“您不会看到苹果告诉任何开发人员在他们的应用程序中该怎么做”。如果App Store规则没有规定规则2.5.6：“浏览网络的应用必须使用适当的WebKit框架和WebKit JavaScript”，他们可能不会获得他们现在所享受的监管关注的一半，或者否认他们必须使用Apple的付款服务。
The experience of attending online is very different from being there in person. Asking questions over Slido in only 280 characters is very hard. I wished that the Slido questions were asked in order of the number of upvotes they received.
在线参加的经验与亲自在那里大不相同。只用280个字符就Slido提出问题非常困难。我希望按照他们收到的高级投票数量提出Slido问题。
I didn’t especially like that the questions were bagged up into groups before the Gatekeepers answered; it made it easy to forget the details, or (gasp!) to evade them. Perhaps Gatekeepers should give shorter initial presentations, and questions answered one by one.
我并不特别喜欢在看门人回答之前将问题分组为小组。它很容易忘记细节，或者（喘息！）逃避它们。也许网守应该给出较短的初始演讲，并一一回答问题。
Lucia Bonova, Queen of the DMA, attempted to keep Apple to schedule, and moderated the day with good humour, continually mocking John Ozbay who frankly deserves it because he’s handsome, talented, fabulously wealthy yet an all-round good guy (the bastard).
DMA女王Lucia Bonova试图让Apple安排安排，并以幽默的幽默为主持，并不断嘲笑John Ozbay，后者坦率地说，因为他帅气，才华横溢，才华横溢，非常富有，却是一个全面的好人（Bastard）。
Stay tuned for my write-up of Google’s DMA Compliance workshop!
请继续关注我对Google的DMA合规研讨会的文章！
My unofficial transcripts
我的非正式成绩单
I made these transcripts using MacWhisper from the official video recording. I manually corrected the passages I quoted above, so those are more accurate than these raw transcripts. Apologies if the software or I mis-spelled a name!
我使用官方视频录音中的MacWhisper制作了这些笔录。我手动纠正了上面引用的段落，因此这些段落比这些原始成绩单更准确。如果软件或我错了一个名字，则表示歉意！
See also
参见
Apple’s Second DMA Compliance Workshop: An Aggressive Defence of Rights by Alba Ribera Martínez, Lecturer in Competition Law and Digital Markets Regulation
苹果的第二次DMA合规研讨会：竞争法和数字市场法规的讲师AlbaRiberaMartínez的积极辩护
Buy"Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
购买“呼唤月球”，这是我在印度泰国，土耳其居住时创作的首张歌曲。（在Bandcamp上只有2英镑。）
Leave a Reply
留下答复
