.png)
4 months ago
7
Up the kriek: Apple gets punchy in Brussels DMA compliance workshop
Thursday 3 July 2025After 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.
Session 1: Interoperabiity
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:
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.
He gave several indications that Apple intends to litigate until the 29th century:
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.
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.
Indeed, the tactic of endlessly litigating is classic Apple; as its former General Counsel, Bruce Sewell explained to law students, they
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.
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
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.
John Ozbay, of Open Web Advocacy, asked about the process by which developers and other supplicants can request interoperability with 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 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.
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
(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?”)
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
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.
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:
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.
According to Apple, they didn’t have time to set up a Github/ Bugzilla system, and anyway, the system is working brilliantly:
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.
Session 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.
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.
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.
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:
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.
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:
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.
Session 3: browser choice architecture
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).
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,
we agree with Apple that the hot seat should be default on Android as well. So we will be raising this tomorrow.
Then, Roderick turned to the ridiculous terms Apple imposes on vendors who want to ship non-WebKit browsers:
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?
This wasn’t answered. Gary handwaved:
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.
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.
Frederick from riedel.wtf asked about APIs currently avalable to WebKit-based browsers (similar to mine about Parental Controls earlier):
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.
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.
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:
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?
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.
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!
Talking of developer woe, James Heppell of OWA asked
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?
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.
John “porn advocate” Ozbay of OWA asked a question that we’d jammed together before the meeting:
Last year, after we made a lot of noise to get Apple to reinstate homescreen web apps in the EU,
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?
Kyle was neither vague, nor encouraging; a sort of Francis Bacon to Gary’s Turner:
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.
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.
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?
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.
And that concludes my highlights from the day. Session 4 was on data portability, which is vital, but outside my primary interests.
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.
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?
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:
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.
Linux, Windows, and Android are similar. Such magical Operating Systems! If only Apple knew how to contact MacOS developers.
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:
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.
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.
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).
Stay tuned for my write-up of Google’s DMA Compliance workshop!
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!
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
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
