Post

Replies

Boosts

Views

Activity

Is MusicKit JS supported or permitted in headless Chromium on embedded Linux?
Hi, We are building a network audio device running embedded Linux (headless — no display, no user-facing browser UI). I'd like to clarify whether MusicKit JS can be used in this environment, both technically and from a licensing standpoint. Our setup Embedded Linux on ARM, no screen Headless Chromium running as a background service MusicKit JS loaded in a page to authenticate the user and play Apple Music Questions Is MusicKit JS supported in a headless browser context, or is it intended only for interactive, user-facing browser sessions? MusicKit JS requires a Developer Token with an origin claim, and a valid web origin. If the page is served locally on the device (e.g. http://127.0.0.1) with no public domain, what origin should be used? Is a local origin acceptable? Is embedding MusicKit JS inside device firmware — where the browser is never visible to the user and playback is not initiated through a normal browsing session — within the MusicKit terms of use? I want to confirm whether running MusicKit JS in headless Chromium would be considered an acceptable implementation。 For context: we are already MFi licensees with AirPlay 2 integrated. We simply want to be certain any additional work stays within the authorized scope. Any guidance — including a pointer to the relevant section of the MusicKit terms — would be much appreciated. Thanks in advance
1
0
30
13h
Is MusicKit JS supported or permitted in headless Chromium on embedded Linux?
Hi, We are building a network audio device running embedded Linux (headless — no display, no user-facing browser UI). I'd like to clarify whether MusicKit JS can be used in this environment, both technically and from a licensing standpoint. Our setup Embedded Linux on ARM, no screen Headless Chromium running as a background service MusicKit JS loaded in a page to authenticate the user and play Apple Music Questions Is MusicKit JS supported in a headless browser context, or is it intended only for interactive, user-facing browser sessions? MusicKit JS requires a Developer Token with an origin claim, and a valid web origin. If the page is served locally on the device (e.g. http://127.0.0.1) with no public domain, what origin should be used? Is a local origin acceptable? Is embedding MusicKit JS inside device firmware — where the browser is never visible to the user and playback is not initiated through a normal browsing session — within the MusicKit terms of use? I want to confirm whether running MusicKit JS in headless Chromium would be considered an acceptable implementation。 For context: we are already MFi licensees with AirPlay 2 integrated. We simply want to be certain any additional work stays within the authorized scope. Any guidance — including a pointer to the relevant section of the MusicKit terms — would be much appreciated. Thanks in advance
Replies
1
Boosts
0
Views
30
Activity
13h